Subject: Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
From: Moshe Litvin <[email-masked]>
To: [email-masked]
Date: Wed, 1 Apr 1998 10:14:26 +0300

Peter Gutmann wrote:
>
> Moshe Litvin <[email-masked]> writes:
> >Peter Gutmann wrote:
> >>Since including certain extensions like
> >>basicConstraints, keyUsage, certificatePolicies, and a few others is
> >>pointless unless they're marked critical, I'm thinking of recommending that
> >>if used, these extensions must be marked critical.  What do people think
> >>about this?
>
> >I think that this prove the point, marking an extension as critical will
> >render it useless for a lot of software, you don't want to do it unless you
> >have a VERY good reason to do so.
>
> But if an extension isn't marked critical then by implication it's marked
> useless, because an implementation is free to ignore it.  For example:

Critical does not necessary mean important. The critical flag was meant
to be a backward compatibility flag - a way to add information to a
certificate without breaking existing applications.

Unless explicitly specified an application must process any extension it
understands regardless of the criticality flag. The criticality flag is
meant only for application that does not understand the specific
extension.

>
> >I suggest the we will should say that the the basicConstraints shouldn't be
> >marked critical on a CA's certificate.
>
> will make it possible for anyone to ignore the basicConstraints.  The whole
> point of having the constraints (basic, path, policy, etc) is to place some
> limits on what can be done with a certificate, but by making these extensions
> non-critical they also become non-constraints.

Consider a basicConstraint extension with ca=TRUE and no
pathLenConstraint. This extension means no constraints at all.
The ONLY effect of marking it as critical is to stop applications that
don't recognize that extension from processing the certificate, and
since that particular extension represent no constraint - why on earth
would you want that ??

>
> PKIX part 1 requires that compliant implementations handle a number of
> important constraint extensions, so there shouldn't be any problem in
> requiring that various constraints are marked critical.  At the moment the
> handling of constraints is very haphazard, because you can just ignore
> anything you don't like (basicConstraint = non-CA, keyUsage = keyEncipherment
> only, but you can ignore that and treat it as a CA cert for keyCertSigning if
> you want because the constraint extensions aren't critical).

No, No, No. A PKIX part 1 compliant application must support the
basicConstraint extension and therefore for a compliant application
there e is no difference weather the extension is marked critical or
not. It MUST process it any way.

The whole debate is how we tell non PKIX compliant applications that
don't support it if they can use the certificate or not.

> An alternative to this is to have a cert.policy which requires that all
> constraint extensions be processed and enforced, whether they're marked
> critical or not.

This IS the situation.

Moshe
--
-----------------------------------------------------------------------
Moshe Litvin                    Check Point Software Technologies Ltd.

[email-masked]            Tel:   +972-3-753-4601 (972-3-753-4555)
                                Fax:   +972-3-575-9256
-----------------------------------------------------------------------

Approved-By: [email-masked]
Date:         Tue, 31 Mar 1998 09:42:25 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
To: [email-masked]

--simple boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Description: "cc:Mail Note Part"

Moshe Litvin <[email-masked]> writes:
>Peter Gutmann wrote:
>>Since including certain extensions like
>>basicConstraints, keyUsage, certificatePolicies, and a few others is
>>pointless unless they're marked critical, I'm thinking of recommending that
>>if used, these extensions must be marked critical.  What do people think
>>about this?

>I think that this prove the point, marking an extension as critical will
>render it useless for a lot of software, you don't want to do it unless you
>have a VERY good reason to do so.

But if an extension isn't marked critical then by implication it's marked
useless, because an implementation is free to ignore it.  For example:

>I suggest the we will should say that the the basicConstraints shouldn't be
>marked critical on a CA's certificate.

will make it possible for anyone to ignore the basicConstraints.  The whole
point of having the constraints (basic, path, policy, etc) is to place some
limits on what can be done with a certificate, but by making these extensions
non-critical they also become non-constraints.  It's a bit like the
recommended 130kmh speed limit on autobahns (which are treated like
non-critical extensions), the theoretical limit is 130, you're sitting there
doing 180, and you're getting overtaken by Porsches and whatnot doing about
250.  It's not until you actually get police enforcing things (about 100m past
the Austrian border) that everyone slows down, and you get the effect of a
critical extension where you obey the rules or else.

PKIX part 1 requires that compliant implementations handle a number of
important constraint extensions, so there shouldn't be any problem in
requiring that various constraints are marked critical.  At the moment the
handling of constraints is very haphazard, because you can just ignore
anything you don't like (basicConstraint = non-CA, keyUsage = keyEncipherment
only, but you can ignore that and treat it as a CA cert for keyCertSigning if
you want because the constraint extensions aren't critical).  What would be
better is a requirement like:

  If the cert is a v3 cert then it must contain at least a basicConstraints
  extension, and if it contains <any certificate constraint extensions> then
  these must be marked critical.

or something similar.  Since an implementation must be able to handle these
extensions to comply with the standard, there shouldn't be any problems with
marking them critical.

An alternative to this is to have a cert.policy which requires that all
constraint extensions be processed and enforced, whether they're marked
critical or not.  Unfortunately in order to avoid allowing implementations to
ignore it if they feel so inclined, you need to mark it critical...

Peter.

--simple boundary--

Approved-By: [email-masked]
Date:         Tue, 31 Mar 1998 09:42:25 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Gutmann <[email-masked]>
Subject:      Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
Comments: To: [email-masked]
To: [email-masked]

Moshe Litvin <[email-masked]> writes:
>Peter Gutmann wrote:
>>Since including certain extensions like
>>basicConstraints, keyUsage, certificatePolicies, and a few others is
>>pointless unless they're marked critical, I'm thinking of recommending that
>>if used, these extensions must be marked critical.  What do people think
>>about this?

>I think that this prove the point, marking an extension as critical will
>render it useless for a lot of software, you don't want to do it unless you
>have a VERY good reason to do so.

But if an extension isn't marked critical then by implication it's marked
useless, because an implementation is free to ignore it.  For example:

>I suggest the we will should say that the the basicConstraints shouldn't be
>marked critical on a CA's certificate.

will make it possible for anyone to ignore the basicConstraints.  The whole
point of having the constraints (basic, path, policy, etc) is to place some
limits on what can be done with a certificate, but by making these extensions
non-critical they also become non-constraints.  It's a bit like the
recommended 130kmh speed limit on autobahns (which are treated like
non-critical extensions), the theoretical limit is 130, you're sitting there
doing 180, and you're getting overtaken by Porsches and whatnot doing about
250.  It's not until you actually get police enforcing things (about 100m past
the Austrian border) that everyone slows down, and you get the effect of a
critical extension where you obey the rules or else.

PKIX part 1 requires that compliant implementations handle a number of
important constraint extensions, so there shouldn't be any problem in
requiring that various constraints are marked critical.  At the moment the
handling of constraints is very haphazard, because you can just ignore
anything you don't like (basicConstraint = non-CA, keyUsage = keyEncipherment
only, but you can ignore that and treat it as a CA cert for keyCertSigning if
you want because the constraint extensions aren't critical).  What would be
better is a requirement like:

  If the cert is a v3 cert then it must contain at least a basicConstraints
  extension, and if it contains <any certificate constraint extensions> then
  these must be marked critical.

or something similar.  Since an implementation must be able to handle these
extensions to comply with the standard, there shouldn't be any problems with
marking them critical.

An alternative to this is to have a cert.policy which requires that all
constraint extensions be processed and enforced, whether they're marked
critical or not.  Unfortunately in order to avoid allowing implementations to
ignore it if they feel so inclined, you need to mark it critical...

Peter.

Approved-By: [email-masked]
Date:         Mon, 30 Mar 1998 09:52:17 +0100
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Francisco Jordan <[email-masked]>
Organization: UPC
Subject:      [IETF-PKIX] Error in draft-ietf-pkix-crmf-00.txt
To: [email-masked]

Martin,

the problem is due to the "draft-ietf-pkix-crmf-00.txt" document
in "Appendix C. ASN.1 Structures and OIDs" has an incorrect
specification for POPOSigningKey type, namely:

        POPOSigningKey ::= SEQUENCE {
                poposkInput           POPOSigningKeyInput OPTIONAL,
                algorithmIdentifier   AlgorithmIdentifier,
                signature             BIT STRING }

which conveys an ambiguity in "poposkInput" field.

Note that the same document in "5.4 Proof of Possession Syntax"
specifies a correct syntax, namely:

        POPOSigningKey ::= SEQUENCE {
                poposkInput         [0] POPOSigningKeyInput OPTIONAL,
                algorithmIdentifier     AlgorithmIdentifier,
                signature               BIT STRING }

Please fix yourself the bug and I will send you the new version
including the other stuff asap.

Best Regards,
Francisco Jordan

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 30 Mar 1998 10:14: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:      Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
Comments: To: [email-masked]
To: [email-masked]

This is somewhat tangential, but we have a case where we would like to go to an external CA to replace a certificate which was previously issued by our CA toolkit for internal use.

In other words, our PKIS CA toolkit will allow a user to set up his installation for internal use, generate certificates for servers, etc. However, the toolkit doesn't really know what the customer's organization name is, so there is no due diligence.  If and when the organization wishes to make his facilities available to the outside world, they don't want to have to reissue all of the subordinate certificates, but instead wants to have a public CA (one whose root is widely known) issue a replacement certificate.

We can issue a certificate signing request containing the public key and all of the other attributes, but we would also like to include the serial number, so that upwards references (Subject to Issuer) will be correct.  Assuming that we guarantee a machine-unique serial number, is there anything wrong with including the Serial in the attributes field in PKCS 10?

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Peter Gutmann <[email-masked]> 03/29 11:55 AM >>>
While making some long-overdue updates to the X.509 style guide, I saw that the
section on PKCS #10 use might need some corrections.  This currently says:

  According to the PKCS #10 spec, the attributes field is mandatory, so if it's
  empty it's encoded as a zero-length field.  The example however assumes that
  if there are no attributes, the field shouldn't be present, treating it like
  an OPTIONAL field.  A number of vendors conform to the example rather than
  the specification, but just to confuse the issue RSADSI, who produced PKCS
  #10, regard things the other way around, with the spec being right and the
  example being wrong.  The most obvious effect of this is that TIPEM (which
  was the only available toolkit for PKCS#10 for a long time) follows the spec
  and does it "wrong (sense #2)", whereas more recent independant
  implementations follow the example and do it "wrong (sense #1)".

  PKCS #10 also dates from the days of X.509v1 and includes references to
  obsolete and deprecated objects and data formats.  PKCS #6 extended
  certificates are a workaround for the abscence of certificate extensions in
  X.509v1 and shouldn't be used at all, and it's probably a good idea to avoid
  the use of PKCS #9 extended attributes as well (some certification request
  protocols bypass the use of PKCS #9 by wrapping extra protocol layers
  containing PKCS #9 elements around the outside of PKCS #10).  Unfortunately
  since PKCS #10 doesn't mention X.509v3 at all, there's no clear indication of
  what is and isn't valid as an attribute for X.509v3 (for example a
  GeneralName should be treated as a valid attribute, a BasicConstraint may or
  may not be treated as valid depending on the CA's certification policy, and
  an AuthorityKeyIdentifier would definitely be an invalid attribute).

  To add to the confusion, the S/MIME certificate request draft states that
  X.509v3 extensions used as attributes in a certification request should be
  encoded as a SEQUENCE OF extensions wrapped up in a PKCS #9 attribute
  identified by the OID { pkcs-9 14 }.

Unfortunately I haven't been able to find anything which clears up the
confusion over either the encoding of the attributes field, or the use of
X.509v3 extensions.  Is anyone aware of implementations which still encode the
attributes as if they were declared 'Attributes OPTIONAL'?  Everything I've
seen recently always encodes the attributes as a zero-length field, however
being outside the US I can't check what most of the commonly-available
implementations do.  Should I recommend that they always be encoded as per the
spec and drop the section on encoding as per the example entirely?  (NB: I know
what the official position on this is, what I'd like to know is what it's like
in practice).

The other area of confusion is what's in the attributes.  PKCS #10 still refers
to the deprecated PKCS #6 extended certificates, as well as PKCS #9 extended
attributes, but not X.509v3 attributes/extensions which would probably be more
useful.  If I could get some indication of usage of X.509v3 attributes in a
certification request I'd like to add some comments on it to the guide -
because PKCS #10 predates the various v3 attributes you often have to resort to
guesswork to find out what is and isn't acceptable.  Are the comments in the
text above appropriate?  How should X.509v3 attributes be specified, as per the
S/MIME draft or directly as attributes (without the PKCS #9 wrapping)?  What
attributes are valid?  What ones are used in practice?

On the subject of extensions, the guide currently makes some rather vague
comments about handling extensions.  Looking through the X.509v3, S/MIME, and
PKIX cert-related drafts, I've noticed that the recommendations in there about
handling the critical flag are even more vague, since if the critical flag
isn't set most of the extensions are meant to be of an advisory nature only.
This means that an implementation could conceivably handle them with:

 1. If extension is critical and unrecognised, cert = invalid.
 2. If extension is noncritical, ignore it.

which relegates all noncritical extensions to communicating the message "I'm
only including this to bloat up the cert" (very few of the certs I've got have
their extensions marked as critical, in playing with MSIE and Netscape I've
found that doing this renders some certs unusable by both browsers).  For
instance consider the <anonymous CA> root cert, which is marked, via a keyUsage
extension, as being for cert and CRL signing only.  Since it's non-critical,
I'm free to ignore this and use it for key exchange, encryption, and whatever
else I please.

The problem lies in the nature of the critical flag (and I know this has been
debated before, but it was never really resolved).  At the moment it's used as:

 Critical = you must process this extension
 Non-critical = you don't have to process this extension

However "you don't have to process this extension" leaves implementors free to
either process it anyway or ignore it.  What complicates this issue is that
various standards leave the question of criticality up to implementors ("it
would be cool if you made this critical, but don't like, feel any pressure to
do so", or words to that effect).  Since including certain extensions like
basicConstraints, keyUsage, certificatePolicies, and a few others is pointless
unless they're marked critical, I'm thinking of recommending that if used,
these extensions must be marked critical.  What do people think about this?

Peter.

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 30 Mar 1998 09:56: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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] [CERT-TALK] Subject line tag
To: [email-masked]

I strongly agree.  I've been nailed a couple of times, on this list and
elsewhere. So have others on this list. It's embarrassing, to say the least.

And while were at it, could they PLEASE stop modifying the text type from
quoted-printable to 8-bit? There is no justification for doing so, and
it forces me to manually insert carriage returns in every line.

Bob

>Far worse, for me, is the substitution of the list in the Reply-to field,
>which causes extra manual effort to reply to the sender of a message, and
>has tricked numerous people into sending to the list when they meant to
>reply to the sender privately, since before it was reconfigured you could
>simply reply-to-sender or reply-to-all depending on whether or not you
>wanted the list involved.
>
>I took this up privately with the list administrators, but they disagreed.
>Since no one else seemed to have a problem, I let it drop, but maybe there's
>some interest in this also...
>
>brian
>
>Brian Thomas, CISSP - Distributed Systems Architect  [email-masked]
>Southwestern Bell                                    [email-masked]
>One Bell Center,  Room 34G3                          Tel: 314 235 3141
>St. Louis, MO 63101                                  Fax: 314 235 0162
>
>
>
>> I agree with Michael, and wonder if the configuration of the PKIX list
>> server could be modified to stop putting this annoying chaff in it's
>> subject lines.
>>
>> The response time of the new list server is great, but it's munging of
>> email header fields is annoying.  Can we keep the horsepower and ditch
>> the twiddling?

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  Moshe Litvin <[email-masked]>
Date:         Mon, 30 Mar 1998 09:46:23 +0300
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: Moshe Litvin <[email-masked]>
Subject:      Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
To: [email-masked]

Peter Gutmann wrote:

> Since including certain extensions like
> basicConstraints, keyUsage, certificatePolicies, and a few others is pointless
> unless they're marked critical, I'm thinking of recommending that if used,
> these extensions must be marked critical.  What do people think about this?

In the same message he also wrote:

>  (very few of the certs I've got have
> their extensions marked as critical, in playing with MSIE and Netscape I've
> found that doing this renders some certs unusable by both browsers).

I think that this prove the point, marking an extension as critical will
render it useless for a lot of software, you don't want to do it unless
you have a VERY good reason to do so.

About the basicConstraints extension (from pkix-ipki-part1-07)

  This profile requires the use of this extension, and it shall always
  be critical for CA certificates.

Suppose we have an application that does not understand that extension,
therefore he must assume that every certificate can act as a CA
certificate and validate other certificate. It now gets a certificate
with a basicConstraints extension with cA=TRUE and no pathLenConstraint,
which means that it is a CA certificate with no limit on the number of
CA certificate that can follows. It exactly what the application assumed
about the certificate but it can't use it because the extension was
marked critical.

We really want to stop an application from using a non-CA certificate as
a CA certificate, but to do that we must put the critical extension on
the end entity extension.

I suggest the we will should say that the the basicConstraints shouldn't
be marked critical on a CA's certificate.

Moshe
--
-----------------------------------------------------------------------
Moshe Litvin                    Check Point Software Technologies Ltd.

[email-masked]            Tel:   +972-3-753-4601 (972-3-753-4555)
                                Fax:   +972-3-575-9256
-----------------------------------------------------------------------

Approved-By:  "Pawluk, Jean" <[email-masked]>
Date:         Sun, 29 Mar 1998 17:03:32 -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: "Pawluk, Jean" <[email-masked]>
Subject:      [IETF-PKIX] PLEASE FIX
To: [email-masked]

Would whoever is sending mail to :

  [email-masked]

  [email-masked]

  fou                      at novell.com
  allen long           at novell.com

  [email-masked]

PLEASE remove these people from your email lists or forwarders since
they are not on the IETF-PKIX mailing list.  Thier address are invalid
and are returning numerous mail errors to the PKIX mailbox.

 Thanks in advance,

 Jean

Some of  details extracted from the mail error messages
----------------------------------------------------------------------
--> Error description:
Error-For:  [email-masked]
Error-Code: 0
Error-Text: 550 User unknown

----------------------------------------------------------------------
     ----- The following addresses had permanent fatal errors -----
<[email-masked]>
    (expanded from: <[email-masked]>)
----------------------------------------------------------------------
The mail you sent could not be delivered to:

fou

The user/address is either incorrect or no longer valid in Novell's mail
system.  Please check the address and resend.
----------------------------------------------------------------------
The mail you sent could not be delivered to:

allen_long

The user/address is either incorrect or no longer valid in Novell's mail
system.  Please check the address and resend.
----------------------------------------------------------------------
   ----- The following addresses had permanent fatal errors -----
<[email-masked]>
    (expanded from: <[email-masked]>)

Approved-By: [email-masked]
Date:         Sun, 29 Mar 1998 10:55:23 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Gutmann <[email-masked]>
Subject:      [IETF-PKIX] Questions about PKCS #10 and cert extensions
To: [email-masked]

While making some long-overdue updates to the X.509 style guide, I saw that the
section on PKCS #10 use might need some corrections.  This currently says:

  According to the PKCS #10 spec, the attributes field is mandatory, so if it's
  empty it's encoded as a zero-length field.  The example however assumes that
  if there are no attributes, the field shouldn't be present, treating it like
  an OPTIONAL field.  A number of vendors conform to the example rather than
  the specification, but just to confuse the issue RSADSI, who produced PKCS
  #10, regard things the other way around, with the spec being right and the
  example being wrong.  The most obvious effect of this is that TIPEM (which
  was the only available toolkit for PKCS#10 for a long time) follows the spec
  and does it "wrong (sense #2)", whereas more recent independant
  implementations follow the example and do it "wrong (sense #1)".

  PKCS #10 also dates from the days of X.509v1 and includes references to
  obsolete and deprecated objects and data formats.  PKCS #6 extended
  certificates are a workaround for the abscence of certificate extensions in
  X.509v1 and shouldn't be used at all, and it's probably a good idea to avoid
  the use of PKCS #9 extended attributes as well (some certification request
  protocols bypass the use of PKCS #9 by wrapping extra protocol layers
  containing PKCS #9 elements around the outside of PKCS #10).  Unfortunately
  since PKCS #10 doesn't mention X.509v3 at all, there's no clear indication of
  what is and isn't valid as an attribute for X.509v3 (for example a
  GeneralName should be treated as a valid attribute, a BasicConstraint may or
  may not be treated as valid depending on the CA's certification policy, and
  an AuthorityKeyIdentifier would definitely be an invalid attribute).

  To add to the confusion, the S/MIME certificate request draft states that
  X.509v3 extensions used as attributes in a certification request should be
  encoded as a SEQUENCE OF extensions wrapped up in a PKCS #9 attribute
  identified by the OID { pkcs-9 14 }.

Unfortunately I haven't been able to find anything which clears up the
confusion over either the encoding of the attributes field, or the use of
X.509v3 extensions.  Is anyone aware of implementations which still encode the
attributes as if they were declared 'Attributes OPTIONAL'?  Everything I've
seen recently always encodes the attributes as a zero-length field, however
being outside the US I can't check what most of the commonly-available
implementations do.  Should I recommend that they always be encoded as per the
spec and drop the section on encoding as per the example entirely?  (NB: I know
what the official position on this is, what I'd like to know is what it's like
in practice).

The other area of confusion is what's in the attributes.  PKCS #10 still refers
to the deprecated PKCS #6 extended certificates, as well as PKCS #9 extended
attributes, but not X.509v3 attributes/extensions which would probably be more
useful.  If I could get some indication of usage of X.509v3 attributes in a
certification request I'd like to add some comments on it to the guide -
because PKCS #10 predates the various v3 attributes you often have to resort to
guesswork to find out what is and isn't acceptable.  Are the comments in the
text above appropriate?  How should X.509v3 attributes be specified, as per the
S/MIME draft or directly as attributes (without the PKCS #9 wrapping)?  What
attributes are valid?  What ones are used in practice?

On the subject of extensions, the guide currently makes some rather vague
comments about handling extensions.  Looking through the X.509v3, S/MIME, and
PKIX cert-related drafts, I've noticed that the recommendations in there about
handling the critical flag are even more vague, since if the critical flag
isn't set most of the extensions are meant to be of an advisory nature only.
This means that an implementation could conceivably handle them with:

 1. If extension is critical and unrecognised, cert = invalid.
 2. If extension is noncritical, ignore it.

which relegates all noncritical extensions to communicating the message "I'm
only including this to bloat up the cert" (very few of the certs I've got have
their extensions marked as critical, in playing with MSIE and Netscape I've
found that doing this renders some certs unusable by both browsers).  For
instance consider the <anonymous CA> root cert, which is marked, via a keyUsage
extension, as being for cert and CRL signing only.  Since it's non-critical,
I'm free to ignore this and use it for key exchange, encryption, and whatever
else I please.

The problem lies in the nature of the critical flag (and I know this has been
debated before, but it was never really resolved).  At the moment it's used as:

 Critical = you must process this extension
 Non-critical = you don't have to process this extension

However "you don't have to process this extension" leaves implementors free to
either process it anyway or ignore it.  What complicates this issue is that
various standards leave the question of criticality up to implementors ("it
would be cool if you made this critical, but don't like, feel any pressure to
do so", or words to that effect).  Since including certain extensions like
basicConstraints, keyUsage, certificatePolicies, and a few others is pointless
unless they're marked critical, I'm thinking of recommending that if used,
these extensions must be marked critical.  What do people think about this?

Peter.

Approved-By:  Andy Nourse <[email-masked]>
Date:         Fri, 27 Mar 1998 17:21: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: Andy Nourse <[email-masked]>
Subject:      [IETF-PKIX] Archives?
To: [email-masked]

Where is this list archived?
The location in the homepage isn't it.

Andy Nourse - Cisco Systems

Approved-By:  Paul Koning <[email-masked]>
Date:         Fri, 27 Mar 1998 17:17: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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] [CERT-TALK] Subject line tag
To: [email-masked]

>>>>> "Brian" == Brian M Thomas <[email-masked]> writes:

 Brian> Far worse, for me, is the substitution of the list in the
 Brian> Reply-to field, which causes extra manual effort to reply to
 Brian> the sender of a message, and has tricked numerous people into
 Brian> sending to the list when they meant to reply to the sender
 Brian> privately, since before it was reconfigured you could simply
 Brian> reply-to-sender or reply-to-all depending on whether or not
 Brian> you wanted the list involved.

 Brian> I took this up privately with the list administrators, but
 Brian> they disagreed.  Since no one else seemed to have a problem, I
 Brian> let it drop, but maybe there's some interest in this also...

YES!

This is the only mailer I've ever seen that does this and it's really
annoying.

        paul

Approved-By:  "Brian M. Thomas" <[email-masked]>
Date:         Fri, 27 Mar 1998 15:44: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] [CERT-TALK] Subject line tag
To: [email-masked]

Far worse, for me, is the substitution of the list in the Reply-to field,
which causes extra manual effort to reply to the sender of a message, and
has tricked numerous people into sending to the list when they meant to
reply to the sender privately, since before it was reconfigured you could
simply reply-to-sender or reply-to-all depending on whether or not you
wanted the list involved.

I took this up privately with the list administrators, but they disagreed.
Since no one else seemed to have a problem, I let it drop, but maybe there's
some interest in this also...

brian

Brian Thomas, CISSP - Distributed Systems Architect  [email-masked]
Southwestern Bell                                    [email-masked]
One Bell Center,  Room 34G3                          Tel: 314 235 3141
St. Louis, MO 63101                                  Fax: 314 235 0162

> I agree with Michael, and wonder if the configuration of the PKIX list
> server could be modified to stop putting this annoying chaff in it's
> subject lines.
>
> The response time of the new list server is great, but it's munging of
> email header fields is annoying.  Can we keep the horsepower and ditch
> the twiddling?
>
>
>
> ----- Begin Included Message -----
>
> To: [email-masked]
> Subject: Re: [CERT-TALK] Subject line tag
> Date: Fri, 27 Mar 1998 08:31:26 -0800
> From: Michael Helm <[email-masked]>
>
> > > I wonder if Cert Talk subscribers, like the E-CARM list, could tag their
> > > subject lines (as above) to help us all manage our in-boxes?
>
> Please, NO!  Don't fill the most significant bits of the
> subject line with chaff (unless you have a secret message
> in there you want me to look for).  If you need something
> to sort on, you _can_ use the information you already have; I suggest
> the first line:
>
>   From [email-masked] ...
> but the to: & cc: lines may work.
>
> There's nothing sillier than a folder of mail like this:
>
> ssh:fionn% scan +ECARM | tail
>  268  03/25 Ben Wright         [E-CARM] Making PKI signatues legal<<The US Gene
>  269  03/26 Ed Gerck           Re: [E-CARM] Making PKI signatues legal<<On Wed,
>  270  03/27*Self <Single-user  Re: [E-CARM] Making PKI signatues legal<<Date se
>  271  03/25 Judie Mulholland   [E-CARM] What's New in The 2BGuide<<fyi/j <snip>
>  272  03/26 pj ponder          [E-CARM] Incorrect attribution here in one of my
>  273  03/26 "William H. Geige  [E-CARM] Failed signature<<- -----BEGIN PGP SIGN
>  274  03/26 Judie Mulholland   Re: [E-CARM] Failed signature<<there is somethin
>  275  03/26 matthew@nablewest  Re: [E-CARM] Failed signature<<Dear Sirs- I too
>  276  03/26 listmanager@orang  [E-CARM] Call for Founders: Digital Bearer Settl
>  277  03/27 Judie Mulholland   [E-CARM] TKR-NEWSLETTER<<fyi/j - ---------- Forw
>
> It's a petty annoyance, but it's an annoyance; in a busy list
> I don't want to be scanning that useless tag all the time when
> making the decision about whether or not this message is something
> I should read.
>
> ----- End Included Message -----
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 27 Mar 1998 14:00:24 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] [CERT-TALK] Subject line tag
To: [email-masked]

I agree with Michael, and wonder if the configuration of the PKIX list
server could be modified to stop putting this annoying chaff in it's
subject lines.

The response time of the new list server is great, but it's munging of
email header fields is annoying.  Can we keep the horsepower and ditch
the twiddling?

----- Begin Included Message -----

To: [email-masked]
Subject: Re: [CERT-TALK] Subject line tag
Date: Fri, 27 Mar 1998 08:31:26 -0800
From: Michael Helm <[email-masked]>

> > I wonder if Cert Talk subscribers, like the E-CARM list, could tag their
> > subject lines (as above) to help us all manage our in-boxes?

Please, NO!  Don't fill the most significant bits of the
subject line with chaff (unless you have a secret message
in there you want me to look for).  If you need something
to sort on, you _can_ use the information you already have; I suggest
the first line:

  From [email-masked] ...
but the to: & cc: lines may work.

There's nothing sillier than a folder of mail like this:

ssh:fionn% scan +ECARM | tail
 268  03/25 Ben Wright         [E-CARM] Making PKI signatues legal<<The US Gene
 269  03/26 Ed Gerck           Re: [E-CARM] Making PKI signatues legal<<On Wed,
 270  03/27*Self <Single-user  Re: [E-CARM] Making PKI signatues legal<<Date se
 271  03/25 Judie Mulholland   [E-CARM] What's New in The 2BGuide<<fyi/j <snip>
 272  03/26 pj ponder          [E-CARM] Incorrect attribution here in one of my
 273  03/26 "William H. Geige  [E-CARM] Failed signature<<- -----BEGIN PGP SIGN
 274  03/26 Judie Mulholland   Re: [E-CARM] Failed signature<<there is somethin
 275  03/26 matthew@nablewest  Re: [E-CARM] Failed signature<<Dear Sirs- I too
 276  03/26 listmanager@orang  [E-CARM] Call for Founders: Digital Bearer Settl
 277  03/27 Judie Mulholland   [E-CARM] TKR-NEWSLETTER<<fyi/j - ---------- Forw

It's a petty annoyance, but it's an annoyance; in a busy list
I don't want to be scanning that useless tag all the time when
making the decision about whether or not this message is something
I should read.

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

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Fri, 27 Mar 1998 09:32:59 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
Subject:      Re: [IETF-PKIX] Patent 5699431
To: [email-masked]

"David P. Kemp" writes:
> > From: "Perry E. Metzger" <[email-masked]>
> >
> > I'd say it is. The document is supposed to be self contained to some
> > extent. If you print it and get on an airplane to read, is it too much
> > to ask that a paragraph be there telling you why you would care about
> > this mysterious patent number?
>
>
> I apologize for the flip response.  Of course it would be helpful to
> include a sentence referring to the subject matter of the patent,
> something like "partitioning of revocation information".   But
> bibliographic references in general do not include abstracts, just
> sufficient information for the reader to fetch the information being
> referenced.

Actually, bibliographic references DO contain a micro-abstract: the
name of the paper in question, which is usually suggestive. A patent
number is *not* suggestive, however, and contains far less information
than the name of a paper would.

Perry

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 27 Mar 1998 08:51:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      [IETF-PKIX] Patent 5699431
To: [email-masked]

> From: "Perry E. Metzger" <[email-masked]>
>
> I'd say it is. The document is supposed to be self contained to some
> extent. If you print it and get on an airplane to read, is it too much
> to ask that a paragraph be there telling you why you would care about
> this mysterious patent number?

I apologize for the flip response.  Of course it would be helpful to
include a sentence referring to the subject matter of the patent,
something like "partitioning of revocation information".   But
bibliographic references in general do not include abstracts, just
sufficient information for the reader to fetch the information being
referenced.

I suspect that the lack of explanation is due to the fact that
including the patent abstract verbatim in the RFC might be viewed as
too wordy, and attempting to condense or paraphrase it might have legal
implications, or stir up debate over whether the proposed text is an
accurate summary of the claims.

Approved-By: [email-masked]
Date:         Thu, 26 Mar 1998 22:01:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA4OjIxOjE3UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBbSUVURi1QS0lYXSBNZXNzYWdlIFVuZGVsaXZl
cmFibGUgdG8gY2M6TWFpbA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLQ0K

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogUG9zdG1hc3RlciBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA3OjE0OjM2UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBbSUVURi1QS0lYXSBNZXNzYWdlIFVuZGVsaXZl
cmFibGUgdG8gY2M6TWFpbA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLQ0K

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authoriz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authoriz"

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogUG9zdG1hc3RlciBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_de~1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_de~1"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA2OjIzOjQ0UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBSZTogW0lFVEYtUEtJWF0gQ29tbWVudHMgb24g
RHJhZnQgQ01DLTAwDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tDQo=

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Author~1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Author~1"

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogbW15ZXJzQHZlcmlzaWduLmNvbV9hdF9J
TlRFUk5FVCBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov

Jim,

Thanks for taking the time to thoroughly review these drafts.  They help
considerably in moving the work products forward.  Some responses to your
comments:

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of Jim Schaad (Exchange)
> Sent: Wednesday, March 25, 1998 12:33 PM
> To: [email-masked]
> Subject: [IETF-PKIX] Comments on Draft CMC-00
>
>
> This is my first cut at comments about the CMC draft.  I think this still
> needs some work to make it usable in a general case solution.  I have many
> fewer comments on this draft at this point because a large point of it
> depends on getting clarifications for CRMF and CMMF first.

Agree.

>
> 1.  Section 3 - I don't think it is correct to call this a new CMS content
> type.  You are not defining this in the CMS specifiction.  Please use the
> sentence "This document defines a new content type PKIDATA.  This content
> type is used as an encapulsated content within the CMS security
> framework."

OK.

>
> 2.  Section 3.1, paragraph 2 -- I think you should really refer to this as
> "the familiar CMS (formerly PKCS7) degerate".

OK.

>
> 3.  Section 3.1 -- Please re-define id-pkiData in this section rather than
> puttin in the reference to PKIXCERT.

OK.

>
> 4.  Section 4.1, paragraph 3 -- The use of MailListKeyIdentifier in this
> draft should be strongly discuraged.  This is for sending
> encrypted messages
> to a DL and MUST NOT be used for PKI work.

Mailing lists could be used to broadcast revocation information and CA key
updates.

>
> 5.  Section 4.2 - Since we are using CMS as the basis of the
> Crypto in this
> document.  Please change the reference of how signatures and key
> exchange is
> to be done from the PKIXCERT documents to the CMS document.  I
> don't want to
> have to have a CMS implemention with two different types of
> algorithms just
> because the two documents are not in 100% agreement.

This makes sense.  However we should make certain that both works are
aligned since it affects interoperability in the more general case.

>
> 6.  Section 4.4, paragraph 2 - The procedure in the second paragraph not
> very clear. I see nothing in section 4.3 about enveloping as an
> id-pKIData.
> It discusses EnvelopedData and SignedData but not PKIdata -- did
> you mean a
> different section?

The phrase " . . . as defined in section 4.3 . . ." should be deleted.  The
third paragraph in this section speaks to the requirements directly.

>
> 7.  Section 4.4, paragraph 3 - Change the section reference from
> 5.3 to 4.3

OK.

>
> 8.  Section 4.4 in the Encryption Option 1:  (I may have mislead
> you on this
> one)  It should be as follows:
>         signedData.AuthencatedAttributes.contentType  <- id-envelopedData
>         signedData.AuthencatedAttributes.contentHint   <- id-pkiData

OK.

>
> 9. Section 4.5, paragraph 2, bullet 1:  This should be refering to the
> content-hint attribute not the content-type attribute.  This is
> the correct
> property to say what the innermost content is.  Signature validation will
> fail if you change the content-type attribute.

OK.

>
> 10.  Section 4.8.1 paragraph 2 - In the last sentence I am not sure if you
> really mean that the subject name should be encoded as an empty
> sequence or
> as a missing property.  Which do you mean?

Empty sequence.  The subject Name is not OPTIONAL in a PKCS10:

CertificationRequestInfo ::= SEQUENCE {
  version Version,
  subject Name,
  subjectPublicKeyInfo SubjectPublicKeyInfo,
  attributes [0] IMPLICIT Attributes }

>
> 11.  Section 4.8.5 - Should GetCert have a mode which returns the chain of
> certificates rather than just a single certificate.

Sending back a chain is implied by specification of CertRep as a response
which does accomodate sending back the chain.  CMC currently reads " . . . a
SignedData response containing the requested certificate . . .".  I'll add
"As noted in CMMF, this response MUST contain a single certificate and
SHOULD include other certificates which link the issuer to higher level
certification authorities."

>
> 12. Section 4.8.7 - I don't care if the mesage format for a RevReq is not
> covered by CMS -- can we still state something good here about how it is
> sent to the server and the server recognizes this?  The concept of local
> implementation does not help the world with internet access, just small
> conclaves.

In re-reading this, I agree that the sentence "The structure of an unsigned
. . . RevReq . . . is a matter of local implementation." is too loose to
ensure interoperability.  It's probably best to clarify this text by cases:

1.  The use of CMS in the case of RA-authenticated revocation request is
clear cut.

2.  For the case of a end-user initiated revocation request in instances
when the end-entity's private key is reliable and available, CMS is equally
useful to authenticate the request.

3.  It is the case where either the end-entity's private key is either
unreliable (e.g. compromise) or not available (e.g. token broke, forgot
password, etc.).  As a strawman I would propose specification of an
unencapsulated CertRep that SHALL contain the passphrase.

>
> 13.  General Comment:  I would like to see an additional content type
> defined which would address one of the needs that I can see.  I want to be
> able to return more than one CMMF body in a single message.  Thus
> I propose
> that we add a new message type of XX (to be assigned).  The body of this
> message type will be:
>
>         MultipleResponse ::= SEQUENCE OF ContentInfo
>
> Where one or more signed items each containing a different response may be
> included.  This will allow me to return both a CertRepContent,
> KeyRecRepContent and some additional messages as the same time in a single
> transaction.

A useful requirement, but the MultiResponse syntax should include
messageType, or are we thinking of two different encapsulation models?

>
> jim
>

Mike

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_ms~1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_ms~1"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov--

Approved-By: [email-masked]
Date:         Thu, 26 Mar 1998 20:21: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: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA3OjE0OjM2UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBbSUVURi1QS0lYXSBNZXNzYWdlIFVuZGVsaXZl
cmFibGUgdG8gY2M6TWFpbA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLQ0K

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogUG9zdG1hc3RlciBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA2OjIzOjQ0UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBSZTogW0lFVEYtUEtJWF0gQ29tbWVudHMgb24g
RHJhZnQgQ01DLTAwDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tDQo=

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authoriz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authoriz"

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogbW15ZXJzQHZlcmlzaWduLmNvbV9hdF9J
TlRFUk5FVCBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov

Jim,

Thanks for taking the time to thoroughly review these drafts.  They help
considerably in moving the work products forward.  Some responses to your
comments:

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of Jim Schaad (Exchange)
> Sent: Wednesday, March 25, 1998 12:33 PM
> To: [email-masked]
> Subject: [IETF-PKIX] Comments on Draft CMC-00
>
>
> This is my first cut at comments about the CMC draft.  I think this still
> needs some work to make it usable in a general case solution.  I have many
> fewer comments on this draft at this point because a large point of it
> depends on getting clarifications for CRMF and CMMF first.

Agree.

>
> 1.  Section 3 - I don't think it is correct to call this a new CMS content
> type.  You are not defining this in the CMS specifiction.  Please use the
> sentence "This document defines a new content type PKIDATA.  This content
> type is used as an encapulsated content within the CMS security
> framework."

OK.

>
> 2.  Section 3.1, paragraph 2 -- I think you should really refer to this as
> "the familiar CMS (formerly PKCS7) degerate".

OK.

>
> 3.  Section 3.1 -- Please re-define id-pkiData in this section rather than
> puttin in the reference to PKIXCERT.

OK.

>
> 4.  Section 4.1, paragraph 3 -- The use of MailListKeyIdentifier in this
> draft should be strongly discuraged.  This is for sending
> encrypted messages
> to a DL and MUST NOT be used for PKI work.

Mailing lists could be used to broadcast revocation information and CA key
updates.

>
> 5.  Section 4.2 - Since we are using CMS as the basis of the
> Crypto in this
> document.  Please change the reference of how signatures and key
> exchange is
> to be done from the PKIXCERT documents to the CMS document.  I
> don't want to
> have to have a CMS implemention with two different types of
> algorithms just
> because the two documents are not in 100% agreement.

This makes sense.  However we should make certain that both works are
aligned since it affects interoperability in the more general case.

>
> 6.  Section 4.4, paragraph 2 - The procedure in the second paragraph not
> very clear. I see nothing in section 4.3 about enveloping as an
> id-pKIData.
> It discusses EnvelopedData and SignedData but not PKIdata -- did
> you mean a
> different section?

The phrase " . . . as defined in section 4.3 . . ." should be deleted.  The
third paragraph in this section speaks to the requirements directly.

>
> 7.  Section 4.4, paragraph 3 - Change the section reference from
> 5.3 to 4.3

OK.

>
> 8.  Section 4.4 in the Encryption Option 1:  (I may have mislead
> you on this
> one)  It should be as follows:
>         signedData.AuthencatedAttributes.contentType  <- id-envelopedData
>         signedData.AuthencatedAttributes.contentHint   <- id-pkiData

OK.

>
> 9. Section 4.5, paragraph 2, bullet 1:  This should be refering to the
> content-hint attribute not the content-type attribute.  This is
> the correct
> property to say what the innermost content is.  Signature validation will
> fail if you change the content-type attribute.

OK.

>
> 10.  Section 4.8.1 paragraph 2 - In the last sentence I am not sure if you
> really mean that the subject name should be encoded as an empty
> sequence or
> as a missing property.  Which do you mean?

Empty sequence.  The subject Name is not OPTIONAL in a PKCS10:

CertificationRequestInfo ::= SEQUENCE {
  version Version,
  subject Name,
  subjectPublicKeyInfo SubjectPublicKeyInfo,
  attributes [0] IMPLICIT Attributes }

>
> 11.  Section 4.8.5 - Should GetCert have a mode which returns the chain of
> certificates rather than just a single certificate.

Sending back a chain is implied by specification of CertRep as a response
which does accomodate sending back the chain.  CMC currently reads " . . . a
SignedData response containing the requested certificate . . .".  I'll add
"As noted in CMMF, this response MUST contain a single certificate and
SHOULD include other certificates which link the issuer to higher level
certification authorities."

>
> 12. Section 4.8.7 - I don't care if the mesage format for a RevReq is not
> covered by CMS -- can we still state something good here about how it is
> sent to the server and the server recognizes this?  The concept of local
> implementation does not help the world with internet access, just small
> conclaves.

In re-reading this, I agree that the sentence "The structure of an unsigned
. . . RevReq . . . is a matter of local implementation." is too loose to
ensure interoperability.  It's probably best to clarify this text by cases:

1.  The use of CMS in the case of RA-authenticated revocation request is
clear cut.

2.  For the case of a end-user initiated revocation request in instances
when the end-entity's private key is reliable and available, CMS is equally
useful to authenticate the request.

3.  It is the case where either the end-entity's private key is either
unreliable (e.g. compromise) or not available (e.g. token broke, forgot
password, etc.).  As a strawman I would propose specification of an
unencapsulated CertRep that SHALL contain the passphrase.

>
> 13.  General Comment:  I would like to see an additional content type
> defined which would address one of the needs that I can see.  I want to be
> able to return more than one CMMF body in a single message.  Thus
> I propose
> that we add a new message type of XX (to be assigned).  The body of this
> message type will be:
>
>         MultipleResponse ::= SEQUENCE OF ContentInfo
>
> Where one or more signed items each containing a different response may be
> included.  This will allow me to return both a CertRepContent,
> KeyRecRepContent and some additional messages as the same time in a single
> transaction.

A useful requirement, but the MultiResponse syntax should include
messageType, or are we thinking of two different encapsulation models?

>
> jim
>

Mike

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov--

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Thu, 26 Mar 1998 16:47:05 -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: Tony Bartoletti <[email-masked]>
Comments: To: [email-masked]
To: [email-masked]

At 06:59 PM 3/26/98 -0500, you wrote:
>"David P. Kemp" writes:
>> > > >Note: Implementors of this protocol should consider the
applicability of
> the
>> > > following patent(s): US patent no. 5,699,431
>> >
>> > Would there be something wrong with including enough text from the
>> > patent that someone would know WHY they would want to examine it?
>>
>>
>> I guess it's too much to expect that everyone knows to get patent
>> information from http://www.patents.ibm.com/details?patent_number=5699431,
>
>I'd say it is. The document is supposed to be self contained to some
>extent. If you print it and get on an airplane to read, is it too much
>to ask that a paragraph be there telling you why you would care about
>this mysterious patent number?
>
>And what if IBM stops providing this free service?
>
>Perry

I concur.  After reading through the "20 claims" and several references,
I would still need to hire a patent lawyer to give me any clue at all.

Just what is so "innovative" here that I should move with caution in
developing, deploying (or commercializing) something.

Why do I feel like patenting the method of Pythagorus' Theorem, citing
existing patents for addition, subtraction, squares and roots used in
this novel method for determining distances?

"Note:  Implementors of mathematical functions should consider the
 applicability of the following patents:  ..."

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By: [email-masked]
Date:         Thu, 26 Mar 1998 19:14: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: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]

------ =_0_MIME_Boundary_27088.351aef82.im52390m.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA2OjIzOjQ0UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBSZTogW0lFVEYtUEtJWF0gQ29tbWVudHMgb24g
RHJhZnQgQ01DLTAwDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tDQo=

------ =_0_MIME_Boundary_27088.351aef82.im52390m.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogbW15ZXJzQHZlcmlzaWduLmNvbV9hdF9J
TlRFUk5FVCBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351aef82.im52390m.hqrtmta1.doe.gov

Jim,

Thanks for taking the time to thoroughly review these drafts.  They help
considerably in moving the work products forward.  Some responses to your
comments:

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of Jim Schaad (Exchange)
> Sent: Wednesday, March 25, 1998 12:33 PM
> To: [email-masked]
> Subject: [IETF-PKIX] Comments on Draft CMC-00
>
>
> This is my first cut at comments about the CMC draft.  I think this still
> needs some work to make it usable in a general case solution.  I have many
> fewer comments on this draft at this point because a large point of it
> depends on getting clarifications for CRMF and CMMF first.

Agree.

>
> 1.  Section 3 - I don't think it is correct to call this a new CMS content
> type.  You are not defining this in the CMS specifiction.  Please use the
> sentence "This document defines a new content type PKIDATA.  This content
> type is used as an encapulsated content within the CMS security
> framework."

OK.

>
> 2.  Section 3.1, paragraph 2 -- I think you should really refer to this as
> "the familiar CMS (formerly PKCS7) degerate".

OK.

>
> 3.  Section 3.1 -- Please re-define id-pkiData in this section rather than
> puttin in the reference to PKIXCERT.

OK.

>
> 4.  Section 4.1, paragraph 3 -- The use of MailListKeyIdentifier in this
> draft should be strongly discuraged.  This is for sending
> encrypted messages
> to a DL and MUST NOT be used for PKI work.

Mailing lists could be used to broadcast revocation information and CA key
updates.

>
> 5.  Section 4.2 - Since we are using CMS as the basis of the
> Crypto in this
> document.  Please change the reference of how signatures and key
> exchange is
> to be done from the PKIXCERT documents to the CMS document.  I
> don't want to
> have to have a CMS implemention with two different types of
> algorithms just
> because the two documents are not in 100% agreement.

This makes sense.  However we should make certain that both works are
aligned since it affects interoperability in the more general case.

>
> 6.  Section 4.4, paragraph 2 - The procedure in the second paragraph not
> very clear. I see nothing in section 4.3 about enveloping as an
> id-pKIData.
> It discusses EnvelopedData and SignedData but not PKIdata -- did
> you mean a
> different section?

The phrase " . . . as defined in section 4.3 . . ." should be deleted.  The
third paragraph in this section speaks to the requirements directly.

>
> 7.  Section 4.4, paragraph 3 - Change the section reference from
> 5.3 to 4.3

OK.

>
> 8.  Section 4.4 in the Encryption Option 1:  (I may have mislead
> you on this
> one)  It should be as follows:
>         signedData.AuthencatedAttributes.contentType  <- id-envelopedData
>         signedData.AuthencatedAttributes.contentHint   <- id-pkiData

OK.

>
> 9. Section 4.5, paragraph 2, bullet 1:  This should be refering to the
> content-hint attribute not the content-type attribute.  This is
> the correct
> property to say what the innermost content is.  Signature validation will
> fail if you change the content-type attribute.

OK.

>
> 10.  Section 4.8.1 paragraph 2 - In the last sentence I am not sure if you
> really mean that the subject name should be encoded as an empty
> sequence or
> as a missing property.  Which do you mean?

Empty sequence.  The subject Name is not OPTIONAL in a PKCS10:

CertificationRequestInfo ::= SEQUENCE {
  version Version,
  subject Name,
  subjectPublicKeyInfo SubjectPublicKeyInfo,
  attributes [0] IMPLICIT Attributes }

>
> 11.  Section 4.8.5 - Should GetCert have a mode which returns the chain of
> certificates rather than just a single certificate.

Sending back a chain is implied by specification of CertRep as a response
which does accomodate sending back the chain.  CMC currently reads " . . . a
SignedData response containing the requested certificate . . .".  I'll add
"As noted in CMMF, this response MUST contain a single certificate and
SHOULD include other certificates which link the issuer to higher level
certification authorities."

>
> 12. Section 4.8.7 - I don't care if the mesage format for a RevReq is not
> covered by CMS -- can we still state something good here about how it is
> sent to the server and the server recognizes this?  The concept of local
> implementation does not help the world with internet access, just small
> conclaves.

In re-reading this, I agree that the sentence "The structure of an unsigned
. . . RevReq . . . is a matter of local implementation." is too loose to
ensure interoperability.  It's probably best to clarify this text by cases:

1.  The use of CMS in the case of RA-authenticated revocation request is
clear cut.

2.  For the case of a end-user initiated revocation request in instances
when the end-entity's private key is reliable and available, CMS is equally
useful to authenticate the request.

3.  It is the case where either the end-entity's private key is either
unreliable (e.g. compromise) or not available (e.g. token broke, forgot
password, etc.).  As a strawman I would propose specification of an
unencapsulated CertRep that SHALL contain the passphrase.

>
> 13.  General Comment:  I would like to see an additional content type
> defined which would address one of the needs that I can see.  I want to be
> able to return more than one CMMF body in a single message.  Thus
> I propose
> that we add a new message type of XX (to be assigned).  The body of this
> message type will be:
>
>         MultipleResponse ::= SEQUENCE OF ContentInfo
>
> Where one or more signed items each containing a different response may be
> included.  This will allow me to return both a CertRepContent,
> KeyRecRepContent and some additional messages as the same time in a single
> transaction.

A useful requirement, but the MultiResponse syntax should include
messageType, or are we thinking of two different encapsulation models?

>
> jim
>

Mike

------ =_0_MIME_Boundary_27088.351aef82.im52390m.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351aef82.im52390m.hqrtmta1.doe.gov--

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Thu, 26 Mar 1998 18:59:44 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
To: [email-masked]

"David P. Kemp" writes:
> > > >Note: Implementors of this protocol should consider the applicability of
 the
> > > following patent(s): US patent no. 5,699,431
> >
> > Would there be something wrong with including enough text from the
> > patent that someone would know WHY they would want to examine it?
>
>
> I guess it's too much to expect that everyone knows to get patent
> information from http://www.patents.ibm.com/details?patent_number=5699431,

I'd say it is. The document is supposed to be self contained to some
extent. If you print it and get on an airplane to read, is it too much
to ask that a paragraph be there telling you why you would care about
this mysterious patent number?

And what if IBM stops providing this free service?

Perry

Importance: Normal
Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 26 Mar 1998 15:23:51 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Draft CMC-00
To: [email-masked]

Jim,

Thanks for taking the time to thoroughly review these drafts.  They help
considerably in moving the work products forward.  Some responses to your
comments:

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of Jim Schaad (Exchange)
> Sent: Wednesday, March 25, 1998 12:33 PM
> To: [email-masked]
> Subject: [IETF-PKIX] Comments on Draft CMC-00
>
>
> This is my first cut at comments about the CMC draft.  I think this still
> needs some work to make it usable in a general case solution.  I have many
> fewer comments on this draft at this point because a large point of it
> depends on getting clarifications for CRMF and CMMF first.

Agree.

>
> 1.  Section 3 - I don't think it is correct to call this a new CMS content
> type.  You are not defining this in the CMS specifiction.  Please use the
> sentence "This document defines a new content type PKIDATA.  This content
> type is used as an encapulsated content within the CMS security
> framework."

OK.

>
> 2.  Section 3.1, paragraph 2 -- I think you should really refer to this as
> "the familiar CMS (formerly PKCS7) degerate".

OK.

>
> 3.  Section 3.1 -- Please re-define id-pkiData in this section rather than
> puttin in the reference to PKIXCERT.

OK.

>
> 4.  Section 4.1, paragraph 3 -- The use of MailListKeyIdentifier in this
> draft should be strongly discuraged.  This is for sending
> encrypted messages
> to a DL and MUST NOT be used for PKI work.

Mailing lists could be used to broadcast revocation information and CA key
updates.

>
> 5.  Section 4.2 - Since we are using CMS as the basis of the
> Crypto in this
> document.  Please change the reference of how signatures and key
> exchange is
> to be done from the PKIXCERT documents to the CMS document.  I
> don't want to
> have to have a CMS implemention with two different types of
> algorithms just
> because the two documents are not in 100% agreement.

This makes sense.  However we should make certain that both works are
aligned since it affects interoperability in the more general case.

>
> 6.  Section 4.4, paragraph 2 - The procedure in the second paragraph not
> very clear. I see nothing in section 4.3 about enveloping as an
> id-pKIData.
> It discusses EnvelopedData and SignedData but not PKIdata -- did
> you mean a
> different section?

The phrase " . . . as defined in section 4.3 . . ." should be deleted.  The
third paragraph in this section speaks to the requirements directly.

>
> 7.  Section 4.4, paragraph 3 - Change the section reference from
> 5.3 to 4.3

OK.

>
> 8.  Section 4.4 in the Encryption Option 1:  (I may have mislead
> you on this
> one)  It should be as follows:
>         signedData.AuthencatedAttributes.contentType  <- id-envelopedData
>         signedData.AuthencatedAttributes.contentHint   <- id-pkiData

OK.

>
> 9. Section 4.5, paragraph 2, bullet 1:  This should be refering to the
> content-hint attribute not the content-type attribute.  This is
> the correct
> property to say what the innermost content is.  Signature validation will
> fail if you change the content-type attribute.

OK.

>
> 10.  Section 4.8.1 paragraph 2 - In the last sentence I am not sure if you
> really mean that the subject name should be encoded as an empty
> sequence or
> as a missing property.  Which do you mean?

Empty sequence.  The subject Name is not OPTIONAL in a PKCS10:

CertificationRequestInfo ::= SEQUENCE {
  version Version,
  subject Name,
  subjectPublicKeyInfo SubjectPublicKeyInfo,
  attributes [0] IMPLICIT Attributes }

>
> 11.  Section 4.8.5 - Should GetCert have a mode which returns the chain of
> certificates rather than just a single certificate.

Sending back a chain is implied by specification of CertRep as a response
which does accomodate sending back the chain.  CMC currently reads " . . . a
SignedData response containing the requested certificate . . .".  I'll add
"As noted in CMMF, this response MUST contain a single certificate and
SHOULD include other certificates which link the issuer to higher level
certification authorities."

>
> 12. Section 4.8.7 - I don't care if the mesage format for a RevReq is not
> covered by CMS -- can we still state something good here about how it is
> sent to the server and the server recognizes this?  The concept of local
> implementation does not help the world with internet access, just small
> conclaves.

In re-reading this, I agree that the sentence "The structure of an unsigned
. . . RevReq . . . is a matter of local implementation." is too loose to
ensure interoperability.  It's probably best to clarify this text by cases:

1.  The use of CMS in the case of RA-authenticated revocation request is
clear cut.

2.  For the case of a end-user initiated revocation request in instances
when the end-entity's private key is reliable and available, CMS is equally
useful to authenticate the request.

3.  It is the case where either the end-entity's private key is either
unreliable (e.g. compromise) or not available (e.g. token broke, forgot
password, etc.).  As a strawman I would propose specification of an
unencapsulated CertRep that SHALL contain the passphrase.

>
> 13.  General Comment:  I would like to see an additional content type
> defined which would address one of the needs that I can see.  I want to be
> able to return more than one CMMF body in a single message.  Thus
> I propose
> that we add a new message type of XX (to be assigned).  The body of this
> message type will be:
>
>         MultipleResponse ::= SEQUENCE OF ContentInfo
>
> Where one or more signed items each containing a different response may be
> included.  This will allow me to return both a CertRepContent,
> KeyRecRepContent and some additional messages as the same time in a single
> transaction.

A useful requirement, but the MultiResponse syntax should include
messageType, or are we thinking of two different encapsulation models?

>
> jim
>

Mike

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 26 Mar 1998 18:20: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]>
To: [email-masked]

> From: "Perry E. Metzger" <[email-masked]>
>
> Stephen Samson writes:
> > >We recommend the inclusion of a note in the following internet drafts:
> >
> > >draft-ietf-pkix-cmc-00.txt
> > >draft-ietf-pkix-opp-ftp-http-02.txt; and
> > >draft-ietf-pkix-ocsp-03.txt.
> > >
> > >The text of the note should be as follows:
> > >
> > >Note: Implementors of this protocol should consider the applicability of the
> > following patent(s): US patent no. 5,699,431
>
> Would there be something wrong with including enough text from the
> patent that someone would know WHY they would want to examine it?
>
> Perry

I guess it's too much to expect that everyone knows to get patent
information from http://www.patents.ibm.com/details?patent_number=5699431,
just as it was negligent to not include a full reference for the documents.

For reference, they are:
  ftp://ietf.org/internet-drafts/draft-ietf-pkix-cmc-00.txt
  ftp://ietf.org/internet-drafts/draft-ietf-pkix-opp-ftp-http-02.txt
  ftp://ietf.org/internet-drafts/draft-ietf-pkix-ocsp-03.txt

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Thu, 26 Mar 1998 17:09:27 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
To: [email-masked]

Stephen Samson writes:
> >We recommend the inclusion of a note in the following internet drafts:
>
> >draft-ietf-pkix-cmc-00.txt
> >draft-ietf-pkix-opp-ftp-http-02.txt; and
> >draft-ietf-pkix-ocsp-03.txt.
> >
> >The text of the note should be as follows:
> >
> >Note: Implementors of this protocol should consider the applicability of the
> following patent(s): US patent no. 5,699,431

Would there be something wrong with including enough text from the
patent that someone would know WHY they would want to examine it?

Perry

Approved-By:  Warwick Ford <[email-masked]>
Date:         Thu, 26 Mar 1998 16:09:21 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] agenda for next weeks meetings
To: [email-masked]

Here is a tentative agenda for next week.  Apologies if I have missed
anything that anyone has asked for.  Please advise omissions or requested
additions.

Warwick

IETF PKIX AGENDA - LOS ANGELES
Meeting times: Wed 4/1, 3:30-5:30; Thur 4/2, 9:00-11:30

- Certificate and CRL Profile
- LDAP Profile and Schema
- OCSP (and RCSP)
- CRMF and CMP
- CMMF
- CMC
- Time Stamping Protocol
- Notary Protocol
- PKIX Implementation Notes (B. LaMacchia)
- IPSEC and S/MIME support

At 02:21 AM 3/25/98 -0800, Jeff Weinstein wrote:
>Is someone going to post an agenda for next weeks meetings in LA?

******** PLEASE NOTE NEW CONTACT DETAILS ********
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Approved-By: [email-masked]
Date:         Thu, 26 Mar 1998 11:19:29 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Samson <[email-masked]>
To: [email-masked]

>We recommend the inclusion of a note in the following internet drafts:

>draft-ietf-pkix-cmc-00.txt
>draft-ietf-pkix-opp-ftp-http-02.txt; and
>draft-ietf-pkix-ocsp-03.txt.
>
>The text of the note should be as follows:
>
>Note: Implementors of this protocol should consider the applicability of the
following patent(s): US patent no. 5,699,431

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Thu, 26 Mar 1998 16:18:16 -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] New OCSP Requirements (and new straw poll...)
Comments: To: Stephen Kent <[email-masked]>
To: [email-masked]

Steve,

> We have an extension in PKIX that points to where a CRL can be found.  Do
> we need to extend this to allow for an explicit pointer to where an OCSP
> query should be directed? That would provide an unambiguous way to address
> this problem.
>
> >The problem is that the pointer only gives a *hint* on the place where
> >we can fetch the information. We have not defined a chain of trust which
> >allows to *make sure* that the information we get is really coming from
> >the right source.
>
> The pointer is put into the cert by the CA, so I consider it to be more
> than a "hint."  The CA shoukd be the definitive source for the location of
> its own cert and the CRL on which the subject cert would be listed, etc.
> If we define an explicit pointer for OCSP purposes, I would expect it to be
> just as definitive.  However, as you suggest in the next paragraph, there
> is the question of how we validate a response as being from an authorized
> source of validity info realtive to the CA in question. So, I think the
> real issue is not that the pointer here is just a hint, but that it is just
> a pointer, not a public key!  However, we could fix that, couldn't we?

I said :" We have not defined a chain of trust". The question is :
should we leave this open (and thus recognize that the problem has to be
solve one way or another) or should we tell how to build such a chain ?
I wanted to say that we have no story at this time. Since we are close
to the meeting, we could have chat on this topic in LA.

> >There is one exception: if the key used by the OCSP is the same private
> >key as the key of the CA (which might not be the best situation). For
> >the other cases, and in particular the delegation case, we currently
> >have no story.

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Stephen Kent <[email-masked]>
Date:         Thu, 26 Mar 1998 10:05: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
Comments: To: [email-masked]
To: [email-masked]

Denis,

>> We have an extension in PKIX that points to where a CRL can be found.  Do
>> we need to extend this to allow for an explicit pointer to where an OCSP
>> query should be directed? That would provide an unambiguous way to address
>> this problem.
>
>The problem is that the pointer only gives a *hint* on the place where
>we can fetch the information. We have not defined a chain of trust which
>allows to *make sure* that the information we get is really coming from
>the right source.

The pointer is put into the cert by the CA, so I consider it to be more
than a "hint."  The CA shoukd be the definitive source for the location of
its own cert and the CRL on which the subject cert would be listed, etc.
If we define an explicit pointer for OCSP purposes, I would expect it to be
just as definitive.  However, as you suggest in the next paragraph, there
is the question of how we validate a response as being from an authorized
source of validity info realtive to the CA in question. So, I think the
real issue is not that the pointer here is just a hint, but that it is just
a pointer, not a public key!  However, we could fix that, couldn't we?

>There is one exception: if the key used by the OCSP is the same private
>key as the key of the CA (which might not be the best situation). For
>the other cases, and in particular the delegation case, we currently
>have no story.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 25 Mar 1998 18:16: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
Comments: To: [email-masked]
To: [email-masked]

Denis,

>> We have an extension in PKIX that points to where a CRL can be found.  Do
>> we need to extend this to allow for an explicit pointer to where an OCSP
>> query should be directed? That would provide an unambiguous way to address
>> this problem.
>
>The problem is that the pointer only gives a *hint* on the place where
>we can fetch the information. We have not defined a chain of trust which
>allows to *make sure* that the information we get is really coming from
>the right source.

The pointer is put into the cert by the CA, so I consider it to be more
than a "hint."  The CA shoukd be the definitive source for the location of
its own cert and the CRL on which the subject cert would be listed, etc.
If we define an explicit pointer for OCSP purposes, I would expect it to be
just as definitive. However, as your next paragraph notes, the real issues
here is how to verify the authorization of an OCSP responder associated
with the pointer we can provide.  That's a valid question.

>There is one exception: if the key used by the OCSP is the same private
>key as the key of the CA (which might not be the best situation). For
>the other cases, and in particular the delegation case, we currently
>have no story.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 25 Mar 1998 12:50:24 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
To: [email-masked]

Mike,

>
>Is this not AuthorityInfoAccess extension as defined in PKIX Part 1?

yes.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 25 Mar 1998 18:15: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Using PKIX
To: [email-masked]

Fredrick,

>1)  Yes, I am also a European guy addicted to Hardware Tokens.  My question
>is about how to make a distinction between a Hardware Key and a Software
>one.  Suppose you have a Certification Authority which supports centralised
>key generation, both in software and on hardware tokens (suppose one of the
>Internet CA's would like to do this),
>        1) How can an EE tell the CA where to store the Certificate and the
>secret key?

One might encode this piece of info in the cert policy extension.

Steve

Approved-By:  Valentin Oprean <[email-masked]>
Date:         Thu, 26 Mar 1998 15:54:25 +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: Valentin Oprean <[email-masked]>
Subject:      [IETF-PKIX] data to/from X.509
To: [email-masked]

Hi!

I am a student and i try to learn some basic stuff about X.509 since i have
to use X.509 together with Oracles Data Cartridge. I am interested in
finding information regarding how data must look like before going in the
X.509 and how it looks leaving the X.509 or what kind of data do I have to
use to/from X.509.

If anybody knows any places where i could find the information please let
me know.

Thanks in advance,

Valentin ([email-masked])

Approved-By: [email-masked]
Date:         Wed, 25 Mar 1998 12:32:44 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Comments on Draft CMC-00
To: [email-masked]

This is my first cut at comments about the CMC draft.  I think this still
needs some work to make it usable in a general case solution.  I have many
fewer comments on this draft at this point because a large point of it
depends on getting clarifications for CRMF and CMMF first.

1.  Section 3 - I don't think it is correct to call this a new CMS content
type.  You are not defining this in the CMS specifiction.  Please use the
sentence "This document defines a new content type PKIDATA.  This content
type is used as an encapulsated content within the CMS security framework."

2.  Section 3.1, paragraph 2 -- I think you should really refer to this as
"the familiar CMS (formerly PKCS7) degerate".

3.  Section 3.1 -- Please re-define id-pkiData in this section rather than
puttin in the reference to PKIXCERT.

4.  Section 4.1, paragraph 3 -- The use of MailListKeyIdentifier in this
draft should be strongly discuraged.  This is for sending encrypted messages
to a DL and MUST NOT be used for PKI work.

5.  Section 4.2 - Since we are using CMS as the basis of the Crypto in this
document.  Please change the reference of how signatures and key exchange is
to be done from the PKIXCERT documents to the CMS document.  I don't want to
have to have a CMS implemention with two different types of algorithms just
because the two documents are not in 100% agreement.

6.  Section 4.4, paragraph 2 - The procedure in the second paragraph not
very clear. I see nothing in section 4.3 about enveloping as an id-pKIData.
It discusses EnvelopedData and SignedData but not PKIdata -- did you mean a
different section?

7.  Section 4.4, paragraph 3 - Change the section reference from 5.3 to 4.3

8.  Section 4.4 in the Encryption Option 1:  (I may have mislead you on this
one)  It should be as follows:
        signedData.AuthencatedAttributes.contentType  <- id-envelopedData
        signedData.AuthencatedAttributes.contentHint   <- id-pkiData

9. Section 4.5, paragraph 2, bullet 1:  This should be refering to the
content-hint attribute not the content-type attribute.  This is the correct
property to say what the innermost content is.  Signature validation will
fail if you change the content-type attribute.

10.  Section 4.8.1 paragraph 2 - In the last sentence I am not sure if you
really mean that the subject name should be encoded as an empty sequence or
as a missing property.  Which do you mean?

11.  Section 4.8.5 - Should GetCert have a mode which returns the chain of
certificates rather than just a single certificate.

12. Section 4.8.7 - I don't care if the mesage format for a RevReq is not
covered by CMS -- can we still state something good here about how it is
sent to the server and the server recognizes this?  The concept of local
implementation does not help the world with internet access, just small
conclaves.

13.  General Comment:  I would like to see an additional content type
defined which would address one of the needs that I can see.  I want to be
able to return more than one CMMF body in a single message.  Thus I propose
that we add a new message type of XX (to be assigned).  The body of this
message type will be:

        MultipleResponse ::= SEQUENCE OF ContentInfo

Where one or more signed items each containing a different response may be
included.  This will allow me to return both a CertRepContent,
KeyRecRepContent and some additional messages as the same time in a single
transaction.

jim

Approved-By:  Tim Polk <[email-masked]>
Date:         Wed, 25 Mar 1998 15:03: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: Tim Polk <[email-masked]>
Subject:      [IETF-PKIX] new draft of certificate profile
To: [email-masked]

The much anticipated (or is that maligned?) seventh draft of the
certificate profile is now available via http.  (In the immortal words of
Maxwell Smart, "I missed the I-D submission deadline by *this much*.")  The
URL is

        http://csrc.nist.gov/pki/draft-ietf-pkix-ipki-part1-07.txt

You must use the whole URL; there are no links from the PKI welcome page. I
will submit draft 7 formally on Monday.

This draft satisfies all Last Call requirements.  This draft has several
minor enhancements.

Most importantly, the document incorporates UTF-8 in several key areas.
This was done to conform with RFC 2277, "IETF Policy on Character Sets and
Languages" and should satisfy most of those concerns. The one controversial
point - we are now *leading* ISO's definition of DirectoryString by
including UTF8String as a choice.  That won't be official for several months.

Next most important (on my list anyway) is the updated path validation text
(section 7.) We were out of synch with ISO's most recent work there.

Wilcarding has been excised from the subject alternative name.  The
applications that wanted this feature have discovered better ways to
achieve their goals.  There were simply too many opportunities for
misinterpretation, usually resulting in serious security problems.

The conformance requirements have been clarified somewhat...  Acording to
RFC 2119, "Key Words for Use in RFCs to Indicate Requirement Levels," any
of the key words {MUST, SHALL, REQUIRE, SHOULD, RECOMMEND, MAY, OPTIONAL}
were good key words for stating conformance requirements.  I did not
attempt to standardize on any particular subset (MUST and SHALL appear
interchangeably), but I did try to remove all inappropriate occurences of
the word "will", since it didn't make the list.

I also added a Table of Contents, updated the References, and added a
patent statement from Entrust.

Please let me know if you have any difficulty downloading the document!

Hope to see you in LA!

Tim Polk

P.S.  I downloaded the text file on another machine, just to double check.
I *believe* the formatting is intact.  If I'm wrong, please let me know
ASAP and I'll correct it.

Approved-By: [email-masked]
Date:         Wed, 25 Mar 1998 11:15:44 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Biddle, Bradford" <[email-masked]>
Subject:      Re: [IETF-PKIX] [E-CARM] PKI, CAs, TTPs &c.
Comments: To: George Capehart <[email-masked]>, [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: [email-masked]

I'll toss out some thoughts on this topic, to all of the lists which
George added (although I share his discomfort with the breadth of the
cross-posting -- my vote would be for E-CARM as the forum for any
further discussion).

Below I've pasted in, first, an adapted version of some brief points I
made in connection with some written comments submitted to the Commerce
Department when they were looking at PKI issues last summer. Second,
I've pasted in the introduction to a paper I wrote called "Legislating
Market Winners" which appeared in the Summer 1997 issue of the World
Wide Web Journal (an expanded version is forthcoming in the San Diego
Law Review), along with a cite to the current URL. Both the Commerce
Dept. comments and the paper address the business-model issues raised in
this thread, although the focus of both is largely on the issue of the
need or desirability of PKI-related legislation.

Both of the items below are increasingly a bit dated. I've grown
uncomfortable with the "open PKI/closed PKI" nomenclature which I use
below.  In general, as used below, "open PKI" refers to the ABA Digital
Signature Guidelines/Utah Digital Signature Act/VeriSign-style "public"
CA model, whereby CAs issue generic "identity" certificates to
"subscribers" for use in a wide variety of transactions. "Closed PKI"
refers not to a closed or proprietary system, but rather to a PKI model
whereby limited -purpose certificates are used in a closed or bounded
context.

Here's an adapted version of the five points submitted to the Commerce
Dept., which I also posted to several lists last summer:

1.   The conventional wisdom about how certification authorities will
function is wrong. The "open PKI" model envisioned by the ABA Guidelines
is an economically inefficient model that would not survive under
marketplace discipline. Generic, all-purpose identity certificates
issued by freestanding third-party CAs are simply not what the
marketplace is demanding. The marketplace has developed, and continues
to develop, more economically efficient, useful, and imaginative
business models.

2.   CAs practicing the open PKI business model envisioned by the ABA
Guidelines can and should compete in the marketplace without special
legislation.  CAs practicing this model can overcome the "contractual
privity problem" which is used to justify ABA Guidelines-style
legislation.

3.   Legislation which endorses the open PKI model will harm the
development of the electronic commerce marketplace. Even legislation
which implements an  "optional" state-endorsed authentication scheme
risks drawing capital and resources away from more efficient and
innovative enterprises, and risks creating economic harms which are
externalized on to innocent parties.

4.   Licensing efforts focused on the open PKI model risk being either
irrelevant or harmful. Licensing is an intrusive form of market
intervention that should be  reserved for situations where demonstrated
market flaws cannot be addressed by other, less intrusive means.
Mandatory licensing of CAs would be harmful; optional licensing of CAs
is simply unnecessary.

5.   The ABA Guidelines-inspired legislation enacted to date poses
serious risks to the development of a robust global electronic commerce
infrastructure. CAs, which could conceivably be global businesses, are
faced with the specter of conforming to dramatically inconsistent local
regulatory schemes.  Such legislation is unwise and unnecessary.

Here's the introduction to the "Legislating Market Winners" article:

[full article at <http://www.acusd.edu/~biddle/LMW.htm>]

"Legislating Market Winners: Digital Signature Laws and the
Electronic Commerce Marketplace"

The argument goes something like this: Internet commerce is
hampered by the authentication problem. There is no reliable
way to ensure that the sender of an electronic transmission is
in fact who they purport to be. Digital signatures, supported by
a "public key infrastructure" of certification authorities (CAs)
and certificate databases, can solve this authentication
problem. CAs will not emerge under the current legal regime,
however, because they face uncertain and potentially
immense liability exposure. Additionally, the legal status of
digitally signed documents is unclear. Therefore, legislation is
needed which defines and limits CA liability and which
establishes the legality of digitally signed documents.

This argument has captured an influential segment of the legal
community, and has led to the enactment of "digital signature
legislation" in several U.S. states and foreign nations.
Unfortunately, the argument is built on fundamentally flawed
assumptions, and the legislation enacted based upon it is
correspondingly flawed. Much (but not all) of the digital
signature legislation enacted to date presumes a vision of
electronic commerce that simply is not tenable, and which
would not "naturally" evolve in the marketplace. This
legislation poses the risk of profoundly distorting an infant
market and locking in business models which are harmful to
consumers and to the future development of electronic
commerce.

The type of public key infrastructure (PKI) envisioned by many
of the existing digital signature laws is not viable. The problem
is liability. Digital signature legislation drafters have assumed
that the potential liability exposure faced by CAs is somehow a
flaw of the existing legal regime. This is an erroneous
assumption: the liability exposure faced by CAs under the
"open PKI" model envisioned by legislation drafters is a
product of a business model that cannot internalize the costs
associated with its implementation. Moreover, in attempting to
limit the liability exposure of CAs, current digital signature laws
shift an immense liability burden onto consumers who use the
infrastructure envisioned by these laws. Putting this type of
liability burden on consumers violates long-held tenets of
public policy, and is a result which consumers would reject in
any truly "bargained for" transaction.

Digital signatures will undoubtedly play a significant role in
electronic commerce. However, rather than being
implemented in the "open PKI" model envisioned by various
digital signature laws, digital signatures are more likely to be
utilized under a "closed PKI" system. Under a closed PKI
system, the liability problems associated with digital
signatures become much more manageable. This article
describes the differences between open and closed PKI, and
suggests that, in the absence of legislative displacement,
certain marketplace trends indicate that closed PKI is indeed
the likely market winner.

The open PKI model can and should compete against closed
PKI and other authentication technologies, and should not be
accorded special legal status via legislation. Such legislation is
unnecessary: the "contractual privity problem" which is used
to justify open PKI legislation is a red herring. Commercial CAs
utilizing the open PKI model can compete in the marketplace
without special PKI legislation. These CAs are unlikely to
succeed, not because of flaws with the legal system, but
because the open PKI model is not a winning business model.

Despite raising the very peculiar specter of regulating an
essentially nonexistent industry (CAs), and despite increased
recognition of the problems associated with the very specific
vision of electronic commerce embodied in these digital
signature laws, laws based on the open PKI model continue to
be proposed and implemented. This article suggests that one
of several factors behind the continued momentum of this
legislation, particularly at the federal and international levels, is
its synergy with cryptographic "key escrow" proposals. While
digital signature legislation ostensibly addresses the use of
cryptography only for the purposes of authentication, and not
for confidentiality, the infrastructure created by these laws is
ideal for implementing a key escrow scheme.

Ultimately this article argues that digital signature laws which
impose a particular view of electronic commerce should be
abandoned. Laws which remove specific, well-defined barriers
to electronic commerce -- such as unnecessary "writing" or
handwritten signature requirements -- and which allow the
electronic commerce marketplace to evolve unfettered should
be encouraged.

 - - - - - - -

I look forward to further discussion on this topic!

Regards,
Brad

Brad Biddle <[email-masked]>
Cooley Godward LLP <http://www.cooley.com>
4365 Executive Dr. Ste. 1100 San Diego, CA 92121
voice: (619) 550-6301  fax: (619) 453-3555

> -----Original Message-----
> From: George Capehart [SMTP:[email-masked]]
> Sent: Wednesday, March 25, 1998 4:00 AM
> To:   [email-masked]
> Cc:   [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject:      Re: [E-CARM] PKI, CAs, TTPs &c.
>
> First, *MAJOR* apologies for cross-posting like this, but I have been
> having the same questions as those posed below.  I know that there
> have
> been various threads in the different groups that have touched on
> them,
> but most have taken tangents at some point or another or simply
> weren't
> appropriate for the list.  I, for one, would like to attack this whole
> area.  I changed jobs and ISPs a while back and have had a *really*
> hard
> time getting caught back up.  I have a feeling this would be a forum
> that would allow the thoughts and work being done by the different
> groups to converge.  I'd like to see discussion of these topics
> progress, whether on this list, in private or <shudder> on a new list
> if
> need be . . .
>
> pj ponder wrote:
> >
> > Is this a good time to discuss the practicality of certificate and
> > CA based public key infrastructure?  Is there any interest in
> discussing
> > whether truly open PKI is viable? Trusted third parties?  Cross
> > certification?  If you are interested in this, or have an opinion on
> the
> > trust or business models represented by open PKI and public CAs, we
> can
> > either discuss it here, or in private email.  I'm hearing a general
> > rumbling that indicates it just won't work - not from a technical
> > viewpoint, we know the math works - but from a practical perspective
> of
> > how it might be implemented.
>
> rgds,
> --
> /*  George Capehart    [email-masked]      +1 704.866.9151
> *
>  *
> *
>  *  "If you push something hard enough, it will fall over."
> *
>  *                          Fudd's First Law of Opposition
> */
> ======================================================================
> =====
> Help with Majordomo commands plus list archives and information is
> available through the E-Carm web page at www.kc-inc.net/e-carm/.
> Sponsored by The Knowledge Connection.
> ======================================================================
> =====

Approved-By:  George Capehart <[email-masked]>
Date:         Wed, 25 Mar 1998 06:59:44 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: George Capehart <[email-masked]>
Subject:      Re: [IETF-PKIX] [E-CARM] PKI, CAs, TTPs &c.
Comments: To: pj ponder <[email-masked]>
Comments: cc: [email-masked], CERT-TALK <[email-masked]>, IETF-SPKI <[email-masked]>, MCG-TALK <[email-masked]>
To: [email-masked]

First, *MAJOR* apologies for cross-posting like this, but I have been
having the same questions as those posed below.  I know that there have
been various threads in the different groups that have touched on them,
but most have taken tangents at some point or another or simply weren't
appropriate for the list.  I, for one, would like to attack this whole
area.  I changed jobs and ISPs a while back and have had a *really* hard
time getting caught back up.  I have a feeling this would be a forum
that would allow the thoughts and work being done by the different
groups to converge.  I'd like to see discussion of these topics
progress, whether on this list, in private or <shudder> on a new list if
need be . . .

pj ponder wrote:
>
> Is this a good time to discuss the practicality of certificate and
> CA based public key infrastructure?  Is there any interest in discussing
> whether truly open PKI is viable? Trusted third parties?  Cross
> certification?  If you are interested in this, or have an opinion on the
> trust or business models represented by open PKI and public CAs, we can
> either discuss it here, or in private email.  I'm hearing a general
> rumbling that indicates it just won't work - not from a technical
> viewpoint, we know the math works - but from a practical perspective of
> how it might be implemented.

rgds,
--
/*  George Capehart    [email-masked]      +1 704.866.9151  *
 *                                                                    *
 *  "If you push something hard enough, it will fall over."           *
 *                          Fudd's First Law of Opposition            */

Approved-By:  Jeff Weinstein <[email-masked]>
Date:         Wed, 25 Mar 1998 02:21:14 -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: Jeff Weinstein <[email-masked]>
Subject:      [IETF-PKIX] agenda for next weeks meetings
To: [email-masked]

Is someone going to post an agenda for next weeks meetings in LA?

        --Jeff

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Wed, 25 Mar 1998 10:53:59 -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] New OCSP Requirements (and new straw poll...)
Comments: To: Stephen Kent <[email-masked]>
To: [email-masked]

Steve,

Thank you for handling the topic through short messages. I will do the
same.

> Denis,
>
> We have an extension in PKIX that points to where a CRL can be found.  Do
> we need to extend this to allow for an explicit pointer to where an OCSP
> query should be directed? That would provide an unambiguous way to address
> this problem.

The problem is that the pointer only gives a *hint* on the place where
we can fetch the information. We have not defined a chain of trust which
allows to *make sure* that the information we get is really coming from
the right source.

There is one exception: if the key used by the OCSP is the same private
key as the key of the CA (which might not be the best situation). For
the other cases, and in particular the delegation case, we currently
have no story.

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 24 Mar 1998 17:44:35 -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] Comments on CRMF-00
To: [email-masked]

Hi Jim,

One quick comment:

>----------
>From:  Jim Schaad (Exchange)[SMTP:[email-masked]]
>Sent:  Tuesday, March 24, 1998 12:45 PM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Comments on CRMF-00
>
(...stuff deleted...)

>17. Given that we have a CMMF document now, and both CMP and CMC refer that
>that document as well as this one. Is there any reason not to combine CRMF
>and CMMF into a single document? I believe that the original reasons for
>seperating them are no longer applicable.

Note that CMP does not point to CMMF (CMMF was still a thought, not yet
a draft, when the final version of CMP was being submitted so CMP had
nothing to point to).  CMP does, however, point to CRMF.

This, perhaps, is as good a reason as any to keep them as separate
documents for the time being.

Carlisle.

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 24 Mar 1998 15:46:41 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
To: [email-masked]

Steve,

Is this not AuthorityInfoAccess extension as defined in PKIX Part 1?

Mike

-----Original Message-----
From: Stephen Kent <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, March 24, 1998 2:20 PM
Subject: Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)

>Denis,
>
>We have an extension in PKIX that points to where a CRL can be found.  Do
>we need to extend this to allow for an explicit pointer to where an OCSP
>query should be directed? That would provide an unambiguous way to address
>this problem.
>
>Steve
>

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Tue, 24 Mar 1998 14:33:31 -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: Tony Bartoletti <[email-masked]>
Subject:      [IETF-PKIX] Belated Post Response
Comments: To: "David P. Kemp" <[email-masked]>
To: [email-masked]

David, on March 10, you wrote:

> The PKIX list server seems to be back up, but this message from Monday
> hasn't popped out yet, so we'll try again.
>
>   dpk
>
>
> ----- Begin Included Message -----
>
> > From: Tony Bartoletti <[email-masked]>
> >
> > > From: [email-masked]
> > >

It looks like it just did, two weeks later!  Ain't computers wunnerful?

____TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 24 Mar 1998 17:31: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on CRMF-00
To: [email-masked]

> From: "David P. Kemp" <[email-masked]>
>
> Appendix C. ASN.1 Structures and OIDs

One other change we might consider:  importing IssuerSerial from
X.509, and defining:

   OldCertId ::= IssuerSerial

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 24 Mar 1998 17:19:29 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on CRMF-00
To: [email-masked]

> From: "Jim Schaad (Exchange)" <[email-masked]>
>
> 14. id-pkip definition should be "::=" not "::"
> 15. Several instances of regCtrl exist which should be id-regCtrl
> 16. The following elements are not defined in the module and need to be:
> AttributeTypeAndValue, EnvelopedData, GeneralName, Name,
> AlgorithmIdentifier, Version, Extensions, UniqueIdentifier,
> SubjectPublicKeyInfo

Thanks to Jim and to Phil Griffin, who also spotted these (and a few
other) errors and reported them to the authors.  The following ASN.1
module from March 2 corrects all the errors I am aware of at this point,
and should be included in the next CRMF draft.

Dave Kemp

Appendix C. ASN.1 Structures and OIDs

CRMF DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS
    Version, AlgorithmIdentifier, Name, Time, SubjectPublicKeyInfo,
    Extensions
        FROM AuthenticationFramework {joint-iso-ccitt ds(5) module(1)
        authenticationFramework(7) 3}

    selectedAttributeTypes
        FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1)
        usefulDefinitions(0) 3}

    UniqueIdentifier
        FROM SelectedAttributeTypes selectedAttributeTypes

    GeneralName
        FROM CertificateExtensions {joint-iso-ccitt ds(5) module(1)
        certificateExtensions(26) 0}

    EnvelopedData
        FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840)
        rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) };

CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {
    certReq   CertRequest,
    pop       ProofOfPossession  OPTIONAL,
    -- content depends upon key type
    regInfo   SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }

CertRequest ::= SEQUENCE {
    certReqId     INTEGER,          -- ID for matching request and reply
    certTemplate  CertTemplate,  -- Selected fields of cert to be issued
    controls      Controls OPTIONAL }   -- Attributes affecting issuance

CertTemplate ::= SEQUENCE {
    version      [0] Version               OPTIONAL,
    serialNumber [1] INTEGER               OPTIONAL,
    signingAlg   [2] AlgorithmIdentifier   OPTIONAL,
    issuer       [3] Name                  OPTIONAL,
    validity     [4] OptionalValidity      OPTIONAL,
    subject      [5] Name                  OPTIONAL,
    publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
    issuerUID    [7] UniqueIdentifier      OPTIONAL,
    subjectUID   [8] UniqueIdentifier      OPTIONAL,
    extensions   [9] Extensions            OPTIONAL }

  OptionalValidity ::= SEQUENCE {
      notBefore  [0] Time OPTIONAL,
      notAfter   [1] Time OPTIONAL } --at least one must be present

Controls  ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
    type         OBJECT IDENTIFIER,
    value        ANY DEFINED BY type }

ProofOfPossession ::= CHOICE {
    raVerified        [0] NULL,
    -- used if the RA has already verified that the requester is in
    -- possession of the private key
    signature         [1] POPOSigningKey,
    keyEncipherment   [2] POPOPrivKey,
    keyAgreement      [3] POPOPrivKey }

POPOSigningKey ::= SEQUENCE {
    poposkInput           [0] POPOSigningKeyInput OPTIONAL,
    algorithmIdentifier   AlgorithmIdentifier,
    signature             BIT STRING }
    -- The signature (using "algorithmIdentifier") is on the
    -- DER-encoded value of poposkInput.  NOTE: If the CertReqMsg
    -- certReq CertTemplate contains the subject and publicKey values,
    -- then poposkInput MUST be omitted and the signature MUST be
    -- computed on the DER-encoded value of CertReqMsg certReq.  If
    -- the CertReqMsg certReq CertTemplate does not contain the public
    -- key and subject values, then poposkInput MUST be present and
    -- MUST be signed.  This strategy ensures that the public key is
    -- not present in both the poposkInput and CertReqMsg certReq
    -- CertTemplate fields.

POPOSigningKeyInput ::= SEQUENCE {
    authInfo            CHOICE {
        sender              [0] GeneralName,
        -- used only if an authenticated identity has been
        -- established for the sender (e.g., a DN from a
        -- previously-issued and currently-valid certificate
        publicKeyMAC        [1] BIT STRING },
        -- used if no authenticated GeneralName currently exists for
        -- the sender; publicKeyMAC contains a password-based MAC
        -- on the DER-encoded value of publicKey
    publicKey           SubjectPublicKeyInfo }  -- from CertTemplate

POPOPrivKey ::= CHOICE {
    thisMessage       [0] BIT STRING,
    -- posession is proven in this message (which contains the private
    -- key itself (encrypted for the CA))
    subsequentMessage [1] SubsequentMessage,
    -- possession will be proven in a subsequent message
    dhMAC             [2] BIT STRING }
    -- for keyAgreement (only), possession is proven in this message
    -- (which contains a MAC (over the DER-encoded value of the
    -- certReq parameter in CertReqMsg, which must include both subject
    -- and publicKey) based on a key derived from the end entity's
    -- private DH key and the CA's public DH key);
    -- the dhMAC value MUST be calculated as per the directions given
    -- in Appendix A.

SubsequentMessage ::= INTEGER {
    encrCert (0),
    -- requests that resulting certificate be encrypted for the
    -- end entity (following which, POP will be proven in a
    -- confirmation message)
    challengeResp (1) }
    -- requests that CA engage in challenge-response exchange with
    -- end entity in order to prove private key possession

-- Object identifier assignments --

id-pkix  OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 }

-- arc for Internet X.509 PKI protocols and their components
id-pkip  OBJECT IDENTIFIER ::= { id-pkix 5 }

-- Registration Controls in CRMF
id-regCtrl        OBJECT IDENTIFIER ::= { id-pkip 1 }

id-regCtrl-regToken          OBJECT IDENTIFIER ::= { id-regCtrl 1 }
--with syntax:
RegToken ::= OCTET STRING

id-regCtrl-authenticator      OBJECT IDENTIFIER ::= { id-regCtrl 2 }
--with syntax:
Authenticator ::= OCTET STRING

id-regCtrl-pkiPublicationInfo    OBJECT IDENTIFIER ::= { id-regCtrl 3 }
--with syntax:
PKIPublicationInfo ::= SEQUENCE {
   action     INTEGER {
                dontPublish (0),
                pleasePublish (1) },
   pubInfos  SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
     -- pubInfos MUST NOT be present if action is "dontPublish"
     -- (if action is "pleasePublish" and pubInfos is omitted,
     -- "dontCare" is assumed)

SinglePubInfo ::= SEQUENCE {
    pubMethod    INTEGER {
        dontCare    (0),
        x500        (1),
        web         (2),
        ldap        (3) },
    pubLocation  GeneralName OPTIONAL }

id-regCtrl-pkiArchiveOptions     OBJECT IDENTIFIER ::= { id-regCtrl 4 }
--with syntax:
PKIArchiveOptions ::= CHOICE {
    encryptedPrivKey     [0] EncryptedKey,
    -- the actual value of the private key
    keyGenParameters     [1] KeyGenParameters,
    -- parameters which allow the private key to be re-generated
    archiveRemGenPrivKey [2] BOOLEAN }
    -- set to TRUE if sender wishes receiver to archive the private
    -- key of a key pair which the receiver generates in response to
    -- this request; set to FALSE if no archival is desired.

EncryptedKey ::= CHOICE {
    encryptedValue        EncryptedValue,
    envelopedData     [0] EnvelopedData }
    --import from [CMS], where the inner content of the
    --EnvelopedData is id-envelopedData and the data content is a
    --BIT STRING encoding of the private key

EncryptedValue ::= SEQUENCE {
    encValue          BIT STRING,
    -- the encrypted value itself
    intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
    -- the intended algorithm for which the value will be used
    symmAlg       [1] AlgorithmIdentifier  OPTIONAL,
    -- the symmetric algorithm used to encrypt the value
    encSymmKey    [2] BIT STRING           OPTIONAL,
    -- the (encrypted) symmetric key used to encrypt the value
    keyAlg        [3] AlgorithmIdentifier  OPTIONAL,
    -- algorithm used to encrypt the symmetric key
    valueHint     [4] OCTET STRING         OPTIONAL }
    -- a brief description or identifier of the encValue content
    -- (may be meaningful only to the sending entity, and used only
    -- if EncryptedValue might be re-examined by the sending entity
    -- in the future)

KeyGenParameters ::= OCTET STRING

id-regCtrl-oldCertID          OBJECT IDENTIFIER ::= { id-regCtrl 5 }
--with syntax:
OldCertId ::= CertId

CertId ::= SEQUENCE {
    issuer           GeneralName,
    serialNumber     INTEGER }

id-regCtrl-protocolEncrKey    OBJECT IDENTIFIER ::= { id-regCtrl 6 }
--with syntax:
ProtocolEncrKey ::= SubjectPublicKeyInfo

-- Registration Info in CRMF
id-regInfo      OBJECT IDENTIFIER ::= { id-pkip 2 }
id-regInfo-asciiPairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
AsciiPairs ::= OCTET STRING
id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest

END

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 24 Mar 1998 12:07:40 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: Scott Guthery <[email-masked]>
To: [email-masked]

Scott,

...

>Digital certificates are not about identity.  They are about risk.

I disagree with this broad statement.  Sometimes certs are about risk.
Certs used in many financial systems are not about identity, but about
ensuring that a merchant gets paid.  Sometimes, howeverm certs are about
identity, e.g., as input to an access control decision or for identofying
the sender of an e-mail message.  If the issuer of a cert is also the only
consumer of the cert (in an access control system), I don't think "risk"
captures the essence of certs used here.  Similarly, when I receive signed
e-mail, I want to know the identity of the sender, period.  I may not be
taking some overt action as a result of receipt of the message, and so risk
does not seem to appropriate here either.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 24 Mar 1998 13:46: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] New OCSP Requirements (and new straw poll...)
Comments: To: [email-masked]
To: [email-masked]

Denis,

We have an extension in PKIX that points to where a CRL can be found.  Do
we need to extend this to allow for an explicit pointer to where an OCSP
query should be directed? That would provide an unambiguous way to address
this problem.

Steve

Approved-By: [email-masked]
Date:         Tue, 24 Mar 1998 09:45:41 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Comments on CRMF-00
To: [email-masked]

The following represents my best guess on how to implement enrollment
protocols based on the CRMF specification (I do realize that only the
enrollment message itself is in this document).
1. Section 3, bullet item d: Please add the following sentence to the end.
"(Details of this are covered in other drafts.)"
2. publicKeyMAC -- Only one hash alg allowed?
3. Section 5.4 POPOSigningKeyInput: I don't understand the use of the
authInfo/sender field. Under what circumstances would this be used? Why
would the sender name not be put into the CertTemplate field instead?
4. Section 6. Since you have stated that transaction processing is out of
the scope of this specfication, please change "transaction identifier" to
"request identifier".
5. Section 7.1 -- I have a problem with Registration Token Controls, I can
see it is an octet string, but I cannot determine how I should fill in this
field. Is this just a copy of the token issued by the CA or will this be
different from CA to CA and therefore not standardized in any way? I would
suggest that we define a specific way to do this for this draft. If other
CAs want to use a different way, they should define both the OID and the new
structure for this information.
6. Section 7.3, last paragraph. This states that it is where the EE would
like to find the certificate. What restrictions does this really place on
the CA about publishing? For example is it legal for a CA to publish in a
location or way which is not requested by the PKIPublicationInfo control.
7. Section 7.4 -- Can we turn around the parameters to EncryptedValue?
People who are hand coding will appreciate the fact that we give the
parameters needed to do the decryption prior to giving the value to be
decrypted.
8. Section 7.4 -- I don't know if you can "legally" used EnvelopedData at
this point. Only ContentInfo is actually exported from the CMS module.
9. Section 7.4 -- I see no benefit in requiring that the contentType field
in the EnvelopedData object must be id-data. In a number of cases inclusion
of ASN data directly without another wrapping makes sense and this should be
done using the correct OID.
10. Section 7.6 -- This is incompatable with some of the POP methods. This
needs to be stated in the text for this section.
11. Appendix A. -- Which (or what) subjectName and issuerName are we using?
I assume but it is not stated that we are using the issuer and subject names
for the CA certificate. I make this assumption because I don't necessarily
have the fields in the request (in fact I don't have the subject name by
definition).
Please state this explicity.
12. If you are doing Name-Value pairs, I strongly sugguest you add an
id-regInfo-utf8 for non-ascii situations.
13. Appendix B.1 -- Please put in information in this section about how to
do quoting in the event that either ? or % is part of the value field.
14. id-pkip definition should be "::=" not "::"
15. Several instances of regCtrl exist which should be id-regCtrl
16. The following elements are not defined in the module and need to be:
AttributeTypeAndValue, EnvelopedData, GeneralName, Name,
AlgorithmIdentifier, Version, Extensions, UniqueIdentifier,
SubjectPublicKeyInfo
17. Given that we have a CMMF document now, and both CMP and CMC refer that
that document as well as this one. Is there any reason not to combine CRMF
and CMMF into a single document? I believe that the original reasons for
seperating them are no longer applicable.
jim

Approved-By: [email-masked]
Date:         Wed, 25 Mar 1998 03:53:20 +1200
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 Gutmann <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
Comments: To: [email-masked]
To: [email-masked]

Bob Jueneman <[email-masked]> wrote:

>One question regarding the "least general encoding" rule.  Is it sufficient
>for a given application to trust the code page that is typically used in
>order to decide the string type, or is it necssary to examine each individual
>character in the string in order to determine what the absolutely minimal
>directoryString type should be?

You should use the current code page/locale/whatever (this can get rather
complex, for example under Win32 each individual thread can have its own
locale, although I doubt anyone really takes advantage of this functionality).

Hal Lockhart <[email-masked]> asked:

>Could you add a short comment clarifying the differences between
>printableString, IA5String and visibleString?

Printable = alphanumerics plus a very limited amount of punctuation.
IA5String = (effectively) ASCII, including all the control codes.
VisibleString (aka ISO646String) = ASCII without the control codes.

The only really sensible/useful one there is VisibleString.  For most of the
others it would have been a lot more logical to constrain VisibleString than
to invent lots of new string types with strange restrictions placed on them
(there are several more string types alongside the ones above).  For example
you can't encode an email address in a PrintableString because it doesn't
include an '@', and you're not allowed a VisibleString, so you have to go all
the way up to T61String just to specify your email address.

Assuming that it's too late to change the DirectoryString definition, one
change in usage which would go a long way towards fixing the current mess is
to require the following:

  PrintableString - Use this if possible.
  T61String - Can only contain 8859-1, no escape sequences or anything else.
  BMPString - Use this if it's not 8859-1.
  UniversalString - Don't use this at all.

as well as requiring strict compliance to the "least general" encoding rule
(this isn't done at the moment, I know of at least one widely-used
implementation which seems to randomly use T61String in place of
PrintableString).

Currently, since T61String allows escape sequences, you can move from the
default 8859-1 to pretty much anything, including gratuitous changing of
codesets simply to foil direct comparisons of characters.  Restricting it to
8859-1 only would fix this problem.

Given that it's unlikely that any implementations to date use T61String for
much other than 8859-1 (apart from ones which stuff anything into a T61String,
which are broken anyway), it should be possible to make the change without
breaking things too much.  It would also be really nice to drop in
VisibleString in place of that &*#$ PrintableString, but I guess that would
break too many implementations.

Peter.

Approved-By: [email-masked]
Date:         Tue, 24 Mar 1998 19:38:22 +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: Bengtsson Jim <[email-masked]>
Subject:      [IETF-PKIX] Cross certification question
To: [email-masked]

Hi,

I have a question on cross-certification described in "Certificate
Management Protocols", chapter 4.6(revision 7).

It is stated:
"The requester CA writes the requester certificate to the Repository".
Shouldn´t it be stated "The requester CA writes the received
cross-certificate to the Repository"?

It isn't stated that the responder CA should distribute the
cross-certificate to its repository(along  the rest of the certificates
it issued, and a regulary updated CRL); then why is the statement I
asked about stated present?

Regards,
Jim Bengtsson

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 9 Mar 1998 10:43: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> From: Tony Bartoletti <[email-masked]>
>
> > From: [email-masked]
> >
> >Wrong mailing list.  What you said above is the SPKI notion, but it's not
> >the PKIX notion, of the semantics of the subject name field in a
> >certificate.
> >
> >Steve
>
> I agree with your characterization of subject name SPKI vis-a-vis PKIX.
>
> Dan makes a secondary point, in that the cost of carrying different keys
> for every usage (identification or authorization, I suppose) be weighed
> against the potential privacy concern of having one key (especially in
> the case of an identity role) employed so widely that tracking usage on
> the one key produces a virtual dossier on the owner.

Tony's characterization is eloquent enough that it cannot be improved
upon, but merely restated.  By following the "wallet and paper signature"
model and having a single public key which announces "This Is Me!", users
would be voluntarily adopting the very thing they refuse to have
imposed upon them externally: a national ID.

My primary objection to multiple certification is the lack of handling
flexibility, not usage tracking.  If certificates are analogous to the
contents of a wallet, then I would like to be able to dynamically decide
what to carry in my wallet depending on where I'm going.  Normally I'd
carry everything, for convenience.  But if I'm going on a trip, I'd
remove the cards I'm not expecting to need so that if the wallet is
lost or stolen, I don't have to cancel everything.

In a token or key database, if every certificate's copy of the
private key has the same value (or in Paul Koning's model, which I
haven't heard of being supported in commercially available tokens or
applications, every certificate refers to the same storage location for
the private key), then the assignment of certificates to storage
modules is done once at issuance.  But if every certificate uses a
different private key, then those keys can be moved in and out of the
storage module as needed to accommodate where the module will be used.
I might normally want to keep my "AMEX Platinum" key on my smartcard,
but if I were going to plug that smartcard into a mall kiosk or an IETF
terminal room machine, I'd rather take the AMEX key off and leave just
an S/MIME email key on the card.

The third objection to multiple certification is that it leads
inexorably to a permanent key that cannot be updated.  Although it is
impossible for a single CA to verify that a key has not been certified
somewhere else, it is certainly possible and often desirable for that
CA to ensure that the key is changed at renewal.  But if a single key
is used for all certificates, and the validity dates for all CAs are
not synchronized, then it is impossible for any CA to rekey it's own
subjects' certificates, much less establish rekey periods that are
appropriate for the purpose of the certificates.

In summary, the disadvantages of a shared key across certificates include:

* inability of the user to change the contents of a storage module
* inability for any CA to establish a policy of rekeying on reissuance
* enables usage tracking
* not supported by current applications (counterexamples welcome)

The advantages include:

* might save memory (if each cert doesn't keep it's own copy of the
  private key).

With regard to comments that a standard requiring users not to share
keys is "unenforceable":  so is any standard recommending behavior that
is in the user's interest.  No one is going to jail for failing
to eat their Recommended Daily Allowance of Vitamin A.  But it is
nonetheless useful to publish RDA numbers ("standards") for vitamins
and minerals to allow consumers to make educated decisions based on
information published by nutrition experts and food producers.

PKIX is an information resource, not just a technical interoperability
specification.  Let's write security considerations that provide some
useful guidance on choosing a key sharing policy.

Dave Kemp

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 24 Mar 1998 11:08:00 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

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

Content-Type: text/plain; charset=us-ascii

Michael Myers <[email-masked]> scrawled:
>
> You raise some very good points about the details implied by caching.
> Transport independance further complicates this subject.  We should expect
> that some environments can and will inject client-transparent cache
> management mechanisms.  What's your opinion of  companion draft approach,
> where the OCSP spec defines the basic point-to-point interface while a
> companion draft addresses requirements, assumptions and recommendations
> regarding caching?

Capital idea!  I'll even volunteer to write it.

                Marc

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

Approved-By:  Russ Housley <[email-masked]>
Date:         Tue, 24 Mar 1998 13:25: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: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Using PKIX
To: [email-masked]

At 07:46 AM 3/24/98 -0500, Frederik Loeckx wrote:
>1)  Yes, I am also a European guy addicted to Hardware Tokens.  My question
>is about how to make a distinction between a Hardware Key and a Software
>one.  Suppose you have a Certification Authority which supports centralised
>key generation, both in software and on hardware tokens (suppose one of the
>Internet CA's would like to do this),
>        1) How can an EE tell the CA where to store the Certificate and the
>secret key?

Is this really necessary?  If the CA sends the centrally generated keying
material to the EE, the EE will store it in the appropriate place.  When a
hardware token is used, I would hope that the keying material to revover
the private key is available only on that token.  In this case, the private
key cannot be used until it is put on the token and recovered.

>        2) Is there a way to transmit all the stuff to use the smartcard
>(unblocking PIN, access PIN, ..) along with the message in a secured way?

This is a good question.  PKIX has never looked at the issues associated
with distributing token specific information.  It might be useful to define
extensions to the protocols (once they are stable) for this information.
All of the protocols have extension mechanisms.

Russ

Approved-By:  Russ Housley <[email-masked]>
Date:         Tue, 24 Mar 1998 13:56: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: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

PKIX Part 1 says:

   Conforming CAs are not required to issue CRLs if other revocation or
   status mechanisms are provided.  Conforming CAs that issue CRLs are
   required to issue version 2 CRLs, and must include the date by which
   the next CRL will be issued in the nextUpdate field (Section
   5.1.2.5).  Conforming applications are required to process version 1
   and 2 CRLs.

Therefore, it seems to me that nextUpdate should be required.

Russ

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 24 Mar 1998 11:22:07 -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] Using PKIX
To: [email-masked]

Hi Frederik,

>----------
>From:  Frederik Loeckx[SMTP:[email-masked]]
>Sent:  Tuesday, March 24, 1998 7:46 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Using PKIX
>
>Hello everybody,
>
>I am trying to fit the PKIX messages onto some global Public Key
>Infrastructures I can think off.
>
>This exercise was pretty usefull and most of the cases are fully covered by
>PKIX.  There are however two situations in which I don't know what to do.
>Perhaps the list can help me finding a way out.

The situations you describe are not explicitly covered by the CMP/CRMF
documents.  However, these documents specify a framework within which
you can certainly accommodate what you need.

>1)  Yes, I am also a European guy addicted to Hardware Tokens.  My question
>is about how to make a distinction between a Hardware Key and a Software
>one.  Suppose you have a Certification Authority which supports centralised
>key generation, both in software and on hardware tokens (suppose one of the
>Internet CA's would like to do this),
>        1) How can an EE tell the CA where to store the Certificate and the
>secret key?

There are a couple of options here.  I think the preferred route is to
define another choice for the PKIArchiveOptions control in CRMF
(something like "storeOnHardwareToken  [3]  BOOLEAN").  The second
possibility is to define a new Control for the request (again, something
like "StoreOnHardwareToken ::= BOOLEAN").  Note that in either case, the
CMP CertResponse message would have a status of "granted" but would omit
the optional certifiedKeyPair.

>        2) Is there a way to transmit all the stuff to use the smartcard
>(unblocking PIN, access PIN, ..) along with the message in a secured way?

Yes.  Since this is not specific to each certificate in the CMP
CertReqMessages or CertRepMessage (assuming there are multiple), but is
instead related to the message as a whole, this is a good example of a
use for the generalInfo field of the CMP PKIHeader.  An InfoTypeAndValue
can be defined to carry this data (perhaps with syntax EncryptedValue
from CRMF).  Note that if this data is generated by the CA and sent to
the EE (e.g., for cases in which the CA initializes the hardware token
itself) then the EE should send a protocolEncryptionKey control in the
CertRequest so that the data can be protected for confidentiality.

>2) I have a problem with the CertTemplate where the whole
>SubjectPublicKeyInfo is treated as one big entity.  Suppose (in the same
>case of centralised keygen), I want to be able to request a 1024 bit RSA
>key (and not an 512 bit one).  This means I need to transmit the modulus
>length somewhere in the message.  The only possibility I have found, is to
>include some dummy modulus and exponent in the SubjectPublicKeyInfo field.
>But now the CA thinks I am asking him to certify my public key instead of
>generating a new keypair for me.  Am I missing something?

There are three possibilities here.  I think the preferred route is to
send nothing in the SubjectPublicKeyInfo but to send a
protocolEncryptionKey control (the size of the modulus in the protocol
encryption key dictates the size to use for the modulus of the
centrally-generated key pair).  Another alternative is the one you
suggest in which a modulus and exponent are transmitted but are clearly
not intended as the public key (e.g., a modulus of 2**1023 and an
exponent of 0).  Thirdly, a new control can be defined for the request
(something like "SizeOfReqModulus ::= INTEGER").

Again, the situations you describe can be handled in the existing
CMP/CRMF framework.  Furthermore, one or more of the proposals presented
above can be standardized if there is sufficient interest in doing so.

Thanks for your interest!

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

Approved-By:  Frederik Loeckx <[email-masked]>
Date:         Tue, 24 Mar 1998 07:46: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: Frederik Loeckx <[email-masked]>
Subject:      [IETF-PKIX] Using PKIX
To: [email-masked]

Hello everybody,

I am trying to fit the PKIX messages onto some global Public Key
Infrastructures I can think off.

This exercise was pretty usefull and most of the cases are fully covered by
PKIX.  There are however two situations in which I don't know what to do.
Perhaps the list can help me finding a way out.

1)  Yes, I am also a European guy addicted to Hardware Tokens.  My question
is about how to make a distinction between a Hardware Key and a Software
one.  Suppose you have a Certification Authority which supports centralised
key generation, both in software and on hardware tokens (suppose one of the
Internet CA's would like to do this),
        1) How can an EE tell the CA where to store the Certificate and the
secret key?
        2) Is there a way to transmit all the stuff to use the smartcard
(unblocking PIN, access PIN, ..) along with the message in a secured way?

2) I have a problem with the CertTemplate where the whole
SubjectPublicKeyInfo is treated as one big entity.  Suppose (in the same
case of centralised keygen), I want to be able to request a 1024 bit RSA
key (and not an 512 bit one).  This means I need to transmit the modulus
length somewhere in the message.  The only possibility I have found, is to
include some dummy modulus and exponent in the SubjectPublicKeyInfo field.
But now the CA thinks I am asking him to certify my public key instead of
generating a new keypair for me.  Am I missing something?

Regards,

Frederik Loeckx

Approved-By:  Nada Kapidzic Cicovic <[email-masked]>
Date:         Tue, 24 Mar 1998 12:30:14 +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: Nada Kapidzic Cicovic <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

At 12:23 3/20/98 -0500, Russ Housley wrote:
>At 05:13 PM 3/19/98 +1200, Peter Gutmann wrote:
>>4.2.1.2.
>>
>>This gives the subject key identifier as the hash of the
subjectPublicKeyInfo
>>*without* the tag and length.  Is this a mistake, or is it meant to be like
>>that?  Every other instance in which an ASN.1 object is hashed (eg
>>certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes the
>>entire object.  In fact the PKIX CMP draft uses a hash of the full
>>subjectPublicKeyInfo in the OOBCertHash, which would make it incompatible
>with
>>the value in the subject key identifier.  Requiring a well-defined standard
>>X.509 object to be broken up into pieces before processing it seems an
>>extremely peculiar move, so I'm guessing it's some sort of mistake in the
>spec.
>
>This was done prior to the CMP section.  To use the public key, you need to
>get the value out of the certificate without the associated ASN.1 stuff, so
>that was the reason we chose to hash just the key.

However, for RSA public keys you still have ASN.1 there, since the public
key consists of n and e, which are coded as ASN.1 sequence. Therefore, your
reasoning does not hold.

I suggest to use whole SubjectPublicKeyInfo for calculation of key ids, to
avoid confusion and have compatibility with CMP OOBCertHash.

....

>>7.3.2.
>>
>>This gives a redundant definition of the DH p and g values (the ASN.1
>>definition is followed immediately by text which says exactly the same
>thing -
>>actually the RSA definition does this too with n and e), but doesn't explain
>>the INTEGER which is the DH public key (what *is* this value?  The only
thing
>>I can think of is g^x mod p, but that shouldn't be a fixed value).  It also
>>goes to some lengths to explain the encoding of the INTEGER parameter as a
>BIT
>>STRING, which seems very odd.
>
>Whould you like to suggest improved text?
>
>Russ
>

I would like to suggest the following change in the text:

Instead of:

"The Diffie-Hellman public key (an INTEGER) is mapped to a
subjectPublicKey (a BIT STRING) as follows: the most significant bit
(MSB) of the INTEGER becomes the MSB of the BIT STRING; the least
significant bit (LSB) of the INTEGER becomes the LSB of the BIT
STRING."

to have:

"The DSA public key shall be ASN.1 encoded as an INTEGER; this
encoding shall be used as the contents (i.e., the value) of the
subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
data element.

        DHPublicKey ::= INTEGER -- public key y = g^x mod p"

This would be in accordance with DSA public key definition from 7.3.3.

Regards,

Nada

______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 23 Mar 1998 14:17:53 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

Paul,

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, March 23, 1998 9:52 AM
Subject: Re: [IETF-PKIX] OCSP Update

>>I agree that the semantics of nextUpdate need refinement.  I've placed a
>>note in the v.04 text (the one I posted) calling attention to this issue.
>>I would prefer that nextUpdate have exactly the same semantics as its
>>counterpart in X.509 CRLs, nothing more and nothing less.
>
>But the wording in the new OCSP is *much less* than what is in PKIX part 1.
In
>part 1, there is no disclaimer to the validity of the data between the two
>time, at least none that I could find.

The text on nextUpdate in the v-04 draft was largely drawn from the RCSP
contribution.  I placed a note in the text regarding these statement rather
than take a unilateral position in the update.  This view of nextUpdate
clearly  needs resolution against the commonly held view of nextUpdate in
CRLs, which OCSP is intended to replace for some environments.

If we conclude that { thisUpdate-nextUpdate} semantics are broken, then
they're broken for both OCSP and X.509 CRLs.   If not, then X.509 semantics
should apply.

>
>>The use of nextUpdate is not restricted to caches.  Caches accelerate
basic
>>functions; consider LDAP.  That said, we should not presume responses
can't
>>or won't be cached.  The exact mechanism may vary now by transport.
>
>If we suspect that there will be any caching, we have to add very strong
words
>about it and about cache time skew problems to the OCSP draft. The time
skew
>problems for HTTP caches were discussed in grotesque detail on the HTTP WG
>mailing list about two years ago, and they are amazingly complex and
>dangerous.

I'm confident that Phill can fill us in here when his travel plans enable
him to do so.

>
>If caching is allowed, I believe that we have to change nextUpdate to being
>required in every message, and we have to define it much more tightly than
we
>do now. For instance, what if a cache has a recent response that says
>"notRevoked", and then is too busy to cache a following response that says
>"revoked"? The user querying the cache would have no idea of the latter,
and
>without a nextUpdate that means something, would have no way to find out
the
>real value or to even know that they were getting a stale value.

I have no problem mandating nextUpdate.  There is  a modest bandwidth impact
but resulting reduction is options enhances interoperability.  Real time
responses would set both values equal.

>
>My preference is to say "no caching is allowed", but if others in the WG
want
>caching (and I fully agree that it could help relieve OCSP servers), we
>need to
>look at what that means to users of the cached data.

You raise some very good points about the details implied by caching.
Transport independance further complicates this subject.  We should expect
that some environments can and will inject client-transparent cache
management mechanisms.  What's your opinion of  companion draft approach,
where the OCSP spec defines the basic point-to-point interface while a
companion draft addresses requirements, assumptions and recommendations
regarding caching?

>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

Mike

Approved-By:  Stephen Kent <[email-masked]>
Date:         Mon, 23 Mar 1998 07:28: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Unique Identification of a Certificate
To: [email-masked]

Slava,

While the hash of a CA's key would likely be unique, it also is a terrible
search key in many instances. One has to be careful about the context in
which a pointer to a CA cert is being used. In a cert, having a CA "key ID"
that is based on the hash of the CA is fine, because we already have the CA
name, and maybe even a locator.  In other protocol context we should have a
similar level of naming for search purposes, and rely on something like a
key hash just for disambiguation among multiple possible keys associated
with the same CA.

Steve

Approved-By: [email-masked]
Date:         Mon, 23 Mar 1998 13:22: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: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Comments on draft CMMF-00
To: [email-masked]

Here are the first set of comments that I have on this draft:

1.  Lets combine this with CRMF to produce a single draft of all messages.
The reasons for breaking them into two drafts no longer exist to the best of
my knowledge.

2.  Formatting issue:  Should be some space before the start of section 4.

3. Section 4.2 - Need to put in a defintion for PKIFreeText into this draft.
Should not have to reference CMP for this, it is now a primitive.

4. Section 4.4 - I can see the use of having both encryptedValue and
cMSEnveloped in the EncryptedData type, however I see no use for the last
two types.  All they are doing is making the structures more difficult and
harder to interop with, more options mean more problems.  Additionally I
have heard of no current efforts to move the PKCS #8 and 12 into IETF
drafts.

5.  Section 4.4 - I don't understand the reasoning behind the fact that RSA
uses a symmetric key and D-H does not.  It seems reasonable to me to say
that you don't need to have the encrypted symmetric key in D-H, but allow it
anyway.  If you are going to put the text in this manner please change it to
working such as the following:

"For key agreement algorithms (such as Diffie-Hellman), the encSymmKey field
of EncryptedValue is not included.  For key exchange algorithms (such as
RSA), the encSymmKey is a symmetric key encrypted under the subscriber's
public key."

6.  Section 5.2.1 -- I need far more information about what the structure of
rspInfo should be?  If we don't define it then we can't possibly get a get
interopability.  There appears to be a vague reference to it being
name/value pairs, but this is not certian from the text.

7. Section 5.1 - Please add a certReqId to the PKCSReq type.  This allows
for a correct value to be placed in a CertRepContent in the event that
multiple PKCSReqs are sent to a CA.

8. Section 5.3 - Need to add a CertReqId to this message. If multiple
requests have been sent in then this would be needed to disabmiguate the
different requests.

9. Section 5.3 - Does this imply that you must put a subject and issuer into
the certificate request if you want to use this polling method?  Does this
imply that a CA cannot return PENDING as a code in the event that a subject
and issuer name have not been placed in the request? or just that the
certificates cannot be polled for?

10. Section 5.4 - How do I retrieve a CRL in the event that the CA has an
empty Issuer name?  Do I put the empty name in the issuerName field or do I
extract a portion of the IssuerAltName?

11. Section 5.5.1 - Should change PrintableString to UTF8string in the
RevRequest ASN.

12. Section 5.5.1 - Why is there not a SEQUENCE OF RevRequest defined?  The
text about certDetails in RevReqContent implies to me that the RevRequest
form would be perfered if you actually knew the issuer and serial number.  I
see nothing which would prevent the usage of the RevReqContent except for
the "I don't have access to my keys any more" case.

13. Section 5.6 - Please change the first sentence to: "The response to the
RevReqContent message."  I am making an assumption that this message would
not be generated in response to a RevRequest message since the first
sentence is currently singular rather than plural.  This may be a bad
assumption.

14. Section 5.7 - Please change FullCertTemplates in the comment for
POPODecKeyChallContent to CertReqMessages.

15. Section 5.7 - In order to make the association between the request and
the challenge clearer, I strongly suggest adding a CertReqId field to the
Challenge structure.  This means that we could remove the order association
in the comment on POPODecKeyChallContent if desired and still have correct
associations.

16. Section 5.7 - It would appear to be that something should definitely be
said about the suggested length of A being used in the challenge,  I also
see some potential problems about the total length of the integer and the
senders GeneralName.  What should be done if the encoding of Rand happens to
be larger than the longest value that is encryptable by the public key?  If
you are using a bulk algorithm for doing the key exchange/key agreement
versions, then you must specify the AlgorithmIdentifier of the bulk
encryption algorithm.

17. Section 5.7 - What would be the correct way to say that I failed to do
this?  THere is a success body content defined but not a failure body.  I
can see this as possibly being handled in the overlying protocal but that
potentically should be stated.

18. Section 5.7 - There is a reference to PKIHeader, but I can not find the
defintion of this in either CRMF or CMMF.  Please put in a defintion or
correct the reference.

19. Section 5.9 - The second sentence in this paragraph implies that I will
be generating a response to these announcement messages.  I cannot believe
that this is what was intended. I would suggest "These messages are
generally unsolicited and may be received by End Entities at random times."

20. Section 5.9.1 - I disagree that the old CA private key is no longer
required after sending out this message.  I think that you still need the
old CA private key to produce CRLs right up to the time that the old CA
certificate expires.  Here the the problem that I see with your statement.
Lets say that I am using my own private CA which is publishing CRLs via an
HTTP link.  I send you a signed message with my certificates and the current
(old) chain.  The CA then updates it key set and send me the information and
publishes out a CRL signed with its (new) private key.  You then attempt to
verify the message I sent you and pick up the CRL.  You are unable to verify
the signature on the CRL and thus the message I sent you.  If I now send you
a new message it will verify since I have the new chain of certificates to
send to you.  This is fine in a closed environment but not on the internet.

21.  Section 5.10 - From the fact that the CA is just anouncing this
information, am I correct in assuming that the request for this would come
from an Out-Of-Band request?  It makes no sense to me that this would just
randomly show up in my mailbox.  I would feel very srongly that this should
be an explicit request/reply message in the normal format rather than tan
anouncement message.

22. Section 5.10 - The structure includes a field for newSigCert, how and
where was the request for this certificate made if this is just a random
annoucement? (I use the words random from a client point of view.  I know
that the CA will only generate this message in response to some well defined
events, but the client does not see those events.)

23. Section 5.11 - There are a set of examples that are partially defined.
It would appear that atleast some of the items in the examples
(CAKeyUpdateInfo) are explicitly called out in the spec and therefore should
not appear here.

24. Section 5.11/5.12 -- I give up.  This is not defined enough for me to
even start to understand how to use these messages.

25. Section 6. There is a warning in this section about the unadvisablity of
doing arbitrary decryptions and sending them back to somebody.  It would
appear to me that this is very close to what is being done in the
challenge/response POP seqeuences.  I think a paragraph either here or in
the section on the POP messages would be in order about why I should not
consider this to be an explicitly documented version of this attack I am
suppose to ipmlement.

26. Need an appendix containing the ASN pulled out into a single module for
easy reference.

jim schaad

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 23 Mar 1998 15:24: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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

Hi David,

>----------
>From:  David P. Kemp[SMTP:[email-masked]]
>Sent:  Monday, March 23, 1998 2:43 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP Update
>
>> From: Paul Koning <[email-masked]>
>>
>>  IMC> My preference is to say "no caching is allowed", but if others
>>  IMC> in the WG want caching (and I fully agree that it could help
>>  IMC> relieve OCSP servers), we need to look at what that means to
>>  IMC> users of the cached data.
>>
>> I find it very hard to imagine that a "no caching allowed" rule will
>> turn out to be acceptable.  Yes, caching creates some new issues; I'd
>> say those issues need to be addressed.
>
>Original OCSP attempted to satisfy two radically different purposes:
>1) efficient distribution of timely certificate revocation status, and
>2) simplifying end-user systems by relieving them of the burden of
>   validating certification paths.

...

>My view of OCSP is that it serves purpose 2 only, and should thus be
>called "Online Certificate Validation Protocol".  A relying party
>could operate a "validation proxy server" to perform all path validation
>tasks (trust point maintenance, cert storage and retrieval, signature
>verification, validity period checking, revocation checking, processing
>certificatePolicies, etc.)  Applications would query the validation
>proxy using OCVP, conceptually using statically-configured keys to
>avoid the bootstrapping problem (they could be symmetric keys for
>performance), and all clients of a given validation proxy MUST be
>considered a single Relying Party.

I tend to disagree here.  It seems to me that "purpose 2" is falls
nicely within the scope and concept of the notary protocol, whereas
"purpose 1" is what may be covered by OCSP.

>The path validation engine, whether located in a proxy server or built
>into each application, needs to get timely revocation status from the
>CA.  But the CA-to-validation-engine protocol should be different from
>the validation-proxy-to-client protocol, because they do two different
>things.
>
>If we are designing an "Online Certificate (Revocation) Status
>Protocol", to satisfy purpose 1, then it must not cache responses
>received from the CA unless the response contains a CA-generated
>expiration time, in which case the response may be cached only until
>it expires.  I believe that the per-certificate nature of the current
>OCSP and RCSP drafts make them less suitable for distributed cache
>maintenance than a bulk-update protocol based on CertificateLists.

I agree with this.

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

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 23 Mar 1998 14:43: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

> From: Paul Koning <[email-masked]>
>
>  IMC> My preference is to say "no caching is allowed", but if others
>  IMC> in the WG want caching (and I fully agree that it could help
>  IMC> relieve OCSP servers), we need to look at what that means to
>  IMC> users of the cached data.
>
> I find it very hard to imagine that a "no caching allowed" rule will
> turn out to be acceptable.  Yes, caching creates some new issues; I'd
> say those issues need to be addressed.
>
>         paul

I agree with Paul Hoffman - my preference is "no caching allowed" for
certificate revocation status, not because it couldn't in principle
be made to work, but because if caching appears to be needed then CRLs
are a better mechanism for maintaining consistency between the CA and
caching servers than individual per-certificate transactions.

Original OCSP attempted to satisfy two radically different purposes:
1) efficient distribution of timely certificate revocation status, and
2) simplifying end-user systems by relieving them of the burden of
   validating certification paths.

Attempting to satisfy both requirements with a single protocol just
results in confusion between the two purposes.  Revocation status must
flow from the CA to the Relying Party and thus involves communication
efficiency / timeliness tradeoffs.  Path validation must be performed
by the Relying Party itself, but is a static function of its inputs.

My view of OCSP is that it serves purpose 2 only, and should thus be
called "Online Certificate Validation Protocol".  A relying party
could operate a "validation proxy server" to perform all path validation
tasks (trust point maintenance, cert storage and retrieval, signature
verification, validity period checking, revocation checking, processing
certificatePolicies, etc.)  Applications would query the validation
proxy using OCVP, conceptually using statically-configured keys to
avoid the bootstrapping problem (they could be symmetric keys for
performance), and all clients of a given validation proxy MUST be
considered a single Relying Party.

The path validation engine, whether located in a proxy server or built
into each application, needs to get timely revocation status from the
CA.  But the CA-to-validation-engine protocol should be different from
the validation-proxy-to-client protocol, because they do two different
things.

If we are designing an "Online Certificate (Revocation) Status
Protocol", to satisfy purpose 1, then it must not cache responses
received from the CA unless the response contains a CA-generated
expiration time, in which case the response may be cached only until
it expires.  I believe that the per-certificate nature of the current
OCSP and RCSP drafts make them less suitable for distributed cache
maintenance than a bulk-update protocol based on CertificateLists.

Approved-By:  Paul Koning <[email-masked]>
Date:         Mon, 23 Mar 1998 13:04:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Comments:     Hyperbole mail buttons accepted, v04.023.
From: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

>>>>> "IMC" == IMC  <Paul> writes:

>...
 IMC> My preference is to say "no caching is allowed", but if others
 IMC> in the WG want caching (and I fully agree that it could help
 IMC> relieve OCSP servers), we need to look at what that means to
 IMC> users of the cached data.

I find it very hard to imagine that a "no caching allowed" rule will
turn out to be acceptable.  Yes, caching creates some new issues; I'd
say those issues need to be addressed.

        paul

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Mon, 23 Mar 1998 12:47:01 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: Scott Guthery <[email-masked]>
To: [email-masked]

"Scott Guthery" writes:
> >In any real financial transaction system in use *today*, the
> >relationships are bilateral and there is no need for third party
> >identity verification, since the bilateral counterparties have
> >prearranged their relationship.
>
> Barter is the only one I can think of and even in this case there are
> consumer protection laws.  Cash is backed by social 'suasion or
> its issuer.

Not quite.

"Cash" used to mean "gold". Gold is not backed that way.

Banknotes, which you are refering to, used to be standard commercial
paper in the manner of any other commercial paper. As such, they were
not automatically accepted by a creditor -- and a creditor would often
demand endorsement of the banknote. (People might be interested in
finding out what the legal implications of endorsement are. I suppose
one could still demand endorsement of a $100 bill on the premise that
it might be counterfeit, but in practice no one does so.)

You are correct that since the creation of legal tender laws and the
Fed, we no longer have private issuance of banknotes, and thus federal
reserve notes are treated as though they were cash in our
system. However, for our purposes, $100 bills count as "gold
substitutes". To put it another way, both parties have a bilateral
arrangement with the Federal Government, implicitly via its imposition
of the legal tender laws.

> Checks are backed by a legal system and its incarceration powers.

True enough, but as merchants rarely get paid off on bounced checks
from strangers, what counts to a bank is whether they are going to get
paid off of the individual check they have been handed, and not
whether ultimately some criminal sanction might be brought. Thus, the
reluctance of many merchants to take non-certified checks, and a
series of bilateral arrangements at places that do take checks, like
Supermarkets that set up "courtesy check cashing cards" and other
schemes to limit risk.

By the way, I will point out that the check case is COMPLETELY
bilateral. There is no legal obligation on the part of the bank to the
merchant -- the bank is not liable if the check bounces, and the
merchant has no legal relationship with the merchant of any other
sort, either. The check is an order to the bank from its customer (who
happens to be the merchant's customer as well) ordering disbursment of
funds, but the check is NOT an instrument of the bank, and the bank in
no way guarantees payment. If there is a default, it is the customer
who owes money, not the bank. "Bilateral relationships".

> Credit and debit cards rest on contracts between the cardholder and
> the merchant with the bank or the bankcard association.

Bilateral arrangements, all.

> Giros, ATMs, ACH etc. all have active third party involvement.

Nope. They are all a series of bilateral arrangements.

Take an ATM, for example. You present a bank card to a NYCE
machine. The bank tells NYCE you are withdrawing money, NYCE tells
your bank, your bank tells NYCE "yes, I'll pay off that sum", and at
that point NYCE tells the bank card machine owner that it will
guarantee that you get paid. No third party arrangements -- all are
bilateral arrangements.

> The question is not if there will be a third party but who will it
> be.

ALL clearing and settlement rests ultimately on bilateral
arrangements. ALL of it.

You are inaccurately labeling intermediaries third parties, which they
are not -- they are engaged in intermediation, which is different.

> Being a third party to financial transactions is a very, very good
> business to be in

There are no "third parties" to financial transactions.

That is why the phrase is INTERMEDIATION. Financial institutions act
as INTERMEDIARIES to a pair of bilateral transactions -- not as third
parties in a multilateral transaction. The liability is all bilateral.

When I trade stock, I do not care if the counterparty fails to
deliver, because my *intermediaries* assume liability for that. If
there is a failure to deliver, the counterparty's broker has to
deliver. That is part of what they get paid for -- their
intermediation involves a guarantee to deliver.

Even seemingly "multiparty" transactions never are. Take cosignature
of a debt instrument. The cosigner is guaranteeing payment, and
assumes all risk in exchange for another arrangment with the
debtor. The lender disburses funds to the debtor, but it is the
cosigner that assumes all risk, not the debtor, which is why the
cosigner ends up being the entity that the lender credit checks. The
arrangement is effectively (again) bilateral.

Now, digital signature technology has dramatic potential for lowering
the costs of intermediation, and simpling intermediation by reducing
the number of intermediaries that have to be involved. However, as all
the counterparties to all the individual bilateral components of a
transaction continue know each other, there is no need for third party
identity verification.

Perry

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 23 Mar 1998 09:22:30 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

>I agree that the semantics of nextUpdate need refinement.  I've placed a
>note in the v.04 text (the one I posted) calling attention to this issue.
>I would prefer that nextUpdate have exactly the same semantics as its
>counterpart in X.509 CRLs, nothing more and nothing less.

But the wording in the new OCSP is *much less* than what is in PKIX part 1. In
part 1, there is no disclaimer to the validity of the data between the two
time, at least none that I could find.

>The use of nextUpdate is not restricted to caches.  Caches accelerate basic
>functions; consider LDAP.  That said, we should not presume responses can't
>or won't be cached.  The exact mechanism may vary now by transport.

If we suspect that there will be any caching, we have to add very strong words
about it and about cache time skew problems to the OCSP draft. The time skew
problems for HTTP caches were discussed in grotesque detail on the HTTP WG
mailing list about two years ago, and they are amazingly complex and
dangerous.

If caching is allowed, I believe that we have to change nextUpdate to being
required in every message, and we have to define it much more tightly than we
do now. For instance, what if a cache has a recent response that says
"notRevoked", and then is too busy to cache a following response that says
"revoked"? The user querying the cache would have no idea of the latter, and
without a nextUpdate that means something, would have no way to find out the
real value or to even know that they were getting a stale value.

My preference is to say "no caching is allowed", but if others in the WG want
caching (and I fully agree that it could help relieve OCSP servers), we
need to
look at what that means to users of the cached data.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 23 Mar 1998 08:46:14 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

Paul,

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
>Thank you for responding this quickly, Mike! I believe you are right, that
>this will help reduce the amount about OCSP the WG needs to talk about in
LA.
>
>A few notes:
>
>>Changed all occurrences of "producedAt" with "thisUpdate".
>
>Er, not all of them. You left producedAt in the ASN.1. :-)

Thanks for the catch.

>
>>QUESTION:  Meaning of thisUpdate (formerly producedAt) field.  Is it the
>>time at which the response was signed, or the time when the certificate
was
>>placed on a CRL (that is, the value of thisUpdate of a CRL that may be
used
>>to source OCSP responses)?
>
>I think it has to be the time the response was signed. How would a
>requester know the difference between:
>>2.  revoked responses not sourced by a CRL.
>>3.  revoked responses sourced by a CRL.
>Unless you add a field that says "this response was sourced by a CRL", a
>requestor won't know what date you are referring to.

I agree that the value for thisUpdate should be the time at which a response
was signed.  I'm waiting to hear what others might think.

>
>>QUESTION:  Should we accommodate the following extended error cases?
>>
>>PROPOSED RESOLUTION:  Yes, by adding appropriate INTEGER values to
>>OCSPResponseStatus.
>
>But those integer values better be different than the ones you listed,
>since they overlap with the current response statuses.

Yes.  I did not want to disturb that spectrum prematurely.

>
>At the end of section 2.4, there are multiple disclaimers for the meaning
>of nextUpdate. To me, they make nextUpdate useless. And, now that the HTTP
>carrying mechanism is a POST instead of a GET, meaning the response can't
>be cached, I think there is no more use for nextUpdate. Since it is not
>definitive, based on the disclaimers, I think it should just be taken out.
>If people want it left in, I think it has to mean "the CA assures the
>recipient that the certificate status is valid until the nextUpdate time",
>which is a pretty scary thing to assure.

I agree that the semantics of nextUpdate need refinement.  I've placed a
note in the v.04 text (the one I posted) calling attention to this issue.
I would prefer that nextUpdate have exactly the same semantics as its
counterpart in X.509 CRLs, nothing more and nothing less.

The use of nextUpdate is not restricted to caches.  Caches accelerate basic
functions; consider LDAP.  That said, we should not presume responses can't
or won't be cached.  The exact mechanism may vary now by transport.

>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

Mike

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 23 Mar 1998 11:13: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Unique Identification of a Certificate
To: [email-masked]

> From: Denis Pinkas <[email-masked]>
>
> > Specifically one can eliminate the CA name (both primary and
> > alternative) from certificate identification. Instead one can use (a
> > hash of?) CA public key/serial number combination to identify a
> > certificate. This approach attempts to use one of the fundamental
> > assumptions made by SPKI working group that PKI principals are
> > essentially signing keys and names are just some of the attributes bound
> > to the key by means of issuing a certificate.
>
> In order to identify/fetch a certificate, the only way *for PKIX* to
> identify/retrieve a certificate is to use a CA name first, associated
> with either a subject name or a certificate serial number.
>
> This message is sent to the wrong mailing list. It belongs to SPKI, not
> PKIX.

I disagree.  Although the SPKI key-is-principal principle is unsuited
for identifying entities, it is perfectly reasonable to use a public key
to identify a specific issuer certificate.  The X.509 standard
authorityKeyIdentifier extension, which "identifies the public key to
be used to verify the signature on this certificate or CRL", recognizes
that fact.

If every CA had subjectKeyIdentifier in it's own certificates and
authorityKeyIdentifier in every certificate it issued, then one could
could fetch issuer certificates by key identifier.  But since that
practice is not ubiquitous (and if you allow a CA to have more
than one cert with a given key), it's also necessary to include the
issuer/serialNumber in any scheme to uniquely identify a certificate.

> CertID                  ::=     SEQUENCE {
>          issuerKeyHash            Hash,
>          serialNumber                    CertificateSerialNumber,
> }
>
> where issuerKeyHash is a hash of subjectPublicKeyInfo field from the
> corresponding CA certificate,

This is a reasonable approach if you ignore the cert retrieval and
multiple-key issues, however you still need to specify the hash
algorithm since it's inappropriate to hard code a single algorithm
into the standard:

   CertID ::= SEQUENCE {
      issuerKeyID       KeyID,
      serialNumber      CertificateSerialNumber }

   KeyID  ::= CHOICE {
      publicKey         [0] SubjectPublicKeyInfo,
      sha1KeyHash       [1] OCTET STRING,     -- SHA1 of SubjectPublicKeyInfo
      ripemd160KeyHash  [2] OCTET STRING,
       ...       }

All in all, it gets pretty ugly if you want to make it work in all cases.
It may be easier just to use the existing authority and subject key
identifier extensions instead of trying to design something new.

BTW, the current definition of AuthorityKeyIdentifier is an offense to
the sensibilities!  It's as if someone sat around and thought "ASN.1
has a WITH COMPONENTS construct - it'd be a shame if we couldn't come
up with some excuse to use it." The current extension should be
deprecated and replaced with:

   AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier   KeyIdentifier OPTIONAL,
      authorityCert   IssuerSerial OPTIONAL }

where IssuerSerial is as defined in X.509 (GeneralNames, serial number,
and optional UID).

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 23 Mar 1998 16:19:19 -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 Update
To: [email-masked]

Michael Myers wrote:

(...)

> NEW AND DEFERRED REQUIREMENTS
> -----------------------------
>
> Delegation
> ----------
> Deleted text addressing authority delegation requirements per recent list
> traffic on the subject.

Before addressing delegation, we need to solve the basic problem which
is to identify the right OCSP, when ambiguous CA names are being used.
This item should be moved in the "QUESTIONS FOR DISCUSSION" list.

(...)

> QUESTIONS FOR DISCUSSION
> ------------------------

(...)

> QUESTION:  Should we accommodate the following extended error cases?
>
> Standard values for reason-text SHALL include:
> "1   The root for this certificate is not trusted on this responder."

This item is no more relevant. We do not address validation, but
revocation status only.

> "2   Could not find CA’s public key."

This item is no more relevant. If it is the right OCSP, then it must
have the right information, otherwise it is a status like "service
temporary unavailable".

> "3   CA’s public key invalid."

I fear this also has to do with validation. Please explain ... or
delete.  :-)

> "4   CA’s public key revoked."
> "5   CA’s public key expired."

This status would only be sent if the CA certificate has not be renewed
in time; otherwise there should be a nice rollover between CA public
keys.

> "6   CA not authorized for Subject’s name."

This item is no more relevant. We do not address validation, but
revocation status only.

> "7   CA not authorized for Subject’s privileges."

This item is no more relevant. We do not address validation, but
revocation status only.

> "8   CA’s public key did not validate signature."

Please explain.

> "9   Could not find CA’s revocation information."
> "10  CA’s CRL out of date."

Fine.

(...)

I would like to add an additional topic to this list, since it seems
that we are re-inventing a new "year 2000" problem. Suppose that I
received a signed message on the monday but that the certificate has
expired during the week-end, I fear that I will get an expired status in
place of a "notRevoked" status.

Add the following question:

QUESTION: Is the "expired" status really needed/meaningful ?

Denis

P.S. There is a new version attached. I would like to mention that there
might be some good reason why the IETF does not agree to publish new
drafts after the deadline.

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 23 Mar 1998 15:38:54 -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] Unique Identification of a Certificate
Comments: To: Ambarish Malpani <[email-masked]>
Comments: cc: "Ietf-Smime (E-mail)" <[email-masked]>
To: [email-masked]

See an updated proposal for CertUID at the end of this E-mail.

Ambarish Malpani wrote:

> Hi Denis,
>     I joined the SMIME mailing list just recently, so I am not certain
> of the problem you guys are trying to solve. Let me explain the
> issues in RCSP and the reasoning for choosing the method I have
> for trying to uniquely identify a cert:

> In RCSP, a client is sending over one or more certificates to an
> RCSP responder, to check their revocation status.
> I think we all agree that issuer/serial is sufficient to uniquely
> identify a certificate.

I would disagree with this, unless "issuer" is a FDN in the X.521 sense.

> So the question is: how does one uniquely identify an issuer.

This is not the right question.   :-(

> I submit that the DN is not enough, because it is possible for
> the to be DN name clashes - either maliciously, or because two
> groups don't talk to each other before they choose their names.

DN can clash when they are RDNs (Relative Distinguished Names).

> There really is no way of enforcing uniqueness is issuer DNs all
> over the world.

Correct.

> However, public keys don't suffer from the problem of impersonation.
> If somebody else claims to have the same public/private key as me,
> it is easy to prove otherwise.

OK.

> Therefore, we have chosen to use the issuerDN, issuerPublicKey
> and CertificateSerialNumber to uniquely identify a cert. (I need
> to add the issuerAltName also, as you have).

The problem to consider is an empty DN and the use of an issuerAltName.
The issuerAltName and the CertificateSerialNumber do not necessarily
identify uniquely a certificate unless some additional assumptions are
made on the structure of the issuerAltName.

> As an optimization, to reduce the size of a request, we ask the
> requestor to hash the issuerDN and issuerPublicKey in the request
> rather than sending all the bytes.

Hold on a second. You suppose an upstream problem already solved !
If you get a signed message, you may need to identify who signed it and
with which certificate. The structure you propose below does not allows
this, unless by some magic you get an hint.

> Adding the certificateHash in the CertUID doesn't help us identify
> the cert at all, because as an RCSP responder, I don't have the
> cert itself - so I can't verify the CertHash against anything.

But it does help the requester  :-)

See also the response I sent today to Carlisle, where I raise the basic
question on the means to identify the right OCSP. If that question is
solved, then your problem is also solved. However, I do not claim that
the answer to that question is unique or easy. :-)

> As an aggregator of revocation data/CRLs from multiple CAs, we
> would like to be able to accept all CRLs - including ones where
> the DNs might clash.
>
> Is the SMIME problem different from this one? Does the recipient
> already have the certificate the sender is referring to?
>
> Regards,
> Ambarish
>
> P.S. For those who haven't been actively following these groups,
> my suggestion for cert identification is:
>
> CertID                  ::=     SEQUENCE {
>         issuerNameAndKeyHash            Hash,
>         serialNumber                    CertificateSerialNumber,
> }
>
> IssuerNameAndKey                ::=     SEQUENCE {
>         issuerDN                        Name,
>         issuerAltName                   IssuerAltName OPTIONAL,
>         issuerPublicKey                 SubjectPublicKeyInfo
> }
>
> i.e. you identify a cert by the hash of the IssuerNameAndKey
> and a serial number.
>
> The hash includes the public key of the issuer - this prevents the
> Banana Republic CA from impersonating our well beloved and well
> trusted US CA ;-).
>
> Ofcourse, if keeping the size of the request small is not important,
> or the recipient might not be able to figure out the issuer from
> the hash, it might make sense to send IssuerNameAndKey instead
> of its hash.
>
> Denis Pinkas wrote:
>
> > There is no final position yet, but it seems that we are going towards
> > the following structure:
> >
> > CertUID ::=     SEQUENCE {
> >      issuerDN           Name,
> >      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
> >      serial             CertificateSerialNumber,
> >      certificateHash    CertHash
> > }
> >
> > This allows the support of alternate names and the certificate hash
> > allows to make the difference between certificates that would be issued
> > by CAs having the same name.
> >
> > In any case, I would recommend that the pkix group and the smime group
> > adopt the same structure.
> >
> > Denis

There has been a proposal to make the certificateHash optional. If the
issuerDN is a FDN, then the certificateHash is not needed, so this is a
good reason. If the  issuerAltName has some form of hierarchy that
allows it to be unambiguous, in the same way the certificateHash is not
needed. In all the other cases, it is needed.

I would thus propose the following structure :

CertUID ::=     SEQUENCE {
      issuerDN           Name,
      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
      serial             CertificateSerialNumber,
      certificateHash    CertHash OPTIONAL
}

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 23 Mar 1998 14:18:30 -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] New OCSP Requirements (and new straw poll...)
To: [email-masked]

Carlisle,

I fear that you are opening a new topic of discussion. You wrote:

> > Certificate Identification  -  I think that CA DName with Serial
> > Number is sufficient.
>
> Denis and Ambarish both make valid points here:  we should try to align
> with the S/MIME group if at all possible, but the structure being
> discussed in that group is not sufficient if the OCSP responder does not
> have the certificate itself (e.g., if it only has the issuer's
> certificate and signed revocation information).  Perhaps a solution is
> to add "issuerCertHash" to the CertUID structure, but this is starting
> to look a bit unwieldy...

Another answer to the question would be to modify the format of the CRL
!
When the format of the CRL was designed, the name of the CA was a DN. So
there could be no ambiguity on the name of the CA. We now accept
Alternate names. This allows name collision between CAs.

If the CRLs were using the same structure (i.e. would add the
certificate hash in the CRL) then the OCSP responder could make the
check without the need to get the certificate. Also valid technically, I
do not think, it would be appropriate to make that change at this time,
if we can find another acceptable solution.

Another way is to suppose that the client may get the certificate and
find in the certificate enough information that allows him to make sure
that it talks to a right delegate of the CA.

We should address that issue in the "Security Considerations" section.

" For this service to be effective, requesters must connect to the
*right* certificate status service provider".

If we can correctly address that issue, then we can possibly solve the
problem of CA name homonyms.

I propose to add an item like "Right OCSP" to the list of issues to be
solved and identified by Mike.

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 23 Mar 1998 12:28:25 -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] Unique Identification of a Certificate
To: [email-masked]

Slava Galperin wrote:
>
> Ambarish Malpani wrote:
> >
> >
> > In RCSP, a client is sending over one or more certificates to an
> > RCSP responder, to check their revocation status.
> > I think we all agree that issuer/serial is sufficient to uniquely
> > identify a certificate.
> > So the question is: how does one uniquely identify an issuer.
> > I submit that the DN is not enough, because it is possible for
> > the to be DN name clashes - either maliciously, or because two
> > groups don't talk to each other before they choose their names.
> > There really is no way of enforcing uniqueness is issuer DNs all
> > over the world.
> > However, public keys don't suffer from the problem of impersonation.
> > If somebody else claims to have the same public/private key as me,
> > it is easy to prove otherwise.
> > Therefore, we have chosen to use the issuerDN, issuerPublicKey
> > and CertificateSerialNumber to uniquely identify a cert. (I need
> > to add the issuerAltName also, as you have).
> > As an optimization, to reduce the size of a request, we ask the
> > requestor to hash the issuerDN and issuerPublicKey in the request
> > rather than sending all the bytes.
>
> Actually if we do believe in the uniqueness of the CA signing key pair
> (which would better be true ! ;-) we can take even more extreme approach
> to identifying a cert.
>
> Specifically one can eliminate the CA name (both primary and
> alternative) from certificate identification. Instead one can use (a
> hash of?) CA public key/serial number combination to identify a
> certificate. This approach attempts to use one of the fundamental
> assumptions made by SPKI working group that PKI principals are
> essentially signing keys and names are just some of the attributes bound
> to the key by means of issuing a certificate.

In order to identify/fetch a certificate, the only way *for PKIX* to
identify/retrieve a certificate is to use a CA name first, associated
with either a subject name or a certificate serial number.

This message is sent to the wrong mailing list. It belongs to SPKI, not
PKIX.

> Although X.509 world heavily relies on combination of name/key
> identifier in certificate chaining I guess it would be a pretty safe
> assumption that most CA never use two CA certificates with different CA
> name and same key. Even if CA signing key pair is attached to many
> different names (possibly of different name forms), these names form
> equivalence class and are specified in a single CA certificate possibly
> using a combination of subject and subjectAlternativeName.
>
> Technically I am proposing to use either
>
> CertID                  ::=     SEQUENCE {
>          issuerKeyHash            Hash,
>          serialNumber                    CertificateSerialNumber,
> }
>
> where issuerKeyHash is a hash of subjectPublicKeyInfo field from the
> corresponding CA certificate, or
>
> CertID                  ::=     SEQUENCE {
>          issuerKey          SubjectPublicKeyInfo,
>          serialNumber                    CertificateSerialNumber,
> }
>
> in case we are afraid of the hash collisions and are willing to
> sacrifice some bandwidth for some peace of mind.
>
> Note however, that both in the original RCSP spec and in my proposed
> scheme above there is another interesting open problem of dealing with
> the CA
> key change-over, i.e. when various subsets of the set of all issued
> certificates (and CRLs !) are signed by different signing keys
>
> I would be very interested in group's comments.
> --
> Slava Galperin          Certified Certificate Certifier
> [email-masked]   tel: 650.937.6757
>
>  It doesn't matter so much whether you've won the war or lost it.
>  What matters is who you have lost it to.
>                             -- From the memoirs of a married man

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Scott Guthery <[email-masked]>
Date:         Mon, 23 Mar 1998 05:15:44 -0500
Reply-To: Scott Guthery <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Scott Guthery <[email-masked]>
Subject:      [IETF-PKIX] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0074_01BD561A.BB3E4280
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Perry Metzger notes ...

>In any real financial transaction system in use *today*, the
>relationships are bilateral and there is no need for third party
>identity verification, since the bilateral counterparties have
>prearranged their relationship.

Barter is the only one I can think of and even in this case there are
consumer protection laws.  Cash is backed by social 'suasion or
its issuer.  Checks are backed by a legal system and its
incarceration powers. Credit and debit cards rest on contracts
between the cardholder and the merchant with the bank or the
bankcard association.  Giros, ATMs, ACH etc. all have active
third party involvement.

The question is not if there will be a third party but who will it be.  That's
where the tectonic battle is today.

Being a third party to financial transactions is a very, very good
business to be in which is exactly why many governments give
themselves an exclusive license.  What is happening is that a new
competitor with a much lower cost structure has entered the market.
The new competitor is also offering to solve some anciallary
problems which has at least interested the monopolists who have
responsibility for these problems too.

1) The trick is extracting the transaction fee.  Sometimes it's only
    float, seigniorage or escheate. "Only" is used very loosely here.
   Seigniorage on US cash is worth roughly $25B/year and 1/4 of
   purchased French phone cards are never used.

2) All third parties will limit their risk and will seek to distribute what
     they can't eliminate.  Certificates are quanta of risk.  They have
     two useful properties as compared to existing risk packages: they
    encapsulate much small units of risk and their time unit is seconds
    rather than years.  Order of magnitude smaller risk for an order
    of magnitude less time all in a net-friendly format.  Hmmmmmm.

Digital certificates are not about identity.  They are about risk.

All IMHO, of course.

Cheers, Scott

------=_NextPart_000_0074_01BD561A.BB3E4280
Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="smime.p7s"

------=_NextPart_000_0074_01BD561A.BB3E4280--

Approved-By:  Stephen Kent <[email-masked]>
Date:         Sun, 22 Mar 1998 16:50:03 -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] New OCSP Requirements (and new straw poll...)
To: [email-masked]

Folks,

The ASN.1 change was clear enough to vote on.  Given the broader set of
proposed changes we are now discussing I think it worthwhile to purse this
in more detail at the WG meetings in LA. We can continue to explore these
issues on the mailing list in preparation for the meeting. However, I think
it premature to suggest that a solid vote for the use of ASN.1 necessarily
implies a need to shift from one document, to another as a basis for
further discussion.  Let's give the document authors an opportubity to work
in that issue over the next week.

steve

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Sun, 22 Mar 1998 13:29:09 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

Thank you for responding this quickly, Mike! I believe you are right, that
this will help reduce the amount about OCSP the WG needs to talk about in LA.

A few notes:

>Changed all occurrences of "producedAt" with "thisUpdate".

Er, not all of them. You left producedAt in the ASN.1. :-)

>QUESTION:  Meaning of thisUpdate (formerly producedAt) field.  Is it the
>time at which the response was signed, or the time when the certificate was
>placed on a CRL (that is, the value of thisUpdate of a CRL that may be used
>to source OCSP responses)?

I think it has to be the time the response was signed. How would a
requester know the difference between:
>2.  revoked responses not sourced by a CRL.
>3.  revoked responses sourced by a CRL.
Unless you add a field that says "this response was sourced by a CRL", a
requestor won't know what date you are referring to.

>QUESTION:  Should we accommodate the following extended error cases?
>
>PROPOSED RESOLUTION:  Yes, by adding appropriate INTEGER values to
>OCSPResponseStatus.

But those integer values better be different than the ones you listed,
since they overlap with the current response statuses.

At the end of section 2.4, there are multiple disclaimers for the meaning
of nextUpdate. To me, they make nextUpdate useless. And, now that the HTTP
carrying mechanism is a POST instead of a GET, meaning the response can't
be cached, I think there is no more use for nextUpdate. Since it is not
definitive, based on the disclaimers, I think it should just be taken out.
If people want it left in, I think it has to mean "the CA assures the
recipient that the certificate status is valid until the nextUpdate time",
which is a pretty scary thing to assure.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Michael Myers <[email-masked]>
Date:         Sun, 22 Mar 1998 10:55:14 -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: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] OCSP Update
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01BD5580.FE31E6E0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

All,

I've attached an update to the current OCSP draft that incorporates the
recent ASN.1 poll and requirements comments as well as the contributions
put forward by Malpani and others.  As I noted earlier, my intent here is to
establish a single, harmonized draft that fairly represents the needs
of all who hold an opinion on the evolution of OCSP as a draft standard.

Resolving the comments and contributions revealed further detailed points of
dicussion which I've listed below.  These fall into two broad categories:
New and Deferred Requirements and Questions for Discussion.  Interested
parties are encouraged to review and comment in the spirit of our recent
ASN.1 and requirements poll.  With any luck at all, the OCSP agenda topic in
L.A. will be nothing more than a status report on our consensus regarding
these points.  If I've missed anyone's positions in the recent flurry of
exchanges regarding OCSP, please let me know so I can be sure to at least
get it into the L.A. agenda if not into the next rev of the draft.

Mike

NEW AND DEFERRED REQUIREMENTS
--------------------------------------------------------

Delegation
---------------
Deleted text addressing authority delegation requirements per recent list
traffic on the subject.

Requirement on Basic Response
----------------------------------------------
Added the following requirement to ensure a minimum level of
interoperability:

"OCSP responders SHALL be capable of recognizing and responding to the
id-pkix-ocsp-basic response type.  Correspondingly, OCSP clients SHALL be
capable of receiving and processing the id-pkix-ocsp-basic response type."

Acceptable Response Types
---------------------------------------
Added the following requirements to ensure a minimum level of
interoperability:

"As noted in Section 3.3, OCSP responders SHALL be capable of recognizing
and responding to the id-pkix-ocsp-basic response type.  Correspondingly,
OCSP clients SHALL be capable of receiving and processing the
id-pkix-ocsp-basic response type."

Use of thisUpdate
------------------------
Changed all occurrences of "producedAt" with "thisUpdate".

Interpretation of "time" in StatusWithTime
---------------------------------------------------------------------
Added the following note regarding StatusWithTime:  If the certStatusType is
revoked, onHold or expired, the "time" field of StatusWithTime is the time
of revocation, suspension or expiration respectively.  The date returned for
expiration should match the notAfter date of the certificate’s validity
interval.

Expired State
-----------------
Added an "expired" status value so that a definitive assertion can be made
when the certificate is in this state.  Applications shouldn't query in such
a circumstance, but it's forseeable that some will anyway.

notFound error state
---------------------------
Added a "notFound" error state and the following text:

A recipient of a request may not be able to resolve a reference to the
subject certificate; a value of notFound is returned in such a case.  This
value should not be taken as confirmation of the certificate's existence.

noCRL error state
-------------------------
Added a "noCRL" error state and the following text:

An extension is defined to enable delivery of CRLs with OCSP responses.
However, there is no requirement to list certificates on a CRL in order to
use OCSP to acquire revocation status on those certificates. The error value
noCRL is defined for this instance.

Version
----------
Added an explicit definition of v1:

Version  ::=  INTEGER  {  v1(0) }

QUESTIONS FOR DISCUSSION
-------------------------------------------

QUESTION:  Meaning of thisUpdate (formerly producedAt) field.  Is it the
time at which the response was signed, or the time when the certificate was
placed on a CRL (that is, the value of thisUpdate of a CRL that may be used
to source OCSP responses)?

Note:  There is no requirement to place a certificate on a CRL in order to
implement OCSP.

PROPOSED RESOLUTION:  We have three cases to consider:

1.  notRevoked responses.
2.  revoked responses not sourced by a CRL.
3.  revoked responses sourced by a CRL.

The dominant number of OCSP responses will be positive responses; that is,
indications of non-revocation.  In these cases it is clear that the time of
response production is the only relevant value.

Similarly,  revoked responses not sourced by a CRL should indicate the
response signing time in the value of thisUpdate of a BasicResponse.

Non-repudiation is enhanced when witnessing parties date their signatures.
Since the time field of StatusWithTime could be used to indicate the value
of thisUpdate in a CRL used to source OCSP responses, it seems most useful
to use signing time uniformly.

QUESTION:  Should we accommodate the following extended error cases?

Standard values for reason-text SHALL include:
"1   The root for this certificate is not trusted on this responder."
"2   Could not find CA’s public key."
"3   CA’s public key invalid."
"4   CA’s public key revoked."
"5   CA’s public key expired."
"6   CA not authorized for Subject’s name."
"7   CA not authorized for Subject’s privileges."
"8   CA’s public key did not validate signature."
"9   Could not find CA’s revocation information."
"10  CA’s CRL out of date."

PROPOSED RESOLUTION:  Yes, by adding appropriate INTEGER values to
OCSPResponseStatus.

QUESTION:  What about the text strings?

PROPOSED RESOLUTION:  Keep the text strings in the spec for guidance to
implementors.  Some implementations may wish to provide more user-friendly
dialogs.

QUESTION:  Delete Policy ID extension?

PROPOSED RESOLUTION:  Yes, pending a direct request for its re-inclusion.
It's unclear how this extension would be used in practice.

QUESTION:  Do we keep CERTIFICATE DATA REQUIRED?

PROPOSED RESOLUTION:  Comments anyone?   I left it in for now.

QUESTION:  How best to match a single response to a request?  Inclusion of
the certificates in the response wastes bandwidth, particularly since the
requestor is already in possession of the certificates.

PROPOSED RESOLUTION: Require clients to locally compute certID to match a
response to a request that contains multiple certificates.  Amend syntax of
SingleResponse to specify certID only.

QUESTION: OCSP defined a mandatory "Responder Key Id" field in the response
to provide clients a means to determine which public key to use to validate
the signature on the response.  The RCSP contribution appears to define two
other methods:

1.  specification of "certs" in BasicOCSPResponse; and
2.  "responderName" in ResponseData.

The "certs" field is optional while the responderName is not.  However, the
possibility exists that a given name may be simultaneously associated with
more than one valid signing key.  Clients need a mechanism to identify the
signing key needed to validate the signature on a response.

PROPOSED RESOLUTION:  Comments towards a consensus are welcome.  For a
strawman, consider deleting "certs" from BasicOCSPResponse.  While "certs"
is optional, past experience has shown that applications which implement
support for such optional syntax will more likely than not always send the
certs since there's no way to predict when the recipient doesn't need them.
Doing so would seriously impact the bandwidth efficiencies OCSP set out to
address.   Furthermore, OCSP is not a key distribution protocol.  These
requirements are being addressed by other PKIX work efforts.  To identify
the signing key, replace responderName field of ResponseData and its
associated Name syntax with responderKey and KeyIdentifier syntax, where
KeyIdentifier syntax is intended to align with SubjectKeyIdentifier
definition in PKIX Part 1.  That is, a SHA-1 hash of the key in question.

I amended the definition of ResponseData as follows, pending resolution of
this point:

ResponseData ::= SEQUENCE {
   version                            [0] EXPLICIT Version DEFAULT v1,
   reponderID                           ResponderID,
   responses                           SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName   [0] Name,
   byKey        [1] KeyID }

KeyID ::= KeyIdentifier –-as defined in PKIX Part.1 for SubjectKeyIdentifier

------=_NextPart_000_0013_01BD5580.FE31E6E0
Content-Type: text/plain;
        name="draft-ietf-pkix-ocsp-03.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
        filename="draft-ietf-pkix-ocsp-03.txt"

PKIX Working Group                               Michael Myers(VeriSign)
draft-ietf-pkix-ocsp-03.txt                         Rich Ankney (CertCo)
                                             Ambarish Malpani (Valicert)
                                               Slava Galperin (Netscape)
                                   Carlisle Adams (Entrust Technologies)

Expires in 6 months                                           March 1998

                   X.509 Internet Public Key Infrastructure
                  Online Certificate Status Protocol - OCSP
                        <draft-ietf-pkix-ocsp-03.txt>

Status of this Memo

This document is an Internet-Draft. Internet-Drafts  are  working=20
documents  of the Internet Engineering Task Force (IETF), its areas, and =

its working groups. Note that other groups may also distribute working=20
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum  of  six  months =

and  may be  updated,  replaced, or obsoleted by other documents at any=20
time. It is inappropriate to use Internet-Drafts as  reference  material =

or to cite them other than as "work in progress."

To learn the current status of  any  Internet-Draft,  please  check  the =

"1id-abstracts.txt"  listing  contained  in  the  Internet-Drafts Shadow =

Directories   on   ftp.is.co.za   (Africa),   nic.nordu.net    (Europe), =

munnari.oz.au   (Pacific  Rim),  ds.internic.net  (US  East  Coast),  or =

ftp.isi.edu (US West Coast).

1. Abstract

This document specifies a protocol useful in determining the
current status of a digital certificate without the use of CRLs.
Additional mechanisms addressing PKIX operational requirements are
specified in separate documents.

Section 2 provides an overview of the protocol. Section 3 goes=20
establishes functional requirements, while section 4 provides the=20
details of the protocol. In section 5 we cover security issues with the
protocol. Appendix A demonstrates OCSP over HTTP and appendix B=20
accumulates ASN.1 syntactic elements.

2. Protocol Overview

In lieu of or as a supplement to checking against a periodic CRL, it may
be necessary to obtain timely status regarding a  certificate=92s=20
revocation state (cf. PKIX Part 1, Section 3.3). Examples include high-
value funds transfer or the compromise of a highly sensitive key.

The Online Certificate Status Protocol (OCSP) enables applications
to determine the revocation state of an identified certificate. OCSP may =

Myers, Ankney, Malpani, Galperin, Adams                        [Page 1]
=0CINTERNET DRAFT                                                March =
1998

be used to satisfy some of the operational requirements of providing=20
more timely revocation information than is possible with CRLs.  An OCSP=20
client issues a status request to an OCSP responder and suspends=20
acceptance of the certificate in question until the responder
provides a response.

This protocol specifies the data that needs to be exchanged between an
application checking the revocation status of a certificate and the
server providing that status.

2.1 Request

An OCSP request contains the following data:

- protocol version
- service request
- target certificate identifier or a single end-entity certificate
- optional extensions which MAY be processed by the OCSP Responder

Upon receipt of a request, an OCSP Responder determines if: 1) the=20
message is well formed, 2) the responder is configured to provide the=20
requested service, and 3) the responder can perform the requested=20
service for the subject certificate.  If any one of the prior conditions =

are not met, the OCSP responder produces an error message; otherwise, it =

returns a definitive response.

2.2 Response

All definitive response messages SHALL be digitally signed.  The key=20
used to sign the response MUST belong to one of the following:

- the CA who issued the certificate in question
- a Trusted Responder whose public key is trusted by the requester

A definitive response message is composed of:

- response type identifier (to allow for different response types)
- version of the response
- name of the responder
- responses for each of the certificates in a request
- optional extensions
- signature algorithm OID
- signature computed across hash of the response

The response for each of the certificates in a request consists of

- target certificate identifier
- certificate status value
- response validity interval
- optional extensions

This specification defines the following definitive response indicators=20
for use in the certificate status value:

Myers, Ankney, Malpani, Galperin, Adams                        [Page 2]
=0CINTERNET DRAFT                                                March =
1998

- notRevoked
- revoked
- onHold
- expired

The notRevoked state indicates that the certificate is not revoked. It
does not necessarily mean that the certificate was ever issued. Nor
does it mean that the certificate is in its validity interval. A
notRevoked state by an OCSP responder DOES NOT absolve the application
of the responsibility of checking that the certificate is in its
validity period and has been correctly signed.

The revoked state indicates that the certificate has been revoked.

The onHold state corresponds to valid certificates that are=20
operationally suspended in accordance with PKIX Part 1.

A request that returns an expired state indicates that the validity of=20
the subject certificate has expired.  Applications SHOULD check the=20
validity interval of a certificate and not perform an OCSP request if=20
the certificate=92s validity has expired.

2.3 Exception Cases

In case of errors, the OCSP Responder may return an error message.
Errors can be of the following types:

- malformedRequest
- internalError
- tryLater
- notFound
- certRequired
- noCRL

A server produces the malformedRequest response if the request received=20
does not conform to the OCSP syntax.

The response internalError indicates that the OCSP responder reached
an inconsistent internal state. The query should be retried, potentially
with another responder.

In the event that the OCSP responder is operational, but unable to=20
return a status for the requested certificate, the tryLater response=20
can be used to indicate that the service exists, but is temporarily=20
unable to respond.

A recipient of a request may not be able to resolve a reference to the=20
subject certificate; a value of notFound is returned in such a case.=20
This value should not be taken as confirmation of the certificate's=20
existence.

The response certRequired is returned in cases where the server requires =

the client to supply the certificate data itself in order to construct a =

response.

Myers, Ankney, Malpani, Galperin, Adams                        [Page 3]
=0CINTERNET DRAFT                                                March =
1998

An extension is defined to enable delivery of CRLs with OCSP responses.  =

However, there is no requirement to list certificates on a CRL in order=20
to use OCSP to acquire revocation status on those certificates. The=20
error value noCRL is defined for this instance.

2.4 Response Pre-production

The response validity interval noted in the prior section is composed of =

a {thisUpdate, nextUpdate} pair of elements in the response syntax.=20
Section 4.2 provides details of the response syntax.

OCSP responders MAY pre-produce signed responses specifying the current=20
status of certificates at the time the response was produced.  The time=20
at which the response was produced SHALL be reflected in the thisUpdate=20
field of the response.

If responses are pre-produced, then for a given certificate, the=20
periodicity of this pre-production SHOULD match the response validity=20
interval of the most recently produced response.

[need to resolve the above statement with the following RCSP assertions, =

esp. with respect to positive responses.  Question put to the list.]

The time at which the response was known to be correct SHALL
be specified in the producedAt field of the response. This time is not
necessarily the same as the time at which the response was produced -
e.g. if the responder obtains a CRL from a CA and creates pre-produced
responses, the thisUpdate time should specify the thisUpdate time in
the CRL.

The producer of the response MAY include a value for nextUpdate.  The=20
exact interval between thisUpdate and nextUpdate for given response is=20
a matter of local security and operational policy.  If the nextUpdate=20
field is not present, the response is is known to be correct at the=20
thisUpdate time.  Equivalently, the nextUpdate field is considered to be =

the same as the thisUpdate field.

No assertions are being made about the current state of the certificate, =

nor are any recommendations being made as to when the requestor should=20
check again with the responder.  If the value of nextUpdate is set, it=20
is just a hint, not a guarantee, of when the responder expects to have=20
new information about that certificate's status.

3. Functional Requirements

3.1 Certificate Content

In order to convey to OCSP clients a well-known point of information=20
access, CAs SHALL provide the capability to include the=20
AuthorityInfoAccess extension (defined in PKIX Part 1, section 4.2.2.1)=20
in certificates that can be checked using OCSP.  Alternatively, the=20
accessLocation for the OCSP provider may be configured locally at the=20
OCSP client.

Myers, Ankney, Malpani, Galperin, Adams                        [Page 4]
=0CINTERNET DRAFT                                                March =
1998

CAs that support an OCSP service, either hosted locally or provided by
an Authorized Responder, MAY provide a value for a
uniformResourceIndicator (URI) accessLocation and the OID value
id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate
corresponds to the URL placed into an OCSP request.

3.3 Error Responses

Upon receipt of a request which fails to parse, the receiving OCSP=20
responder SHALL respond with an error message.  Error responses MAY be=20
signed.

3.5 Signed Response Acceptance Requirements

Prior to accepting a signed response as valid, OCSP clients SHALL=20
confirm that:

1.  The certificate identified in a received response corresponds to=20
    that which was identified in the corresponding request;
=20
2.  The signature on the response is valid;
=20
3.  The identity of the signer matches the intended recipient of the=20
    request.

4. Detailed Protocol

The ASN.1 syntax imports terms defined in the X.509 Certificate and CRL
Profile Internet Draft. For signature calculation, the data to be signed =

is encoded using the ASN.1 distinguished encoding rules (DER) [X.690].

ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.

The terms imported from elsewhere are: Version, Extensions,=20
CertificateSerialNumber, SubjectPublicKeyInfo, Name,=20
AlgorithmIdentifier, GeneralizedTime

4.1 Request Syntax

OCSPRequest     ::=3D  SEQUENCE {
   version             [0]  EXPLICIT Version DEFAULT v1,
   hashAlgorithm            AlgorithmIdentifier,
   requestList            SEQUENCE OF Request,
   requestExtensions   [1]  EXPLICIT Extensions OPTIONAL }

Version  ::=3D  INTEGER  {  v1(0) }

Request ::=3D CHOICE {
   certID              [0]  EXPLICIT CertID,
   cert                [1]  EXPLICIT Certificate }

Myers, Ankney, Malpani, Galperin, Adams                        [Page 5]
=0CINTERNET DRAFT                                                March =
1998

CertID ::=3D SEQUENCE {
   issuerNameAndKeyHash Hash,
   serialNumber         CertificateSerialNumber }

IssuerNameAndKey ::=3D SEQUENCE {
   issuer               Name,
   issuerPublicKey      SubjectPublicKeyInfo }

Hash                    ::=3D   OCTET STRING --hash of IssuerNameAndKey--

3.2 Response Syntax

This section specifies the ASN.1 specification for a confirmation
response. The actual formatting of the message could vary depending on
the transport mechanism used (http, smtp, ldap, etc.).

3.2.1 ASN.1 Specification of the OCSP Response

An OCSP response at a minimum consists of a responseStatus field=20
indicating the processing status of the prior request.  If the value of=20
responseStatus is one of the error conditions, responseBytes are not=20
set.

OCSPResponse ::=3D SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::=3D ENUMERATED {
    successful            (0),      --Response has valid confirmations
    malformedRequest      (1),      --Illegal confirmation request
    internalError         (2),      --Internal error in issuer
    tryLater              (3),      --Try again later
    notFound              (4),      --Certificate not on record
    certRequired          (5)       --Must supply certificate }

3.2.1.1 BasicResponse

The value for responseBytes consists of an OBJECT IDENTIFIER and a=20
response syntax identified by that OID encoded as an OCTET STRING:

ResponseBytes ::=3D     SEQUENCE {
    responseType   OBJECT IDENTIFIER,
    response       OCTET STRING }

For a basic OCSP responder, responseType will be id-pkix-ocsp-basic,
where:

id-pkix-ocsp           OBJECT IDENTIFIER ::=3D { id-ad-ocsp }
id-pkix-ocsp-basic     OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 1 }

OCSP responders SHALL be capable of recognizing and responding to the=20
id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be =

capable of receiving and processing the id-pkix-ocsp-basic response=20
type.

Myers, Ankney, Malpani, Galperin, Adams                        [Page 6]
=0CINTERNET DRAFT                                                March =
1998

The value for response SHALL be the DER encoding of BasicOCSPResponse:

BasicOCSPResponse       ::=3D SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs                [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

The value for signature SHALL be computed on the hash of the DER=20
encoding ResponseData.

3.2.1.2 ResponseData

ResponseData ::=3D SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   reponderID               ResponderID,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::=3D CHOICE {
   byName   [0] Name,
   byKey    [1] KeyHash }

KeyHash ::=3D KeyIdentifier =96-SHA-1 hash as defined in PKIX Part.1

3.2.1.3 SingleResponse

[note: question put to the list regarding bandwidth issues associated=20
with sending certificates back; could just use certID directly since=20
requester already has certificates in question.]

SingleResponse ::=3D SEQUENCE {
   request            Request,
   certStatus         CertStatus,
   producedAt         GeneralizedTime,
   nextUpdate         [0] EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions   [2] EXPLICIT Extensions OPTIONAL }

CertStatus ::=3D CHOICE {
    certStatusType    [0] EXPLICIT CertStatusType (notRevoked | onHold),
    statusWithTime    [1] EXPLICIT StatusWithTime }

StatusWithTime ::=3D SEQUENCE {
    certStatusType    CertStatusType (revoked),
    time              GeneralizedTime }

CertStatusType ::=3D ENUMERATED {
    notRevoked        (0),  --This serial number is not revoked
    revoked           (1),  --Serial number was revoked
    onHold            (2),  --Cert is on hold
    expired           (3)   -- certificate is expired }

Applications SHOULD determine by observation of the certificate=92s=20
validity interval that a certificate is expired.  The expired value of=20

Myers, Ankney, Malpani, Galperin, Adams                        [Page 7]
=0CINTERNET DRAFT                                                March =
1998

CertStatusType defines a value to return when a request is received for=20
a subject certificate in this state.

3.2.2 Notes on OCSP Responses

If the certStatusType is revoked, onHold or expired, the time field of=20
StatusWithTime is the time of revocation, suspension or expiration=20
respectively.  The date returned for expiration should match the=20
notAfter date of the certificate=92s validity interval.

The thisUpdate and nextUpdate fields define a recommended validity
interval. This interval corresponds to the {thisUpdate, nextUpdate}
interval in CRLs. Responses whose nextUpdate value is earlier
than the local system time value SHOULD be considered unreliable.
Responses whose thusUpdate time is earlier than the local system time
SHOULD be considered unreliable.  Responses where the nextUpdate value
is not set are equivalant to a CRL with no time for nextUpdate (see
section 2.3).

3.3 Mandatory and Optional Cryptographic Algorithms

Clients that request OCSP services SHALL be capable of processing=20
responses signed used DSA keys identified by the DSA sig-alg-oid=20
specified in section 7.2.2 of PKIX Part 1.  Clients SHOULD also be=20
capable of processing RSA signatures as specified in section 7.2.1 of=20
PKIX Part 1.  OCSP responders SHALL support the SHA1 hash algorithm.

3.4 Extensions

This section defines some standard extensions.  Support for all=20
extensions is OPTIONAL.  For each extension, the definition indicates=20
its syntax, processing performed by the OCSP Responder, and any=20
extensions which are included in the corresponding response.

3.4.1 Nonce

The nonce cryptographically binds a request and a response to prevent
replay attacks. The nonce is included as one of the requestExtensions
in requests, while in responses it would be included as one of the
responseExtensions.  In both the request and the response, the nonce
will be identified by the object identifier id-pkix-ocsp-nonce, while
the extnValue is the value of the nonce.

id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 2 }

3.4.2 Signed Requests

This extension allows the requester to sign a request. The requestor=20
includes an extension that has the signatureIdentifier, the actual bits=20
of the signature and a sequence of certificates to allow the OCSP=20
responder to verify the signature. The data to be signed is just the=20
basic request (none of the extensions). The OCSP Responder can verify=20
the signature, potentially using certificates that have been included=20

Myers, Ankney, Malpani, Galperin, Adams                        [Page 8]
=0CINTERNET DRAFT                                                March =
1998

with the extension. The signature on a request will be identified by id-
pkix-ocsp-signature, while the value will be SignatureData, where:

id-pkix-ocsp-signature OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 5 }

SignatureData ::=3D SEQUENCE {
   signatureAlgorithm       AlgorithmIdentifier,
   signature                BIT STRING,
   certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

3.4.3 CRL References

It may be desirable for the OCSP responder to indicate the CRL on which=20
a revoked or onHold certificate is found. This can be useful where OCSP=20
is used between repositories, and also as an auditing mechanism. The
CRL may be specified by a URL (the URL at which the CRL is available),
a number (CRL number) or a time (the time at which the relevant CRL
was created). These extensions will be specified as singleExtensions.
The identifier for this extension will be id-pkix-ocsp-crl, while the
value will be CrlID.

id-pkix-ocsp-crl       OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 4 }

CrlID ::=3D SEQUENCE {
   crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
   crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
   crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

For the choice crlUrl, the IA5String will specify the URL at which the
CRL is available. For crlNum, the INTEGER will specify the value of the
CRL number extension of the relevant CRL. For crlTime, the=20
GeneralizedTime will indicate the time at which the relevant CRL was=20
issued.

Note:  There is no requirement to list certificates on a CRL in order to =

use OCSP to acquire revocation status on those certificates.  Therefore=20
inclusion of this extension in a request may yield no CRL information. =20
The error value noCRL is defined for this instance.

3.4.4 Acceptable Response Types

An OCSP client MAY wish to specify the kinds of response types it
understands. To do so, it SHOULD use an extension with the OID
id-pkix-ocsp-response, and the value AcceptableResponses. The OIDs
included in AcceptableResponses are the OIDs of the various response
types this client can accept (e.g., id-pkix-ocsp-basic).

id-pkix-ocsp-response  OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 3 }

AcceptableResponses ::=3D       SEQUENCE OF { id OBJECT IDENTIFIER }

As noted in section 3.3, OCSP responders SHALL be capable of recognizing =

and responding to the id-pkix-ocsp-basic response type. Correspondingly, =

Myers, Ankney, Malpani, Galperin, Adams                        [Page 9]
=0CINTERNET DRAFT                                                March =
1998

OCSP clients SHALL be capable of receiving and processing the id-pkix-
ocsp-basic response type.

3.4.5 Other Extensions

CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are=20
also supported as singleExtensions.

4. Security Considerations

For this service to be effective, certificate using systems must connect =

to the certificate status service provider. In the event such a=20
connection cannot be obtained, certificate-using systems could implement =

CRL processing logic as a fall-back position.

A denial of service vulnerability is evident with respect to a flood of=20
queries constructed to produce error responses.  The production of a=20
cryptographic signature significantly affects response generation cycle=20
time, thereby exacerbating the situation.

Unsigned error responses can be produced more rapidly and thus reduce=20
the danger of this attack. However, unsigned error responses open up the =

protocol to another denial of service attack, where the attacker sends=20
false error responses.

The use of precomputed responses allows replay attacks in which an=20
old (notRevoked) response is replayed prior to its expiration date but=20
after the certificate has been revoked. Deployments of OCSP should=20
carefully evaluate the benefit of precomputed responses against the=20
probability of a replay attack and the costs associated its successful=20
execution.

5. References

[HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee,
       R. Fielding & H. Frystyk, RFC 1945, May 1996.=20

[ABNF] Augmented BNF for Syntax Specifications: ABNF.  D. Crocker,
P.  Overell, RFC 2234, November 1997.

[MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels,
 S. Bradner, RFC 2119, March 1997.

[URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter,
M.  McCahill, RFC 1738, December 1994.

7. Author=92s Address

Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019
[email-masked]
=20

Myers, Ankney, Malpani, Galperin, Adams                        [Page 10]
=0CINTERNET DRAFT                                                March =
1998

Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA  20151
[email-masked]

Ambarish Malpani
ValiCert, Inc.
3160 W. Bayshore Drive
Palo Alto, CA 94303
[email-masked]

Slava Galperin
Netscape Communications Corp.
MV-068
501 E. Middlefield Rd.
Mountain View, CA 94043
[email-masked]

Carlisle Adams
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario
K1V 1A7
Canada
[email-masked]

Appendix A

A.1 OCSP over HTTP

This section describes the formatting that will be done to the request
and response to support HTTP.

A.1.1 Request

An OCSP request is an HTTP 1.0 POST method. The Content-Type header
has the value "application/ocsp-request" while the body of the message
is the DER encoding of the OCSPRequest.

A.1.2 Response

An HTTP-based OCSP response is composed of the appropriate HTTP headers,
followed by the DER encoding of the OCSPResponse. The Content-Type
header has the value "application/ocsp-response". The Content-Length
header SHOULD specify the length of the response. Other HTTP headers
MAY be present and MAY be ignored if not understood by the requestor.

Myers, Ankney, Malpani, Galperin, Adams                        [Page 11]
=0CINTERNET DRAFT                                                March =
1998

Appendix B:  OCSP in ASN.1

OCSPRequest     ::=3D  SEQUENCE {
   version             [0]  EXPLICIT Version DEFAULT v1,
   hashAlgorithm            AlgorithmIdentifier,
   requestList            SEQUENCE OF Request,
   requestExtensions   [1]  EXPLICIT Extensions OPTIONAL }

Version  ::=3D  INTEGER  {  v1(0) }

Request ::=3D CHOICE {
   certID              [0]  EXPLICIT CertID,
   cert                [1]  EXPLICIT Certificate }

CertID ::=3D SEQUENCE {
   issuerNameAndKeyHash Hash,
   serialNumber         CertificateSerialNumber }

IssuerNameAndKey ::=3D SEQUENCE {
   issuer               Name,
   issuerPublicKey      SubjectPublicKeyInfo }

Hash                    ::=3D   OCTET STRING --hash of IssuerNameAndKey--

OCSPResponse ::=3D SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::=3D ENUMERATED {
    successful            (0),      --Response has valid confirmations
    malformedRequest      (1),      --Illegal confirmation request
    internalError         (2),      --Internal error in issuer
    tryLater              (3),      --Try again later
    notFound              (4),      --Certificate not on record
    certRequired          (5)       --Must supply certificate }

BasicOCSPResponse       ::=3D SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs                [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

ResponseData ::=3D SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   reponderID               ResponderID,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::=3D CHOICE {
   byName   [0] Name,
   byKey    [1] KeyHash }

KeyHash ::=3D KeyIdentifier =96-SHA-1 hash as defined in PKIX Part.1

Myers, Ankney, Malpani, Galperin, Adams                        [Page 12]
=0CINTERNET DRAFT                                                March =
1998

SingleResponse ::=3D SEQUENCE {
   request            Request,
   certStatus         CertStatus,
   producedAt         GeneralizedTime,
   nextUpdate         [0] EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions   [2] EXPLICIT Extensions OPTIONAL }

CertStatus ::=3D CHOICE {
    certStatusType    [0] EXPLICIT CertStatusType (notRevoked | onHold),
    statusWithTime    [1] EXPLICIT StatusWithTime }

StatusWithTime ::=3D SEQUENCE {
    certStatusType    CertStatusType (revoked),
    time              GeneralizedTime }

CertStatusType ::=3D ENUMERATED {
    notRevoked        (0),  --This serial number is not revoked
    revoked           (1),  --Serial number was revoked
    onHold            (2),  --Cert is on hold
    expired           (3)   -- certificate is expired }

--Extensions

SignatureData ::=3D SEQUENCE {
   signatureAlgorithm       AlgorithmIdentifier,
   signature                BIT STRING,
   certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

AcceptableResponses ::=3D       SEQUENCE OF { id OBJECT IDENTIFIER }

CrlID ::=3D SEQUENCE {
   crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
   crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
   crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

-- Object Identifiers

id-pkix-ocsp           OBJECT IDENTIFIER ::=3D { id-ad-ocsp }
id-pkix-ocsp-basic     OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 2 }
id-pkix-ocsp-response  OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 3 }
id-pkix-ocsp-crl       OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 4 }
id-pkix-ocsp-signature OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 5 }

Myers, Ankney, Malpani, Galperin, Adams                        [Page 13]

------=_NextPart_000_0013_01BD5580.FE31E6E0--

Priority: normal
Approved-By:  David Chadwick <[email-masked]>
Date:         Sun, 22 Mar 1998 00:06:39 +0000
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Comments:     Authenticated sender is <[email-masked]>
From: David Chadwick <[email-masked]>
Organization: University of Salford
Subject:      Re: [IETF-PKIX] New OCSP Requirements
Comments: To: [email-masked]
To: [email-masked]

> Date:          Sat, 21 Mar 1998 14:21:48 -0800
> Reply-to:      [email-masked]
> From:          Peter Gutmann <[email-masked]>
> Subject:       Re: [IETF-PKIX] New OCSP Requirements
> To:            [email-masked]

> After following the current debate on OCSP-related issues, I thought I'd
> provide my own contribution to online validity checking.  I think this should
> solve all the current problems.  Since it's very short, I've included it
> below.  It's pre-released by just over a week, but I thought it was
> appropriate to post it now while the issue is still under active debate.
>
> Peter.

Unfortunately, because you live in Australia, your draft will only
have a very short time span, insufficient to catch anyone out. This
is because April fool's day only officially lasts until midday, and
when you issue it, it will be March 31 in Europe, and when it expires
at midday in Australia, it will only just have turned midnight on
April 1 in Europe, so we wont have time to check out your extension
or get fooled by it.

Hope this is still intelligible to you down under.
Gooday to you all (or should I say goodnight?)
David

>
> -- Snip --
>
> XIKP Working Group                                              P. Gutmann
> Internet Draft                                      University of Auckland
> expires in six months                                         1 April 1998
>
>                    Internet X.509 Public Key Infrastructure
>             Operational Protocols: Certificate Validity Checking
>                          <draft-ietf-pkix-parp-01.txt>
>
> Abstract
>
>   This document describes an active online certificate revocation protocol
>   which bypasses some of the shortcomings of existing protocols.  The protocol
>   described in this document is Peter's Active Revocation Protocol (PARP),
>   which provides for online validity checking for certificates.
>
>   Please send comments on this document to the Usenet alt.flarf.parp newsgroup.
>
> 1. Protocol Description
>
>   The PARP protocol is very simple and involves an X.509v3 certificate
>   extension which provides a facility for online certificate validity checking.
>   The extension is as follows:
>
>     id-ce-parp OBJECT IDENTIFIER ::= { id-ce 99 }
>
>     PARPObject ::= CHOICE {
>         activeXControl  [0] OCTET STRING,
>         javaApplet      [1] OCTET STRING,
>         win95           [2] OCTET STRING
>         }
>
>   To check a certificates validity, the ActiveX control or Java applet is
>   extracted from the extension and executed.  Since the validity checking is
>   performed entirely by the code contained within the extension, there is no
>   need for tedious protocol specification and interoperability testing, as
>   anything which can run ActiveX or Java can verify a certificate.
>
>   The Win95 option is a special case which applies to older systems running DOS
>   or Windows 3.1 which don't provide support for ActiveX or Java.  This option
>   includes a complete Windows 95 installation in the extension which, when run,
>   installs Win95 on the machine, locates and downloads whatever support is
>   necessary for ActiveX and/or Java (typically a copy of MSIE), and then
>   performs a PARP verification as described above.  CA's which include the
>   Win95 option should be aware that this may lead to a small increase in
>   certificate size.
>
> Security Considerations
>
>   CA's which include the Win95 option may wish to operate from a different
>   country than the one in which their subjects are located, preferably one with
>   strong gun control legislation.
>
>
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 370 957 287
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
***************************************************

Approved-By: [email-masked]
Date:         Sat, 21 Mar 1998 14:21:48 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Gutmann <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

After following the current debate on OCSP-related issues, I thought I'd
provide my own contribution to online validity checking.  I think this should
solve all the current problems.  Since it's very short, I've included it
below.  It's pre-released by just over a week, but I thought it was
appropriate to post it now while the issue is still under active debate.

Peter.

-- Snip --

XIKP Working Group                                              P. Gutmann
Internet Draft                                      University of Auckland
expires in six months                                         1 April 1998

                   Internet X.509 Public Key Infrastructure
            Operational Protocols: Certificate Validity Checking
                         <draft-ietf-pkix-parp-01.txt>

Abstract

  This document describes an active online certificate revocation protocol
  which bypasses some of the shortcomings of existing protocols.  The protocol
  described in this document is Peter's Active Revocation Protocol (PARP),
  which provides for online validity checking for certificates.

  Please send comments on this document to the Usenet alt.flarf.parp newsgroup.

1. Protocol Description

  The PARP protocol is very simple and involves an X.509v3 certificate
  extension which provides a facility for online certificate validity checking.
  The extension is as follows:

    id-ce-parp OBJECT IDENTIFIER ::= { id-ce 99 }

    PARPObject ::= CHOICE {
        activeXControl  [0] OCTET STRING,
        javaApplet      [1] OCTET STRING,
        win95           [2] OCTET STRING
        }

  To check a certificates validity, the ActiveX control or Java applet is
  extracted from the extension and executed.  Since the validity checking is
  performed entirely by the code contained within the extension, there is no
  need for tedious protocol specification and interoperability testing, as
  anything which can run ActiveX or Java can verify a certificate.

  The Win95 option is a special case which applies to older systems running DOS
  or Windows 3.1 which don't provide support for ActiveX or Java.  This option
  includes a complete Windows 95 installation in the extension which, when run,
  installs Win95 on the machine, locates and downloads whatever support is
  necessary for ActiveX and/or Java (typically a copy of MSIE), and then
  performs a PARP verification as described above.  CA's which include the
  Win95 option should be aware that this may lead to a small increase in
  certificate size.

Security Considerations

  CA's which include the Win95 option may wish to operate from a different
  country than the one in which their subjects are located, preferably one with
  strong gun control legislation.

Approved-By:  Michael Myers <[email-masked]>
Date:         Sat, 21 Mar 1998 13:32:51 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
To: [email-masked]

Carlisle,

I don't see that a poll is necessary here.  In the end, we're all looking
for a single, harmonized draft.

The intent of my posting was to identify where the current OCSP work product
should be updated to reflect these recent contributions.  I'm prepared to
execute this editorial role to ensure that the OCSP effort fairly and openly
reflects IETF process and PKIX consensus.

Mike

-----Original Message-----
From: Carlisle Adams <[email-masked]>
. . .
>Where do we go from here?  Given that the primary purpose of RSCP was to
>do the editing work necessary to move the OCSP draft to ASN.1 and to
>transport independence, it seems to me that the RCSP draft is the
>logical basis for progression.  [If Mike is agreeable, his name can
>certainly be included again on the authors list; furthermore, the
>protocol name can go back to "OCSP" if people prefer this.]
>
>Is it time for another straw poll?  Should the PKIX WG move forward from
>the current OCSP or from the current RCSP?
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>

Approved-By:  Michael Myers <[email-masked]>
Date:         Sat, 21 Mar 1998 10:23:25 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] We voted, now what?
To: [email-masked]

Rich,

We'll have to address questions regarding specifics of the ASN.1 question
going into L.A.  Doubtless the Malpani et. al. contribution provides a
strawman regarding ASN.1.

One should expect bits on the wire to change as a consequence of this
decision.  In the very near term, there is nonetheless merit in proving the
concept using the -02 syntax, particularly since as your implementation has
shown the development investment is minor.  I would expect that the proof of
concept trials regarding OCSP that I'm aware of would inform the evolution
of the draft standard irregardless of the specific transfer syntax.

As to the socket protocol, this is just a placeholder for the moment until
we can determine if the request for this level of transport independance is
sufficiently broad-based to warrant treatment in the draft standard.  It is
my intent to keep the the number of options to a minimum in the interests of
interoperability.

Mike

-----Original Message-----
From: Rich Salz <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Friday, March 20, 1998 7:21 AM
Subject: [IETF-PKIX] We voted, now what?

>I'm confused by the results of the straw poll.
>
>I understand that the documentation used in the RFC is going to change.
>Instead of
>        ocsp-request = url version target [extensions] [signature]
[extensions]
>        extensions = *extension
>It's going to be
>        OCSP-REQUEST ::= { SIGNED { VERSION TARGET EXTENSIONS }
EXTENSIONS }
>        EXTENSIONS ::= SEQUENCE OF EXTENSION
>(I'm sure I have syntax errors in both notations. :)
>
>What's not at all clear to me is this:
>    -   Is the wire protocol also going to change?  I have seen messages
>        on this list that implied this, asked for this, and were also
>        silent on this matter.
>    -   If so, how?
>            -   A new reserved port# which sends/receives the PDU's
>                defined in the spec; and/or
>            -   For HTTP, a defined "well-known URL" which uses GET
>                and replies to transmit the PDU's as a defined MIME type
>    -   If not, how?
>            -   Define an ASN.1 to "netascii" mapping?
>
>Is it clear to everyone else?  Anyone else? :)
>        /r$
>

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 20 Mar 1998 19:53:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

Perry,

We seem to be at cross purposes. You keep talking about
financial systems, and I'm trying to address the issue of
Reliance Limits in NON-financial applications

I was involved in the early days of SET, I am reasonably
familiar with how the banking/credit card system works, and
quite agree that from a liability perspective, the
digital signature aspect of SET is a rather low priority. In fact
the original iKP proposal made by IBM assumed that the
banks wouldn't bother to implement the consumer digital signature.

Other than the increasinly stringent "know your customer" rules
being applied to combat money laundering, the banks and credit card
companies wouldn't care you are identity-wise, so long as you
pay your bill on time.  SET doesn't depend on your signature to
tell whether you have money in the bank to cover your pruchase,
they go ask the bank.

Duh.

What the signature does provide, if you were watching all the
flames on SET last year, is protiction to the MERCHANT against
repudiation of a purchase, especially of intangible goods, by
a customer who under the previously existing rules could simply
disavow the purchase, leaving the bank to roll over on the merchant,
who had no receipt to back up his claim. The system was patently
unfair in that case, and to their credit Visa fixed the problem. If the
purchase order is digially signed, the merchant can push back against
the bank's attempt to deny the charge, and let the merchant, the
bank, and the customer fight it out in court, if necessary.

>> I certainly understand the difficulties with using a Reliance Limit
>> in the absence of "Dynamic, signed attributes retrieved securely by
>> authenticated real-time access to an on-line repository". That is
>> the primary reason why I have been pushing hard for a notarization
>> model that includes the ability to indicate to the repository, CA,
>> or other mediator what the estimated value of a particular message
>> is to the relying party, in case either the subscriber or the CA
>> would like to keep track of the aggregate value and cut off further
>> approvals by revoking the certificate if things look like they are
>> getting out of hand.
>
>I would again ask you what your model is for how these certificates
>will be used.

Fair enough.
>
>In any real financial transaction system in use *today*, the
>relationships are bilateral and there is no need for third party
>identity verification, since the bilateral counterparties have
>prearranged their relationship.

OK. Once more, the transaction are NOT necessarily financial
in nature, and in particular they are NOT taking place over any kind
of a pre-established transaction system, financial or otherwise.
and they do NOT necessarily involve preestablished knowledge of
parties, much less a re-arranged contractual agreement.
So I am not even going to discuss EDI, much less credit cards
or routine banking, although the EDI folks would very much like to get
away from the model of having to neotiate individual contracts
between all of the trading partners.

But do you imagine that I just discarded all possible uses of a
digital signature?  Of course not.

Take purchase orders, for example.  Many, many businesses
place orders every day to merchants they may have never dealt
with before, and they simply ask to be billed.  After the invoiced
items arrive and the bill comes in, they pay it, in many cases
using the USPS to deliver a physical check.

Would they like to be able to send orders in electronically? Yes.
Would the merchant like to have just a little better evidence as
to who this company is than a rpeprinted form or letterhead?
Yes.  Could a digitally signed document, backed up by a
certificate issued by a CA who had done at least some minimal
due diligence, such as confimring the company's Dun and Bradstreet
listing, provide that additional level of assurance. Yes.  Is the
additional speed transaction speed provided by the Internet, as
compared to sending that hard-copy letterhead evidence, worth
a great deal. Yes.  (This is the whole rationale behind an open PKI--
it is intended to facilitate a very wide variety of transactions between
relative strangers wh cannot be face to face, or pay cash.)

Could the company get screwed if the CA issued a certificate to the
wrong person? Yes, absolutely.  Even without some kind of velocity
controls, would the company like to take some modest precautions
against the possibility that some very large ticket items could somehow
be ordered erroneously, apparently signed by them, and leading to
a major battle? Yes.  Is some kind of a reliance limit at least a reasonable
and prudent inimum precaution against such a possibility, just like the
requirement for two signatures on a check over a certain amount?
Yes, yes, yes.
>
>> If I want to check that the latest series of messages really and
>> truly came from Perry, Andrew, or Dwight, perhaps because I want to
>> buy or sell short some CA's stock, depending on how I value the
>> message, then I may want to be reasonably sure that the message came
>> from them.
>
>> And in the good old fashioned American tradition, if something goes wrong,
>> I don't want to take the blame for a stupid decision on my part, I want to
>> sue someone to get well! :-)
>
>> Perry, however, may not enjoy the thought of my suing him for a gigabuck
>> because his rant led me to do something dumb, and especially if he didn't
>> even send the message but his evil twin Skippy did -- even if he is confident
>> that he will prevail in court --  he doesn't even want to get involved in
>> such silliness
>
>> So he might very well want to negotiate some kind of a limit of
>> liability with his CA, to be put into his certificate as at least an
>> approximate indicator o f what both he and the CA think might be a
>> reasonable upper limit for a "commercially reasonable" reliance.
>
>You will pardon me for noting that this is a highly, highly convoluted
>example. I can't think of anyone reasonable spending time thinking of
>how to rig the world's electronic mail system to make lawsuits most
>feasible (although I'm certain that various unreasonable people
>working for law firms spend time fantasizing about it.)

I'm not trying to make them more feasible, I'm trying to defend AGAINST
that possibility, by setting out limits where the possibility that an
errant transaction would be accepted as commercially reasonable
can be reasonably well tolerated.

If you don't want to take any financial risk at all, perhaps because you
realize that you really don't have adequate controls over your keys,
then you are free to specify a Relianace Limit of ZERO.  What's wrong
with that?
>
>Let me produce a much more straightforward example of how one uses
>identity information: credit card based payments. In a credit card
>based payment system, the "identity" of the person signing the credit
>card payment slip is utterly uninteresting. "So what if you are Bob
>Jueneman", says the Merchant. "How do I know you have credit left your
>card account?  How do I know you have an account at this bank? How do
>I know the bank exists?"

Agreed, as previously stipulated.
>
>None of those are answers that verifying your handy-dandy shiny
>Versign Certificate will give. All it will say is "This is indeed
>someone named Bob Jueneman."
>
>Well, the dirty little secret is that the merchant doesn't give a
>flying damn what your name is, except so he can send you catalogs at
>Christmas, and even then he doesn't care if you used your real
>name. All he wants is his money.

Not quite, as I discussed above.  He also needs a receipt
for the goods, or at least a signed order,  to back up his claim
that you were in fact the customer who ordered and receive
the merchandise.
>
>Now, the way that your merchant finds out that his money is coming to
>him is by talking to his bank, which says "yup, you're getting your
>money". He trusts his bank -- whether foolishly or correctly matters
>to no one but him. He doesn't have to care about your "Verisign
>Certificate" which he won't care about. The merchant's bank trusts the
>clearing system which trusts the issuing bank which in the end cares
>who you are, because you, "Bob Jueneman", have a bilateral
>relationship with the bank.
>
>In a 21st Century equivalent of this transaction, we can add massive
>security simply by providing a digital signature that gets verified by
>the issuing bank. The banks have all the liability, not the merchant,
>who doesn't care and needn't care. For the issuing bank's safety, it
>may wish to make sure that a digital signature on the request for
>payment matches the on-file public key of the person to whom the card
>has been issued. Does the issuing bank care about what Verisign thinks
>your name is? No. It doesn't give a damn. It has your key in its
>database, and can trust that information. (If it has trouble with the
>security on that database it has far worse problems on its hands, like
>people faking how much is in various accounts.)
>
>For real future credit transactions, I can't see what use certificates
>will be except as a convenient format for conveying public keys, and
>I'm very skeptical about the use of third party CAs ever becoming
>important in real financial transaction systems.

Well, Visa, MasterCard, American Express, et al, may in fact be wrong,
but they certainly see a role, if not the primary role. As you say, the
certificate doesn't tell anyone how much money you have in the bank.

>> Does that mean that because we can't be perfect, we shouldn't even
>> try to be prudent? I don't think so.  Even if it is like chicken soup for
>> a cold, it presumably won't hurt, and might actually do some good.
>
>I'm asking a far more fundamental question.
>
>In the financial transactions case -- the case where the concept of a
>"Reliance Limit" is the most relevant -- are there any real instances
>in which anyone needs certificates at all?

Well, if not, then this discussion is cetainly moot, and not worth wasting
either of our time!  I obviously disagree that Reliance Limits are
only of use in such well structured environments, where I basically
agree with your asessment. But that wasn't my point.
>
>If no one should care about the use of certificates from third party
>CAs in financial transactions -- if the only certificates that get
>issued are by the bank for the use of its customers in dealing only
>with the bank itself -- then why should we care about "Reliance
>Limits" at all?
>
>Perry

I think we have probably beat this one to death.  If you suddenly
have an epiphany and change your mind  by all means post it to the
list, but otherwise we can probably just continue this in private, or let
it drop and agree to disagee.

Regards,

Bob

Approved-By:  Warwick Ford <[email-masked]>
Date:         Fri, 20 Mar 1998 21:12:00 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
To: [email-masked]

I agree that concensus is emerging.  However, I suggest we concentrate on
resolving all the issues to everyone's satisfaction first, leaving the
editorial logistics aside for a moment.  In any case, I don't feel a straw
poll is either necessary or appropriate for that purpose.  If we can agree
on one protocol, then the best way to proceed is to ask all of the
substantive contributors to work together to produce the resultant
document.  I think that is best handled in person at the LA meeting.

Warwick

At 05:44 PM 3/20/98 -0500, Carlisle Adams wrote:
>All,
>
>As a concrete (and succinct) example, I include Russ' latest posting,
>but I think that "rough consensus" is building on almost all these
>issues.
>
>>----------
>>From:  Russ Housley[SMTP:[email-masked]]
>>Sent:  Thursday, March 19, 1998 12:16 PM
>>To:    [email-masked]
>>Subject:       Re: [IETF-PKIX] New OCSP Requirements
>>
>>Mike:
>>
>>Here are my responses:
>>
>>ASN.1  -  I support moving from ABNF to ASN.1.
>
>Definite rough consensus.  Issue closed (as far as I can tell).
>
>>Multiple Certs In Request  -  I think that this is desirable, but not
>>mandatory.
>
>Rough consensus (although I think the S/MIME example moves this to
>"mandatory").
>
>>Transport Independance  -  In my opinion, binding to HTTP is a mistake.
>>Independence to the transport is highly desirable.
>
>Rough consensus.
>
>>Multiple Response Types  -  I think that revocation information is
>>sufficient.
>
>It may be too early to judge rough consensus, but there does seem to be
>agreement that multiple response types would be easy to do syntactically
>(particularly in ASN.1) and would provide desirable generality for
>future evolution of the protocol without adding undue complexity.
>
>>Ceritificate Identification  -  I think that CA DName with Serial Number is
>>sufficient.
>
>Denis and Ambarish both make valid points here:  we should try to align
>with the S/MIME group if at all possible, but the structure being
>discussed in that group is not sufficient if the OCSP responder does not
>have the certificate itself (e.g., if it only has the issuer's
>certificate and signed revocation information).  Perhaps a solution is
>to add "issuerCertHash" to the CertUID structure, but this is starting
>to look a bit unwieldy...
>
>>Delegation of Authority  -  I think we should consider an enhancement at a
>>later time in conjunction with other attribute certificate work.  However,
>>you might want to include a certificate type in the protocol as a place
>>holder.
>
>It may be too early to judge rough consensus here as well, but there
>does seem to be agreement that this work should be done in a broader
>context.
>
>
>
>
>Where do we go from here?  Given that the primary purpose of RSCP was to
>do the editing work necessary to move the OCSP draft to ASN.1 and to
>transport independence, it seems to me that the RCSP draft is the
>logical basis for progression.  [If Mike is agreeable, his name can
>certainly be included again on the authors list; furthermore, the
>protocol name can go back to "OCSP" if people prefer this.]
>
>Is it time for another straw poll?  Should the PKIX WG move forward from
>the current OCSP or from the current RCSP?
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>
******** PLEASE NOTE NEW CONTACT DETAILS ********
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Fri, 20 Mar 1998 19:32:41 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

Bob Jueneman writes:
> I have to mildly disagree.

As someone highly involved in the world of certificates for the last
decade, I would be shocked if you didn't.

> I don't want to get all wrapped up in a general purpose discussion
> of trust, nor of the various pros and cons of possible transaction systems.

I wasn't discussing the question of "Trust" at all. I was discussing
whether financial transaction systems actually need CAs.

> I certainly understand the difficulties with using a Reliance Limit
> in the absence of "Dynamic, signed attributes retrieved securely by
> authenticated real-time access to an on-line repository". That is
> the primary reason why I have been pushing hard for a notarization
> model that includes the ability to indicate to the repository, CA,
> or other mediator what the estimated value of a particular message
> is to the relying party, in case either the subscriber or the CA
> would like to keep track of the aggregate value and cut off further
> approvals by revoking the certificate if things look like they are
> getting out of hand.

I would again ask you what your model is for how these certificates
will be used.

In any real financial transaction system in use *today*, the
relationships are bilateral and there is no need for third party
identity verification, since the bilateral counterparties have
prearranged their relationship.

> If I want to check that the latest series of messages really and
> truly came from Perry, Andrew, or Dwight, perhaps because I want to
> buy or sell short some CA's stock, depending on how I value the
> message, then I may want to be reasonably sure that the message came
> from them.

> And in the good old fashioned American tradition, if something goes wrong,
> I don't want to take the blame for a stupid decision on my part, I want to
> sue someone to get well! :-)

> Perry, however, may not enjoy the thought of my suing him for a gigabuck
> because his rant led me to do something dumb, and especially if he didn't
> even send the message but his evil twin Skippy did -- even if he is confident
> that he will prevail in court --  he doesn't even want to get involved in
> such silliness

> So he might very well want to negotiate some kind of a limit of
> liability with his CA, to be put into his certificate as at least an
> approximate indicator o f what both he and the CA think might be a
> reasonable upper limit for a "commercially reasonable" reliance.

You will pardon me for noting that this is a highly, highly convoluted
example. I can't think of anyone reasonable spending time thinking of
how to rig the world's electronic mail system to make lawsuits most
feasible (although I'm certain that various unreasonable people
working for law firms spend time fantasizing about it.)

Let me produce a much more straightforward example of how one uses
identity information: credit card based payments. In a credit card
based payment system, the "identity" of the person signing the credit
card payment slip is utterly uninteresting. "So what if you are Bob
Jueneman", says the Merchant. "How do I know you have credit left your
card account?  How do I know you have an account at this bank? How do
I know the bank exists?"

None of those are answers that verifying your handy-dandy shiny
Versign Certificate will give. All it will say is "This is indeed
someone named Bob Jueneman."

Well, the dirty little secret is that the merchant doesn't give a
flying damn what your name is, except so he can send you catalogs at
Christmas, and even then he doesn't care if you used your real
name. All he wants is his money.

Now, the way that your merchant finds out that his money is coming to
him is by talking to his bank, which says "yup, you're getting your
money". He trusts his bank -- whether foolishly or correctly matters
to no one but him. He doesn't have to care about your "Verisign
Certificate" which he won't care about. The merchant's bank trusts the
clearing system which trusts the issuing bank which in the end cares
who you are, because you, "Bob Jueneman", have a bilateral
relationship with the bank.

In a 21st Century equivalent of this transaction, we can add massive
security simply by providing a digital signature that gets verified by
the issuing bank. The banks have all the liability, not the merchant,
who doesn't care and needn't care. For the issuing bank's safety, it
may wish to make sure that a digital signature on the request for
payment matches the on-file public key of the person to whom the card
has been issued. Does the issuing bank care about what Verisign thinks
your name is? No. It doesn't give a damn. It has your key in its
database, and can trust that information. (If it has trouble with the
security on that database it has far worse problems on its hands, like
people faking how much is in various accounts.)

For real future credit transactions, I can't see what use certificates
will be except as a convenient format for conveying public keys, and
I'm very skeptical about the use of third party CAs ever becoming
important in real financial transaction systems.

> Does that mean that because we can't be perfect, we shouldn't even
> try to be prudent? I don't think so.  Even if it is like chicken soup for
> a cold, it presumably won't hurt, and might actually do some good.

I'm asking a far more fundamental question.

In the financial transactions case -- the case where the concept of a
"Reliance Limit" is the most relevant -- are there any real instances
in which anyone needs certificates at all?

If no one should care about the use of certificates from third party
CAs in financial transactions -- if the only certificates that get
issued are by the bank for the use of its customers in dealing only
with the bank itself -- then why should we care about "Reliance
Limits" at all?

Perry

Approved-By:  Slava Galperin <[email-masked]>
Date:         Fri, 20 Mar 1998 14:43:32 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Slava Galperin <[email-masked]>
Organization: Netscape Communications Corp
Subject:      Re: [IETF-PKIX] Unique Identification of a Certificate
To: [email-masked]

Ambarish Malpani wrote:
>
>
> In RCSP, a client is sending over one or more certificates to an
> RCSP responder, to check their revocation status.
> I think we all agree that issuer/serial is sufficient to uniquely
> identify a certificate.
> So the question is: how does one uniquely identify an issuer.
> I submit that the DN is not enough, because it is possible for
> the to be DN name clashes - either maliciously, or because two
> groups don't talk to each other before they choose their names.
> There really is no way of enforcing uniqueness is issuer DNs all
> over the world.
> However, public keys don't suffer from the problem of impersonation.
> If somebody else claims to have the same public/private key as me,
> it is easy to prove otherwise.
> Therefore, we have chosen to use the issuerDN, issuerPublicKey
> and CertificateSerialNumber to uniquely identify a cert. (I need
> to add the issuerAltName also, as you have).
> As an optimization, to reduce the size of a request, we ask the
> requestor to hash the issuerDN and issuerPublicKey in the request
> rather than sending all the bytes.

Actually if we do believe in the uniqueness of the CA signing key pair
(which would better be true ! ;-) we can take even more extreme approach
to identifying a cert.

Specifically one can eliminate the CA name (both primary and
alternative) from certificate identification. Instead one can use (a
hash of?) CA public key/serial number combination to identify a
certificate. This approach attempts to use one of the fundamental
assumptions made by SPKI working group that PKI principals are
essentially signing keys and names are just some of the attributes bound
to the key by means of issuing a certificate.

Although X.509 world heavily relies on combination of name/key
identifier in certificate chaining I guess it would be a pretty safe
assumption that most CA never use two CA certificates with different CA
name and same key. Even if CA signing key pair is attached to many
different names (possibly of different name forms), these names form
equivalence class and are specified in a single CA certificate possibly
using a combination of subject and subjectAlternativeName.

Technically I am proposing to use either

CertID                  ::=     SEQUENCE {
         issuerKeyHash            Hash,
         serialNumber                    CertificateSerialNumber,
}

where issuerKeyHash is a hash of subjectPublicKeyInfo field from the
corresponding CA certificate, or

CertID                  ::=     SEQUENCE {
         issuerKey          SubjectPublicKeyInfo,
         serialNumber                    CertificateSerialNumber,
}

in case we are afraid of the hash collisions and are willing to
sacrifice some bandwidth for some peace of mind.

Note however, that both in the original RCSP spec and in my proposed
scheme above there is another interesting open problem of dealing with
the CA
key change-over, i.e. when various subsets of the set of all issued
certificates (and CRLs !) are signed by different signing keys

I would be very interested in group's comments.
--
Slava Galperin          Certified Certificate Certifier
[email-masked]   tel: 650.937.6757

 It doesn't matter so much whether you've won the war or lost it.
 What matters is who you have lost it to.
                            -- From the memoirs of a married man

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Fri, 20 Mar 1998 17:44:48 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
To: [email-masked]

All,

As a concrete (and succinct) example, I include Russ' latest posting,
but I think that "rough consensus" is building on almost all these
issues.

>----------
>From:  Russ Housley[SMTP:[email-masked]]
>Sent:  Thursday, March 19, 1998 12:16 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] New OCSP Requirements
>
>Mike:
>
>Here are my responses:
>
>ASN.1  -  I support moving from ABNF to ASN.1.

Definite rough consensus.  Issue closed (as far as I can tell).

>Multiple Certs In Request  -  I think that this is desirable, but not
>mandatory.

Rough consensus (although I think the S/MIME example moves this to
"mandatory").

>Transport Independance  -  In my opinion, binding to HTTP is a mistake.
>Independence to the transport is highly desirable.

Rough consensus.

>Multiple Response Types  -  I think that revocation information is
>sufficient.

It may be too early to judge rough consensus, but there does seem to be
agreement that multiple response types would be easy to do syntactically
(particularly in ASN.1) and would provide desirable generality for
future evolution of the protocol without adding undue complexity.

>Ceritificate Identification  -  I think that CA DName with Serial Number is
>sufficient.

Denis and Ambarish both make valid points here:  we should try to align
with the S/MIME group if at all possible, but the structure being
discussed in that group is not sufficient if the OCSP responder does not
have the certificate itself (e.g., if it only has the issuer's
certificate and signed revocation information).  Perhaps a solution is
to add "issuerCertHash" to the CertUID structure, but this is starting
to look a bit unwieldy...

>Delegation of Authority  -  I think we should consider an enhancement at a
>later time in conjunction with other attribute certificate work.  However,
>you might want to include a certificate type in the protocol as a place
>holder.

It may be too early to judge rough consensus here as well, but there
does seem to be agreement that this work should be done in a broader
context.

Where do we go from here?  Given that the primary purpose of RSCP was to
do the editing work necessary to move the OCSP draft to ASN.1 and to
transport independence, it seems to me that the RCSP draft is the
logical basis for progression.  [If Mike is agreeable, his name can
certainly be included again on the authors list; furthermore, the
protocol name can go back to "OCSP" if people prefer this.]

Is it time for another straw poll?  Should the PKIX WG move forward from
the current OCSP or from the current RCSP?

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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 20 Mar 1998 14:43:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

Perry, Andrew, and Dwight,

I have to mildly disagree.

I don't want to get all wrapped up in a general purpose discussion
of trust, nor of the various pros and cons of possible transaction systems.
This isn't the place for that -- I'll leave the philosophy to Ed Gerck.

I certainly understand the difficulties with using a Reliance Limit in the
absence of "Dynamic, signed attributes retrieved securely by authenticated
real-time access to an on-line repository". That is the primary reason why
I have been pushing hard for a notarization model that includes the ability
to indicate to the repository, CA, or other mediator what the estimated value
of a particular message is to the relying party, in case either the subscriber
or the CA would like to keep track of the aggregate value and cut off further
approvals by revoking the certificate if things look like they are getting
out of hand.

This does NOT mean that all such messages are expected to be financial
transactions, at all. If I want to check that the latest series of messages
really and truly came from Perry, Andrew, or Dwight, perhaps because I
want to buy or sell short some CA's stock, depending on how I value the
message, then I may want to be reasonably sure that the message came
from them.

And in the good old fashioned American tradition, if something goes wrong,
I don't want to take the blame for a stupid decision on my part, I want to
sue someone to get well! :-)

Perry, however, may not enjoy the thought of my suing him for a gigabuck
because his rant led me to do something dumb, and especially if he didn't
even send the message but his evil twin Skippy did -- even if he is confident
that he will prevail in court --  he doesn't even want to get involved in
such silliness

So he might very well want to negotiate some kind of a limit of liability with
his CA, to be put into his certificate as at least an approximate indicator of
what both he and the CA think might be a reasonable upper limit for a
"commercially reasonable" reliance.  If I as the relyin gparty ignore that limit,
fuzzy though it might be, then I am taking the risk on my own head.

So yes, I agree. Without a closed loop validation, the CA doesn't know
how many times the subscriber will actually use his key to sign something, nor
the value of the "transaction"; and even the signer doesn't necessarily
know how many different people will validate his signature, and how many
times. (Consider a code-signing function applied to Windows 95.)

So from that perspective, if either the CA or the subscriber screwed up,
they could be facing infinity squared liability, even if the Reliance Limit
were a penny.

Yup, that's true.  So what?

Does that mean that because we can't be perfect, we shouldn't even
try to be prudent? I don't think so.  Even if it is like chicken soup for
a cold, it presumably won't hurt, and might actually do some good.

Surely you wouldn't completely dismiss the difference in due diligence
offered by the various classes of Verisign certificate, would you? In a sense,
they have a Relaince Limit -- it's just in their CPS instead of in their certificate.

Although we as technologists often think that we know a lot more about
the law, commerce, technology, etc. than the legislators do (and on some
favorite hot-button topics of mine, I'm certainly convinced that I do), we
didn't choose to run for office, and certainly weren't elected.  So the laws
are what they are, and we can perhaps lobby to change them if we
disagree with them, but we probably shouldn't ignore them.

As a result, we plan to provide for an optional Reliance Limit extension in
the certificates which our customers can produce using our  CA tools,
and the only issue I have is whether to include a Reliance Limit per
transaction, or per certificate (which is effectively what VeriSign does
in their CPS), or both.  At the moment I intend to provide both options.

The other issue is how to denominate the currency, but ISO 4317
solves that problem, and even allows me to specify the currency in gold.
(Whether grams, troy ounces, or pounds isn't clear).  So far, I can't
encode a Reliance Limit in terms of pound of flesh, but I'm working on it. :-)

I just didn't want to miss some particularly funky feature that some jurisdiction
thought would be neat, out of ignorance.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Andrew Csinger <[email-masked]> 03/20 12:13 PM >>>
>At 13:15 3/20/98 -0500, Perry E. Metzger wrote:
>>Sorry for ranting. I normally remain silent here, but the whole
>>concept of using third party signature guarantees in transactions is
>>so absurd -- and flys so far in the face of almost 1000 years of
>>merchant law and practice -- that I just had to say something. Its
>>utterly ridiculous.
>>Perry
>
>That's OK.  I've been saying it for years and it still gives me pleasure.
>I'll say it again:
>
>The signature on the certificate is not by itself the basis for trust.
>
>Andrew
>
>PS: Dynamic, signed attributes retrieved securely by authenticated real-
>    time access to an on-line repository, now, that's a different matter ;)

Approved-By:  Paul Koning <[email-masked]>
Date:         Fri, 20 Mar 1998 16:44:04 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

Question on Peter Gutmann's discussion on character string encoding:

It strikes me that part of the problem comes from the fact that ASN.1,
for historical reasons, includes a number of oddball string encodings
that are way out of mainstream.  Teletext is one example; I don't
remember exactly what T61String stands for but that sounds like
another.

Would it be possible to restrict encodings used to be selected only
from major mainstream standards?  Specifically: ISO 8859-1 (Latin-1)
and Unicode?

This has the advantage that most strings will in fact come across as
Latin-1; much of the time you can get away with thinking of that as
"ASCII".  It also has the advantage of supporting the national
characters of much of western Europe.  And, if memory serves, it's the
closest standard set to what Windows uses for its character set.

        paul

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 20 Mar 1998 13:52:59 -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] New CertUID (was: Re: [IETF-PKIX] New OCSPRequirements)
Comments: To: [email-masked]
To: [email-masked]

Isnt't the use of both serial and certificateHash redundant?

Perhaps CHOICE of two OPTIONAL attributes?

And I think we probably ought to spell out the desired semantics of the Issuer DN and/or issuerAltName.

There has been some extensive discussion of the cert-talk list about the requirement for multiple subjectAltNames to support multilingual countries. Some of these names may be "official", and some may be unofficial trnaslations or transliterations.

But merely defining the syntax isn't sufficinet. If I include my company's JPEG logo in subjectAltName, does that mean that would be a useful issuerAltName?  Probably not.

What are we assuming about these names, then.  Should they be locations I can retrieve a certificate from?  Probably. Using what kind of access method-- LDAP, http, mental telepathy? Any of the above?

Pardon me for barging in, since I just joined this list to discuss the multiple certificate per key issue.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Marc Branchaud <[email-masked]> 03/20 10:08 AM >>>
-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Denis Pinkas <[email-masked]> scrawled:
>
> This topic is being debated on the smime mailing list when talking about
> the CMS specification. There is no final position yet, but it seems that
> we are going towards the following structure:
>
> CertUID ::=     SEQUENCE {
>      issuerDN           Name,
>      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
>      serial             CertificateSerialNumber,
>      certificateHash    CertHash
> }
>
> This allows the support of alternate names and the certificate hash
> allows to make the difference between certificates that would be issued
> by CAs having the same name.
>
> In any case, I would recommend that the pkix group and the smime group
> adopt the same structure.
>

I'm completely for using this construct as the "official" certificate ID of
fine PKI implementations everywhere.

If I might make one small suggestion, it would be to make the
certificateHash OPTIONAL.  This would mean that the basic ID form is the
most efficient DN-and-serial, and it would only need to be expanded if that
were insufficient.

I did not follow the smime thread that lead / is leading to this structure,
so if there's a good reason for making certificateHash mandatory, please post
it.

                Marc

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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 20 Mar 1998 13:17: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:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
Comments: To: [email-masked], [email-masked]
To: [email-masked]

Peter, your comments and comparisons are extraordinarily useful, if sufficiently depressing to warrant taking a whole bottle of Prozac.

One question regarding the "least general encoding" rule.  Is it sufficient for a given application to trust the code page that is typically used in order to decide the string type, or is it necssary to examine each individual character in the string in order to determine what the absolutely minimal directoryString type should be?

Bob

>>> Peter Gutmann <[email-masked]> 03/19 11:52 PM >>>
Included below is the section from the X.509 style guide
(http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt) which covers
character set and string encoding issues, both the existing text on character
sets and the new bit on comparing strings.  I'd be interested in any comments
people have on this, in particular whether anyone has seriously looked at
implementing proper string handling on multiple platforms.  I have code which
implements this stuff if anyone wants it, the only condition for use is that
you have to send me a copy of any changes so I can keep things updated and
consistent.  I'd also like to get it tested by people in locales which use
DBCS's and other non-ASCII, non-8859-1 character sets.

Peter.

-- Snip --

Character Sets
--------------

Character strings are used in various places (most notably in DN's), and are
encumbered by the fact that ASN.1 defines a whole series of odd subsets of
ASCII/ISO 646 as character string types, but only provides a few peculiar and
strange oddball character encodings for anything outside this limited character
range.
                    The protruding upper halves of the letters now appear to
                    read, in the local language, "Go stick your head in a pig",
                    and are no longer illuminated, except at times of special
                    celebration.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

To use the example of DN's, the allowed string types are:

DirectoryString ::= CHOICE {
    teletexString           TeletexString (SIZE (1..maxSize)),
    printableString         PrintableString (SIZE (1..maxSize)),
    bmpString               BMPString (SIZE (1..maxSize)),
    universalString         UniversalString (SIZE (1..maxSize))
    }

The easiest one to use, if you can get away with it, is IA5String, which is
basically 7-bit ASCII, but with the dollar sign potentially replaced with a
"currency symbol".  In the DirectoryString case, you have to make do with
PrintableString, which is one of the odd ASCII/ISO 646 subsets (for example you
can't encode an '@', which makes it rather challenging to encode email
addresses).

Beyond that there is the T.61/TeletexString, which can select different
character sets using escape codes (this is one of the aforementioned "peculiar
and strange oddball encodings").  The character sets are Japanese Kanji (JIS C
6226-1983, set No. 87), Chinese (GB 2312-80, set No. 58), and Greek, using
shifting codes specified in T.61 or the international version, ISO 6937.  Some
of the characters have a variable-length encoding (ie it takes 2 bytes to
encode a character, with the interpretation being done in a context-specific
manner).  The reason I'm mentioning all this detail is to justify ending this
paragraph with the comment "Avoid this one".  Anyway: Avoid this one.

                    There are those who will say Danforth and I were utterly
                    mad not to flee for our lives after that; since our
                    conclusions were now completely fixed, and of a nature I
                    need not even mention to those who have read my account so
                    far.
                        - H.P.Lovecraft, "At the Mountains of Madness".

Next are the BMPString and UniversalString, with BMPString having 16-bit
characters and UniversalString having 32-bit characters, both encoded in
big-endian format.  BMPString is a subset of UniversalString, being the 16-bit
character range in the 0/0 plane (ie the UniversalString characters in which
the 16 high bits are 0, or UCS-2), corresponding to straight ISO 10646/Unicode
characters.  UniversalString apparently comes with its own set of complex
encoding issues involving mucking around with code tables and shift functions
and escape sequences and variable-length character encodings and God knows what
other horrors (another part of the standard however says that "Control
functions and signatures shall not be used").  In addition the ASN.1 standard
says that it should only be used if the encoding possibilities are constrained,
it's better to avoid it entirely and only use BMPString/ISO 10646/Unicode.

                    I might as well be frank in stating what we saw; though at
                    the time we felt that it was not to be admitted even to
                    each other.  The words reaching the reader can never even
                    suggest the awfulness of the sight itself.
                        - H.P.Lovecraft, "At the Mountains of Madness".

However, there is a problem with this: at the moment few implementors know how
to handle or encode BMPStrings, and people have made all sorts of guesses as to
how Unicode strings should be encoded: with or without Unicode byte order marks
(BOMs), possibly with a fixed endianness, and with or without the terminating
null character.

The correct format for BMPStrings is: big-endian 16-bit characters, no Unicode
byte order marks (BOMs), and no terminating null character (ISO 8825-1 section
8.20).

An exception to this is PFX/PKCS #12, where the passwords are converted to a
Unicode BMPString before being hashed.  However both Netscape and Microsoft's
early implementations treated the terminating null characters as being part of
the string, so the PKCS #12 standard was retroengineered to specify that the
null characters be included in the string.

Because of these problems, the SET designers produced their own alternative,
SETString, for places were DN's weren't required for compatibility purposes.
The design goals for the SETString were to both provide the best coverage of
ASCII and national-language character sets, and also to minimise implementation
pain.  The SETString type is defined as:

SETString ::= CHOICE {
    visibleString           VisibleString (SIZE (1..maxSIZE)),
    bmpString               BMPString (SIZE (1..maxSIZE))
    }

This provides complete ASCII/ISO 646 support using single byte characters, and
national language support through Unicode, which is in common use by industry.

In addition the SET designers decided to create their own version of the
DirectoryString which is a proper subset of the X.500 version.  The initial
version was just an X.500 DirectoryString with a number of constraints applied
to it, but just before publication this was changed to:

DirectoryString ::= CHOICE {
    printableString         PrintableString (SIZE(1..maxSIZE)),
    bmpString               BMPString (SIZE(1..maxSIZE))
    }

It was felt that this improved readablility and interoperability.  T61String
was never seriously considered in the design, and UniversalString with its
four-byte characters had no identifiable industry support and required too much
overhead.  If you want to produce certs which work for both generic X.509 and
SET, then using the SET version of the DirectoryString is a good idea.  It's
trivial to convert an ISO 8859-1 T61String to a BMPString and back (just
add/subtract a 0 byte every other byte).

A good rule of thumb when dealing with these character sets is to use the
"least inclusive" set when trying to determine which encoding to use.  This
means trying to encode as PrintableString first, then T61String, and finally
BMPString/UniversalString.  Microsoft goes from PrintableSting straight to
UniversalString encodings with the result that many cerficates have unnecessary
multibyte encodings, and can't be interpreted by any other software in
existence.  SET requires that either PrintableStrings or BMPStrings be used,
with TeletexStrings and UniversalStrings being forbidden.

>From this we can build the following set of recommendations:

- Use PrintableString if possible (or IA5String if this is allowed, because
  it's somewhat more versatile than PrintableString).
- If if won't go into a PrintableString, try for a BMPString.  However since
  noone's software really understands these, you may have to use a T61String
  instead.
- Only use a T61String if you really have to, and if you don't require SET
  compliance.  Avoid the use of anything involving shifting and escape codes at
  any cost - treat it as a pure ISO 8859-1 string.
- Avoid UniversalStrings.

Comparing DN's
--------------

This is an issue which is so problematic that it requires a section of its own
to cover it fully.  According to X.500, to compare a DN:

- The number of RDN's must match.
- RDN's must have the same number of AVA's.
- Corresponding AVA's must match for equality:
  - Leading and trailing spaces are ignored.
  - Multiple internal spaces are treated as a single internal space.
  - Characters (not code points, which are a particular encoding of a
    character) are matched in a case-insensitive manner.

As it turns out, this matching is virtually impossible to perform (more
specifically, it is virtually impossible to accurately compare two DN's for
equivalence).
                    This, many claim, is not merely impossible but clearly
                    insane, which is why the advertising executives of the star
                    system of Bastablon came up with this quote: 'If you've
                    done six impossible things this morning, why not round it
                    off with breakfast at Milliways, the Restaurant at the End
                    of the Universe?'.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

The reason for this is that, with the vast number of character sets, encodings,
and alternative encodings (code points) for the same character, and the often
very limited support for non-ASCII character sets available on many systems, it
isn't possible to accurately and portably compare any RDN's other than those
containing one of the basic ASCII string types.  The best you can probably do
is to use the strategy outlined below.

First, check whether the number of RDN's is equal.  If they match, break up the
DN's into RDN's and check that the RDN types match.  If they also match, you
need to compare the text in each RDN in turn.  This is where it gets tricky.

                    He walked across to the window and suddenly stumbled
                    because at that moment his Joo-Janta 200 Super-Chromatic
                    Peril Sensitive sunglasses had turned utterly black.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

First, take both strings and convert them to either ASCII (ISO646String) or
Unicode (BMPString) using the "least inclusive" rule.  This is quite a task in
itself, because several implementations aren't too picky about what they'll put
into a string, and will stuff T61String characters into a PrintableString, or
(more commonly) Unicode characters into a T61String or anything into a
BMPString.  Finding a T61String in a PrintableString or an 8-bit character set
string in a BMPString is relatively easy, but the best guess you can take at
detecting a Unicode string in a T61String is to check whether either the string
length is odd or all the characters are ASCII or ASCII with the high bit set.
If neither are true, it might be a Unicode string disguised as a T61String.

Once this is done, you need to canonicalise the strings into a format in which
a comparison can be done, either to compare strings of different types (eg
8-bit character set or DBCS string to BMPString) or strings with the same type
but different encodings (eg two T61Strings using alternative encodings).  To
convert ASCII-as-Unicode to ASCII, just drop the odd-numbered bytes. Converting
a T61String to Unicode is a bit more tricky.  Under Windows 95 and NT, you can
use MultiByteToWideChar(), although the conversion will depend on the current
code page in use.  On systems with widechar support, you can use mbstowcs()
directly if the widechar size is the same as the BMPString char size (which it
generally isn't), otherwise you need to first convert the string to a widechar
string with mbstowcs() and then back down again to a BMPString, taking the
machine endianness into account.  Again, the behaviour of mbstowcs() will
depend on the current locale in use.  If the system doesn't have widechar
support, the best you can do is a brute-force conversion to Unicode by hoping
it's ISO 8859-1 and adding a zero byte every other byte.

Now that you might have the strings in a format where they can be compared, you
can actually try and compare them.  Again, this often ends up as pure guesswork
if the system doesn't support the necessary character sets, or if the
characters use weird encodings which result in identical characters being
located at different code points.

First, check the converted character sets: If one is Unicode and the other
isn't, then the strings probably differ (depending on how well the
canonicalisation step went).  If the types are the same, strip leading,
trailing, and repeated internal spaces from the string, which isn't as easy as
it sounds since there are several possible code points allocated to a space.

Once you've had a go at stripping spaces, you can try to compare the strings.
If the string is a BMPString then under Windows NT (but not Windows 95) you can
use CompareString(), with the usual caveat that the comparison depends on the
current locale.  On systems which support towlower() you can extract the
characters from the string into widechars (taking machine endianness into
account) and compare the towlower() forms, with the usual caveat about locale
and the added problem that towlower() implementations vary from bare-bones
(8859-1 only under Solaris) to vague (Unicode under Win95, OSF/1).  If there's
no support for towlower(), the best you can do is use the normal tolower() if
the characters have a high byte of zero (some systems will support 8859-1 for
tolower(), the worst which can happen is that the characters will be returned
unchanged), and compare the code points directly if it isn't an 8-bit value.

                    Zaphods skin was crawling all over his body as if it was
                    trying to get off.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

Finally, if it's an ASCII string, you can just use a standard case-insensitive
string comparison function.

As you can see, there's almost no way to reliably compare two RDN elements. In
particular, no matter what you do:

- Some malicious users will deliberately pass DN checks with weird encodings.
- Some normal users will accidentally fail DN checks with weird encodings.

This becomes an issue when certain security checks depend on a comparison of
DN's (for example with excluded subtrees in the Name Constraints extension)
because it's possible to create multiple strings which are displayed
identically to the user (especially if you know which platform and/or software
to target) assuming they get displayed at all, but which compare as different
strings.  If you want to be absolutely certain about DN comparisons, you might
need to set a certificate policy of only allowing PrintableStrings in DN's,
because they're the only ones which can be reliably compared.

Approved-By: [email-masked]
Date:         Fri, 20 Mar 1998 14:26:22 -0500
Reply-To: John Horton <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: John Horton <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

And why I would contend that a distributed model vs. a hierarchial model be
designed & implemented.

JH

-----Original Message-----
From: Andrew Csinger <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Friday, March 20, 1998 2:16 PM
Subject: Re: [IETF-PKIX] Reliance limits in statutes

>At 13:15 3/20/98 -0500, Perry E. Metzger wrote:
>>Sorry for ranting. I normally remain silent here, but the whole
>>concept of using third party signature guarantees in transactions is
>>so absurd -- and flys so far in the face of almost 1000 years of
>>merchant law and practice -- that I just had to say something. Its
>>utterly ridiculous.
>>Perry
>
>That's OK.  I've been saying it for years and it still gives me pleasure.
>I'll say it again:
>
>The signature on the certificate is not by itself the basis for trust.
>
>Andrew
>
>PS: Dynamic, signed attributes retrieved securely by authenticated real-
>    time access to an on-line repository, now, that's a different matter ;)
>
>--------------------------------------------------------------
>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
>--------------------------------------------------------------
>

Approved-By:  Jeff Weinstein <[email-masked]>
Date:         Fri, 20 Mar 1998 11:59:59 -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: Jeff Weinstein <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

In case its not clear from my comments below, I say YES to asn.1.

David P. Kemp wrote:
> Your argument presupposes that Microsoft and Netscape will refuse to
> ship IETF-standard OCSP ironmongery in their products, as well as that
> independent developers are incapable of providing that support in the
> script/plugin/applet/dll aftermarket.  How likely is that?

  I just want to be clear here.  Netscape products include a fairly general
ASN.1/BER/DER encoder/decoder internally, which is used by our certificate
and S/MIME libraries.  It is not a burden to us at all to support ASN.1
for OCSP.  It is actually better for us if we don't have to construct a
new parser.

> > I think the vote should also clearly point out that there is a loss of
> > functionality in going to ASN.1.The responses are no longer
> > cachable as HTTP requests.
>
> Then how does KEYGEN work?

  I don't understand Phill's argument.  If OCSP was transport independent,
then we could specify a wrapping for it that would work in HTTP and
be cachable.

        --Jeff

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Fri, 20 Mar 1998 11:39:05 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] Unique Identification of a Certificate
Comments: To: [email-masked]
Comments: cc: "Jim Schaad (Exchange)" <[email-masked]>, Blake Ramsdell <[email-masked]>, "[email-masked]" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
To: [email-masked]

Hi Denis,
    I joined the SMIME mailing list just recently, so I am not certain
of the problem you guys are trying to solve. Let me explain the
issues in RCSP and the reasoning for choosing the method I have
for trying to uniquely identify a cert:

In RCSP, a client is sending over one or more certificates to an
RCSP responder, to check their revocation status.
I think we all agree that issuer/serial is sufficient to uniquely
identify a certificate.
So the question is: how does one uniquely identify an issuer.
I submit that the DN is not enough, because it is possible for
the to be DN name clashes - either maliciously, or because two
groups don't talk to each other before they choose their names.
There really is no way of enforcing uniqueness is issuer DNs all
over the world.
However, public keys don't suffer from the problem of impersonation.
If somebody else claims to have the same public/private key as me,
it is easy to prove otherwise.
Therefore, we have chosen to use the issuerDN, issuerPublicKey
and CertificateSerialNumber to uniquely identify a cert. (I need
to add the issuerAltName also, as you have).
As an optimization, to reduce the size of a request, we ask the
requestor to hash the issuerDN and issuerPublicKey in the request
rather than sending all the bytes.

Adding the certificateHash in the CertUID doesn't help us identify
the cert at all, because as an RCSP responder, I don't have the
cert itself - so I can't verify the CertHash against anything.

As an aggregator of revocation data/CRLs from multiple CAs, we
would like to be able to accept all CRLs - including ones where
the DNs might clash.

Is the SMIME problem different from this one? Does the recipient
already have the certificate the sender is referring to?

Regards,
Ambarish

P.S. For those who haven't been actively following these groups,
my suggestion for cert identification is:

CertID                  ::=     SEQUENCE {
        issuerNameAndKeyHash            Hash,
        serialNumber                    CertificateSerialNumber,
}

IssuerNameAndKey                ::=     SEQUENCE {
        issuerDN                        Name,
        issuerAltName                   IssuerAltName OPTIONAL,
        issuerPublicKey                 SubjectPublicKeyInfo
}

i.e. you identify a cert by the hash of the IssuerNameAndKey
and a serial number.

The hash includes the public key of the issuer - this prevents the
Banana Republic CA from impersonating our well beloved and well
trusted US CA ;-).

Ofcourse, if keeping the size of the request small is not important,
or the recipient might not be able to figure out the issuer from
the hash, it might make sense to send IssuerNameAndKey instead
of its hash.

Denis Pinkas wrote:
>
> There is no final position yet, but it seems that we are going towards
> the following structure:
>
> CertUID ::=     SEQUENCE {
>      issuerDN           Name,
>      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
>      serial             CertificateSerialNumber,
>      certificateHash    CertHash
> }
>
> This allows the support of alternate names and the certificate hash
> allows to make the difference between certificates that would be issued
> by CAs having the same name.
>
> In any case, I would recommend that the pkix group and the smime group
> adopt the same structure.
>
> Denis
>
> --
>       Denis Pinkas     Bull S.A.          mailto:[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

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Fri, 20 Mar 1998 14:30:30 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: Andrew Csinger <[email-masked]>
To: [email-masked]

[This really isn't PKIX material in a direct sense. Uninterested
people will want to hit <delete> now. Sorry for bringing this stuff up.]

Andrew Csinger writes:
> At 13:15 3/20/98 -0500, Perry E. Metzger wrote:
> >Sorry for ranting. I normally remain silent here, but the whole
> >concept of using third party signature guarantees in transactions is
> >so absurd -- and flys so far in the face of almost 1000 years of
> >merchant law and practice -- that I just had to say something. Its
> >utterly ridiculous.
> >Perry
>
> That's OK.  I've been saying it for years and it still gives me pleasure.
> I'll say it again:
>
> The signature on the certificate is not by itself the basis for trust.

"Trust" is not the issue. Certificates are designed to create
multilateral trust, but that sort of trust doesn't matter in most
payment scenarios, because the signature doesn't matter to the payee,
so the payee has no reason to check the signature.

It usually doesn't matter to the merchant if the signature is
legitimate, because that isn't what guarantees if he gets paid. It
matters to the bank, not the merchant -- and the bank's relationship
with the payor is bilateral, not multilateral, so there is no reason
for the bank to trust a third party since it has regular dealings with
the payor and can keep a copy of the payor's public key on file, in
precisely the manner of a signature card.

Of course, most people don't understand this, or ignore it. Sigh.

> PS: Dynamic, signed attributes retrieved securely by authenticated real-
>     time access to an on-line repository, now, that's a different matter ;)

I'm really curious how many people here who are off designing
interesting "Internet Commerce Protocols Of The Future" (TM) even
understand basic concepts of commercial paper, like what an
endorsement signature on a check actually means. My guess is "maybe
two or three of us reading this, at best."

Sigh.

Perry

Approved-By:  Andrew Csinger <[email-masked]>
Date:         Fri, 20 Mar 1998 11:13:21 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Andrew Csinger <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

At 13:15 3/20/98 -0500, Perry E. Metzger wrote:
>Sorry for ranting. I normally remain silent here, but the whole
>concept of using third party signature guarantees in transactions is
>so absurd -- and flys so far in the face of almost 1000 years of
>merchant law and practice -- that I just had to say something. Its
>utterly ridiculous.
>Perry

That's OK.  I've been saying it for years and it still gives me pleasure.
I'll say it again:

The signature on the certificate is not by itself the basis for trust.

Andrew

PS: Dynamic, signed attributes retrieved securely by authenticated real-
    time access to an on-line repository, now, that's a different matter ;)

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

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Fri, 20 Mar 1998 13:15:14 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

Dwight Arthur writes:
> Last I checked, NY and VT pending statutes included the "reliance limit"
> concept. On a personal note, this is one reason that I will work against
> the passage of either.

The entire "reliance limit" idea shows how twisted the whole notion of
using certificates in commerce is.

All real world transactions are bilateral, not multilateral. Digital
signatures are being asked to fulfill roles that real signatures do
not, and the systems to do so are being envisioned by people who've
never touched an actual clearing and settlement system in a real bank
or brokerage. This is very much an example of the engineers completely
misunderstanding how the thing they are trying to enhance operates. A
few months working in the cage at a brokerage or in a clearinghouse
would probably fix most misperceptions, but people of course aren't
perpared to do that.

This is, of course, why the payments systems people have been
developing for several years now have all sunk like lead balloons.

Sorry for ranting. I normally remain silent here, but the whole
concept of using third party signature guarantees in transactions is
so absurd -- and flys so far in the face of almost 1000 years of
merchant law and practice -- that I just had to say something. Its
utterly ridiculous.

Perry

Approved-By:  Russ Housley <[email-masked]>
Date:         Fri, 20 Mar 1998 12:23:30 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

At 05:13 PM 3/19/98 +1200, Peter Gutmann wrote:
>4.2.1.2.
>
>This gives the subject key identifier as the hash of the subjectPublicKeyInfo
>*without* the tag and length.  Is this a mistake, or is it meant to be like
>that?  Every other instance in which an ASN.1 object is hashed (eg
>certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes the
>entire object.  In fact the PKIX CMP draft uses a hash of the full
>subjectPublicKeyInfo in the OOBCertHash, which would make it incompatible
with
>the value in the subject key identifier.  Requiring a well-defined standard
>X.509 object to be broken up into pieces before processing it seems an
>extremely peculiar move, so I'm guessing it's some sort of mistake in the
spec.

This was done prior to the CMP section.  To use the public key, you need to
get the value out of the certificate without the associated ASN.1 stuff, so
that was the reason we chose to hash just the key.

>In addition I really don't like the idea of dumping a raw hash into the
>KeyIdentifier OCTET STRING, because it's not possible to distinguish it from
>whatever anyone else decides to put in there.  Much better would be to use
the
>PKCS #7 DigestInfo, which is well-defined and whose OID + data format
uniquely
>identifies the contents (that is, make the KeyIdentifier an OCTET STRING hole
>for a DigestInfo rather than an opaque blob).  Given that a KeyIdentifier
>could potentially contain anything, it's somewhat risky to put raw,
>unidentified data in there.

The hash the default way to make a key identifier.  Other schemes can be
used.  The idea is to identify the key, and the hash of the key is a simple
way to make an identifier for the key.

>4.2.1.3.
>
>The decipherOnly key usage indicates that the public key can only be used for
>deciphering data.  This would be quite a feat :-).  I assume this should say
>that the private key corresponding to the public key can only be used for
>deciphering data.

No.  The encipherOnly and decipherOnly apply only to key agreement.  These
bits are intended to place rescrictions on the key that results from key
agreement operations.

>Speaking of private vs public keys, it would be useful to have some standard
>unambiguous term defined to indicate the private key which is tied to the
>public key, eg "corresponding to" or "identified by" or "paired with" or
>something similar.  I've used "identified by" (eg "The end-user certificate
>should be signed by the private key identified by a CA certificate"), but I'm
>not sure if that sounds right.  The current draft seems to use different
terms
>in different places.

Different authors leads to different terms.  I suggest that Tim Polk (who
is now the senior editor) make it read like one person wrote it.  This
depends on the amount of time that he can spend on the task.  Are there any
places where this actually makes the text confusing?

>7.3.2.
>
>This gives a redundant definition of the DH p and g values (the ASN.1
>definition is followed immediately by text which says exactly the same
thing -
>actually the RSA definition does this too with n and e), but doesn't explain
>the INTEGER which is the DH public key (what *is* this value?  The only thing
>I can think of is g^x mod p, but that shouldn't be a fixed value).  It also
>goes to some lengths to explain the encoding of the INTEGER parameter as a
BIT
>STRING, which seems very odd.

Whould you like to suggest improved text?

Russ

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Fri, 20 Mar 1998 09:08:15 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      [IETF-PKIX] New CertUID (was: Re: [IETF-PKIX] New OCSP Requirements)
Comments: To: [email-masked]
To: [email-masked]

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

Content-Type: text/plain; charset=us-ascii

Denis Pinkas <[email-masked]> scrawled:
>
> This topic is being debated on the smime mailing list when talking about
> the CMS specification. There is no final position yet, but it seems that
> we are going towards the following structure:
>
> CertUID ::=     SEQUENCE {
>      issuerDN           Name,
>      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
>      serial             CertificateSerialNumber,
>      certificateHash    CertHash
> }
>
> This allows the support of alternate names and the certificate hash
> allows to make the difference between certificates that would be issued
> by CAs having the same name.
>
> In any case, I would recommend that the pkix group and the smime group
> adopt the same structure.
>

I'm completely for using this construct as the "official" certificate ID of
fine PKI implementations everywhere.

If I might make one small suggestion, it would be to make the
certificateHash OPTIONAL.  This would mean that the basic ID form is the
most efficient DN-and-serial, and it would only need to be expanded if that
were insufficient.

I did not follow the smime thread that lead / is leading to this structure,
so if there's a good reason for making certificateHash mandatory, please post
it.

                Marc

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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Fri, 20 Mar 1998 17:07:09 -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] New OCSP Requirements
To: [email-masked]

Michael,

I agree with most of the comments sent on OCSP, the support of
revocation (for multiple certificates) instead of validation, etc... but
I would like to focus on Certificate Identification.

(...)

> To resolve this point, I would ask that participating members of PKIX
> provide their opinion on the matter.  As with the ASN.1 issue, OCSP can and
> will be adjusted to reflect that consensus.  Until then I would prefer to
> maintain the spec of certID as is since it is aligned with concepts defined
> in X.509.
>
> My concern here is alignment with other PKI-based security protocols, not
> the least of with is CMS.  Might I note that the SignerInfos syntax has as
> an element issuerAndSerialNumber which is defined as:
>
> IssuerAndSerialNumber ::= SEQUENCE {
>         issuer Name,
>         serialNumber SerialNumber }
>
> SerialNumber ::= INTEGER

This topic is being debated on the smime mailing list when talking about
the CMS specification. There is no final position yet, but it seems that
we are going towards the following structure:

CertUID ::=     SEQUENCE {
     issuerDN           Name,
     issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
     serial             CertificateSerialNumber,
     certificateHash    CertHash
}

This allows the support of alternate names and the certificate hash
allows to make the difference between certificates that would be issued
by CAs having the same name.

In any case, I would recommend that the pkix group and the smime group
adopt the same structure.

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Rich Salz <[email-masked]>
Date:         Fri, 20 Mar 1998 10:00:32 -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 Salz <[email-masked]>
Subject:      [IETF-PKIX] We voted, now what?
To: [email-masked]

I'm confused by the results of the straw poll.

I understand that the documentation used in the RFC is going to change.
Instead of
        ocsp-request = url version target [extensions] [signature] [extensions]
        extensions = *extension
It's going to be
        OCSP-REQUEST ::= { SIGNED { VERSION TARGET EXTENSIONS } EXTENSIONS }
        EXTENSIONS ::= SEQUENCE OF EXTENSION
(I'm sure I have syntax errors in both notations. :)

What's not at all clear to me is this:
    -   Is the wire protocol also going to change?  I have seen messages
        on this list that implied this, asked for this, and were also
        silent on this matter.
    -   If so, how?
            -   A new reserved port# which sends/receives the PDU's
                defined in the spec; and/or
            -   For HTTP, a defined "well-known URL" which uses GET
                and replies to transmit the PDU's as a defined MIME type
    -   If not, how?
            -   Define an ASN.1 to "netascii" mapping?

Is it clear to everyone else?  Anyone else? :)
        /r$

Approved-By:  "Charles W. Gardiner" <[email-masked]>
Date:         Fri, 20 Mar 1998 10:04:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Charles W. Gardiner" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

    ASN.1 by all means.  It's so simple to use!

Charlie Gardiner

Approved-By:  Dwight Arthur <[email-masked]>
Date:         Thu, 19 Mar 1998 18:27: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: Dwight Arthur <[email-masked]>
Subject:      [IETF-PKIX] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

Bob,

Last I checked, NY and VT pending statutes included the "reliance limit"
concept. On a personal note, this is one reason that I will work against
the passage of either.

-Dwight

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 20 Mar 1998 09:09: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

> From: "Phillip M. Hallam-Baker" <[email-masked]>
>
> The arguments about ASN.1 parsers are completely bogus. Windows NT
> ships with PKCS#7 parsing ironmongery but it does not ship with a generic
> ASN.1 compiler. Similar arguments hold for other platforms.

Why is that an argument against the use of ASN.1 in OCSP?  PKCS#7 is
specified in ASN.1.  If PKCS#7 were specified in ABNF and Windows NT
supported it, then that example might support your position.  But can
you actually envision a world based on ABNF PKCS#7?  I shudder at the
thought :-).

Your argument presupposes that Microsoft and Netscape will refuse to
ship IETF-standard OCSP ironmongery in their products, as well as that
independent developers are incapable of providing that support in the
script/plugin/applet/dll aftermarket.  How likely is that?

> I think the vote should also clearly point out that there is a loss of
> functionality in going to ASN.1.The responses are no longer
> cachable as HTTP requests.

Then how does KEYGEN work?

> It is easy to make arguments about consistency, I am concerned about
> function.

As is everyone else.  Function argues in favor of ASN.1.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 20 Mar 1998 08:49: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

> From: "Matthew S. Hamrick" <[email-masked]>
>
> Yes, provided it specifies DER encoding.
>
> I believe that one's opinion of this topic is heavily influenced by how
> good your ASN.1 / BER / DER tools are. I have a toolset that that
> generates a remarkably good code footprint if you turn indefinite length
> encoding off.

If the toolset generates remarkably bad code with indefinite length
encoding (BER) enabled, it's a very strange toolset.  For the size of
messages envisioned for OCSP, there isn't any particular advantage to
using BER (for one-pass processing), but I don't see any reason to
restrict OCSP to DER either.  Indefinite length is marginally easier
for the encoder, definite length is marginally easier for the decoder.
Either way, as long as the OCSP message fits in memory, the difference
in coder footprint is minimal.

Approved-By:  Russ Housley <[email-masked]>
Date:         Thu, 19 Mar 1998 12:16: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: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

Mike:

Here are my responses:

ASN.1  -  I support moving from ABNF to ASN.1.

Multiple Certs In Request  -  I think that this is desirable, but not
mandatory.

Transport Independance  -  In my opinion, binding to HTTP is a mistake.
Independence to the transport is highly desirable.

Multiple Response Types  -  I think that revocation information is sufficient.

Ceritificate Identification  -  I think that CA DName with Serial Number is
sufficient.

Delegation of Authority  -  I think we should consider an enhancement at a
later time in conjunction with other attribute certificate work.  However,
you might want to include a certificate type in the protocol as a place
holder.

Russ

Approved-By:  Russ Housley <[email-masked]>
Date:         Thu, 19 Mar 1998 12:04:29 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

I would like to see the protocol move to ASN.1.

Russ

At 10:30 PM 3/18/98 -0800, Michael Myers wrote:
>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Fri, 20 Mar 1998 11:44:21 +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: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] Question about CMMF
To: [email-masked]

To the list,

The following is written in Certificate Management Message Formats
(CMMF)
february 1998, page 2:

... Using these message formats, a PKI client may:
           ...
- Request data of a PKI, including:
     - One’s own or others’ certificate

However, in the document I failed to find any ASN.1 structure supporting
the
situation, where an end entity requests for a certificate of another end
entity.

Can someone tell me, which structure/message should be used in this
situation?

- Jakob

Approved-By:  Nada Kapidzic Cicovic <[email-masked]>
Date:         Fri, 20 Mar 1998 11:20: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: Nada Kapidzic Cicovic <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

ASN.1 seems to be a natural choice.

Nada

At 22:30 3/18/98 -0800, you wrote:
>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 22:52:20 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Gutmann <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

Included below is the section from the X.509 style guide
(http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt) which covers
character set and string encoding issues, both the existing text on character
sets and the new bit on comparing strings.  I'd be interested in any comments
people have on this, in particular whether anyone has seriously looked at
implementing proper string handling on multiple platforms.  I have code which
implements this stuff if anyone wants it, the only condition for use is that
you have to send me a copy of any changes so I can keep things updated and
consistent.  I'd also like to get it tested by people in locales which use
DBCS's and other non-ASCII, non-8859-1 character sets.

Peter.

-- Snip --

Character Sets
--------------

Character strings are used in various places (most notably in DN's), and are
encumbered by the fact that ASN.1 defines a whole series of odd subsets of
ASCII/ISO 646 as character string types, but only provides a few peculiar and
strange oddball character encodings for anything outside this limited character
range.
                    The protruding upper halves of the letters now appear to
                    read, in the local language, "Go stick your head in a pig",
                    and are no longer illuminated, except at times of special
                    celebration.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

To use the example of DN's, the allowed string types are:

DirectoryString ::= CHOICE {
    teletexString           TeletexString (SIZE (1..maxSize)),
    printableString         PrintableString (SIZE (1..maxSize)),
    bmpString               BMPString (SIZE (1..maxSize)),
    universalString         UniversalString (SIZE (1..maxSize))
    }

The easiest one to use, if you can get away with it, is IA5String, which is
basically 7-bit ASCII, but with the dollar sign potentially replaced with a
"currency symbol".  In the DirectoryString case, you have to make do with
PrintableString, which is one of the odd ASCII/ISO 646 subsets (for example you
can't encode an '@', which makes it rather challenging to encode email
addresses).

Beyond that there is the T.61/TeletexString, which can select different
character sets using escape codes (this is one of the aforementioned "peculiar
and strange oddball encodings").  The character sets are Japanese Kanji (JIS C
6226-1983, set No. 87), Chinese (GB 2312-80, set No. 58), and Greek, using
shifting codes specified in T.61 or the international version, ISO 6937.  Some
of the characters have a variable-length encoding (ie it takes 2 bytes to
encode a character, with the interpretation being done in a context-specific
manner).  The reason I'm mentioning all this detail is to justify ending this
paragraph with the comment "Avoid this one".  Anyway: Avoid this one.

                    There are those who will say Danforth and I were utterly
                    mad not to flee for our lives after that; since our
                    conclusions were now completely fixed, and of a nature I
                    need not even mention to those who have read my account so
                    far.
                        - H.P.Lovecraft, "At the Mountains of Madness".

Next are the BMPString and UniversalString, with BMPString having 16-bit
characters and UniversalString having 32-bit characters, both encoded in
big-endian format.  BMPString is a subset of UniversalString, being the 16-bit
character range in the 0/0 plane (ie the UniversalString characters in which
the 16 high bits are 0, or UCS-2), corresponding to straight ISO 10646/Unicode
characters.  UniversalString apparently comes with its own set of complex
encoding issues involving mucking around with code tables and shift functions
and escape sequences and variable-length character encodings and God knows what
other horrors (another part of the standard however says that "Control
functions and signatures shall not be used").  In addition the ASN.1 standard
says that it should only be used if the encoding possibilities are constrained,
it's better to avoid it entirely and only use BMPString/ISO 10646/Unicode.

                    I might as well be frank in stating what we saw; though at
                    the time we felt that it was not to be admitted even to
                    each other.  The words reaching the reader can never even
                    suggest the awfulness of the sight itself.
                        - H.P.Lovecraft, "At the Mountains of Madness".

However, there is a problem with this: at the moment few implementors know how
to handle or encode BMPStrings, and people have made all sorts of guesses as to
how Unicode strings should be encoded: with or without Unicode byte order marks
(BOMs), possibly with a fixed endianness, and with or without the terminating
null character.

The correct format for BMPStrings is: big-endian 16-bit characters, no Unicode
byte order marks (BOMs), and no terminating null character (ISO 8825-1 section
8.20).

An exception to this is PFX/PKCS #12, where the passwords are converted to a
Unicode BMPString before being hashed.  However both Netscape and Microsoft's
early implementations treated the terminating null characters as being part of
the string, so the PKCS #12 standard was retroengineered to specify that the
null characters be included in the string.

Because of these problems, the SET designers produced their own alternative,
SETString, for places were DN's weren't required for compatibility purposes.
The design goals for the SETString were to both provide the best coverage of
ASCII and national-language character sets, and also to minimise implementation
pain.  The SETString type is defined as:

SETString ::= CHOICE {
    visibleString           VisibleString (SIZE (1..maxSIZE)),
    bmpString               BMPString (SIZE (1..maxSIZE))
    }

This provides complete ASCII/ISO 646 support using single byte characters, and
national language support through Unicode, which is in common use by industry.

In addition the SET designers decided to create their own version of the
DirectoryString which is a proper subset of the X.500 version.  The initial
version was just an X.500 DirectoryString with a number of constraints applied
to it, but just before publication this was changed to:

DirectoryString ::= CHOICE {
    printableString         PrintableString (SIZE(1..maxSIZE)),
    bmpString               BMPString (SIZE(1..maxSIZE))
    }

It was felt that this improved readablility and interoperability.  T61String
was never seriously considered in the design, and UniversalString with its
four-byte characters had no identifiable industry support and required too much
overhead.  If you want to produce certs which work for both generic X.509 and
SET, then using the SET version of the DirectoryString is a good idea.  It's
trivial to convert an ISO 8859-1 T61String to a BMPString and back (just
add/subtract a 0 byte every other byte).

A good rule of thumb when dealing with these character sets is to use the
"least inclusive" set when trying to determine which encoding to use.  This
means trying to encode as PrintableString first, then T61String, and finally
BMPString/UniversalString.  Microsoft goes from PrintableSting straight to
UniversalString encodings with the result that many cerficates have unnecessary
multibyte encodings, and can't be interpreted by any other software in
existence.  SET requires that either PrintableStrings or BMPStrings be used,
with TeletexStrings and UniversalStrings being forbidden.

>From this we can build the following set of recommendations:

- Use PrintableString if possible (or IA5String if this is allowed, because
  it's somewhat more versatile than PrintableString).
- If if won't go into a PrintableString, try for a BMPString.  However since
  noone's software really understands these, you may have to use a T61String
  instead.
- Only use a T61String if you really have to, and if you don't require SET
  compliance.  Avoid the use of anything involving shifting and escape codes at
  any cost - treat it as a pure ISO 8859-1 string.
- Avoid UniversalStrings.

Comparing DN's
--------------

This is an issue which is so problematic that it requires a section of its own
to cover it fully.  According to X.500, to compare a DN:

- The number of RDN's must match.
- RDN's must have the same number of AVA's.
- Corresponding AVA's must match for equality:
  - Leading and trailing spaces are ignored.
  - Multiple internal spaces are treated as a single internal space.
  - Characters (not code points, which are a particular encoding of a
    character) are matched in a case-insensitive manner.

As it turns out, this matching is virtually impossible to perform (more
specifically, it is virtually impossible to accurately compare two DN's for
equivalence).
                    This, many claim, is not merely impossible but clearly
                    insane, which is why the advertising executives of the star
                    system of Bastablon came up with this quote: 'If you've
                    done six impossible things this morning, why not round it
                    off with breakfast at Milliways, the Restaurant at the End
                    of the Universe?'.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

The reason for this is that, with the vast number of character sets, encodings,
and alternative encodings (code points) for the same character, and the often
very limited support for non-ASCII character sets available on many systems, it
isn't possible to accurately and portably compare any RDN's other than those
containing one of the basic ASCII string types.  The best you can probably do
is to use the strategy outlined below.

First, check whether the number of RDN's is equal.  If they match, break up the
DN's into RDN's and check that the RDN types match.  If they also match, you
need to compare the text in each RDN in turn.  This is where it gets tricky.

                    He walked across to the window and suddenly stumbled
                    because at that moment his Joo-Janta 200 Super-Chromatic
                    Peril Sensitive sunglasses had turned utterly black.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

First, take both strings and convert them to either ASCII (ISO646String) or
Unicode (BMPString) using the "least inclusive" rule.  This is quite a task in
itself, because several implementations aren't too picky about what they'll put
into a string, and will stuff T61String characters into a PrintableString, or
(more commonly) Unicode characters into a T61String or anything into a
BMPString.  Finding a T61String in a PrintableString or an 8-bit character set
string in a BMPString is relatively easy, but the best guess you can take at
detecting a Unicode string in a T61String is to check whether either the string
length is odd or all the characters are ASCII or ASCII with the high bit set.
If neither are true, it might be a Unicode string disguised as a T61String.

Once this is done, you need to canonicalise the strings into a format in which
a comparison can be done, either to compare strings of different types (eg
8-bit character set or DBCS string to BMPString) or strings with the same type
but different encodings (eg two T61Strings using alternative encodings).  To
convert ASCII-as-Unicode to ASCII, just drop the odd-numbered bytes. Converting
a T61String to Unicode is a bit more tricky.  Under Windows 95 and NT, you can
use MultiByteToWideChar(), although the conversion will depend on the current
code page in use.  On systems with widechar support, you can use mbstowcs()
directly if the widechar size is the same as the BMPString char size (which it
generally isn't), otherwise you need to first convert the string to a widechar
string with mbstowcs() and then back down again to a BMPString, taking the
machine endianness into account.  Again, the behaviour of mbstowcs() will
depend on the current locale in use.  If the system doesn't have widechar
support, the best you can do is a brute-force conversion to Unicode by hoping
it's ISO 8859-1 and adding a zero byte every other byte.

Now that you might have the strings in a format where they can be compared, you
can actually try and compare them.  Again, this often ends up as pure guesswork
if the system doesn't support the necessary character sets, or if the
characters use weird encodings which result in identical characters being
located at different code points.

First, check the converted character sets: If one is Unicode and the other
isn't, then the strings probably differ (depending on how well the
canonicalisation step went).  If the types are the same, strip leading,
trailing, and repeated internal spaces from the string, which isn't as easy as
it sounds since there are several possible code points allocated to a space.

Once you've had a go at stripping spaces, you can try to compare the strings.
If the string is a BMPString then under Windows NT (but not Windows 95) you can
use CompareString(), with the usual caveat that the comparison depends on the
current locale.  On systems which support towlower() you can extract the
characters from the string into widechars (taking machine endianness into
account) and compare the towlower() forms, with the usual caveat about locale
and the added problem that towlower() implementations vary from bare-bones
(8859-1 only under Solaris) to vague (Unicode under Win95, OSF/1).  If there's
no support for towlower(), the best you can do is use the normal tolower() if
the characters have a high byte of zero (some systems will support 8859-1 for
tolower(), the worst which can happen is that the characters will be returned
unchanged), and compare the code points directly if it isn't an 8-bit value.

                    Zaphods skin was crawling all over his body as if it was
                    trying to get off.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

Finally, if it's an ASCII string, you can just use a standard case-insensitive
string comparison function.

As you can see, there's almost no way to reliably compare two RDN elements. In
particular, no matter what you do:

- Some malicious users will deliberately pass DN checks with weird encodings.
- Some normal users will accidentally fail DN checks with weird encodings.

This becomes an issue when certain security checks depend on a comparison of
DN's (for example with excluded subtrees in the Name Constraints extension)
because it's possible to create multiple strings which are displayed
identically to the user (especially if you know which platform and/or software
to target) assuming they get displayed at all, but which compare as different
strings.  If you want to be absolutely certain about DN comparisons, you might
need to set a certificate policy of only allowing PrintableStrings in DN's,
because they're the only ones which can be reliably compared.

Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 19 Mar 1998 21:42:24 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] Current Tally on OCSP using ASN.1
To: [email-masked]

As of this posting I count 18 for ASN.1 and 3 opposed.

Unless there's a late surge of opposing write-in votes, I claim the ayes
have it; predictably so.  Point made. So let's get on with the work.

Mike

Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 19 Mar 1998 21:27:16 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

Ambarish,

-----Original Message-----
From: Ambarish Malpani <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, March 19, 1998 1:01 PM
Subject: Re: [IETF-PKIX] New OCSP Requirements

>>. . .
>> ASN.1
>> --------
>> Proposed Resolution:  I will be calling for a poll on this issue in a
>> separate posting and shall update the OCSP draft accordingly.
>
>I agree. A straw poll is a great idea!
>
>>
>> Multiple Certs In Request
>> -----------------------------------
>> The Notary Protocol already enables these more complex constructions.
OCSP
>> is intended to be a simple query on a single certificate.
>>
>> Proposed Resolution:  Allocate this requirement to the notary protocol.
A
>> proposal to add validation of multiple target certs, including a
>> cert-path for each target cert, to the Notary Protocol, was posted to the
>> PKIX list  recently.
>
>If you go with ASN.1, supporting multiple certs in a request is really
>no
>tougher than supporting a single cert. It also makes the solution
>significantly more scalable, because the server needs to provide just
>a single signature instead of multiple signatures.
>Its usage of bandwidth is also lower, since you don't need to make
>independent connections for each of the certificates you want to check.

See my response to Paul Hoffman on the same issue.  Bottom line:  OCSP needs
to accomodate multiple certs if for no other reason than a single S/MIME
message may contain both a signature certificate and an encryption
certificate.

>>
>> Multiple Response Types
>> ----------------------------------
>> OCSP speaks only to revocation information.  This is a well defined
>> spectrum.  Situations that might stimulate the production of other
response
>> types are only producable using more advanced mechanisms that are beyond
the
>> scope of OCSP.
>>
>> Proposed Resolution:  Allocate the requirement for "negotiated response
>> types" to the notary protocol.  The Malpani spec includes a variety of
>> additional information on a revoked certificate, e.g. revocation reason
and
>> invalidity date.  This would be a useful addition in both OCSP and the
>> notary protocol.
>
>Again, why not allow OCSP to support different kinds of responses in the
>future? The only change this needs in the protocol is adding a response
>type field in the header. Hopefully that doesn't make the protocol
>significantly harder to implement.

Agree.

>
>>
>> Ceritificate Identification
>> --------------------------------
>> The proposed alternative to certificate identification addresses
>> requirements that have been debated within X.509 and elsewhere, resulting
in
>> the construct AuthorityKeyIdentifier.  The alternative observes that CA
name
>> collisions are possible and thus proposes the cert ID be a function of CA
>> name and key.  However, the occurrence of this event seems remote given
the
>> prevailing practice of CA naming.
>>
>> Proposed Resolution:  Pending the outcome of the straw poll, revisit the
>> syntax of certId in OCSP.  If indeed the observation regarding CA name
>> collisions can be substantiated as a real-world problem, then PKIX may
wish
>> to consider a defect report to X.509 regarding the security risks
inherent
>> in the AuthorityCertIssuer option of AuthorityKeyIdentifier.
>
>Another simple modification to the protocol. OCSP hashes the entire
>certificate, RCSP hashes the issuer's DN and public key and sends the
>serial number along separately. That makes identification of the
>certificate
>being referred to stronger. It also lets the responder know which issuer
>the requestor is referring to, unlike OCSP, where you just get a hash
>and
>guess about whether you issued that certificate or not.

Please see my response to Paul Hoffman on this issue.

>Optionally, in RCSP, you can send the entire cert in the request.

OCSP enables one to send the entire cert in the request, albeit assuming
HTTP mechanisms.  We may need to revisit this requirement in light of both
the ASN.1 resolution and transport indenpendance.

>
>>
>> Address revocation only in OCSP, not validation
>> ----------------------------------------------------------------
>> Proposed resolution:  Language regarding or implying validation *of
>> certification paths to the target cert* will be removed from OCSP.   The
>> notary protocol may be updated to accomodate this and any additional
context
>> validation schemes.
>
>RCSP doesn't talk about validation of certificate paths either. A
>responder
>gets a set of certificates and responds about the status of each of
>them.
>It doesn't claim to check for paths - that is better done directly by
>the
>client.

Agree.

>
>>
>> Delegation of Authority
>> ------------------------------
>> The proposed delegation model should be revisited in the broader context
of
>> Attribute Certificates and certificate-based access control generally, a
>> topic that has often been informally discussed within PKIX but never
moved
>> forward to a work product.  Establishing point-wise solutions to this
>> problem creates a patchwork of what could and should be a unified
approach
>> to the subject.
>>
>> Proposed Resolution:   Defer discussion of specific delegation mechanisms
to
>> a future work product which consolidates all points of view and essential
>> requirements regarding certificate-based access control.  This future
work
>> product could easily address mechanisms that govern permissible use of
OCSP,
>> Notary Protocol and other essential PKI services.
>
>Both OCSP and RCSP do talk about delegating the task of generating
>responses
>to a responder, who could have a different public/private key pair than
>the
>CA. It makes good sense to allow this, because a CA doesn't really need
>to run 7x24, while a responder does. Also, by allowing delegation of
>OCSP responses, you allow a company, like Verisign, which runs multiple
>independent CAs, to have just a single responder, which replies to
>queries about each of those CAs.
>If you agree that delegation is a good idea, then we should be explicit
>about the implication of this delegation for the CA and how the
>delegation works.

The whole delgation issue needs to be considered in a broader context.
We've been talking about this concept for years but haven't done anything
about it.  It's high time we did.

Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 19 Mar 1998 21:03:02 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

Paul,

I've deleted from this response those points where there are no changes to
the Proposed Resolutions.

Mike

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, March 19, 1998 10:43 AM
Subject: Re: [IETF-PKIX] New OCSP Requirements

>>Multiple Certs In Request
>>-----------------------------------
>>The Notary Protocol already enables these more complex constructions.
OCSP
>>is intended to be a simple query on a single certificate.
>>
>>Proposed Resolution:  Allocate this requirement to the notary protocol.  A
>>proposal to add validation of multiple target certs, including a
>>cert-path for each target cert, to the Notary Protocol, was posted to the
>>PKIX list  recently.
>
>Disagree. I think multiple cert requests in OCSP would be valuable for both
>the end entity and the CA in reducing network traffic. Why waste multiple
>round trips when a single request and a single response will do? A
>real-world example of where this is useful is S/MIME messages that have
>multiple certificates that are from the same CA.
>
>If you trust a single un-nonced response, you will trust many of them in
>the same HTTP response. Of course, notary should allow this as well, but
>this isn't a "heavyweight" kind of requirement.

A good catch.  There could be separate signature and encryption
certificates for a single S/MIME message.  OCSP should accomodate
this scenario.

>>Multiple Response Types
>>----------------------------------
>>OCSP speaks only to revocation information.  This is a well defined
>>spectrum.  Situations that might stimulate the production of other
response
>>types are only producable using more advanced mechanisms that are beyond
the
>>scope of OCSP.
>
>I disagree with the problem statement. Multiple response types could easily
>be used without "more advanced mechanisms". Cutting off multiple response
>types limits the ability to later extend this protocol. This seems like a
>trivial addition to OCSP and would give future protocol developers greater
>flexibility.

The proposed resolution to this problem statement addresses the
syntatic element in the Malpani contribution that enables clients to
specify subsets of response types.  This I felt is beyond the scope of
OCSP.  I was not proposing that OCSP limit itself to a simple binary
response.  It never did.

I believe we are in agreement here that the current base OCSP spec
meets your needs for multiple response types.

>
>>Ceritificate Identification
>>--------------------------------
>>The proposed alternative to certificate identification addresses
>>requirements that have been debated within X.509 and elsewhere, resulting
in
>>the construct AuthorityKeyIdentifier.  The alternative observes that CA
name
>>collisions are possible and thus proposes the cert ID be a function of CA
>>name and key.  However, the occurrence of this event seems remote given
the
>>prevailing practice of CA naming.
>>
>>Proposed Resolution:  Pending the outcome of the straw poll, revisit the
>>syntax of certId in OCSP.  If indeed the observation regarding CA name
>>collisions can be substantiated as a real-world problem, then PKIX may
wish
>>to consider a defect report to X.509 regarding the security risks inherent
>>in the AuthorityCertIssuer option of AuthorityKeyIdentifier.
>
>A restatement of this resolution is "wait until there is a problem, then
>kick it to a different standards body". There is certainly a lot of
>precedent for this :-), but not in the best interest of the folks
>implementing OCSP. I think simply removing the "|" in the definition of
>"hash" in the current OCSP spec is a much better idea that will completely
>avoid the problem before it ever comes up. Computing the hash over a
>combination of two fields is not much more onerous than computing it over
>one or the other.

I can and will agree that the variation in hash computation is trival.
However, variation in the hash computation is not the issue raised by the
Proposed Resolution, but rather whether we as a group feel that the observed
security weakness is a real one.  If so, then I feel that owe it the ITU to
inform them of our conclusions regarding the security of their
recommendations on this point.  Members of PKIX have done so in the past as
we work to interpret X.509 for our needs.  If we haven't sufficient
consensus regarding the security risk to take this step, then I must
question the basis of the change.

To resolve this point, I would ask that participating members of PKIX
provide their opinion on the matter.  As with the ASN.1 issue, OCSP can and
will be adjusted to reflect that consensus.  Until then I would prefer to
maintain the spec of certID as is since it is aligned with concepts defined
in X.509.

My concern here is alignment with other PKI-based security protocols, not
the least of with is CMS.  Might I note that the SignerInfos syntax has as
an element issuerAndSerialNumber which is defined as:

IssuerAndSerialNumber ::= SEQUENCE {
        issuer Name,
        serialNumber SerialNumber }

SerialNumber ::= INTEGER

Approved-By:  Stephen Kent <[email-masked]>
Date:         Thu, 19 Mar 1998 20:45:07 -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] OCSP ASN.1 Poll
To: [email-masked]

Mike,

I vote for use of ASN.1.

Steve

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 13:09:31 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

I vote NO.

The arguments about ASN.1 parsers are completely bogus. Windows NT
ships with PKCS#7 parsing ironmongery but it does not ship with a generic
ASN.1 compiler. Similar arguments hold for other platforms.

I think the vote should also clearly point out that there is a loss of
functionality in going to ASN.1.The responses are no longer
cachable as HTTP requests.

It is easy to make arguments about consistency, I am concerned about
function.

    Phill

>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 15:01:04 -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: Charles Blauner <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

Folks;

I would also vote yes on the ASN.1 encoding question.

Charles Blauner
JP Morgan
Security & Internet Architecture

ambarish @ valicert.com on 03/19/98 02:51:33 PM

Please respond to [email-masked]

To:   IETF-PKIX @ LISTS.TANDEM.COM
cc:   (Charles Blauner)
Subject:  Re: [IETF-PKIX] OCSP ASN.1 Poll

YES

Ambarish

Michael Myers wrote:
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 19 Mar 1998 17:19:09 -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] Comments on pkix-ipki-part1
Comments: To: [email-masked]
To: [email-masked]

Extremely useful and interesting. I hadn't seen it, and it even has a quote of mine!

Thanks, Bruce, and especially, Peter.

Bob

>>> Bruce Greenblatt <[email-masked]> 03/19 4:17 PM >>>
Hey Bob,

Check out http://www.cs.auckland.ac.nz/~pgut001/...

Bruce

> -----Original Message-----
> From: Bob Jueneman [SMTP:[email-masked]]
> Sent: Thursday, March 19, 1998 11:44 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
>
> Peter,
>
> First of all, my condolances on your power outage situation. That's
> right up there with one of my other correspondent's having her entire
> town (Minden, North Dakota, US -- not exactly a huge metropolis like
> Auckland, but none heless devastating to her) flooded out and her
> basement full of mud.
>
> WRT the character encoding issue, I would be happy to reprise my
> collection of sends and receives if you were incommunicado and missed
> some. I am particularly interested in the problem of multilingual
> company names, both "official" (registered) and unofficial
> transliterations and translations.  And as a result of that
> discussion, I am increasingly interested in including jpeg logos in
> subjectaltname and issuerAltName.
>
> Even before you finish updating your style guide, which I confess not
> to have seen (a URL?), I would appreciate any comments you might have
> on "broken" attributes.  If you haven't notice it yet, one of my
> candiates is the explicitNotice field -- it's unusable without
> allowing multiples, with a language tag.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
>
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
>
> "The most dangerous strategy is to cross a chasm in two jumps."
>
>
> >>> Peter Gutmann <[email-masked]> 03/18 10:13 PM >>>
> [I'm sending this from an alternative address, mail from my usual
> address
>  either isn't getting or out is vanishing somewhere]
>
> While I was waiting for our local power monopoly to figure out how
> they were
> going to supply the central business district of the city with power
> (apparently the power outage we're currently in the middle of,
> documented at
> http://www.kcbbs.gen.nz/users/peterg/power.txt, rates as the worst
> peacetime
> power outage ever), I thought I'd poke around with cert extensions a
> bit so I
> could add them to the X.509 style guide.
>
> It's probably going to double in size.  I also need to reread my
> H.P.Lovecraft
> collection so I can find enough quotes about horror and madness to
> decorate
> the margins in the manner that the guide currently does :-).  I caught
> the
> tail end of the debate on character encodings, I'll have a long
> section
> devoted to that in there as well (there's at least one extension which
> breaks
> completely over this issue).
>
> In the meantime, here are a few quick comments on the 14 October draft
> of
> ipki-part1.  Some problems I noticed were:
>
> 4.2.1.2.
>
> This gives the subject key identifier as the hash of the
> subjectPublicKeyInfo
> *without* the tag and length.  Is this a mistake, or is it meant to be
> like
> that?  Every other instance in which an ASN.1 object is hashed (eg
> certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes
> the
> entire object.  In fact the PKIX CMP draft uses a hash of the full
> subjectPublicKeyInfo in the OOBCertHash, which would make it
> incompatible with
> the value in the subject key identifier.  Requiring a well-defined
> standard
> X.509 object to be broken up into pieces before processing it seems an
> extremely peculiar move, so I'm guessing it's some sort of mistake in
> the spec.
>
> In addition I really don't like the idea of dumping a raw hash into
> the
> KeyIdentifier OCTET STRING, because it's not possible to distinguish
> it from
> whatever anyone else decides to put in there.  Much better would be to
> use the
> PKCS #7 DigestInfo, which is well-defined and whose OID + data format
> uniquely
> identifies the contents (that is, make the KeyIdentifier an OCTET
> STRING hole
> for a DigestInfo rather than an opaque blob).  Given that a
> KeyIdentifier
> could potentially contain anything, it's somewhat risky to put raw,
> unidentified data in there.
>
> 4.2.1.3.
>
> The decipherOnly key usage indicates that the public key can only be
> used for
> deciphering data.  This would be quite a feat :-).  I assume this
> should say
> that the private key corresponding to the public key can only be used
> for
> deciphering data.
>
> Speaking of private vs public keys, it would be useful to have some
> standard
> unambiguous term defined to indicate the private key which is tied to
> the
> public key, eg "corresponding to" or "identified by" or "paired with"
> or
> something similar.  I've used "identified by" (eg "The end-user
> certificate
> should be signed by the private key identified by a CA certificate"),
> but I'm
> not sure if that sounds right.  The current draft seems to use
> different terms
> in different places.
>
> 7.3.2.
>
> This gives a redundant definition of the DH p and g values (the ASN.1
> definition is followed immediately by text which says exactly the same
> thing -
> actually the RSA definition does this too with n and e), but doesn't
> explain
> the INTEGER which is the DH public key (what *is* this value?  The
> only thing
> I can think of is g^x mod p, but that shouldn't be a fixed value).  It
> also
> goes to some lengths to explain the encoding of the INTEGER parameter
> as a BIT
> STRING, which seems very odd.
>
> D.1.
>
> The supposed CA certificate isn't actually a CA cert because the
> basicConstraints are empty.  Is this really what NIST CA certs look
> like? If
> it is, I should add another entry to the "Bugs" section of the X.509
> style
> guide :-).
>
> Peter.

Approved-By:  [email-masked]
Date:         Fri, 20 Mar 1998 09:52:33 +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: [email-masked]
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

Use ASN.1

> -----Original Message-----
> From: Michael Myers [SMTP:[email-masked]]
> Sent: Thursday, March 19, 1998 4:31 PM
> To:   [email-masked]
> Subject:      [IETF-PKIX] OCSP ASN.1 Poll
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

Approved-By:  "Matthew S. Hamrick" <[email-masked]>
Date:         Thu, 19 Mar 1998 17:43:14 -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: "Matthew S. Hamrick" <[email-masked]>
Organization: i2 Technologies
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

This is a multi-part message in MIME format.
--------------6700EFFC1B70A30C25E237F0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yes, provided it specifies DER encoding.

I believe that one's opinion of this topic is heavily influenced by how
good your ASN.1 / BER / DER tools are. I have a toolset that that
generates a remarkably good code footprint if you turn indefinite length
encoding off.

Michael Myers wrote:

> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

--------------6700EFFC1B70A30C25E237F0
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Matthew S. Hamrick
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Matthew S. Hamrick
n:              Hamrick;Matthew S.
org:            Uptronics Incorporated
adr:            298 S. Sunnyvale Ave.;;Suite 211;Sunnyvale;CA;96086;US
email;internet: [email-masked]
title:          Cryptologic Engineer
tel;work:       408.774.6207
tel;fax:        408.774.6201
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------6700EFFC1B70A30C25E237F0--

Approved-By:  Bruce Greenblatt <[email-masked]>
Date:         Thu, 19 Mar 1998 15:17:40 -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: Bruce Greenblatt <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

Hey Bob,

Check out http://www.cs.auckland.ac.nz/~pgut001/...

Bruce

> -----Original Message-----
> From: Bob Jueneman [SMTP:[email-masked]]
> Sent: Thursday, March 19, 1998 11:44 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
>
> Peter,
>
> First of all, my condolances on your power outage situation. That's
> right up there with one of my other correspondent's having her entire
> town (Minden, North Dakota, US -- not exactly a huge metropolis like
> Auckland, but none heless devastating to her) flooded out and her
> basement full of mud.
>
> WRT the character encoding issue, I would be happy to reprise my
> collection of sends and receives if you were incommunicado and missed
> some. I am particularly interested in the problem of multilingual
> company names, both "official" (registered) and unofficial
> transliterations and translations.  And as a result of that
> discussion, I am increasingly interested in including jpeg logos in
> subjectaltname and issuerAltName.
>
> Even before you finish updating your style guide, which I confess not
> to have seen (a URL?), I would appreciate any comments you might have
> on "broken" attributes.  If you haven't notice it yet, one of my
> candiates is the explicitNotice field -- it's unusable without
> allowing multiples, with a language tag.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
>
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
>
> "The most dangerous strategy is to cross a chasm in two jumps."
>
>
> >>> Peter Gutmann <[email-masked]> 03/18 10:13 PM >>>
> [I'm sending this from an alternative address, mail from my usual
> address
>  either isn't getting or out is vanishing somewhere]
>
> While I was waiting for our local power monopoly to figure out how
> they were
> going to supply the central business district of the city with power
> (apparently the power outage we're currently in the middle of,
> documented at
> http://www.kcbbs.gen.nz/users/peterg/power.txt, rates as the worst
> peacetime
> power outage ever), I thought I'd poke around with cert extensions a
> bit so I
> could add them to the X.509 style guide.
>
> It's probably going to double in size.  I also need to reread my
> H.P.Lovecraft
> collection so I can find enough quotes about horror and madness to
> decorate
> the margins in the manner that the guide currently does :-).  I caught
> the
> tail end of the debate on character encodings, I'll have a long
> section
> devoted to that in there as well (there's at least one extension which
> breaks
> completely over this issue).
>
> In the meantime, here are a few quick comments on the 14 October draft
> of
> ipki-part1.  Some problems I noticed were:
>
> 4.2.1.2.
>
> This gives the subject key identifier as the hash of the
> subjectPublicKeyInfo
> *without* the tag and length.  Is this a mistake, or is it meant to be
> like
> that?  Every other instance in which an ASN.1 object is hashed (eg
> certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes
> the
> entire object.  In fact the PKIX CMP draft uses a hash of the full
> subjectPublicKeyInfo in the OOBCertHash, which would make it
> incompatible with
> the value in the subject key identifier.  Requiring a well-defined
> standard
> X.509 object to be broken up into pieces before processing it seems an
> extremely peculiar move, so I'm guessing it's some sort of mistake in
> the spec.
>
> In addition I really don't like the idea of dumping a raw hash into
> the
> KeyIdentifier OCTET STRING, because it's not possible to distinguish
> it from
> whatever anyone else decides to put in there.  Much better would be to
> use the
> PKCS #7 DigestInfo, which is well-defined and whose OID + data format
> uniquely
> identifies the contents (that is, make the KeyIdentifier an OCTET
> STRING hole
> for a DigestInfo rather than an opaque blob).  Given that a
> KeyIdentifier
> could potentially contain anything, it's somewhat risky to put raw,
> unidentified data in there.
>
> 4.2.1.3.
>
> The decipherOnly key usage indicates that the public key can only be
> used for
> deciphering data.  This would be quite a feat :-).  I assume this
> should say
> that the private key corresponding to the public key can only be used
> for
> deciphering data.
>
> Speaking of private vs public keys, it would be useful to have some
> standard
> unambiguous term defined to indicate the private key which is tied to
> the
> public key, eg "corresponding to" or "identified by" or "paired with"
> or
> something similar.  I've used "identified by" (eg "The end-user
> certificate
> should be signed by the private key identified by a CA certificate"),
> but I'm
> not sure if that sounds right.  The current draft seems to use
> different terms
> in different places.
>
> 7.3.2.
>
> This gives a redundant definition of the DH p and g values (the ASN.1
> definition is followed immediately by text which says exactly the same
> thing -
> actually the RSA definition does this too with n and e), but doesn't
> explain
> the INTEGER which is the DH public key (what *is* this value?  The
> only thing
> I can think of is g^x mod p, but that shouldn't be a fixed value).  It
> also
> goes to some lengths to explain the encoding of the INTEGER parameter
> as a BIT
> STRING, which seems very odd.
>
> D.1.
>
> The supposed CA certificate isn't actually a CA cert because the
> basicConstraints are empty.  Is this really what NIST CA certs look
> like? If
> it is, I should add another entry to the "Bugs" section of the X.509
> style
> guide :-).
>
> Peter.

Approved-By:  Slava Galperin <[email-masked]>
Date:         Thu, 19 Mar 1998 15:04: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: Slava Galperin <[email-masked]>
Organization: Netscape Communications Corp
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

Michael Myers wrote:
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?

I guess I said YES already by contributing to the ASN.1-based
alternative proposal ;-)

--
Slava Galperin          Certified Certificate Certifier
[email-masked]   tel: 650.937.6757

 It doesn't matter so much whether you've won the war or lost it.
 What matters is who you have lost it to.
                            -- From the memoirs of a married man

Approved-By:  John Lowry <[email-masked]>
Date:         Thu, 19 Mar 1998 17:08:26 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: John Lowry <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

I vote for ASN.1

-- but then I _like_ ASN.1 ...

John Lowry

>----------
>From:  Michael Myers[SMTP:[email-masked]]
>Sent:  Thursday, March 19, 1998 1:30 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] OCSP ASN.1 Poll
>
>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Thu, 19 Mar 1998 16:43:50 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

I'll add my vote for ASN.1.

I hope someone's keeping track of all this so we don't need a re-count
at the end...  :-)

Carlisle.

>----------
>From:  Michael Myers[SMTP:[email-masked]]
>Sent:  Thursday, March 19, 1998 1:30 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] OCSP ASN.1 Poll
>
>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Thu, 19 Mar 1998 16:33: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: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

I think that I would prefer to see the protocol expressed in ASN.1.

        Robert Zuccherato
        Entrust Technologies

>----------
>From:  Michael Myers[SMTP:[email-masked]]
>Sent:  Thursday, March 19, 1998 1:30 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] OCSP ASN.1 Poll
>
>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By:  Todd Glassey <[email-masked]>
Date:         Thu, 19 Mar 1998 12:46:09 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msFBDDE29CC76111E8611F3ABA
Content-Type: multipart/mixed; boundary="------------9F8D9B49165CF14C0D4E0CBB"

This is a multi-part message in MIME format.
--------------9F8D9B49165CF14C0D4E0CBB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

yes, ASN.1 is better than ABNF notation styles

Todd

Ambarish Malpani wrote:

> YES
>
> Ambarish
>
> Michael Myers wrote:
> >
> > All,
> >
> > Here's the separate ASN.1 poll question mentioned in my prior message:
> >
> > Should OCSP request and response syntax be expressed in ASN.1?
> >
> > A rough consensus of YES would result in modifying the existing
> > OCSP draft to change the request and response syntax appropriately.
> >
> > A rough consensus of NO would result in maintaining the current
> > ABNF syntax.
> >
> > In either case, protocol elements may change as a result of the
> > incorporation of additional requirements.
> >
> > Mike
>
> --
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                              (650) 849-9880
> ValiCert, Inc.                                  [email-masked]
> 3160 W. Bayshore Road                         http://www.valicert.com
> Palo Alto, CA 94303

--
--------
--  Regards,
--  Todd Glassey

Todd's Latest Rant --
---------------------
"...Plan?, There ain't no plan, I though' you had the plan..."
      The Pig Killer - Mad Max: Beyond Thunderdome

--------------9F8D9B49165CF14C0D4E0CBB
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Glassey, Todd S.
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Todd S. Glassey
n:              Glassey;Todd S.
org:            Coastek, Inc.
adr:            5550 Scotts Valley Drive;;Suite 700;Scotts Valley;Ca;95066;USA
email;internet: [email-masked]
title:          Chief Scientist and Principal Founder
tel;work:       408.440.0180
tel;fax:        408.438.2979
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------9F8D9B49165CF14C0D4E0CBB--

--------------msFBDDE29CC76111E8611F3ABA
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msFBDDE29CC76111E8611F3ABA--

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Thu, 19 Mar 1998 12:49:16 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

Hi Mike/All,
    The changes we have proposed in RCSP were specifically designed to
make it easier to implement. Not harder. I am not sure why any of
these would make OCSP more "heavyweight".

Let's address each of the changes:

Michael Myers wrote:
>
> All,
>
> The recent discussion on OCSP has resulted in a list of candidate new
> requirements that have not yet received the full vetting of the group.  I
> spoke with Rich  regarding the relationship of these requirements to both
> OCSP and the notary protocol in the context of his recent posting on
> "lightweight" and "heavyweight" options.
>
> This discussion led to the following joint proposal.  The "lightweight"
> option is OCSP revised to accomodate requirements appropriate to its scope
> from among  those identified by the Malpani et. al. contribution.  The
> "heavyweight" option is the notary protocol equivalently revised to
> accomodate other of the of those requirements.
>
> Taking each point by point:
>
> ASN.1
> --------
> Proposed Resolution:  I will be calling for a poll on this issue in a
> separate posting and shall update the OCSP draft accordingly.

I agree. A straw poll is a great idea!

>
> Multiple Certs In Request
> -----------------------------------
> The Notary Protocol already enables these more complex constructions.  OCSP
> is intended to be a simple query on a single certificate.
>
> Proposed Resolution:  Allocate this requirement to the notary protocol.  A
> proposal to add validation of multiple target certs, including a
> cert-path for each target cert, to the Notary Protocol, was posted to the
> PKIX list  recently.

If you go with ASN.1, supporting multiple certs in a request is really
no
tougher than supporting a single cert. It also makes the solution
significantly more scalable, because the server needs to provide just
a single signature instead of multiple signatures.
Its usage of bandwidth is also lower, since you don't need to make
independent connections for each of the certificates you want to check.

>
> Transport Independance
> ---------------------------------
> The initial OCSP drafts was structure to enable transport independance.  The
> current draft is written to ensure that at least one transport mechanism is
> implemented.  Until recently, no exception was taken to that position.
>
> Proposed Resolution:  Correct the current OCSP draft to speak to the
> enablement of transport independance, but yet maintain HTTP as one
> well-defined mechanism.  Consideration is being given to a sockets-based
> specification in the base OCSP draft.  If other transports are desired,
> interested parties are encouraged to produce companion drafts.

Agree.

>
> Multiple Response Types
> ----------------------------------
> OCSP speaks only to revocation information.  This is a well defined
> spectrum.  Situations that might stimulate the production of other response
> types are only producable using more advanced mechanisms that are beyond the
> scope of OCSP.
>
> Proposed Resolution:  Allocate the requirement for "negotiated response
> types" to the notary protocol.  The Malpani spec includes a variety of
> additional information on a revoked certificate, e.g. revocation reason and
> invalidity date.  This would be a useful addition in both OCSP and the
> notary protocol.

Again, why not allow OCSP to support different kinds of responses in the
future? The only change this needs in the protocol is adding a response
type field in the header. Hopefully that doesn't make the protocol
significantly harder to implement.

>
> Ceritificate Identification
> --------------------------------
> The proposed alternative to certificate identification addresses
> requirements that have been debated within X.509 and elsewhere, resulting in
> the construct AuthorityKeyIdentifier.  The alternative observes that CA name
> collisions are possible and thus proposes the cert ID be a function of CA
> name and key.  However, the occurrence of this event seems remote given the
> prevailing practice of CA naming.
>
> Proposed Resolution:  Pending the outcome of the straw poll, revisit the
> syntax of certId in OCSP.  If indeed the observation regarding CA name
> collisions can be substantiated as a real-world problem, then PKIX may wish
> to consider a defect report to X.509 regarding the security risks inherent
> in the AuthorityCertIssuer option of AuthorityKeyIdentifier.

Another simple modification to the protocol. OCSP hashes the entire
certificate, RCSP hashes the issuer's DN and public key and sends the
serial number along separately. That makes identification of the
certificate
being referred to stronger. It also lets the responder know which issuer
the requestor is referring to, unlike OCSP, where you just get a hash
and
guess about whether you issued that certificate or not.
Optionally, in RCSP, you can send the entire cert in the request.

>
> Address revocation only in OCSP, not validation
> ----------------------------------------------------------------
> Proposed resolution:  Language regarding or implying validation *of
> certification paths to the target cert* will be removed from OCSP.   The
> notary protocol may be updated to accomodate this and any additional context
> validation schemes.

RCSP doesn't talk about validation of certificate paths either. A
responder
gets a set of certificates and responds about the status of each of
them.
It doesn't claim to check for paths - that is better done directly by
the
client.

>
> Delegation of Authority
> ------------------------------
> The proposed delegation model should be revisited in the broader context of
> Attribute Certificates and certificate-based access control generally, a
> topic that has often been informally discussed within PKIX but never moved
> forward to a work product.  Establishing point-wise solutions to this
> problem creates a patchwork of what could and should be a unified approach
> to the subject.
>
> Proposed Resolution:   Defer discussion of specific delegation mechanisms to
> a future work product which consolidates all points of view and essential
> requirements regarding certificate-based access control.  This future work
> product could easily address mechanisms that govern permissible use of OCSP,
> Notary Protocol and other essential PKI services.

Both OCSP and RCSP do talk about delegating the task of generating
responses
to a responder, who could have a different public/private key pair than
the
CA. It makes good sense to allow this, because a CA doesn't really need
to run 7x24, while a responder does. Also, by allowing delegation of
OCSP responses, you allow a company, like Verisign, which runs multiple
independent CAs, to have just a single responder, which replies to
queries about each of those CAs.
If you agree that delegation is a good idea, then we should be explicit
about the implication of this delegation for the CA and how the
delegation works.

>
> Mike

Regards,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 19 Mar 1998 12:45:56 -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 ASN.1 Poll
Comments: To: [email-masked]
To: [email-masked]

I think I'm on record for strongly favoring ASN.1.

Bob

>>> Michael Myers <[email-masked]> 03/18 11:30 PM >>>
All,

Here's the separate ASN.1 poll question mentioned in my prior message:

Should OCSP request and response syntax be expressed in ASN.1?

A rough consensus of YES would result in modifying the existing
OCSP draft to change the request and response syntax appropriately.

A rough consensus of NO would result in maintaining the current
ABNF syntax.

In either case, protocol elements may change as a result of the
incorporation of additional requirements.

Mike

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Thu, 19 Mar 1998 11:51:33 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

YES

Ambarish

Michael Myers wrote:
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 19 Mar 1998 12:43:47 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
Comments: To: Peter Gutmann <[email-masked]>
To: [email-masked]

Peter,

First of all, my condolances on your power outage situation. That's right up there with one of my other correspondent's having her entire town (Minden, North Dakota, US -- not exactly a huge metropolis like Auckland, but none heless devastating to her) flooded out and her basement full of mud.

WRT the character encoding issue, I would be happy to reprise my collection of sends and receives if you were incommunicado and missed some. I am particularly interested in the problem of multilingual company names, both "official" (registered) and unofficial transliterations and translations.  And as a result of that discussion, I am increasingly interested in including jpeg logos in subjectaltname and issuerAltName.

Even before you finish updating your style guide, which I confess not to have seen (a URL?), I would appreciate any comments you might have on "broken" attributes.  If you haven't notice it yet, one of my candiates is the explicitNotice field -- it's unusable without allowing multiples, with a language tag.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Peter Gutmann <[email-masked]> 03/18 10:13 PM >>>
[I'm sending this from an alternative address, mail from my usual address
 either isn't getting or out is vanishing somewhere]

While I was waiting for our local power monopoly to figure out how they were
going to supply the central business district of the city with power
(apparently the power outage we're currently in the middle of, documented at
http://www.kcbbs.gen.nz/users/peterg/power.txt, rates as the worst peacetime
power outage ever), I thought I'd poke around with cert extensions a bit so I
could add them to the X.509 style guide.

It's probably going to double in size.  I also need to reread my H.P.Lovecraft
collection so I can find enough quotes about horror and madness to decorate
the margins in the manner that the guide currently does :-).  I caught the
tail end of the debate on character encodings, I'll have a long section
devoted to that in there as well (there's at least one extension which breaks
completely over this issue).

In the meantime, here are a few quick comments on the 14 October draft of
ipki-part1.  Some problems I noticed were:

4.2.1.2.

This gives the subject key identifier as the hash of the subjectPublicKeyInfo
*without* the tag and length.  Is this a mistake, or is it meant to be like
that?  Every other instance in which an ASN.1 object is hashed (eg
certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes the
entire object.  In fact the PKIX CMP draft uses a hash of the full
subjectPublicKeyInfo in the OOBCertHash, which would make it incompatible with
the value in the subject key identifier.  Requiring a well-defined standard
X.509 object to be broken up into pieces before processing it seems an
extremely peculiar move, so I'm guessing it's some sort of mistake in the spec.

In addition I really don't like the idea of dumping a raw hash into the
KeyIdentifier OCTET STRING, because it's not possible to distinguish it from
whatever anyone else decides to put in there.  Much better would be to use the
PKCS #7 DigestInfo, which is well-defined and whose OID + data format uniquely
identifies the contents (that is, make the KeyIdentifier an OCTET STRING hole
for a DigestInfo rather than an opaque blob).  Given that a KeyIdentifier
could potentially contain anything, it's somewhat risky to put raw,
unidentified data in there.

4.2.1.3.

The decipherOnly key usage indicates that the public key can only be used for
deciphering data.  This would be quite a feat :-).  I assume this should say
that the private key corresponding to the public key can only be used for
deciphering data.

Speaking of private vs public keys, it would be useful to have some standard
unambiguous term defined to indicate the private key which is tied to the
public key, eg "corresponding to" or "identified by" or "paired with" or
something similar.  I've used "identified by" (eg "The end-user certificate
should be signed by the private key identified by a CA certificate"), but I'm
not sure if that sounds right.  The current draft seems to use different terms
in different places.

7.3.2.

This gives a redundant definition of the DH p and g values (the ASN.1
definition is followed immediately by text which says exactly the same thing -
actually the RSA definition does this too with n and e), but doesn't explain
the INTEGER which is the DH public key (what *is* this value?  The only thing
I can think of is g^x mod p, but that shouldn't be a fixed value).  It also
goes to some lengths to explain the encoding of the INTEGER parameter as a BIT
STRING, which seems very odd.

D.1.

The supposed CA certificate isn't actually a CA cert because the
basicConstraints are empty.  Is this really what NIST CA certs look like? If
it is, I should add another entry to the "Bugs" section of the X.509 style
guide :-).

Peter.

Approved-By:  John Pawling <[email-masked]>
Date:         Thu, 19 Mar 1998 14:21: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: John Pawling <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

All,

I vote to use ASN.1.

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

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 11:55: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: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

At 10:30 PM 3/18/98 -0800, you wrote:

>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?

I would vote NO, if it was clearly understood by everybody that OCSP is not
going to be extended or enhanced in any way and that all enhancements will
be done in the Notary Protocol.  Given IETF history, I don't believe this
for a minute.

Hal

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

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 12:07:34 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

My vote is:

        Yes

Michael Myers wrote:
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

--
               ================================================

      _/_/_/                   David J. Horvath
   _/      _/
  _/       _/                  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]

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 11:25: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: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

At 05:13 PM 3/19/98 +1200, Peter Gutmann wrote:

>Speaking of private vs public keys, it would be useful to have some standard
>unambiguous term defined to indicate the private key which is tied to the
>public key, eg "corresponding to" or "identified by" or "paired with" or
>something similar.  I've used "identified by" (eg "The end-user certificate
>should be signed by the private key identified by a CA certificate"), but I'm
>not sure if that sounds right.  The current draft seems to use different
terms
>in different places.

How about "matched", e.g. matched-public key, matched-private key?

Hal

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

Approved-By:  Peter Sylvester <[email-masked]>
Date:         Thu, 19 Mar 1998 19:24:12 +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: Peter Sylvester <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

hello,

I wonder whether someone has considered to use a very
lightweight protocol for OCSP based on UDP for exemple
like mapping a request using DNS.

Peter Sylvester

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 19 Mar 1998 10:21:02 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

>Multiple Certs In Request
>-----------------------------------
>The Notary Protocol already enables these more complex constructions.  OCSP
>is intended to be a simple query on a single certificate.
>
>Proposed Resolution:  Allocate this requirement to the notary protocol.  A
>proposal to add validation of multiple target certs, including a
>cert-path for each target cert, to the Notary Protocol, was posted to the
>PKIX list  recently.

Disagree. I think multiple cert requests in OCSP would be valuable for both
the end entity and the CA in reducing network traffic. Why waste multiple
round trips when a single request and a single response will do? A
real-world example of where this is useful is S/MIME messages that have
multiple certificates that are from the same CA.

If you trust a single un-nonced response, you will trust many of them in
the same HTTP response. Of course, notary should allow this as well, but
this isn't a "heavyweight" kind of requirement.

>Transport Independance
>---------------------------------
>The initial OCSP drafts was structure to enable transport independance.  The
>current draft is written to ensure that at least one transport mechanism is
>implemented.  Until recently, no exception was taken to that position.
>
>Proposed Resolution:  Correct the current OCSP draft to speak to the
>enablement of transport independance, but yet maintain HTTP as one
>well-defined mechanism.  Consideration is being given to a sockets-based
>specification in the base OCSP draft.  If other transports are desired,
>interested parties are encouraged to produce companion drafts.

Agree.

>Multiple Response Types
>----------------------------------
>OCSP speaks only to revocation information.  This is a well defined
>spectrum.  Situations that might stimulate the production of other response
>types are only producable using more advanced mechanisms that are beyond the
>scope of OCSP.

I disagree with the problem statement. Multiple response types could easily
be used without "more advanced mechanisms". Cutting off multiple response
types limits the ability to later extend this protocol. This seems like a
trivial addition to OCSP and would give future protocol developers greater
flexibility.

>Ceritificate Identification
>--------------------------------
>The proposed alternative to certificate identification addresses
>requirements that have been debated within X.509 and elsewhere, resulting in
>the construct AuthorityKeyIdentifier.  The alternative observes that CA name
>collisions are possible and thus proposes the cert ID be a function of CA
>name and key.  However, the occurrence of this event seems remote given the
>prevailing practice of CA naming.
>
>Proposed Resolution:  Pending the outcome of the straw poll, revisit the
>syntax of certId in OCSP.  If indeed the observation regarding CA name
>collisions can be substantiated as a real-world problem, then PKIX may wish
>to consider a defect report to X.509 regarding the security risks inherent
>in the AuthorityCertIssuer option of AuthorityKeyIdentifier.

A restatement of this resolution is "wait until there is a problem, then
kick it to a different standards body". There is certainly a lot of
precedent for this :-), but not in the best interest of the folks
implementing OCSP. I think simply removing the "|" in the definition of
"hash" in the current OCSP spec is a much better idea that will completely
avoid the problem before it ever comes up. Computing the hash over a
combination of two fields is not much more onerous than computing it over
one or the other.

>Address revocation only in OCSP, not validation
>----------------------------------------------------------------
>Proposed resolution:  Language regarding or implying validation *of
>certification paths to the target cert* will be removed from OCSP.   The
>notary protocol may be updated to accomodate this and any additional context
>validation schemes.

Agree.

>Delegation of Authority
>------------------------------
>The proposed delegation model should be revisited in the broader context of
>Attribute Certificates and certificate-based access control generally, a
>topic that has often been informally discussed within PKIX but never moved
>forward to a work product.  Establishing point-wise solutions to this
>problem creates a patchwork of what could and should be a unified approach
>to the subject.
>
>Proposed Resolution:   Defer discussion of specific delegation mechanisms to
>a future work product which consolidates all points of view and essential
>requirements regarding certificate-based access control.  This future work
>product could easily address mechanisms that govern permissible use of OCSP,
>Notary Protocol and other essential PKI services.

Agree. This is an important topic, but can be dealt with in a single work
that modifies the other PKIX documents at once.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 19 Mar 1998 09:48:31 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

Yes. I'm no fan of ASN.1, but it clearly is better for this protocol.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Thu, 19 Mar 1998 09:44:07 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

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

Content-Type: text/plain; charset=us-ascii

Michael Myers <[email-masked]> scrawled:
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>

Yes, use ASN.1.

Regardless of the merits or lack thereof of ASN.1 vs. ABNF, mixing the two
within PKIX doesn't seem wise.

                Marc

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

Approved-By:  Boby Joseph <[email-masked]>
Date:         Thu, 19 Mar 1998 11:14:46 -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: Boby Joseph <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

My vote is:

YES

Boby Joseph
3Com Corporation

Approved-By:  Kevin Kingdon <[email-masked]>
Date:         Thu, 19 Mar 1998 08:45:55 -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: Kevin Kingdon <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

My vote is:

YES

Kevin Kingdon
RSA Data Security, Inc.

> -----Original Message-----
> From: Michael Myers [SMTP:[email-masked]]
> Sent: Wednesday, March 18, 1998 10:31 PM
> To:   [email-masked]
> Subject:      [IETF-PKIX] OCSP ASN.1 Poll
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Thu, 19 Mar 1998 11:29:12 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Question about the CMMF/CMRF drafts
To: [email-masked]

Hi Jim,

>----------
>From:  Jim Schaad (Exchange)[SMTP:[email-masked]]
>Sent:  Wednesday, March 18, 1998 4:28 PM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Question about the CMMF/CMRF drafts
>
>Are theses drafts suppose to stand along and be usable as an enrollment
>protocol?  Or are you required to use the CMC (or other equivalent) drafts
>in order to get a functional protocol?

CRMF/CMMF are meant to be used as message bodies within CMP, or CMC, or
some other spec.

Carlisle.

Approved-By:  Stephen Kent <[email-masked]>
Date:         Thu, 19 Mar 1998 10:50: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] Wouldnt adding a certified timestamp kill the issues re: multiple               keys/certificates
To: [email-masked]

Todd,

>Say all,
>So what I was wondering is wouldn't adding some secondary temporal
>authentication mechanisms, like a certified timestamp for instance,
>cleanup the
>Multiple Key per certificate dilemma.
>
>Seems like a no-brianer solution and strengthens the Certificate Value as
>well!
>What do you think?

No, but nice try ;-).  Multiple certs in force at the same time with the
same key pose a problem that is not addressed by time stamping.

Steve

Approved-By: [email-masked]
Date:         Wed, 18 Mar 1998 13:28:06 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Question about the CMMF/CMRF drafts
To: [email-masked]

Are theses drafts suppose to stand along and be usable as an enrollment
protocol?  Or are you required to use the CMC (or other equivalent) drafts
in order to get a functional protocol?

jim schaad

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 17:13:27 +1200
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 Gutmann <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
Comments: cc: [email-masked]
To: [email-masked]

[I'm sending this from an alternative address, mail from my usual address
 either isn't getting or out is vanishing somewhere]

While I was waiting for our local power monopoly to figure out how they were
going to supply the central business district of the city with power
(apparently the power outage we're currently in the middle of, documented at
http://www.kcbbs.gen.nz/users/peterg/power.txt, rates as the worst peacetime
power outage ever), I thought I'd poke around with cert extensions a bit so I
could add them to the X.509 style guide.

It's probably going to double in size.  I also need to reread my H.P.Lovecraft
collection so I can find enough quotes about horror and madness to decorate
the margins in the manner that the guide currently does :-).  I caught the
tail end of the debate on character encodings, I'll have a long section
devoted to that in there as well (there's at least one extension which breaks
completely over this issue).

In the meantime, here are a few quick comments on the 14 October draft of
ipki-part1.  Some problems I noticed were:

4.2.1.2.

This gives the subject key identifier as the hash of the subjectPublicKeyInfo
*without* the tag and length.  Is this a mistake, or is it meant to be like
that?  Every other instance in which an ASN.1 object is hashed (eg
certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes the
entire object.  In fact the PKIX CMP draft uses a hash of the full
subjectPublicKeyInfo in the OOBCertHash, which would make it incompatible with
the value in the subject key identifier.  Requiring a well-defined standard
X.509 object to be broken up into pieces before processing it seems an
extremely peculiar move, so I'm guessing it's some sort of mistake in the spec.

In addition I really don't like the idea of dumping a raw hash into the
KeyIdentifier OCTET STRING, because it's not possible to distinguish it from
whatever anyone else decides to put in there.  Much better would be to use the
PKCS #7 DigestInfo, which is well-defined and whose OID + data format uniquely
identifies the contents (that is, make the KeyIdentifier an OCTET STRING hole
for a DigestInfo rather than an opaque blob).  Given that a KeyIdentifier
could potentially contain anything, it's somewhat risky to put raw,
unidentified data in there.

4.2.1.3.

The decipherOnly key usage indicates that the public key can only be used for
deciphering data.  This would be quite a feat :-).  I assume this should say
that the private key corresponding to the public key can only be used for
deciphering data.

Speaking of private vs public keys, it would be useful to have some standard
unambiguous term defined to indicate the private key which is tied to the
public key, eg "corresponding to" or "identified by" or "paired with" or
something similar.  I've used "identified by" (eg "The end-user certificate
should be signed by the private key identified by a CA certificate"), but I'm
not sure if that sounds right.  The current draft seems to use different terms
in different places.

7.3.2.

This gives a redundant definition of the DH p and g values (the ASN.1
definition is followed immediately by text which says exactly the same thing -
actually the RSA definition does this too with n and e), but doesn't explain
the INTEGER which is the DH public key (what *is* this value?  The only thing
I can think of is g^x mod p, but that shouldn't be a fixed value).  It also
goes to some lengths to explain the encoding of the INTEGER parameter as a BIT
STRING, which seems very odd.

D.1.

The supposed CA certificate isn't actually a CA cert because the
basicConstraints are empty.  Is this really what NIST CA certs look like? If
it is, I should add another entry to the "Bugs" section of the X.509 style
guide :-).

Peter.

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 08:20:37 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
Comments: To: [email-masked]
To: [email-masked]

no

>>> Michael Myers <[email-masked]> 03/18/98 11:30PM >>>
All,

Here's the separate ASN.1 poll question mentioned in my prior message:

Should OCSP request and response syntax be expressed in ASN.1?

A rough consensus of YES would result in modifying the existing
OCSP draft to change the request and response syntax appropriately.

A rough consensus of NO would result in maintaining the current
ABNF syntax.

In either case, protocol elements may change as a result of the
incorporation of additional requirements.

Mike
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!

Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 19 Mar 1998 07:23:29 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

Hi Dave,

Already had your vote on record Dave.  :-)

Mike

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, March 19, 1998 6:58 AM
Subject: Re: [IETF-PKIX] OCSP ASN.1 Poll

>> From: Michael Myers <[email-masked]>
>>
>> Here's the separate ASN.1 poll question mentioned in my prior message:
>>
>> Should OCSP request and response syntax be expressed in ASN.1?
>
>
>If I've already voted, do I have to do it again? :-)
>
>Regards,
>Dave Kemp
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 19 Mar 1998 09:36:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

> From: Michael Myers <[email-masked]>
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?

If I've already voted, do I have to do it again? :-)

Regards,
Dave Kemp

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Thu, 19 Mar 1998 14:00:12 +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: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] Obtaining a certificate for user B.
To: [email-masked]

To the list,

Consider the situation, where user A wants the certificate
of another user B and a fully operational Directory is not
present (e.g. the situation described in CMC, page 13).

- Should the ASN.1 type be 'GetCert' ?
- How is this structure encapsulated in a PKIMessage ?

- Jakob

Approved-By:  Michael Myers <[email-masked]>
Date:         Wed, 18 Mar 1998 22:30:45 -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: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

All,

Here's the separate ASN.1 poll question mentioned in my prior message:

Should OCSP request and response syntax be expressed in ASN.1?

A rough consensus of YES would result in modifying the existing
OCSP draft to change the request and response syntax appropriately.

A rough consensus of NO would result in maintaining the current
ABNF syntax.

In either case, protocol elements may change as a result of the
incorporation of additional requirements.

Mike

Approved-By:  Michael Myers <[email-masked]>
Date:         Wed, 18 Mar 1998 22:23:52 -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: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] New OCSP Requirements
To: [email-masked]

All,

The recent discussion on OCSP has resulted in a list of candidate new
requirements that have not yet received the full vetting of the group.  I
spoke with Rich  regarding the relationship of these requirements to both
OCSP and the notary protocol in the context of his recent posting on
"lightweight" and "heavyweight" options.

This discussion led to the following joint proposal.  The "lightweight"
option is OCSP revised to accomodate requirements appropriate to its scope
from among  those identified by the Malpani et. al. contribution.  The
"heavyweight" option is the notary protocol equivalently revised to
accomodate other of the of those requirements.

Taking each point by point:

ASN.1
--------
Proposed Resolution:  I will be calling for a poll on this issue in a
separate posting and shall update the OCSP draft accordingly.

Multiple Certs In Request
-----------------------------------
The Notary Protocol already enables these more complex constructions.  OCSP
is intended to be a simple query on a single certificate.

Proposed Resolution:  Allocate this requirement to the notary protocol.  A
proposal to add validation of multiple target certs, including a
cert-path for each target cert, to the Notary Protocol, was posted to the
PKIX list  recently.

Transport Independance
---------------------------------
The initial OCSP drafts was structure to enable transport independance.  The
current draft is written to ensure that at least one transport mechanism is
implemented.  Until recently, no exception was taken to that position.

Proposed Resolution:  Correct the current OCSP draft to speak to the
enablement of transport independance, but yet maintain HTTP as one
well-defined mechanism.  Consideration is being given to a sockets-based
specification in the base OCSP draft.  If other transports are desired,
interested parties are encouraged to produce companion drafts.

Multiple Response Types
----------------------------------
OCSP speaks only to revocation information.  This is a well defined
spectrum.  Situations that might stimulate the production of other response
types are only producable using more advanced mechanisms that are beyond the
scope of OCSP.

Proposed Resolution:  Allocate the requirement for "negotiated response
types" to the notary protocol.  The Malpani spec includes a variety of
additional information on a revoked certificate, e.g. revocation reason and
invalidity date.  This would be a useful addition in both OCSP and the
notary protocol.

Ceritificate Identification
--------------------------------
The proposed alternative to certificate identification addresses
requirements that have been debated within X.509 and elsewhere, resulting in
the construct AuthorityKeyIdentifier.  The alternative observes that CA name
collisions are possible and thus proposes the cert ID be a function of CA
name and key.  However, the occurrence of this event seems remote given the
prevailing practice of CA naming.

Proposed Resolution:  Pending the outcome of the straw poll, revisit the
syntax of certId in OCSP.  If indeed the observation regarding CA name
collisions can be substantiated as a real-world problem, then PKIX may wish
to consider a defect report to X.509 regarding the security risks inherent
in the AuthorityCertIssuer option of AuthorityKeyIdentifier.

Address revocation only in OCSP, not validation
----------------------------------------------------------------
Proposed resolution:  Language regarding or implying validation *of
certification paths to the target cert* will be removed from OCSP.   The
notary protocol may be updated to accomodate this and any additional context
validation schemes.

Delegation of Authority
------------------------------
The proposed delegation model should be revisited in the broader context of
Attribute Certificates and certificate-based access control generally, a
topic that has often been informally discussed within PKIX but never moved
forward to a work product.  Establishing point-wise solutions to this
problem creates a patchwork of what could and should be a unified approach
to the subject.

Proposed Resolution:   Defer discussion of specific delegation mechanisms to
a future work product which consolidates all points of view and essential
requirements regarding certificate-based access control.  This future work
product could easily address mechanisms that govern permissible use of OCSP,
Notary Protocol and other essential PKI services.

Mike

Approved-By:  Todd Glassey <[email-masked]>
Date:         Wed, 18 Mar 1998 12:43:05 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      [IETF-PKIX] Wouldnt adding a certified timestamp kill the issues re: multiple keys/certificates
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms137323960C72F5C5ED82D5B1
Content-Type: multipart/mixed; boundary="------------E689DCC0AD24C21396A92BAD"

This is a multi-part message in MIME format.
--------------E689DCC0AD24C21396A92BAD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Say all,
So what I was wondering is wouldn't adding some secondary temporal
authentication mechanisms, like a certified timestamp for instance, cleanup the
Multiple Key per certificate dilemma.

Seems like a no-brianer solution and strengthens the Certificate Value as well!
What do you think?

Todd

--
--------
--  Regards,
--  Todd Glassey

Todd's Latest Rant --
---------------------
"...Plan?, There ain't no plan, I though' you had the plan..."
      The Pig Killer - Mad Max: Beyond Thunderdome

--------------E689DCC0AD24C21396A92BAD
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Todd S. Glassey
n:              Glassey;Todd S.
org:            Coastek, Inc.
adr:            5550 Scotts Valley Drive;;Suite 700;Scotts Valley;Ca;95066;USA
email;internet: [email-masked]
title:          Chief Scientist and Principal Founder
tel;work:       408.440.0180
tel;fax:        408.438.2979
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------E689DCC0AD24C21396A92BAD--

--------------ms137323960C72F5C5ED82D5B1
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms137323960C72F5C5ED82D5B1--

Approved-By: [email-masked]
Date:         Wed, 18 Mar 1998 10:05:48 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: [email-masked]

In the MISPC, and elsewhere, if an extension is critical, then each reliant party's client software must be able to process the extension according to the issuing CA's CPS.  If followed (and, I think this will be rare), then the client software will have to "know" the CPS under which the cert is issued to act in accordance with those CPS constraints as part of the validation process.  This rule also addresses the issues Bob brought up with regard to multiple certificates (multiple CPS) for the same key pair tying the cert to the message.

If we abandon the critical extension processing rule, then the CPS reading becomes more critical for liability and risk assumption or re-direction.  If we enforce the rule, then liability and risk assumption becomes explicit.

>>> Stephen Kent <[email-masked]> 03/17/98 06:59PM >>>
Paul,

I think the question of who reads a CPS and how closely is relevant to this
discussion, even if it may be somewhat separable.

>
>Section 2.0 of the draft is quite clear on this:
>   A certificate user should review the certification practice Statement
>   (CPS) generated by the CA before relying on the authentication or
>   non-repudiation services associated with the public key in a
>   particular certificate.  To this end, this standard does not
>   prescribe legally binding rules or duties.

Yes, the draft says that now, and I want to suggest that we tone this down
a bit, since not all CAs will have a CPS.  The CPS notion is important for
3rd party CAs, and organizational CAs issuing certs for extranet purposes,
but proprietary CAs may not have to have one, unless they operate in Utah
;-).

>I think it would be a good idea to add words to this such as:
>
>To avoid confusion, a CPS should say which attributes of a certificate have
>been verified. Further, a CPS should not state that only part of any
>attribute is verified; either the entire attribute is verified, or none of
>the attribute is verified. This is particularly important for attributes
>with rfc822Name values, since the two parts of the value can be validated
>in different fashions, and many CAs will choose not to validate one part or
>the other.

Yes, one could do that, but actually assuming that users will pay close
enough attention to note these differences strikes me as unwarranted.   As
a "security guy" I know from experinece that users pay little attention to
various warnings and the average CPS is way too big to expect the average
user to really read it.  Remember the "Internet Exploder" program, an
ActuveX module that had a valid Microsoft ActiveX vendor signature on it?
People downloaded it and when it popped up a window that said it would shut
down the user's PC when clicked, most users actually cliked the button and
watched in surprize while their system shut down!  The metaphor I use in my
talks on CA policies is that of VCR programming: the vast majority of
(U.S.) VCR owners are incapable of performing this task and thus VCRPlus is
a big hit.  How much harder is it to evaluate a CPS, a complex "trust"
graph in a PKI, etc?

Steve
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!

Approved-By: [email-masked]
Date:         Wed, 18 Mar 1998 10:22:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] The argument for using NTPv4 as one of the basis of Certified Time in PKIX-land
To: [email-masked]

At 12:14 PM 3/17/98 -0800, Todd Glassey wrote:

>>>>

<excerpt>

<bold><bigger><bigger>As to time keeping and the IETF's intellectual
properties policies...

</bigger></bigger></bold>To me the question of whether the most important
piece of OLTP & non-repudiated record keeping, policy authentication, and
negotiation, i.e. the timestamps and most importantly - their time
source, is protected under a patent and thus "un-standardizable" is one
of the key reasons we, Coastek, are  proposing using an extended-evolved
version of the already ubiquitous NTPv3 (the upcoming NTPv4) as a primary
source of credible and certified time in networking facilities

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

Forgive my ignorance, but what patent are your referring to?

Hal

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

Harold W. Lockhart Jr.               Platinum technology, Solutions

Chief Technical Architect            8 New England Executive Park

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

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

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

Approved-By: [email-masked]
Date:         Wed, 18 Mar 1998 09:46:49 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and ignored.
From: [email-masked]
Subject:      [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ldapv2-schema-00.txt
To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

        Title           : Internet X.509 Public Key Infrastructure LDAPv2 Schema
        Author(s)       : T. Howes, S. Boeyen, P. Richard
        Filename        : draft-ietf-pkix-ldapv2-schema-00.txt
        Pages           : 6
        Date            : 16-Mar-98

     The schema defined in this document is a minimal schema to  support
     PKIX  in an LDAPv2 environment, as defined in draft-ietf-pkix-ipki-
     ldapv2-06.txt. Only PKIX-specific components  are  specified  here.
     LDAP  servers, acting as PKIX repositories should support the auxi-
     liary object classes defined in this  specification  and  integrate
     this  schema  specification with the generic and other application-
     specific schemas as appropriate, depending on the  services  to  be
     supplied by that server.

     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 with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pkix-ldapv2-schema-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-00.txt

Internet-Drafts directories are located at:

        Africa: ftp.is.co.za

        Europe: ftp.nordu.net
                ftp.nis.garr.it

        Pacific Rim: munnari.oz.au

        US East Coast: ds.internic.net

        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:      [email-masked].  In the body type:
        "FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-00.txt".

NOTE:   The mail server at ietf.org 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID:     <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-00.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ldapv2-schema-00.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--OtherAccess--

--NextPart--

Approved-By:  Warwick Ford <[email-masked]>
Date:         Tue, 17 Mar 1998 22:58:14 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Carlisle:

Thanks for raising that other problematic case -- another example to
support my contention that we should stick to traditional iterative
procedures if we want our work to progress smoothly.  And no, I was not
trying to be funny.  I'm kinda struggling getting my sense of humor
activated when processing PKIX mails these days.

Re OCSP editing, I am hopeful we are now at a point from which normal
procedures can prevail.  As you well know, an editor's task is not always
easy or enviable, and pressures to finish the job can sometimes result in
issues being given less attention than their contributors feel they
deserve.  I believe this point has been adequately brought to the attention
of the OCSP editors and that we can now move on to an orderly track for
resolving all change requests raised on OCSP and launching serious work on
the Notary protocol (or whatever it should be called).

Regards,
Warwick

At 04:02 PM 3/17/98 -0500, Carlisle Adams wrote:
>Hi Warwick,
>
>>----------
>>From:  Warwick Ford[SMTP:[email-masked]]
>>Sent:  Tuesday, March 17, 1998 12:17 AM
>>To:    [email-masked]
>>Subject:       Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
>>
>>Paul:
>>
>>This posting is about as unhelpful as they can get.  Other actions and
>>comments by various list members recently are also highly questionable, and
>>I think it is time we regained decorum as a group.
>
>...
>>
>>Almost as unhelpful is the approach taken by some list members to produce a
>>"competing draft" for OCSP.  The pre-existing OCSP document has already
>>been through many iterations, reflecting many concensus-reaching decisions.
>> The correct approach to making changes to the OCSP design at this stage is
>>to sumbit a contribution that proposes changes to the current draft,
>>providing rationale for such changes.  The issues are then debated on the
>>list.  This iterative procedure has always worked in the past and taking
>>any other approach could set a most undesirable precedent.
>
>I find it "interesting" (to say the least) that you could write a
>paragraph like the one above.
>
>Most of us either were at the Munich and Washington IETFs, or read the
>minutes of the Munich and Washington IETFs.  Consequently, most of us
>remember seeing a mature, two-year-old PKIX-3 spec., which represented
>the culmination of significant consensus-building efforts by the Working
>Group, turn into {CMP + CRMF + CRS (now CMC) + CMMF} as a result of a
>"competing draft" that showed up not only late in the process, but
>*after* the WG and IETF-wide Last Call periods had been completed.
>
>Is your last sentence above meant to be funny?
>
>>I propose that the "competing draft" be recast as a specific set of change
>>proposals to OCSP, along with rationale for each.
>
>The *only* reason there was a "competing draft" at all is because this
>precise approach had been taken and had met with no success.  The second
>course of action was to re-write the spec. taking into account the
>comments from the list.  Please note that this was deliberately *not*
>submitted as an Internet Draft, but instead was offered to the list (and
>specifically to the OCSP editors) as a basis for progression.  It was
>essentially presented in that form so as to save Mike and Rich the
>editing task of incorporating the list's comments.  Mike refused any
>association whatsoever with that re-write and gave the distinct
>impression that he did not intend to change OCSP.  Only then was it
>decided to submit this re-write as a stand-alone draft.
>
>>Then let's try to
>>quickly reach concensus on each point, acting in a grown-up and
>>professional manner.
>
>Mike now seems willing to do this.  Perhaps the RCSP submission was
>useful after all...  :-)
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>
******** PLEASE NOTE NEW CONTACT DETAILS ********
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 22:05:37 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName
To: [email-masked]

Paul,

I agree that we ought not venture into the area of what it means to
validate the accuracy of specific name types. Nonetheless, I reiterate my
position re the desirability of keeping comments out of 822 names, for the
reasons cited in my most recent messages.

Steve

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 5 Mar 1998 22:16:12 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

David,

If we were able to somehow add cryptographic binding of
the digital signature to the specific certificate that is s
supposed to be used to validate it, virtually all of my objections
to issuing more than one certificate per key would disappear,
and we would be left with some of the positive virtues of that
approach that others have mentioned.

However, I do NOT think that we should insist that each and
every protocol reinvent the wheel. Some will do it wrong (as per
your examples), and some just won't do it at all.

Unfortunately, the SIGNED macro doesn't include a version
indicator (will we _never_ learn?), so we can't do the version 3
trick that we pulled when we found that the X.509 certificate
wasn't adequate for our new extended purpose.

However, I think there is a way out, although from a purist
architectural standpoint it is an ugly hack. But hey, MISSI did
it, and what's good enough for the US Government ought to be
good enough for the rest of us, right?

What I'm proposing is that we define a new series of digital signature
algorithm OIDs, which would include the additional information that
is needed as part of the COMPONENTS.

We can debate the precise information that we might like to include later,
along with the optimum syntax, but this is the approach that as I
recall MISSI took to include clearance information and other parameters
that they had no place to put in the old V1 certificate format. Like I said,
an ugly, but noble hack.

One potential problem is that although currently in-vogue RSA and
DSA key lengths (1024 and 2048 bits) would probably be long enough
to directly include most of what we might like, the 512 bit lengths allowed
by US export (and some import) regulations might be pretty tight, and
would be extremely tight for elliptic curves.

One approach to solving this problem would be to use two message digests,
one for the ToBeSigned, and the other for the ancillary signature data (someone
has to think of a snappy attribute name ¯ I refuse to be blamed for "ancillarySignatureData"), and then include both message digests
within the signature.  This would work for algorithms of up to 320 bits
in length, which might still be tight for some elliptic curve algorithms.

The other approach, which could be extended to arbitrarily long
information, would be to effectively append the existing ToBeSigned
information (normally a message digest) to the ancillary information, and
then compute a super message digest over the entire collection. That
super message digest, plus any additional randomized padding (we
ought to fix that problem while we are at it) would then be the input
to the actual signing operation. This would support signature algorithms
and key lengths which only allow as little as 160 bits of input (or even
128 bits, for MD5)).

The second approach is obviously superior to the first, assuming
that the time for a second hash is considered negligible. But can
anyone think of an even better method?

The benefit of this scheme is that by simply implementing one
or more new enhanced signature algorithms (e.g., "RSA with
SHA-1 and ancillary data") within the underlying toolkits,
virtually all applications would benefit, with virtually no effort at all.

And if we do it right, we might even be able to achieve some degree of
backward compatibility by some sort of slight of hand involving
mapping the algorithm OIDs to existing algorithms
in such a way as to ignore the added information if the code doesn't yet
support it. Maybe some ASN.1 genius can think of a slick trick.

Let me let this sink in before I start talking about all of the stuff I
would like to see included. Hopefully this time we would do it right,
probably by defining the information to be included in ASN.1 with
strong typing, so that we additional information is proposed to be
added it will be simple to do. But that is tomorrow's homework
assignment.

At a minimum, however, it would have to include some form of
unique identification of the certificate to be used to validate the
signature, either issuerName and serial, authorityKeyId, or at
the very least a hash of the certificate contents (although that
wold cause some problems of circular definition if used within
the certificate itself.)  Certainly a URL or some other kind of hint
as to where to actually find the certificate would be a nice touch,
but we can discuss that independently of the primary issue.

Whaddaya think about the basic concept?

Bob

----

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

>>> "David P. Kemp" <[email-masked]> 3/5/98 13:03:16 >>>
> From: Bob Jueneman <[email-masked]>
>
> The problem, to the extent that there is one, is that the X.509
> definition of the "sign" macro does not provide any means of defining
> precisely which certificate in particular should be used to validate a
> particular signature, and thereby associate a particular set of
> name/rights attributes with that signature.
>
> (That's what often happens when a standard that was intended for one
> purpose is appropriated for another, entirely different purpose. We,
> the digital signature community, probably should have rethought that
> particular issue before adopting the X.509 definition of signature.
> Some other information, such as the date/time and signing and the
> identity of the platform ("location") on which the signature took place
> would have been handy, also.)

Bob,

The X.509 "SIGNED" macro might not have been designed with the intent
of supporting this purpose, and so may be excused for not including
a method of binding a certificate to the signed data.

However, the IETF CMS specification (aka PKCS#7) was designed for
precisely this purpose (providing non-repudiation grade signatures over
generic content), yet it still does not provide a clean method of
binding the signer's certificate to the content.

The CMS definition of SignedData includes {content, certs, crls,
signerInfos}, and some other fields.  There may be multiple signatures
applied to the content, each represented by a SignerInfo.  Each
SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
Because the issuerAndSerialNumber field, which uniquely identifies the
certificate used by the signer, is not covered by the signature, it is
not bound to the content.  I'm not sure why PKCS#7 was designed that
way, but it was, and so is CMS.

It would have been preferable to define an issuerAndSerialNumber
attribute, which could have been included either in
authenticateAttributes to bind it with the signature, or in
unauthenticatedAttributes if the current semantics of not binding the
signer's cert to the signed content is desired.

Perhaps defining a redundant copy of issuerAndSerialNumber, to be
included in authenticatedAttributes, could address the requirement
without breaking backward compatibility.  (It only covers the signer's
cert, not the full path, but it's a start.)
The uglier alternative is  is to double-sign everything, encapsulating a
signedData within another signedData for each parallel signature.

Since CMS is intended to be a generic security encapsulation mechanism,
not just an S/MIME-specific structure, those who feel that this
requirement is important (to address either multiple certification of
keys or proof-of-possession) should discuss it in the S/MIME working
group.  (A SigningTime attribute is already defined in CMS, but a
"location" attribute is not.)

Dave Kemp

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 20:59: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and
To: [email-masked]

Paul,

I think the question of who reads a CPS and how closely is relevant to this
discussion, even if it may be somewhat separable.

>
>Section 2.0 of the draft is quite clear on this:
>   A certificate user should review the certification practice Statement
>   (CPS) generated by the CA before relying on the authentication or
>   non-repudiation services associated with the public key in a
>   particular certificate.  To this end, this standard does not
>   prescribe legally binding rules or duties.

Yes, the draft says that now, and I want to suggest that we tone this down
a bit, since not all CAs will have a CPS.  The CPS notion is important for
3rd party CAs, and organizational CAs issuing certs for extranet purposes,
but proprietary CAs may not have to have one, unless they operate in Utah
;-).

>I think it would be a good idea to add words to this such as:
>
>To avoid confusion, a CPS should say which attributes of a certificate have
>been verified. Further, a CPS should not state that only part of any
>attribute is verified; either the entire attribute is verified, or none of
>the attribute is verified. This is particularly important for attributes
>with rfc822Name values, since the two parts of the value can be validated
>in different fashions, and many CAs will choose not to validate one part or
>the other.

Yes, one could do that, but actually assuming that users will pay close
enough attention to note these differences strikes me as unwarranted.   As
a "security guy" I know from experinece that users pay little attention to
various warnings and the average CPS is way too big to expect the average
user to really read it.  Remember the "Internet Exploder" program, an
ActuveX module that had a valid Microsoft ActiveX vendor signature on it?
People downloaded it and when it popped up a window that said it would shut
down the user's PC when clicked, most users actually cliked the button and
watched in surprize while their system shut down!  The metaphor I use in my
talks on CA policies is that of VCR programming: the vast majority of
(U.S.) VCR owners are incapable of performing this task and thus VCRPlus is
a big hit.  How much harder is it to evaluate a CPS, a complex "trust"
graph in a PKI, etc?

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 20:58: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Paul,

>>Most folks will not read a CPS, especially if it goes into that level of
>>detail, and thus what the fine print says will not matter unless one
>>litigates a dispute.
>
>But if you don't read the CPS, you have no idea if the non-comment part of
>an email address was verified. I could certainly believe that many CAs who
>do not do online enrollment (like corporate CAs) will accept as valid any
>information typed into them by the human CA administrator at a CA console.
>If I walk up to my human administrator and say "here's my common name and
>my email address; give me a cert", there's no sensible way for that human
>to verify that it is really my email address. I think you are thinking too
>much in the Verisign online enrollment model, which is only one way certs
>will be generated.

I am not thinking about any particular enrollment model, VS or otherwise.
And I'm willing to back down a bit from the notion that no user will read
any CPS (though I bet this will be true in the vast majority of the
cases!).  However, I do believe that even the few users who do read a CPS
will not read it very carefully.  Thus the fine distinction between whether
an 822 address is verified, or whether the address and the commented name
is verified, is somehting I am confident will escape almost every user.

>Basically, either someone reads the CPS or they don't. Saying "becasue they
>probably won't, this identifier is OK because it *could* be verified" is
>very dangerous, IMHO. Either it is verified (and th CPS says so), or it
>isn't (and it's not covered in the CPS, or the CPS says "we don't verify
>this").
>
>>I argue that we ought to be careful to not foster a situation that unduly
>>creates an opportunity for confusion.
>
>I fully agree. And I think pretending that a bare email address is verified
>and belongs to the named user is quite an opportunity for confusion.
>Remember, comments in an RFC 822 name *can* be verified. Both parts can be
>verified, or they can be not verified.

Yes, one can verify the comment as well, but I maintain that unless we
require that the comment is always verified, then we are unnecessarily
creating a situation that will confuse users.  The altertiave I proposed
would allow a common (comment?) name to be included separately if
appropriate, and would create an opportunity for the appropriate inclusion
of names based on what a CA really checks.

I;'m not trying to look at this is any strict legal sense, although soe
other list memebrs take that appraoch.  I'm trying to suggest what I
believe is a common sense approach to this issue that will minimize the
likelihood of confusion where it is easy to be confused and easy to avoid
confusion.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 20: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] Comments on sixth draft of IPKI X.509 Certificate and CRL Profile
To: [email-masked]

Tirthankar,

I'm not certain that the example you cite will prove to be a problem.  Not
only must an attacker construct a packet with a public key info field that
has the same hash value as the subject key identifier (for a good hash
algorithm this is generally infeasible if the public key in question
differs), but the public key in the purpored CA cert must correspond to the
private key used to sign the target certificate.  Now, if you're willing to
construct a CA cert with the same public key info and different other
parameters, that will work, but then  you'll have to cause the cert chain
to terminate at a (root) CA acceptable to the cert consumer.  Remember, the
intent of this backpointer is not to add security, but merely to facilitate
selection of the right cert from among several valid ones issued to the
same CA.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 20:58: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Cryptographic binding of certificates tosignatures
To: [email-masked]

Bob,

Sometimes we sign data for authentication and integrity, but not for
non-repudiation.  In such cases, the need to include a cert pointer in the
SIGNED macro may not be critical.  Also, in many instances there may be a
one-to-one correspondence of keys to certs, as we've discussed recently on
the list, so that too may mitigate the criticality of what you propose.
Finally, a protocol or application designer can always include the
necessary info in the signed data if it's critical, thought I admit that we
have examples where this is not the case, e.g., secure e-mail protocols.  I
don't mean to diminish the utility of your suggestion, but I'd rather not
have it delay the advancement of the PKIX standards.  if you want to pursue
this, let's do so independent of the current set of PKIX documents; after
all, it's a broad proposal that goes beyond the cert and CRL formats and
protocols that we are profiling here.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 20:57: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Bob,

For some applications, CRLs are just fine, because there is not a need for
immediate notification of revocation nor retention of data in support of
non-repudaition.  In other cases, a real time attestation of certificate
validity is appropriate.  Because both caes exist, we have two classes of
mechanisms to address the revocation problem.  Let's not belabor this point.

Steve

Approved-By: [email-masked]
Date:         Tue, 17 Mar 1998 17:59:46 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

>However, regardless of whether you believe other working groups have
>conducted themselves in a decorous manner, the precedent for competing
>drafts has been set.  For how long were there two competing drafts
>for the replacement of SSL in the TLS WG?  For how long were there three
>competing drafts for a key management protocol in the IPSEC WG?

Forgive me if am wrong Dave but in those cases the drafts were presented
as precisely that - competing drafts with different names, authors and so
on.

The precedent is that if you want to propose a radically different approach
you do so by issuing an entirely independent draft or you write a mail
proposing
a series of changes.

If you wish to have the endorsement of the previous authors you ask for this
before issuing messages which may cause confusion.

At the very least this avoids the problem of the Malpani draft which misses
the series of edits I made to align it with the HTTP/1.1 specification which
took a considerable amount of time.

    Phill

Approved-By: [email-masked]
Date:         Tue, 17 Mar 1998 12:14:15 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      [IETF-PKIX] The argument for using NTPv4 as one of the basis of Certified Time in PKIX-land
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms87AE52D6C5F874B8D4621B66
Content-Type: multipart/mixed; boundary="------------DEA5BDF02E948F4667E01C67"

This is a multi-part message in MIME format.
--------------DEA5BDF02E948F4667E01C67
Content-Type: multipart/alternative; boundary="------------86AE88F1BD822C56FBC3D5ED"

--------------86AE88F1BD822C56FBC3D5ED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gentlefolk,
in response to some of the questions regarding the legal status of our standards
and standards efforts...

>> All,
>>
>> Does anybody have a patent regarding the protocols described in the Notary
>> Protocols I-D (draft-adams-notary-01.txt)??  Is there anybody who is in the
>> process of applying for a patent regarding the Notary Protocols described in
>> the draft??  Is there anybody that believes that he/she/it has intellectual
>> property in this area and plans to apply for a patent regarding the Notary
>> Protocols described in the draft??(Those of you who are interested  might want
to see RFC 2026 for clarification on the POISSON WG's standards for the IETF's
accepting patented materials for consideration under the IETF Processes).

Robert Zuccherato wrote:

> I believe that the protocols defined in the Notary Protocols Internet
> Draft (draft-adams-notary-01.txt) can be implemented without infringing
> any intellectual property for which Entrust has, or has applied for,
> patent protection.  Should this situation change in the future, we would
> be willing to license the technology on fair and reasonable terms.

>         Robert Zuccherato
>         Entrust Technologies

As to time keeping and the IETF's intellectual properties policies...

To me the question of whether the most important piece of OLTP & non-repudiated
record keeping, policy authentication, and negotiation, i.e. the timestamps and
most importantly - their time source, is protected under a patent and thus
"un-standardizable" is one of the key reasons we, Coastek, are  proposing using
an extended-evolved version of the already ubiquitous NTPv3 (the upcoming NTPv4)
as a primary source of credible and certified time in networking facilities

We need at least one source of time - EVERYWHERE

The real issue, IMHO, is that  we need at least one ubiquitous source of credible
time data for both Security and  and Networking WG's time-centric requirements.
This would allow us to focus on the deployment of user technology rather than
inventing (or reinventing) 200 more mechanisms to provide time to transactions.

Book the Winner - NTP is already "THE" standard per say

With that in mind, NTP is already pretty much an "IETF standard" and as such
extending it to meet the needs of all networking and electronic commerce/trust
systems is really a no-brainer. So with this in mind my question is "Why reinvent
a new wheel...", hopefully its not a NIH issue.

As to timestamping with NTP for non-repudiation and other PKIX services,

   * document & instrument stamping
   * or other digital notary services
   * desktop synchronization and general certified time deployment,

By using NTP as the basis of the time services the key critical component  is a
ubiquitous protocol already EVERYWHERE.

As to adding certified time to the X509 certificate  services, extending the NTP
daemons the use models are reasonably straight forward.

  1. Systems that need no total process end-to-end possession of their time data
     could  easily keep their reliance on the underlying Time Of Day (TOD) clocks
     of the underlying OS's (resynchronized through NTP) and thus deploy some
     sense of certified process based upon the sanctity of the timestamp.
  2. their counterparts that need the certainty of the timestamp as part of an
     embedded trust system, could use our Java based stamping API or
     roll-their-own solutions based upon the Coastek Specified NTP Certified
     Client API that Coastek will be proposing as part of its next IETF Draft.

please remember that because NTP technology has been around for a while and is
native almost all systems, it is robust and well tuned, simply put it is stable
and reasonably mature.

So what does this buy the PKIX WG?

We don't have to completely reinvent the wheel!. By having us within PKIX WG
acknowledging the PKI signed variant of NTP (NTPv4) as one of our certifiable
timesources for non-repudiation, we can create trust models with varying degrees
of time-centicity and support a single sense of time services throughout
networking.

Build your own Certificate Management API... but keep the source of the time
services as NTP

As to the end-user use models, various API style interfaces to allow for the
integration of time services at the CA level  that are easily based upon a simple
API to the PKI Extended NTPv4 Server (For an example see the Entrust Digital
Notary Draft - Draft-adams-notary-01.txt).

PKI X and Time Services

The PKIX WG to date has understood that time data is important but has shy'd away
from standardizing any form of it since commercially certifiable and credible
time sources were until very recently out of reach (expense wise) at the
application programmers level and thus too costly to include in everyday security
and process solutions. But with the new evolution in technology this is no longer
true.

The New Coastek Time Services Draft for PKIX WG

To this end - watch for a new draft from Michael McNeil and myself to be filed at
the end of this week, on PKIX specific use models for the Coastek/Mills
Extensions to NTP. This draft will include document/instrument stamping but is
centered around using certified time as the basis of non-repudiated event logging
and proof infrastructures.

Todd Glassey

--------
--  Regards,
--  Todd Glassey

Todd's Latest Rant --
---------------------
"...Plan?, There ain't no plan, I though' you had the plan..."
      The Pig Killer - Mad Max: Beyond Thunderdome

--------------86AE88F1BD822C56FBC3D5ED
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
Gentlefolk,
<BR>in response to some of the questions regarding the legal status of
our standards and standards efforts...

<P>>> All,
<BR>>>
<BR>>> Does anybody have a patent regarding the protocols described in
the Notary
<BR>>> Protocols I-D (draft-adams-notary-01.txt)??&nbsp; Is there anybody
who is in the
<BR>>> process of applying for a patent regarding the Notary Protocols
described in
<BR>>> the draft??&nbsp; Is there anybody that believes that he/she/it
has intellectual
<BR>>> property in this area and plans to apply for a patent regarding
the Notary
<BR>>> Protocols described in the draft??(Those of you who are interested&nbsp;
might want to see RFC 2026 for clarification on the POISSON WG's standards
for the IETF's accepting patented materials for consideration under the
IETF Processes).

<P>Robert Zuccherato wrote:
<BLOCKQUOTE TYPE=CITE>I believe that the protocols defined in the Notary
Protocols Internet
<BR>Draft (draft-adams-notary-01.txt) can be implemented without infringing
<BR>any intellectual property for which Entrust has, or has applied for,
<BR>patent protection.&nbsp; Should this situation change in the future,
we would
<BR>be willing to license the technology on fair and reasonable terms.</BLOCKQUOTE>

<BLOCKQUOTE TYPE=CITE>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Robert Zuccherato
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Entrust Technologies</BLOCKQUOTE>
&nbsp;
<H3>
As to time keeping and the IETF's intellectual properties policies...</H3>
To me the question of whether the most important piece of OLTP &amp; non-repudiated
record keeping, policy authentication, and negotiation, i.e. the timestamps
and most importantly - their time source, is protected under a patent and
thus "un-standardizable" is one of the key reasons we, Coastek, are&nbsp;
proposing using an extended-evolved version of the already ubiquitous NTPv3
(the upcoming NTPv4) as a primary source of credible and certified time
in networking facilities
<BR>&nbsp;
<H3>
We need at least one source of time - EVERYWHERE</H3>
The real issue, IMHO, is that&nbsp; we need at least one ubiquitous source
of credible time data for both Security and&nbsp; and Networking WG's time-centric
requirements. This would allow us to focus on the deployment of user technology
rather than inventing (or reinventing) 200 more mechanisms to provide time
to transactions.
<BR>&nbsp;
<H2>
Book the Winner - NTP is already "THE" standard per say</H2>
With that in mind, NTP is already pretty much an "IETF standard" and as
such extending it to meet the needs of all networking and electronic commerce/trust
systems is really a no-brainer. So with this in mind my question is "Why
reinvent a new wheel...", hopefully its not a NIH issue.

<P>As to timestamping with NTP for non-repudiation and other PKIX services,
<UL>
<LI>
document &amp; instrument stamping</LI>

<LI>
or other digital notary services</LI>

<LI>
desktop synchronization and general certified time deployment,</LI>
</UL>
By using NTP as the basis of the time services the key critical component&nbsp;
is a ubiquitous protocol already EVERYWHERE.

<P>As to adding certified time to the X509 certificate&nbsp; services,
extending the NTP daemons the use models are reasonably straight forward.
<OL>
<LI>
Systems that need no total process end-to-end possession of their time
data could&nbsp; easily keep their reliance on the underlying Time Of Day
(TOD) clocks of the underlying OS's (resynchronized through NTP) and thus
deploy some sense of certified process based upon the sanctity of the timestamp.</LI>

<LI>
their counterparts that need the certainty of the timestamp as part of
an embedded trust system, could use our Java based stamping API or roll-their-own
solutions based upon the Coastek Specified NTP Certified Client API that
Coastek will be proposing as part of its next IETF Draft.</LI>
</OL>
please remember that because NTP technology has been around for a while
and is native almost all systems, it is robust and well tuned, simply put
it is stable and reasonably mature.
<BR>&nbsp;
<H2>
So what does this buy the PKIX WG?</H2>
We don't have to completely reinvent the wheel!. By having us within PKIX
WG acknowledging the PKI signed variant of NTP (NTPv4) as one of our certifiable
timesources for non-repudiation, we can create trust models with varying
degrees of time-centicity and support a single sense of time services throughout
networking.
<BR>&nbsp;
<H3>
Build your own Certificate Management API... but keep the source of the
time services as NTP</H3>
As to the end-user use models, various API style interfaces to allow for
the integration of time services at the CA level&nbsp; that are easily
based upon a simple API to the PKI Extended NTPv4 Server (For an example
see the Entrust Digital Notary Draft - Draft-adams-notary-01.txt).
<BR>&nbsp;
<H4>
PKI X and Time Services</H4>
The PKIX WG to date has understood that time data is important but has
shy'd away from standardizing any form of it since commercially certifiable
and credible time sources were until very recently out of reach (expense
wise) at the application programmers level and thus too costly to include
in everyday security and process solutions. But with the new evolution
in technology this is no longer true.
<BR>&nbsp;
<H2>
The New Coastek Time Services Draft for PKIX WG</H2>
To this end - watch for a new draft from Michael McNeil and myself to be
filed at the end of this week, on PKIX specific use models for the Coastek/Mills&nbsp;
Extensions to NTP. This draft will include document/instrument stamping
but is centered around using certified time as the basis of non-repudiated
event logging and proof infrastructures.

<P>Todd Glassey

<P>--------
<BR>--&nbsp; Regards,
<BR>--&nbsp; Todd Glassey

<P>Todd's Latest Rant --
<BR>---------------------
<BR>"...Plan?, There ain't no plan, I though' you had the plan..."
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Pig Killer - Mad Max: Beyond Thunderdome
<BR>&nbsp;</HTML>

--------------86AE88F1BD822C56FBC3D5ED--

--------------DEA5BDF02E948F4667E01C67
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Todd S. Glassey
n:              Glassey;Todd S.
org:            Coastek, Inc.
adr:            5550 Scotts Valley Drive;;Suite 700;Scotts Valley;Ca;95066;USA
email;internet: [email-masked]
title:          Chief Scientist and Principal Founder
tel;work:       408.440.0180
tel;fax:        408.438.2979
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------DEA5BDF02E948F4667E01C67--

--------------ms87AE52D6C5F874B8D4621B66
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms87AE52D6C5F874B8D4621B66--

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 17 Mar 1998 16:02:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Hi Warwick,

>----------
>From:  Warwick Ford[SMTP:[email-masked]]
>Sent:  Tuesday, March 17, 1998 12:17 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
>
>Paul:
>
>This posting is about as unhelpful as they can get.  Other actions and
>comments by various list members recently are also highly questionable, and
>I think it is time we regained decorum as a group.

...
>
>Almost as unhelpful is the approach taken by some list members to produce a
>"competing draft" for OCSP.  The pre-existing OCSP document has already
>been through many iterations, reflecting many concensus-reaching decisions.
> The correct approach to making changes to the OCSP design at this stage is
>to sumbit a contribution that proposes changes to the current draft,
>providing rationale for such changes.  The issues are then debated on the
>list.  This iterative procedure has always worked in the past and taking
>any other approach could set a most undesirable precedent.

I find it "interesting" (to say the least) that you could write a
paragraph like the one above.

Most of us either were at the Munich and Washington IETFs, or read the
minutes of the Munich and Washington IETFs.  Consequently, most of us
remember seeing a mature, two-year-old PKIX-3 spec., which represented
the culmination of significant consensus-building efforts by the Working
Group, turn into {CMP + CRMF + CRS (now CMC) + CMMF} as a result of a
"competing draft" that showed up not only late in the process, but
*after* the WG and IETF-wide Last Call periods had been completed.

Is your last sentence above meant to be funny?

>I propose that the "competing draft" be recast as a specific set of change
>proposals to OCSP, along with rationale for each.

The *only* reason there was a "competing draft" at all is because this
precise approach had been taken and had met with no success.  The second
course of action was to re-write the spec. taking into account the
comments from the list.  Please note that this was deliberately *not*
submitted as an Internet Draft, but instead was offered to the list (and
specifically to the OCSP editors) as a basis for progression.  It was
essentially presented in that form so as to save Mike and Rich the
editing task of incorporating the list's comments.  Mike refused any
association whatsoever with that re-write and gave the distinct
impression that he did not intend to change OCSP.  Only then was it
decided to submit this re-write as a stand-alone draft.

>Then let's try to
>quickly reach concensus on each point, acting in a grown-up and
>professional manner.

Mike now seems willing to do this.  Perhaps the RCSP submission was
useful after all...  :-)

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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 17 Mar 1998 13:48:41 -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] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

Andreas,

Yes, I saw that.  My assumption was that was intended to be some kind of a
caveat or restriction, e.g., "Valid for code signing only" or some key
usage parameter.

It is interesting to consider whether including a Reliance Limit would govern
what is considered to be a "commercially reasonable" transaction, especially
in the absence of a more specific statute.

If I were an attorney, I could probably argue either side of the issue in
court with little difficulty!

Regards,

Bob

>>> Andreas Berger <[email-masked]> 03/13 7:17 AM >>>
In the German Signature Law, in "7, Inhalt von Zertifikaten" (Contents
of Certifictes) there is a possibility to restrict the use of
certificates to special applications or other limitation.

I think that this opens the possibilty to define a certificate extension
that specify an amount of money or a limit in liability.

Andreas
Sorry: I am not firm in legal english :-)
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Tue, 17 Mar 1998 11:55:05 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Hi Mike (and All),

Agree, never a dull moment in PKIX! I am responding to your posts in
sequence,
so that people can follow this discussion.

With regards to your post on Sunday:

I don't believe RCSP has introduced any problems. The OCSP spec allows
for a
trusted third party service provider but does not specify any details.
RCSP
has just laid out the details of how that should work. I have addressed
each
of your concerns specifically below:

Michael Myers wrote:
>
> Ambarish, Colleagues:
>
> Never a dull moment in PKIX!
>
> Setting aside ASN.1 debate for a moment, I have one concern regarding the
> suitability of this proposal to today's business practices.
>
> The requirement that "The certificate of an Authorized RCSP Responder
cannot
> be revoked."  is simply too dangerous to be implemented.  The proposal
> appears to anticipate this problem by asserting that the certificate be
> maintained on a very short validity period.  This approach however has at
> least four fatal flaws:
>

I disagree that this requirement is too dangerous. A CA can either (1)
issue
all its RCSP responses itself  or (2) leave it up to RCSP clients to
establish
explicit direct trust relationships with RCSP responers or (3) designate
an RCSP
responder. Your comment applies to case (3). If a CA authorizes another
key to
issue RCSP responses for it, the CA needs to ensure that that key is at
least
as well protected as its own private key.
This point deserves to be made explicitly clear in the specification
itself. The
purpose of stating the requirement explicitly is to alert a CA to the
fact that a
validation service provider must adhere to practice standards consistent
with the
CA's requirement. It would be improper for a CA to trust third party
service
providers willy-nilly. This model is not any different from the model
required
by a CA that outsources its operations to CA service companies.

> 1.  There is no means proposed whereby this certificate would be updated.
> Thus the proposal is incomplete; it cannot be implemented as written.

Not true. The proposal can absolutely be implemented as written and
accomodates
responses originating from the CA (a situation that is identical to the
OCSP
draft) as well as third party trust providers. Third party trust
providers
may obtain their certificates with a straightforward certificate signing
request & response.  Nonetheless, it is probably worth adding some
verbiage
describing how such certificates are updated.

>
> 2.  Even is such a means were well-defined, the proposal suffers serious
> scalability problems due to the frequent need to update the special
> certificate.  Assume the period is two weeks.  Further assume for the sake
> of concreteness that this mechanism is being used to support a Bank's
> customers.   Every two weeks each of those customers will need to make
> contact with a key management center, download the new certificate,
install
> it, review practices disclaimers, click on several buttons etc. etc. All
> that pain every two weeks.  Or four weeks.  For every relying party
wishing
> to do business with the bank.  Now multiply that scenario by a given
number
> of banks; by the number of branch offices in a major corporation; by the
> Internet.  Definitely not a success scenario in my opinion.

Not true at all. RCSP responses allow for the responder may include its
certificate along with the response.  Absolutely *NO* user clicks
required.

>
> 3.  This key management cycle reduces public key infrastructure to the
same
> key management discipline that was used for symmetric key management.  The
> proposal thus takes a giant step backward against the progress we've
> currently
> made on PKI architecture suitable for the Internet.

Just not true.  Perhaps, the spec is confusing somewhere? Please let me
know what
should be rephrased to avoid creating this impression.

>
> 4.  Most importantly, it provides no means to bound the risks of key
> compromise.  A lot can happen in two to four weeks.  Compromise of the
> trusted responder key could, among other things, enable previously revoked
> subscribers to appear to be be re-established.

Not applicable. Please refer to the answer for question 1.

> However, this role-based certificate is analogous to certificates used to
> authorize LRAs, MLAs and other abstract roles.  Would it not be the case
> that this certificate could and indeed should be listed on a CRL?  This
CRL
> could be maintained separate from other CRLs via an CRL extension to
> identify
> the purpose of the CRL.  This would be necessary to prevent the common CRL
> suppression attack.  There is no reason at all why one can't combine
> techniques to deliver an integrated solution.

The purpose of both OCSP and RCSP is to avoid all the problems
associated with CRLs.
The best way to achieve this objective is to clearly state the
requirements that RCSP
or OCSP responders must adhere to. We have already done this.  Given
this, it is
unclear that new CRLs add value or security.

>
> Mike
>

Best regards,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect        (650) 849-9880
ValiCert, Inc.         [email-masked]
3160 W. Bayshore Road               http://www.valicert.com
Palo Alto, CA 94303

Approved-By: [email-masked]
Date:         Fri, 13 Mar 1998 15:17:24 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

In the German Signature Law, in "7, Inhalt von Zertifikaten" (Contents
of Certifictes) there is a possibility to restrict the use of
certificates to special applications or other limitation.

I think that this opens the possibilty to define a certificate extension
that specify an amount of money or a limit in liability.

Andreas
Sorry: I am not firm in legal english :-)
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 17 Mar 1998 12:22:34 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and RCSP
To: [email-masked]

> From: Rich Ankney <[email-masked]>
>
> Can we reach consensus on the need for two protocols
> (lightweight and heavyweight)?

That depends on whether we reach consensus that the problems being
solved by the two protocols are disjoint.

If one protocol can satisfy the requirements of both heavyweight and
lightweight applications (by having a mandatory lightweight core and
optional extensions to handle extra functionality), then it will be
difficult to argue that two separate standards track protocols are
appropriate.

There is precedent for documenting existing practice in an Informational
RFC, while using the standards track to develop a more flexible
alternative.  Is there a disadvantage to following that approach?

Approved-By:  Rich Ankney <[email-masked]>
Date:         Tue, 17 Mar 1998 11:31:32 -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:      [IETF-PKIX] OCSP and RCSP
To: [email-masked]

As one of the authors of both OCSP and RCSP (and also very interested
in the notary protocol), I thought I'd contribute my $.02 worth to the
debate.

I believe there was agreement at the DC meeting to proceed with OCSP
as currently formulated (with the addition of extensions as is done in
the latest draft).  I also agree that further extensions to OCSP are going
to be difficult; an ASN.1-based version would be useful at such a time.

I'd like to see OCSP as currently formulated proceed along the
standards track.  I'd also like to start on a more {flexible|robust|
heavyweight} version of the protocol (the "bigger hammer" referred to
in Mike's Email).  This can be based on the RCSP protocol; it could
also be based on the notary protocol.  Can we reach consensus on
the need for two protocols (lightweight and heavyweight)?  Besides
extensibility, other things in the heavyweight protocol might include
the things suggested by Bob J. in recent messages (I think the
notary protocol does most of these things quite well already).

Regards,
Rich

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 17 Mar 1998 09:23:31 -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] Cryptographic binding of certificates tosignatures
Comments: To: [email-masked]
To: [email-masked]

Denis, I was not really proposing to change the SIGNED macro, but
instead was  proposing a new signature algorithm, in hopes of finding
a magic bullet that would solve this problem once and for all.

If the consensus is that we should rely on the S/MIME group to resolve
this issue, I will go along, but I am uncomfortable, as I believe this is a core
PKIX issue, and should not be relegated to a group dedicated to only one
protocol. I don't mean to slight their competance, only their scope, and the
degree to which other groups may or may not be inclined to follow their lead.

I WOULD recommend that if we agree to defer to the S/MIME group to solve
this problme, that we record the final decision within the PKIX document,
so it will be more likely to be read and followed by other groups.

Bob

>Bob,
>
>You are raising a valid point, but IMO the solution to the problem is
>NOT to change the SIGNED macro. This problem is currently being debated
>in the smime working group while discussing the document "Cryptographic
>Message Syntax".
>
>Some changes to the document draft-ietf-smime-cms-03.txt are being
>considered and discussed, i.e. the addition of an attribute in the
>section 11 (Useful Attributes) on page 23. This document will not only
>apply to S/MIME but to other contexts as well.
>
>Please switch to the smime mailing list to participate (as I did).
>
>I propose(d) to open a time slot in the pkix agenda so that we can
>report the status of the discussion of the smime group to the pkix group
>during the LA meeting.
>
>Denis

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 17 Mar 1998 07:39:17 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Dave,

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, March 17, 1998 6:37 AM
Subject: Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts

>> From: Warwick Ford <[email-masked]>
>>
>> I think it is time we regained decorum as a group.
>
>
>Decorum is good, no doubt about it.
>
>However, regardless of whether you believe other working groups have
>conducted themselves in a decorous manner, the precedent for competing
>drafts has been set.  For how long were there two competing drafts
>for the replacement of SSL in the TLS WG?  For how long were there three
>competing drafts for a key management protocol in the IPSEC WG?
>How many secure email protocols does the IETF currently sponsor?
>It's probably unnecessary to point out that PKIX had for several years
>a single managment protocol before a competing draft emerged.
>

Fair enough, but in this particular case our differences are minor relative
to that which we can agree on, and resolveable at that.  ASN.1 in OCSP has
now been vigorously defended in public.  That was not the case during the
D.C. IETF nor was there any substantive debate on the issue on the list
coming out of D.C.  I'm prepared at this point to move the existing OCSP
draft forward to meet the WG's consensus, to establish a single draft we can
all work towards.

>Sometimes a single set of editors working hard to achieve consensus is
>the most efficient approach; sometimes that approach apparently does
>not meet the needs of all stakeholders, and a start-from-scratch
>proposal is the best way of focusing discussion.  I've heard "put up
>or shut up" more than once in various Working Groups. Interoperability
>considerations, IESG guidelines, and the best interests of all involved
>nearly guarantee that in the end, a single protocol will make it to
>Full Standard.  That's what matters.

Well, in defense, the alternative draft is not a start-from-scratch
approach.  It's more or less the existing text with ASN.1 instead of ABNF.
Having gotten past the ASN.1 debate, this is why I'm confident we can arrive
at a single draft in very short order.

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Tue, 17 Mar 1998 10:07: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: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

I believe that the protocols defined in the Notary Protocols Internet
Draft (draft-adams-notary-01.txt) can be implemented without infringing
any intellectual property for which Entrust has, or has applied for,
patent protection.  Should this situation change in the future, we would
be willing to license the technology on fair and reasonable terms.

        Robert Zuccherato
        Entrust Technologies

>----------
>From:  John Pawling[SMTP:[email-masked]]
>Sent:  Tuesday, March 10, 1998 2:35 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] New Notary Protocol Draft
>
>All,
>
>Does anybody have a patent regarding the protocols described in the Notary
>Protocols I-D (draft-adams-notary-01.txt)??  Is there anybody who is in the
>process of applying for a patent regarding the Notary Protocols described in
>the draft??  Is there anybody that believes that he/she/it has intellectual
>property in this area and plans to apply for a patent regarding the Notary
>Protocols described in the draft??
>
>================================
>John Pawling
>[email-masked]
>J.G. Van Dyke & Associates, Inc.
>================================
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 17 Mar 1998 09:20:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

> From: Warwick Ford <[email-masked]>
>
> I think it is time we regained decorum as a group.

Decorum is good, no doubt about it.

However, regardless of whether you believe other working groups have
conducted themselves in a decorous manner, the precedent for competing
drafts has been set.  For how long were there two competing drafts
for the replacement of SSL in the TLS WG?  For how long were there three
competing drafts for a key management protocol in the IPSEC WG?
How many secure email protocols does the IETF currently sponsor?
It's probably unnecessary to point out that PKIX had for several years
a single managment protocol before a competing draft emerged.

Sometimes a single set of editors working hard to achieve consensus is
the most efficient approach; sometimes that approach apparently does
not meet the needs of all stakeholders, and a start-from-scratch
proposal is the best way of focusing discussion.  I've heard "put up
or shut up" more than once in various Working Groups. Interoperability
considerations, IESG guidelines, and the best interests of all involved
nearly guarantee that in the end, a single protocol will make it to
Full Standard.  That's what matters.

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Tue, 17 Mar 1998 14:35:02 -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] Cryptographic binding of certificates to signatures
To: [email-masked]

Bob,

You are raising a valid point, but IMO the solution to the problem is
NOT to change the SIGNED macro. This problem is currently being debated
in the smime working group while discussing the document "Cryptographic
Message Syntax".

Some changes to the document draft-ietf-smime-cms-03.txt are being
considered and discussed, i.e. the addition of an attribute in the
section 11 (Useful Attributes) on page 23. This document will not only
apply to S/MIME but to other contexts as well.

Please switch to the smime mailing list to participate (as I did).

I propose(d) to open a time slot in the pkix agenda so that we can
report the status of the discussion of the smime group to the pkix group
during the LA meeting.

Denis

> Lars,
>
> What I'm about to say may seem arrogant, but we got to this point
> despite the fact that a lot of pretty bright and involved people,
> including some real security experts -- how shall I say it --
> basically blew it on this point.  The basic SIGNED macro was
> perhaps OK for verifying X.500 directory access, but not
> good enough for signing documents. (I'm including myself in
> the list of people to blame, if not the other attributes.)
>
> That being the case, I have to say that I have a MUCH lower
> level of trust in protocol designers who are not necessarily
> security experts, but are rather experts in their particular
> protocol expertise.  Some of course will get it right.  But
> some won't.
>
> As I said in the answer to another note, we frequently rush
> to get something working, fully intending to come back and
> fix it, only to find out that the budgets have been cut, other
> priorities have arisen, etc., etc. Hoyt Kesterson tells an
> amusing but wry story tracing the width of railroad tracks
> in the US to the de facto standards for ox-drawn wagons in the
> Roman empire.
>
> So even though changing ANYTHING inevitably causes some
> pain and incompatibility, it is no worse than the RSA/DSA
> compatibility issue.  As soon as some minimal level of use
> occurs, applications will very quickly adopt the new algorithm,
> and the pain will be over.
>
> As the Texaco advertisement used to say, "You can pay me now,
> or you can pay me later."  I know everyone thinks that there would
> be too great an impact to change things now, but in reality,
> even SSL is seeing VERY limited use so far, S/MIME is
> just beginning to emerge, and IPSEC is still on the horizon.
> We could certainly fix these problems now, at a negligible cost
> compared to fixing it later on.
>
> Remember when everyone used to think that all of the programs
> that were coded using a two digit date would be obsolete and long
> gone before the year 2000 rolled around?
>
> Bob

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 17 Mar 1998 00:40:21 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Cryptographic binding of certificates tosignatures
Comments: To: [email-masked]
To: [email-masked]

Lars,

What I'm about to say may seem arrogant, but we got to this point
despite the fact that a lot of pretty bright and involved people,
including some real security experts -- how shall I say it --
basically blew it on this point.  The basic SIGNED macro was
perhaps OK for verifying X.500 directory access, but not
good enough for signing documents. (I'm including myself in
the list of people to blame, if not the other attributes.)

That being the case, I have to say that I have a MUCH lower
level of trust in protocol designers who are not necessarily
security experts, but are rather experts in their particular
protocol expertise.  Some of course will get it right.  But
some won't.

As I said in the answer to another note, we frequently rush
to get something working, fully intending to come back and
fix it, only to find out that the budgets have been cut, other
priorities have arisen, etc., etc. Hoyt Kesterson tells an
amusing but wry story tracing the width of railroad tracks
in the US to the de facto standards for ox-drawn wagons in the
Roman empire.

So even though changing ANYTHING inevitably causes some
pain and incompatibility, it is no worse than the RSA/DSA
compatibility issue.  As soon as some minimal level of use
occurs, applications will very quickly adopt the new algorithm,
and the pain will be over.

As the Texaco advertisement used to say, "You can pay me now,
or you can pay me later."  I know everyone thinks that there would
be too great an impact to change things now, but in reality,
even SSL is seeing VERY limited use so far, S/MIME is
just beginning to emerge, and IPSEC is still on the horizon.
We could certainly fix these problems now, at a negligible cost
compared to fixing it later on.

Remember when everyone used to think that all of the programs
that were coded using a two digit date would be obsolete and long
gone before the year 2000 rolled around?

Bob

>>> <[email-masked]> 03/16 1:54 AM >>>
Bob,

[email-masked] wrote:
>
> Lars, I appreciate your "European" hard-token perspective.
> Certainly, how the keys are generated and how they are
> incorporated into certificates can substantially change the risks.

Right, thanks for your appreciation!

> Just to clarify one thing however. Although I mentioned the
> possibility of changing the SIGNED macro, it was only to
> highlight the original source of the problem. I realize that changing
> the basic definition at this time is probably not a viable
> possibility.
>
> However, my final recommendation and conclusion was that we
> consider creating a new set of signature algorithm IDs that would
> end up using RSA, DSA, etc., but would also include additional
> information such as the issuerName and serial number, or perhaps
> just a hash of the certificate, so that the certificate to be used
> is irrevocably tied to the signed text.

Ok, so that would allow some protocols to switch over by using the
new set of algorithm IDs while others can continue using the old ones.

That doesn't change my original criticism however. What may seem
as an improvement in flexibility is really just going back to the original
situation (with some "safe" protocols using the new set of algorithm
IDs and other protocols still being "unsafe"). Why then not leave this
to the protocol designers or, as I suggested, to the key holder and
relying party?

> I also mention the desirability of including some additional information
> such as date/time and possibly the identity of the platform on which
> the signature was applied, for audit purposes.

I can think of many different information fileds that can be useful. Let me
just give you one example: Charcter set coding. Suppose that I sign a
document and include my certificate serial number '123' and later
discover that I'd rather liked to have used the certificate with serial
number '342'. Well then I could try to claim in court that I actually used
the special "Swahilian ASCII coding" (or something like that), where
3=49, 4=50 and 2=51. (There's no limit to my imagination of the usefulness
of this technique ;-).

My point is that we shouldn't put any restrictions to what must be included
in a signature (unless it's really cryptographically relevant like randomness
and formatting for example). If we do, then we'll most certainly run in to the
situation where we find that the standard is too limited. Again, let
this thing be
taken care of by the application designers!

> (You might be particularly interested in the later, from your hard-token
> perspective. Assuming that the token only generates the signature, and
> maybe the message digest that goes into it, the token has no way of
> knowing what the user saw on the screen that was supposed to be
> signed, as opposed to what the application actually presented to be signed.
> Unless the token is limited to only signing once per insertion, a rogue
> merchant could cause the token to sign all sorts of things, while the
> user thinks that she is only buying a dishrag. Including an authenticated
> identification of the platform would help point a smoking gun in such cases.)

Actually, I'm not interested in that possibility. My primary interest
is to have a
common PKI for both smart cards and soft tokens. If smart cards should use
a different signature algorithm than everyone else, it would be a bad thing.

> Other people may have their own pet ideas which should be considered.
> For example, I foresee a time in the relatively near future where
biometrics will
> be combined with digital signatures to circumvent some of the control issues
> that neither a password encrypted key nor a smart token solve, since
either can
> be given away.  It would no doubt be very useful to incorporate the biometric
> indicia into the signature itself, so that it would later be
validated against
> the biometric template included in the certificate. Without
supporting such a
> basic mechanism now, while the industry is still in the process of
writing lots of
> new applications, adding such features would require modifications to
a very large
> number of individual applications -- an almost hopeless task.

Spooky, indeed!

> But I'm not trying at this time to suggest precisely what ancillary
information
> should be included. We are still trying to sort out whether it should be
> done at all. Of course, even if a new signature algorithm ID is
> defined, it doesn't have to be used, so it would be optional from that
> standpoint. For the sake of interoperability, however, it would be a new
> algorithm that would have to be widely supported, unless we can figure
> out a mechanism for making the additional parameters transparent.
>
> I do believe that specifying the suite of signature algorithms that are to be
> supported is one of the functions of this group, so I believe the
discussion is
> appropriate for this list.

Well, I disagree on this point. Let's have the standards finished as soon as
possible so we can start using them. They may not be perfect but we must
remember that there's no such thing as absolute security (unless of course
you don't communicate at all :-).

Kind regards,
/Lars Johansson
Sweden Post

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 17 Mar 1998 00:04:17 -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] RFC 822 names in SubjectAltName and otherextensions
Comments: To: [email-masked]
To: [email-masked]

>>> Dean Povey <[email-masked]> 03/16 2:47 PM >>>
>
>There is a 5th option, create a non-critical comment extension:
>
>id-ce-comment OBJECT IDENTIFIER ::= { ... }
>
>Comment ::= SEQUENCE OF Extension
>
>The Comment Extension has the semantics that anything defined under the
>Comment extension is not verified.
>
>Just my $0.02.
>

Dean, I think this is an excellent idea.  One technical ASN.1 question --
this would allow a particular extension to be a Comment in one
certificate, and not a comment in another certificate. Correct?

However, the context of the original discussion, the RFC822
names, has skewed the discussion somewhat.

To my way of thinking, Nonverified Subscriber Information is not just
a comment -- semantic sugar -- but a legally (presumably) binding
representation made by the Subscriber to the CA, which, however, the
CA is not in a position to independently verify at an economical cost.
So I would not like to see the extension labeled as Comment.

nonverifiedSubscriberInformation is a bit cumbersome, but fortunately
we don't have to DER-encode the attribute names!

A couple of other comments:

I agree that trying to define an attribute that is partially verified and partially
not verified is a recipe for disaster.  Unfortunately, rather than following
the original layout of names proposed in X.521 and the original x.500
implementations, most certificate generation programs (and browsers, etc.)
are rather brain-dead, and tend to seriously overload commonName.

So if someone wants a certificate that includes their honors and degrees,
today they would almost be forced to use something like
commonName="Sir John Smith, MD, Ph.D., Esq., Realtor"

Now, should the CA be required to verify that Mr. Smith has been
knighted (by the Queen of which country?), and has a valid
medical degree, Ph.D., law degree, and is a licensed Realtor?

Generally speaking, I would think not, although some CA might of course
define a certificate class where they would perform such due diligence
diligence.

The better way would be to break out the commonName from
the titles, honors, degrees, generational qualifiers, etc., and allow
people to make representations regarding their honors and degrees
without requiring that the CA independently validate them.

Following this line of reasoning, we should break up the RFC822 name into
two components, the verified e-mail address, and the comment field.

In this case, the name "comment" is perhaps appropriate based
on the terminology of RFC822, but I would still feel that the
comment field should constitute a representation made to
the CA, and not just something of no consequence.

In other words, even if the CA doesn't verify the comment portion,
I should not be able to list someone else's name without running
a serious risk of being sued for misrepresentation.  It might be
a little more difficult to track me down, but if I mislead someone, I
ought to expect to be held accountable for such an act.

Bob

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 16 Mar 1998 21:48: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:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
Comments: To: [email-masked]
To: [email-masked]

Mike,

Since I respect you personally and professionally, I won't comment
on whether your horse has feathers and/or can fly. :-)

However, I'd like to reiterate some of the comments that I have
made in the past, while acknowledging that I have not had the time
to become really substantially involved in the overall subject:

1.  I would GREATLY prefer a common syntax.  Anyone processing
certificates necessarily has some kind of ASN.1 capability, whether
based on a commercial compiler or some home-grown tools. Adding
another syntax virtually guarantees adding another set of tools, for
which high-quality commercial tools may not be available.  I simply
don't understand the "thin client" issue.  We haven't even mentioned
Java, but that is another option, and certainly Java will have ASN.1 tools
available.

2. Since Sead Mufit and I originally pointed out that the entire CRL
notion was outmoded and rather brain dead (four or so years ago,
on the PEM list), I have been arguing that we do NOT need
a certificate status checking protocol, NOR to we need a notary
protocol.  What we DO need is a combination of the two that would
allow a relying party to submit a digital signature and either the
certificates themselves or a reference to them, and have the CA
(or a Repository or other TTP) simply bind the certificate status
to the digital signature, thereby avoiding the entire comparison of
clocks, separately time-stamping the document and the CRLs,
etc., etc.

3. In addition to validating the digital signature, it would be very useful
to support the use of the insurance model, whereby the relying party
declares a assessed valuation and declares a willingness to pay
a standard proportional fee for well-defined Errors and Omissions
insurance against a screw up by the CA, or potentially a compromise
of the signer's keys.

Unfortunately, I do not seem to have been sufficiently persuasive, as
to the best of my knowledge neither the OCSP nor the notary protocol
has embraced these principles.  For this reason, I cannot get at all excited
about implementing either of the two protocols.

As I said, I have not been able to follow all of the discussion, or read
all of the drafts, so if I have misunderstood or missed something, I will
be happy to retract the above conclusions.  But for now, I would vote
against progressing the current drafts any further along the standards track.

Sometimes there seems to such a great rush to get something available
right now, despite known problems, assuming we can fix it later.
Unfortunately, we never seem to get around to the "later".

Bob

Approved-By: [email-masked]
Date:         Mon, 16 Mar 1998 08:54: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: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and otherextensions
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: [email-masked]

Doesn't the liability for the binding of all information in the signed objects come back to haunt the  CA - even if its (75 page) policy says somewhere that it has not verified some parts of the information it bound to the identity provided by the key pair holder?

I often feel that we are trying to put too much information into the certs and their extensions, so as to make them unworkable.

If we separate the user operations from the "binding", then ancillary information can be added to the directory or database by the certificate holder under signed conditions.  This way, the liability and responsibility for the correctness of the information stays with the person verifying it (the holder).

I posit that any necessary information to be provided to the directory/database by the customer can best be done AFTER the cert is issued and the cert holder has digital signing capability.

Michael

>>> "David P. Kemp" <[email-masked]> 03/16/98 07:49AM >>>
> From: Robert Jueneman <[email-masked]>
>
> Steve, I agree with that burying Non-verified Subscriber Informatioon (NVI/ NSI?) in a CPS won't do.  But on the other hand, there is a clear and compelling need for NSI, especially for proprietary attributes.
>
> It would certainly be nice if we had a convenient indicator, much like the Critical indicator.
>
> Perhaps someone can think of a good way of extending the standard to facilitate this?

Bob,

I agree too that there should be a way to indicate "comment" information
that is either not verified by the CA or not intended to be acted upon
(enforced) by the relying party.   X.509 apparently recognizes this need
too; unfortunately the mechanism chosen to implement it was to overload
the meaning of the CRITICAL extension bit.

The CRITICAL bit was originally intended (when unset) to allow
implementations which do not understand a particular extension to use
the remainder of the certificate in which it appears.  However, the
description of several extensions now use that bit to modify the
meaning of the particular extension in implementations which *do*
support it.

I don't know of a good way of extending the standard to facilitate the
inclusion of Non-Verified or Non-mandatory information in certificates,
but can think of four ways with varying degrees of badness:

* Define the v4 Extension syntax to include both a CRITICAL
  bit and a COMMENT bit.  This would be non-backward compatible in
  the same sense that v3 is not compatible with v1 - the COMMENT
  bit would be DEFAULT FALSE and v4 would not be used unless some
  extension had it set TRUE.  It's probably unthinkable to do a
  version rev at this point - forget I mentioned it :-).

* Redefine the syntax of each extension (such as subjectAltName) to
  include a NVI/COMMENT/NON-REQUIRED bit, superceding the OIDs for
  the existing extensions.

* Define duplicate parallel extension OIDs, (such as subjectAltName
  and nvSubjectAltName) to denote verified/mandatory and non-verified/
  optional information.

* Continue along the current path, and overload the CRITICAL bit
  to modify the extension's meaning.  In the case of subjectAltName,
  this would not allow one portion of an RFC822 name to be verified
  and another to be non-verified; the entire extension would have the
  same status, and there can be only one instance of that extension in
  a certificate.
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!

Approved-By: [email-masked]
Date:         Mon, 16 Mar 1998 09:34:18 PST
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: Tirthankar Barari <[email-masked]>
Subject:      [IETF-PKIX] Comments on sixth draft of IPKI X.509 Certificate and CRL Profile
Comments: cc: [email-masked]
To: [email-masked]

I wanted to share my thoughts, stated below, on the
sixth draft of the Internet Public Key Infrastructure
X.509 Certificate and CRL Profile.

In section 4.2.1.2 on Subject Key Identifier, it is defined that :

   "The subject key identifier extension provides a means of identifying
   the particular public key used in an application.  Where a reference
   to a public key identifier is needed (as with an Authority Key
   Identifier) and one is not included in the associated certificate, a
   SHA-1 hash of the subject public key shall be used."

Now, it may so happen that in the Certificate path:

One CA’s  SHA-1 hash of the subject public key  matches, octet by octet,
the SubjectKeyIdentifier of another CA, in the chain, (who choose to
insert an octet string from its own imagination into the
SubjectKeyIdentifier field).

In this case, the uniqueness of the keyIdentifier field is lost.

However, if key identifier And issuer name And serial number are present
in the authority key identifier extension, then the above problem is
resolved.

Hence, I think that the following line in section 4.2.1.1

   "The identification can be based on either the key identifier (the
   subject key identifier in the issuer's certificate) or on the issuer
   name and serial number."

should be modified to :

"The identification can be based on either the key identifier (the
   subject key identifier in the issuer's certificate) or on the issuer
   name and serial number or on the key identifier and issuer name
  and serial number."

and the ASN1 definition of AuthorityKeyIdentifier modified accordingly.

Let me know if more clarification is needed. Also, please send your
comments.

Thanks.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Approved-By:  Warwick Ford <[email-masked]>
Date:         Mon, 16 Mar 1998 21:17:53 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Paul:

This posting is about as unhelpful as they can get.  Other actions and
comments by various list members recently are also highly questionable, and
I think it is time we regained decorum as a group.

For the benefit of everyone, let me summarize how we traditionaly operate.
Having identified a project (e.g., OCSP) we seek a voluntary editor or
editors to lead the process of creating a first draft then iterating that
draft, taking into account comments from the WG, and endeavoring to steer
the project to a concensus result.  Mike Myers and Rich Ankney have been
jointly filling that role wrt OCSP now for many months, and have put in
enormous efforts to steer this project towards a concensus result in the
face of several non-trivial design tradeoffs.

Flaming the volunteer editors in this way is IMHO totally unacceptable.
Our editors, who put in many more hours on our projects than the
sideliners, deserve respect from all of us.

Almost as unhelpful is the approach taken by some list members to produce a
"competing draft" for OCSP.  The pre-existing OCSP document has already
been through many iterations, reflecting many concensus-reaching decisions.
 The correct approach to making changes to the OCSP design at this stage is
to sumbit a contribution that proposes changes to the current draft,
providing rationale for such changes.  The issues are then debated on the
list.  This iterative procedure has always worked in the past and taking
any other approach could set a most undesirable precedent.

I propose that the "competing draft" be recast as a specific set of change
proposals to OCSP, along with rationale for each.  Then let's try to
quickly reach concensus on each point, acting in a grown-up and
professional manner.

Warwick

At 09:19 AM 3/16/98 -0800, Paul Hoffman / IMC wrote:
>Mike:
>
>I would like to add another "horsefeathers" to Dave's comments:
>
>>First, OCSP is on the standards track.
>
>Horsefeathers. Nothing is on standards track until it has achieved working
>group consensus, gone through working group last call, gone through IESG
>last call, and been published. OCSP is *far* from that.
>
>You have steadfastly refused to acknowledge working group consensus on the
>use of ASN.1. This alone is enough to keep it from getting through working
>group last call, much less on standards track. If you don't have the
>consensus of the working group, and it appears you don't, the draft is as
>good as dead, and an alternative draft can be inserted in its place.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>
>
******** PLEASE NOTE NEW CONTACT DETAILS ********
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 16 Mar 1998 17:49:17 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] OCSP alternative comments
To: [email-masked]

Ambarish, Colleagues:

Never a dull moment in PKIX!

Setting aside ASN.1 debate for a moment, I have one concern regarding the
suitability of this proposal to today's business practices.

The requirement that "The certificate of an Authorized RCSP Responder cannot
be revoked."  is simply too dangerous to be implemented.  The proposal
appears to anticipate this problem by asserting that the certificate be
maintained on a very short validity period.  This approach however has at
least four fatal flaws:

1.  There is no means proposed whereby this certificate would be updated.
Thus the proposal is incomplete; it cannot be implemented as written.

2.  Even is such a means were well-defined, the proposal suffers serious
scalability problems due to the frequent need to update the special
certificate.  Assume the period is two weeks.  Further assume for the sake
of concreteness that this mechanism is being used to support a Bank's
customers.   Every two weeks each of those customers will need to make
contact with a key management center, download the new certificate, install
it, review practices disclaimers, click on several buttons etc. etc. All
that pain every two weeks.  Or four weeks.  For every relying party wishing
to do business with the bank.  Now multiply that scenario by a given number
of banks; by the number of branch offices in a major corporation; by the
Internet.  Definitely not a success scenario in my opinion.

3.  This key management cycle reduces public key infrastructure to the same
key management discipline that was used for symmetric key management.  The
proposal thus takes a giant step backward against the progress we've
currently
made on PKI architecture suitable for the Internet.

4.  Most importantly, it provides no means to bound the risks of key
compromise.  A lot can happen in two to four weeks.  Compromise of the
trusted responder key could, among other things, enable previously revoked
subscribers to appear to be be re-established.

However, this role-based certificate is analogous to certificates used to
authorize LRAs, MLAs and other abstract roles.  Would it not be the case
that this certificate could and indeed should be listed on a CRL?  This CRL
could be maintained separate from other CRLs via an CRL extension to
identify
the purpose of the CRL.  This would be necessary to prevent the common CRL
suppression attack.  There is no reason at all why one can't combine
techniques to deliver an integrated solution.

Mike

-----Original Message-----
From: Ambarish Malpani <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, March 16, 1998 2:37 PM
Subject: [IETF-PKIX] New Draft for Checking the Status of a Certificate -
RCSP

>Hi PKIX-land,
>
>    This message is to announce the existance of the draft:
>
>"Internet Public Key Infrastructure Real Time Certificate Status
>Protocol - RCSP", C. Adams, Ambarish Malpani, Rich Ankney, Slava
>Galperin, 03/13/1998. (22007 bytes)
>
>You can find it at:
>
>ftp://ietf.org/internet-drafts/draft-malpani-rcsp-00.txt
>
>It uses ASN.1 and fixes a bunch of other issues with OCSP.
>Some of the main fixes are:
>- uses ASN.1
>- it is independent of the transport layer
>- allows checking of multiple certs/cert chains in a single query
>- supports multiple response types
>- supports a better way of identifying certificates
>- talks explicitly about revoked/non-revoked rather than valid/invalid
>- clearly identifies who is authorized to respond to requests and
>    how you can identify responders.
>
>
>I would like to hear comments about it and people's feeling of
>whether this addresses their needs better than OCSP.
>
>Thanks,
>Ambarish
>
>--
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect                                              (650) 849-9880
>ValiCert, Inc.                                  [email-masked]
>3160 W. Bayshore Road                         http://www.valicert.com
>Palo Alto, CA 94303
>

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Mon, 16 Mar 1998 14:17:46 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] New Draft for Checking the Status of a Certificate - RCSP
To: [email-masked]

Hi PKIX-land,

    This message is to announce the existance of the draft:

"Internet Public Key Infrastructure Real Time Certificate Status
Protocol - RCSP", C. Adams, Ambarish Malpani, Rich Ankney, Slava
Galperin, 03/13/1998. (22007 bytes)

You can find it at:

ftp://ietf.org/internet-drafts/draft-malpani-rcsp-00.txt

It uses ASN.1 and fixes a bunch of other issues with OCSP.
Some of the main fixes are:
- uses ASN.1
- it is independent of the transport layer
- allows checking of multiple certs/cert chains in a single query
- supports multiple response types
- supports a better way of identifying certificates
- talks explicitly about revoked/non-revoked rather than valid/invalid
- clearly identifies who is authorized to respond to requests and
    how you can identify responders.

I would like to hear comments about it and people's feeling of
whether this addresses their needs better than OCSP.

Thanks,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Dean Povey <[email-masked]>
Date:         Tue, 17 Mar 1998 07:47:08 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dean Povey <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

>I don't know of a good way of extending the standard to facilitate the
>inclusion of Non-Verified or Non-mandatory information in certificates,
>but can think of four ways with varying degrees of badness:
>
>* Define the v4 Extension syntax to include both a CRITICAL
>  bit and a COMMENT bit.  This would be non-backward compatible in
>  the same sense that v3 is not compatible with v1 - the COMMENT
>  bit would be DEFAULT FALSE and v4 would not be used unless some
>  extension had it set TRUE.  It's probably unthinkable to do a
>  version rev at this point - forget I mentioned it :-).
>
>* Redefine the syntax of each extension (such as subjectAltName) to
>  include a NVI/COMMENT/NON-REQUIRED bit, superceding the OIDs for
>  the existing extensions.
>
>* Define duplicate parallel extension OIDs, (such as subjectAltName
>  and nvSubjectAltName) to denote verified/mandatory and non-verified/
>  optional information.
>
>* Continue along the current path, and overload the CRITICAL bit
>  to modify the extension's meaning.  In the case of subjectAltName,
>  this would not allow one portion of an RFC822 name to be verified
>  and another to be non-verified; the entire extension would have the
>  same status, and there can be only one instance of that extension in
>  a certificate.

There is a 5th option, create a non-critical comment extension:

id-ce-comment OBJECT IDENTIFIER ::= { ... }

Comment ::= SEQUENCE OF Extension

The Comment Extension has the semantics that anything defined under the
Comment extension is not verified.

Just my $0.02.

--
Dean Povey,                             |  Email: [email-masked]
Research Scientist, Security Unit,      |  Phone: +61 7 3864 2799
CRC for Distributed Systems Technology  |  Fax:   +61 7 3864 1282
Brisbane, Australia                     |  http://www.dstc.qut.edu.au/MSU/

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 16 Mar 1998 12:45:57 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName
To: [email-masked]

>The type of verification
>a CA does on a name is fundamentally different than what it does on an
>SMTP address, regardless of whether one is stronger than the other.

Quite right.

>If the CPS states that an entire attribute is verified, it seems
>inconsistent to have the two parts of a single attribute verified using
>separate procedures.

It doesn't seem inconsistent to me. Are you saying that if a CPS says "We
have verified the following two attributes: common name and email address",
you would find that inconsistent?

>  If the procedures are "equivalent" strength,
>there may not be a problem.

Ah, I think I see the problem. A CPS says what attributes it will vouch
for, and might say how the CA chooses to make this trust. These are two
different issues. An end entity MUST care about what is assured, and SHOULD
care about how that assurance comes about. However, if both the common name
and the email address are vouched for, it shouldn't matter if the common
name appears as part of the email address attribute, nor should it matter
if it doesn't. That is, the end entity takes the set of what is assured and
trusts that (and, hopefully, trusts only that).

The rfc822Name isn't the only type that will have the problem you see.
otherName and EDIPartyName will as well. These are all two-part names where
each part can be verified using very different methods. However, all three
can have the parts be equally assured because the CA trusts whoever
presented the credentials for the attribute. A CPS that says "we trust
these attributes because we know the person, and he wouldn't lie to us" is
a perfectly valid CPS, and one that most corporate CAs would issue.

I don't want PKIX to go down the slippery slope (into the slimy slop) of
saying how to verify the contents of the attributes. How would you "verify"
a uniformResourceIdentifier? An iPAddress? A dNSName? Requiring these be
"verified", as compared to "vouched for", is impossible and therefore
confusing to end users.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 16 Mar 1998 14:34: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName
To: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
>
> I think it would be a good idea to add words to this such as:
>
> To avoid confusion, a CPS should say which attributes of a certificate have
> been verified. Further, a CPS should not state that only part of any
> attribute is verified; either the entire attribute is verified, or none of
> the attribute is verified. This is particularly important for attributes
> with rfc822Name values, since the two parts of the value can be validated
> in different fashions, and many CAs will choose not to validate one part or
> the other.

This goes a long way in the right direction, but I'm still worried that
a full rfc822Name is a mixed-mode expression.  The type of verification
a CA does on a name is fundamentally different than what it does on an
SMTP address, regardless of whether one is stronger than the other.

If the CPS states that an entire attribute is verified, it seems
inconsistent to have the two parts of a single attribute verified using
separate procedures.  If the procedures are "equivalent" strength,
there may not be a problem.

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 16 Mar 1998 09:31:52 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and
To: [email-masked]

>In the "normal" case, where the CA does some validation of the address
>but no validation of the name,

I completely disagree that this is the "normal" case, or that it should be
assumed to be inthe future.

> there is no reason to include the name
>comment in the certificate.  Mail user agents are free to include
>copies of To:/From: headers, including names, in the signed portion of
>the message.

...and should be free to include a verified name in any appropriate and
verified part of the cert.

The proposal to disallow putting the common name in the 822 address is
orthogonal to the proposal that we should assume that no one reads the CPS.
If you don't read the CPS, then you must assume that all fields are
unverified. If you read the CPS, then you should assume that only the
fields listed in the CPS as verified are verified. If a CPS says "all parts
of the 822 name are verified", then it is silly for us to tell CA makers
that they can't use a valid RFC 822 address there.

Section 2.0 of the draft is quite clear on this:
   A certificate user should review the certification practice Statement
   (CPS) generated by the CA before relying on the authentication or
   non-repudiation services associated with the public key in a
   particular certificate.  To this end, this standard does not
   prescribe legally binding rules or duties.

I think it would be a good idea to add words to this such as:

To avoid confusion, a CPS should say which attributes of a certificate have
been verified. Further, a CPS should not state that only part of any
attribute is verified; either the entire attribute is verified, or none of
the attribute is verified. This is particularly important for attributes
with rfc822Name values, since the two parts of the value can be validated
in different fashions, and many CAs will choose not to validate one part or
the other.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 16 Mar 1998 09:19:05 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Mike:

I would like to add another "horsefeathers" to Dave's comments:

>First, OCSP is on the standards track.

Horsefeathers. Nothing is on standards track until it has achieved working
group consensus, gone through working group last call, gone through IESG
last call, and been published. OCSP is *far* from that.

You have steadfastly refused to acknowledge working group consensus on the
use of ASN.1. This alone is enough to keep it from getting through working
group last call, much less on standards track. If you don't have the
consensus of the working group, and it appears you don't, the draft is as
good as dead, and an alternative draft can be inserted in its place.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Rich Salz <[email-masked]>
Date:         Mon, 16 Mar 1998 12:05:51 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Rich Salz <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

>I would love to see a code-size bakeoff between OCSPs; I am conviced
>that Malpani OCSP would fit into a smartcard or palmtop with more room
>and cycles to spare than Myers/Ankney OCSP.

A tempting question, but not one that can be answered.

Many smartcards already have ASN1 and PKCS libraries.
Many web servers and browsers already have HTTP and BASE64 libraries.

And of course, some of each have some of all of the above. :)

My OCSP server implementation is about 50 lines of code, FWIW.
        /r$

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 16 Mar 1998 11:52:31 -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] RFC 822 names in SubjectAltName and
To: [email-masked]

other extensions
X-Sun-Charset: US-ASCII

> From: Mike Smith <[email-masked]>
>
> I often feel that we are trying to put too much information into the certs and their extensions, so as to make them unworkable.
>
> If we separate the user operations from the "binding", then ancillary information can be added to the directory or database by the certificate holder under signed conditions.  This way, the liability and responsibility for the correctness of the information stays with the person verifying it (the holder).
>
> I posit that any necessary information to be provided to the directory/database by the customer can best be done AFTER the cert is issued and the cert holder has digital signing capability.

This is an excellent argument in favor of including only the delivery
address portion of an RFC822 name in certificates.

In the "normal" case, where the CA does some validation of the address
but no validation of the name, there is no reason to include the name
comment in the certificate.  Mail user agents are free to include
copies of To:/From: headers, including names, in the signed portion of
the message.

As Steve pointed out, if the CA verifies a name, it is possible to
include it in a Common Name.  I side with those who believe that
it is less confusing to always put a common name (if verified by the
CA) into the subject Name field, and include only the address in an
RFC822 name.

Approved-By:  Peter Lipp <[email-masked]>
Date:         Mon, 16 Mar 1998 17:46:28 +0100
Reply-To: Peter Lipp <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Lipp <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

>And I think pretending that a bare email address is verified
>and belongs to the named user is quite an opportunity for confusion.

Agreed. Obviously it might be the case that the comment field can be verified
and the email-adress not.

What I'd like to see is that the full SubjectAltName is verified, i.e. if
it contains a comment that this also is verified - or it's non-verified, then
both parts are not verified. The CPS specifies which way a CA does it.
Mixed-mode seems to be a good source of confusion, and while of course
specifyable in the CPS, I'd rather avoid it.

Peter

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 16 Mar 1998 11:08:02 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

> From: Michael Myers <[email-masked]>
>
> The expressive power of ASN.1 is overkill in this case.  It burdens the
> implementor with a steep learning curve, expensive tools, and delays in
> market access just to gain access to an integer value expressing the current
> state of a certificate's status.

Horsefeathers.  How long has Netscape included the KEYGEN construct in
their product line?

(For those not familiar with KEYGEN, it is a component of FORM which
does ASN.1 encoding of a certification request, Base64 encodes the
result, and includes it in an HTTP name=value response just like all
other application/x-www-form-urlencoded FORM components).

Has the use of KEYGEN produced a steep learning curve, expensive tools,
and delays to market for Netscape or for any CAs which work with
web browser input?

> This issue is not one of thin-client vs. full client but more with the
> fundamental problem being addressed and a rational balance
> between that problem's scope and the tools needed to effect
> its solution.

What kind of "rational balance"?  Isn't a syntax which is simple for
simple cases and incrementally extensible to handle more complex
requirements preferable to one which works only for simple requirements
and succombs to baroqueness when faced with anything else?

I would love to see a code-size bakeoff between OCSPs; I am conviced
that Malpani OCSP would fit into a smartcard or palmtop with more room
and cycles to spare than Myers/Ankney OCSP.

Nonetheless, after speaking with Rich, I am not inclined to suggest
that PKIX endorse the use of Malpani OCSP in lieu of Myers/Ankney
OCSP.  Instead, it may be preferable to use the Notary protocol,
perhaps with components of Malpani OCSP rolled in, as a vehicle for
both simple and extended validation requirements.  For online use with
HTTP/TLS, the Notary protocol messages can be neatly encapsulated as
Ambarish suggests, while still being usable over other
transport/protection mechanisms such as SMTP/CMS.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 16 Mar 1998 09:49:02 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

> From: Robert Jueneman <[email-masked]>
>
> Steve, I agree with that burying Non-verified Subscriber Informatioon (NVI/ NSI?) in a CPS won't do.  But on the other hand, there is a clear and compelling need for NSI, especially for proprietary attributes.
>
> It would certainly be nice if we had a convenient indicator, much like the Critical indicator.
>
> Perhaps someone can think of a good way of extending the standard to facilitate this?

Bob,

I agree too that there should be a way to indicate "comment" information
that is either not verified by the CA or not intended to be acted upon
(enforced) by the relying party.   X.509 apparently recognizes this need
too; unfortunately the mechanism chosen to implement it was to overload
the meaning of the CRITICAL extension bit.

The CRITICAL bit was originally intended (when unset) to allow
implementations which do not understand a particular extension to use
the remainder of the certificate in which it appears.  However, the
description of several extensions now use that bit to modify the
meaning of the particular extension in implementations which *do*
support it.

I don't know of a good way of extending the standard to facilitate the
inclusion of Non-Verified or Non-mandatory information in certificates,
but can think of four ways with varying degrees of badness:

* Define the v4 Extension syntax to include both a CRITICAL
  bit and a COMMENT bit.  This would be non-backward compatible in
  the same sense that v3 is not compatible with v1 - the COMMENT
  bit would be DEFAULT FALSE and v4 would not be used unless some
  extension had it set TRUE.  It's probably unthinkable to do a
  version rev at this point - forget I mentioned it :-).

* Redefine the syntax of each extension (such as subjectAltName) to
  include a NVI/COMMENT/NON-REQUIRED bit, superceding the OIDs for
  the existing extensions.

* Define duplicate parallel extension OIDs, (such as subjectAltName
  and nvSubjectAltName) to denote verified/mandatory and non-verified/
  optional information.

* Continue along the current path, and overload the CRITICAL bit
  to modify the extension's meaning.  In the case of subjectAltName,
  this would not allow one portion of an RFC822 name to be verified
  and another to be non-verified; the entire extension would have the
  same status, and there can be only one instance of that extension in
  a certificate.

Approved-By:  [email-masked]
Date:         Mon, 16 Mar 1998 09:54:07 +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] Cryptographic binding of certificates tosignatures
Comments: cc: [email-masked]
To: [email-masked]

Bob,

[email-masked] wrote:
>
> Lars, I appreciate your "European" hard-token perspective.
> Certainly, how the keys are generated and how they are
> incorporated into certificates can substantially change the risks.

Right, thanks for your appreciation!

> Just to clarify one thing however. Although I mentioned the
> possibility of changing the SIGNED macro, it was only to
> highlight the original source of the problem. I realize that changing
> the basic definition at this time is probably not a viable
> possibility.
>
> However, my final recommendation and conclusion was that we
> consider creating a new set of signature algorithm IDs that would
> end up using RSA, DSA, etc., but would also include additional
> information such as the issuerName and serial number, or perhaps
> just a hash of the certificate, so that the certificate to be used
> is irrevocably tied to the signed text.

Ok, so that would allow some protocols to switch over by using the
new set of algorithm IDs while others can continue using the old ones.

That doesn't change my original criticism however. What may seem
as an improvement in flexibility is really just going back to the original
situation (with some "safe" protocols using the new set of algorithm
IDs and other protocols still being "unsafe"). Why then not leave this
to the protocol designers or, as I suggested, to the key holder and
relying party?

> I also mention the desirability of including some additional information
> such as date/time and possibly the identity of the platform on which
> the signature was applied, for audit purposes.

I can think of many different information fileds that can be useful. Let me
just give you one example: Charcter set coding. Suppose that I sign a
document and include my certificate serial number '123' and later
discover that I'd rather liked to have used the certificate with serial
number '342'. Well then I could try to claim in court that I actually used
the special "Swahilian ASCII coding" (or something like that), where
3=49, 4=50 and 2=51. (There's no limit to my imagination of the usefulness
of this technique ;-).

My point is that we shouldn't put any restrictions to what must be included
in a signature (unless it's really cryptographically relevant like randomness
and formatting for example). If we do, then we'll most certainly run in to the
situation where we find that the standard is too limited. Again, let
this thing be
taken care of by the application designers!

> (You might be particularly interested in the later, from your hard-token
> perspective. Assuming that the token only generates the signature, and
> maybe the message digest that goes into it, the token has no way of
> knowing what the user saw on the screen that was supposed to be
> signed, as opposed to what the application actually presented to be signed.
> Unless the token is limited to only signing once per insertion, a rogue
> merchant could cause the token to sign all sorts of things, while the
> user thinks that she is only buying a dishrag. Including an authenticated
> identification of the platform would help point a smoking gun in such cases.)

Actually, I'm not interested in that possibility. My primary interest
is to have a
common PKI for both smart cards and soft tokens. If smart cards should use
a different signature algorithm than everyone else, it would be a bad thing.

> Other people may have their own pet ideas which should be considered.
> For example, I foresee a time in the relatively near future where
biometrics will
> be combined with digital signatures to circumvent some of the control issues
> that neither a password encrypted key nor a smart token solve, since
either can
> be given away.  It would no doubt be very useful to incorporate the biometric
> indicia into the signature itself, so that it would later be
validated against
> the biometric template included in the certificate. Without
supporting such a
> basic mechanism now, while the industry is still in the process of
writing lots of
> new applications, adding such features would require modifications to
a very large
> number of individual applications -- an almost hopeless task.

Spooky, indeed!

> But I'm not trying at this time to suggest precisely what ancillary
information
> should be included. We are still trying to sort out whether it should be
> done at all. Of course, even if a new signature algorithm ID is
> defined, it doesn't have to be used, so it would be optional from that
> standpoint. For the sake of interoperability, however, it would be a new
> algorithm that would have to be widely supported, unless we can figure
> out a mechanism for making the additional parameters transparent.
>
> I do believe that specifying the suite of signature algorithms that are to be
> supported is one of the functions of this group, so I believe the
discussion is
> appropriate for this list.

Well, I disagree on this point. Let's have the standards finished as soon as
possible so we can start using them. They may not be perfect but we must
remember that there's no such thing as absolute security (unless of course
you don't communicate at all :-).

Kind regards,
/Lars Johansson
Sweden Post

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 16 Mar 1998 09:45:43 -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:      [IETF-PKIX] URLs for CMMF and CMC drafts
To: [email-masked]

> I haven't yet seen any notification to this effect yet but the following two
> drafts are available for review and comment on the IETF web site:

Michael,

The addresses you gave are incorrect. You switched draft and ietf. The
corrected URLs are below.

> -- Certificate Management Message Formats
>       ietf-draft-pkix-cmmf-00.txt

ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-cmmf-00.txt

> -- Certificate Management over CMS
>       ietf-draft-pkix-cmc-00.txt

ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-cmc-00.txt

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  [email-masked]
Date:         Mon, 16 Mar 1998 09:01:21 +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] Multiple certificates for same key?
To: [email-masked]

Dave & Phill,

Some short replies...

[email-masked] wrote:
>
> > From: [email-masked]
> >
> > Some people have argued that there's too many security risks
> > involved when dealing with multiple certificates of the same
> > key that it should be prohibited (or at least not recommended :-).
> > I could give you many reasons why there shouldn't be any such
> > restrictions but let me just give you an alternative perspective.
>
> Please list some reasons for preferring multiple certificates per
> key - that is one of the critical items of information missing from
> the discussion so far.
>
> What precisely are the three or four most important advantages of
> multiple certification of keys?  Saving memory on tokens has already
> been mentioned.

My main point was that something that isn't prohibited should be
permitted. Most of the risks that have been discussed so far can
be handled by the policy. But if you want examples I can give you
some:

Saving memory is a valid reson but it can also be interpreted
as saving money. Setting up a PKI based on smart cards is quite
expensive (believe me) so the more certificates/roles that can be
bound to the same token the better. A lot of people are fed up with
how many different cards they have to carry in their wallet already.

I think everyone on this list sees the need for different certificates
(one being the integrity risks).

> Private key storage mechanisms and multiple certificates are
> separate issues.  When you have one security weakness (software
> key storage) it tends to exacerbate security problems in other
> areas (multiple certification).  But saying (or requiring) keys
> to always be stored on tokens does not make the other problems
> go away.  Sure, the private key(s) cannot be extracted from the
> token without perhaps destructive reverse engineering.  But the
> token can still be used by malicious applications to sign things
> the user didn't intend to have signed.  The only way to prevent
> that is to allow segregation of keys by purpose, and not store
> the sensitive keys on tokens that will be highly exposed.

I tend to agree with you that private key storage and multiple
certificates are somewhat separate issues. Perhaps my original
comment should be rehrased as: the security risks are CA's that
certify locally generated keys without careful checking of the
key holders identity.

Your comment on smart cards is in line with Phill's so I'll answer
them both below.

[email-masked] wrote:
>

[...]

>
> The ambiguity problem is considerably worse with a smart
> card than a soft certificate. The one declarative action that
> is possible with the chip in card format is to insert the device
> into a reader. Any variation in semantics must be captured
> by the terminal - which cannot be considered as secure as
> the card itself.

My intention is not to start a debate on the security of smart cards
vs. soft tokens. And I would definitively not like to suggest that
keys should be to always be stored on tokens. There is a need
for both.

However, as you both point out, there are risks with smart cards
as well (not worse than soft tokens though). There's always
something that you must put your trust on, your local workstation
being one example, but that is no different than with soft tokens.

> On the other hand I don't think we should wire any prohibition
> on dual certification of keys into the standard, the practical
> reason being that such a prohibition could not be enforced.
> People are bound to do it whether or not it is a good idea.
> Therefore it would not be a good thing for clients to rely on
> it not taking place.
>
> If there is not going to be an impact on the specififcation we
> do not need to discuss it.

I'm glad to see that we have the same opinion in this case.
I totally agree with you!

Kind regards,
/Lars Johansson
Sweden Post

Approved-By:  Michael Myers <[email-masked]>
Date:         Sun, 15 Mar 1998 22:40:28 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
Comments: To: [email-masked]
To: [email-masked]

Anil,

First, a couple of comments on this general state of affairs and then some
more specific comments on your analysis.

First, OCSP is on the standards track.  It has gone through several
iterations, culminating in  the recent joint authorship of myself and Rich
Ankney, which effort took into account the comments of many interested
parties.  The core concepts have been available for review for three IETFs
and have not fundamentally changed in that time, including the syntatic
approach.  A number of parties are testing the spec with trial
implementations.   At this point It is about as ready for last call as any
work product PKIX has yet produced.

Secondly, further extension of OCSP is counterproductive.  We need to get
something out that is useful in a "good enough" sense ( in the same sense
that CRLs are good enough for many needs) and address more sophisticated
needs with more sophisticated mechanisms. Let's match the size of the hammer
to the size of the nail.

Now, beyond that, your analysis provides us the opportunity to further
examine the core issues.

Mike

-----Original Message-----
From: Anil R. Gangolli <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, March 12, 1998 4:17 PM
Subject: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts

>Attached are some cursory comments on both the Malpani and
>PKIX OCSP drafts.  Some additional notes pertaining only to
>the Malpani draft are included at the end.
>
>--a.

>Comments on the Malpani OCSP recommendation and PKIX OCSP
>Full Validation vs. Revocation

>There appears to be an implicit motivation in the PKIX OCSP
>(draft-ietf-pkix-ocsp-02.txt) work that is missed by the Malpani spec.
>The PKIX spec seems intended to support not only revocation checking
>but full cert path validation for "thin clients" that might have only
>one trust point defined and trust OCSP servers for all more general
>cert path validation tasks.  I believe the PKIX OCSP spec requires
>further elaboration if it is intended to support this, but the Malpani
>spec doesn't provide for this at all.

If I may reiterate a point I've made several times in the past, OCSP was and
is primarily intended as a drop-in replacement for CRL processing where the
unique characteristics of OCSP lend themselves to the problem at hand.
Several commentators have noted the need for additional requirements
regarding validation.  I've agreed over the course of editing the document
to accomodate these needs.  I agree with Rich however that sophisticated
context validation schemes are beyond its scope.

>Some of the wierd hacks in the PKIX OCSP may credibly be explained by
>this motivation.  e.g. the avoidance of ASN.1 and the way the Cert ID
>hash argument is formed by straight concatenation rather than DER
>encoding a sequence.

Indeed, this is exactly the basis for the syntax and its constructions.
Whether or not they are wierd hacks or intuitively obvious implementation
choices may depend upon one's frame of reference.

>Use of ASN.1 and/or HTTP
>I expect that Malpani's revised OCSP using ASN.1 embedded within HTTP
>will be a better framework for the request/response specification than
>the PKIX OCSP scheme using ad hoc encodings over HTTP, but the "thin
>client" issue needs to be discussed.  Is the PKIX scheme trying to
>meet "thin client" requirements?

Most definitely, although not exclusively.  More generally, it addresses
requirements for simplicity in implementation within a well-defined problem
space.

The expressive power of ASN.1 is overkill in this case.  It burdens the
implementor with a steep learning curve, expensive tools, and delays in
market access just to gain access to an integer value expressing the current
state of a certificate's status.

>Is it succeeding?

Yes.  In the best IETF tradition, trial implementations are underway to
prove the concept.  I'm aware of at least two efforts that are directed
at a well-defined market need.

>What is the delta
>between what is required in a thin client that uses certs at all and a
>thin client that uses PKIX OCSP vs. Malpani OCSP?

This issue is not one of thin-client vs. full client but more with the
fundamental problem being addressed and a rational balance
between that problem's scope and the tools needed to effect
its solution.

>If the current PKIX OCSP HTTP scheme is used, the URL encoding should
>be brought more in line with current practice in browsers and other
>HTTP clients.  Use the format of application/x-www-form-urlencoded for
>attribute-value sets both in POSTed requests and all responses.
>Similarly use the more common encoding conventions for GET urls, eg.
>GET /ocsp/ver/1?arg1=value1&arg2=value2... in GET urls.

The spec enables developers of thin clients to export the complexity of CRL
processing to an external server.  I've heard this observation from several
of my larger enterprise customers and major technology partners.  This
effect has nothing to do with timeliness and everything to do with what
might be considered an indirect "feature".  In many such instances the need
for absolute timeliness is less acute.  One is then led to consider the
means by which OCSP can be further enhanced through the natural caching
effects of HTTP.  It is widely known that certain URL constructions, such as
you propose, are inherently non-cacheable. The OCSP request spec advantages
its implementors by proposing construction of a request that enables the
OCSP request to look like a cacheable object.  The ASN.1 approach eliminates
this option.

>Validity Time
>Both the current PKIX OCSP and the Malpani spec need clarification on
>the interperetation of the time interval and the assertion that the
>responder is making relative to these times.
>First, I suggest that "producedAt" be replaced by "validAt", and it be
>interpreted that way.

The intent here is to align with the same notions in CRL for "thisUpdate"
and "nextUpdate".  The corresponding semantics would apply.

>For example an OCSP responder may be producing a response based on a
>CRL that was generated somewhat earlier.  It cannot reasonably extend
>its assertion of validity beyond that of the CRL's "thisUpdate" time.
>The validUntil name is also misleading.  It should, as for CRLs, be
>"nextUpdate" or better "nextExpectedUpdate".

You must not be referencing the latest version as posted to the PKIX group's
link off the IETF web page. The current draft has a "nextUpdate".  The only
change left is to do the right thing and change the "producedAt"
non-terminal to "thisUpdate."

>The validity assertion claimed by the response holds only at any the
>"validAt" time.  In general the relying party must decide whether the
>difference between its current time and the "validAt" time of response
>meets its application requirements.

In general the relying party must decide whether or not to accept  *any*
assertion regarding the fitness of a certificate for a given purpose.  In
particular, RPs should pay attention to unilateral assertions of a
certificate's reliability when those assertions are not provably sourced
by the issuer of the certificate.  Those RPs also have a compelling
need to know when they may next expect or means by which they
may acquire fresher information from the issuing CA.

>The time "nextExpectedUpdate" provides a hint to the relying party on
>the time that new information is expected to be available from the
>responder.  The responder MAY generate new information before the time
>expressed in nextExpectedUpdate.  The responder SHOULD generate new
>information no later than the time expressed in nextExpectedUpdate.

We looked at this problem going into the last IETF.  To summarize those
discussions, if a CA makes revocation information available
asynchronously--that is, before RPs otherwise expect it to be available as
represented by a nextUpdate field--certain of those RPs may be led into
concluding that they have no need to go after fresher information than that
which they've currently cached (either locally or via proxy mechanisms).
Knowing this, an attacker could trick an RP into accepting a signature
as valid--substantiate by local cache and not refreshed due to nextUpdate
logic--when in fact the attacker has a priori recieved a reponse from
the CA showing the certificate as revoked.  Thus CAs that generate new
information before it is expected risk causing their RPs to incorrectly rely
on a certificate.

The situation is analogous to the CRL suppression problem.

These considerations led to the following requirement:

"If responses are pre-produced, then for a given certificate, the
periodicity of this pre-production SHOULD match the response validity
interval of the most recently produced response."

One way of solving this problem is go into a complete "push" mode, but that
still wouldn't solve the problem of the offline RP.

>One might want to add:
>        The relying party SHOULD NOT use a response indicating a
>        certificate's validity beyond the nextExpectedUpdate time.

This seems a reasonable requirement on RPs, but the OCSP spec
cannot place requirements on humans.

>but one should considier that this might better be left to
>application-level standards.
>The only thing that may be important to
>the application is the difference between current time and validAt
>time, if the cost of getting updated information is too hight.  (see
>related notes on Nonce below.)

I agree that it remains within the scope of implementations to determine
what to do in this instance.  It does seem however that there are only two
course of action: either enable users to override the trust engine of their
software, or to automatically cease further processing if the value for
nextUpdate is earlier than the machine's current time.  This later case no
doubt would obtain in the case of machines processing certificates.
IPSEC comes to mind.

>Nonce
>The assertion being claimed by a signed OCSP response is not changed
>by replay.  So it would seem that the purpose of the nonce is not to
>prevent replay attacks but rather to bind the response to a particular
>request in order to allow the relying party later to claim some
>sequence of events (e.g. the relying party must have done the OCSP
>check specifically for transaction X, because it included hash(X) in
>the nonce).

It is the replay of an error responses that's at issue here in the event
when the CA failed for some reason to successfully process a prior request.
This response can be captured for subsequent replay in instances when
subsequent successful requests would have yeilded a VALID response.

>In general I believe that applications and application-level standards
>should define a minimum requirement on revocation checking based on a
>"maximum tolerance window" specifying the maximum allowed difference
>between the current time and a revocation check on that certificate,
>rather than a per-transaction check.

But what if a signer's key is compromised, and the transaction being
processed within this so-called "safe window" is a high-value transaction
worthy of immediate status?  I doubt that applications are going to be
configurable to the granularity of attributes of single transactions.
In fact, I suspect that all we're likely to get in the near term is an
on/off switch on revocation.

>The nonce would be useful in situations where the application or
>application-level standard requires a per-transaction check against
>one of an approved set of responders.  I expect that this will prove
>costly to scale up with OCSPs individually-signed responses.

Rather, any online mechanism must address reliability and availability, from
IP routing networks to DNS name resolution.  The fundamental question is:
who pays for the infrastructure implied by the quite obvious means to
achieve responsive service levels?  This is an open question at this point,
but it is well beyond the scope of the OCSP draft to articulate such
answers.

>This
>starts becoming akin to the function of a notary.

I wholeheartedly agree.

>It is not clear it
>belongs in this spec, but I agree it is cheap to include.

Agree.

>Individual Signatures
>I still have a lot of trouble believing that individually signed
>responses, whether pre-computed or not will scale well for OCSP.

As I've said before, OCSP is not a systems-level design document.  It is an
interface specification between two endpoints such that any requestor A can
interoperate with any responder B.  In this regard it is no different than
any other pairwise interface protocol.  SMTP comes to mind; HTTP; DNS.  I
would further offer that OCSP can be used to actually *improve* the
scalability of some security protocols.  Consider for example the instance
when an OCSP response is included in an S/MIME message or in an ISAKMP main
mode exchange.

>I think that the Malpani spec could be extended to include
>alternate response mechanisms easily.

As your analysis implies, this spec is clearly vectored towards statements
of context validation and as such is much more closely linked to the Notary
Protocol.

Mike

Approved-By:  Michael Myers <[email-masked]>
Date:         Sun, 15 Mar 1998 22:21:32 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Paul,

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Sunday, March 15, 1998 1:05 PM
Subject: Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other
extensions

>Steve:
>I think you are thinking too
>much in the Verisign online enrollment model, which is only one way certs
>will be generated.

Actually, we have several enrollment models.  You may be most familiar with
the Internet variety.  We also enable enterprise-level local registration
authorities who, with appropriate a priori arrangments, are held to be
authoritative for well-defined jurisdictions.

Mike

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Sun, 15 Mar 1998 12:41: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Steve:

We still disagree here, but unlike in many arguments in PKIX, it is clear
where we disagree. :-)

>Most folks will not read a CPS, especially if it goes into that level of
>detail, and thus what the fine print says will not matter unless one
>litigates a dispute.

But if you don't read the CPS, you have no idea if the non-comment part of
an email address was verified. I could certainly believe that many CAs who
do not do online enrollment (like corporate CAs) will accept as valid any
information typed into them by the human CA administrator at a CA console.
If I walk up to my human administrator and say "here's my common name and
my email address; give me a cert", there's no sensible way for that human
to verify that it is really my email address. I think you are thinking too
much in the Verisign online enrollment model, which is only one way certs
will be generated.

Basically, either someone reads the CPS or they don't. Saying "becasue they
probably won't, this identifier is OK because it *could* be verified" is
very dangerous, IMHO. Either it is verified (and th CPS says so), or it
isn't (and it's not covered in the CPS, or the CPS says "we don't verify
this").

>I argue that we ought to be careful to not foster a situation that unduly
>creates an opportunity for confusion.

I fully agree. And I think pretending that a bare email address is verified
and belongs to the named user is quite an opportunity for confusion.
Remember, comments in an RFC 822 name *can* be verified. Both parts can be
verified, or they can be not verified.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Robert Jueneman <[email-masked]>
Date:         Sat, 14 Mar 1998 18:14:08 -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: Robert Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and otherextensions
Comments: To: [email-masked]
To: [email-masked]

Steve, I agree with that burying Non-verified Subscriber Informatioon (NVI/ NSI?) in a CPS won't do.  But on the other hand, there is a clear and compelling need for NSI, especially for proprietary attributes.

It would certainly be nice if we had a convenient indicator, much like the Critical indicator.

Perhaps someone can think of a good way of extending the standard to facilitate this?

Bob

>>> Stephen Kent <[email-masked]> 03/14/98 01:18PM >>>
Paul,

Sorry to have let this languish in my inbox.  When last we discussed this
issue we had resolved that we were in opposite camps re inclusion of
non-verified data in certs, in general, so the matter of including comments
along with the portion of the mailbox name that is used to control delivery
is just one example of this difference of opinion. I'm not sure we have
discussed the NVI matter as much on PKIX ad it had been discussed on PEM in
the past, but there never seems to be complete resolution.  In general, I
think that if a CA does elect to include NVI in a cert, it ought to be
included in extensions that don't have widespread use and a common
interpretation that could result in users being mislead.  Private
extensions are the obvious examples.

As you point out, the CPS for a CA can state whether the more "user
friendly" part of a mailbox name has been verified or not, just as it
states other aspects of the authenitcation process. However, I fear this is
begging the question.
Most folks will not read a CPS, especially if it goes into that level of
detail, and thus what the fine print says will not matter unless one
litigates a dispute.

I argue that we ought to be careful to not foster a situation that unduly
creates an opportunity for confusion.  While 822 addresses (and DNS names)
have a suitable infrastructure for establishing accuracy and uniqueness,
once one adds other, informal identifiers added to them pose more of a
problem. If one wants to include this other info in a cert, how about
including it as a common name component of a DN?

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Sat, 14 Mar 1998 15:18:12 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Paul,

Sorry to have let this languish in my inbox.  When last we discussed this
issue we had resolved that we were in opposite camps re inclusion of
non-verified data in certs, in general, so the matter of including comments
along with the portion of the mailbox name that is used to control delivery
is just one example of this difference of opinion. I'm not sure we have
discussed the NVI matter as much on PKIX ad it had been discussed on PEM in
the past, but there never seems to be complete resolution.  In general, I
think that if a CA does elect to include NVI in a cert, it ought to be
included in extensions that don't have widespread use and a common
interpretation that could result in users being mislead.  Private
extensions are the obvious examples.

As you point out, the CPS for a CA can state whether the more "user
friendly" part of a mailbox name has been verified or not, just as it
states other aspects of the authenitcation process. However, I fear this is
begging the question.
Most folks will not read a CPS, especially if it goes into that level of
detail, and thus what the fine print says will not matter unless one
litigates a dispute.

I argue that we ought to be careful to not foster a situation that unduly
creates an opportunity for confusion.  While 822 addresses (and DNS names)
have a suitable infrastructure for establishing accuracy and uniqueness,
once one adds other, informal identifiers added to them pose more of a
problem. If one wants to include this other info in a cert, how about
including it as a common name component of a DN?

Steve

Approved-By:  Michael Myers <[email-masked]>
Date:         Fri, 13 Mar 1998 18:08:08 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] CMMF and CMC drafts
To: [email-masked]

All,

I haven't yet seen any notification to this effect yet but the following two
drafts are available for review and comment on the IETF web site:

-- Certificate Management Message Formats
      ietf-draft-pkix-cmmf-00.txt

-- Certificate Management over CMS
      ietf-draft-pkix-cmc-00.txt

CMMF integrates PKI message bodies into one document (although points to
CRMF).

The CMC draft carries forward the CRS work which was submitted at the last
IETF to the S/MIME group and which was subsequently redirected to PKIX.

Mike

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Fri, 13 Mar 1998 15:51: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: Robert Zuccherato <[email-masked]>
Subject:      [IETF-PKIX] New Time Stamp Protocols Draft
To: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BD4E97.E9C32330
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Our new Time Stamp Protocols Draft is now available.  We submitted it,
again, as an independent draft since the PKIX charter hasn't yet been
modified to include this work.  It is available at:
ftp://ftp.ietf.org/internet-drafts/draft-adams-time-stamp-01.txt
and has also been attached to this message.

The changes to this draft include CMS (PKCS #7) encapsulation and the
inclusion of a nonce and version number in the request and responses.

As usual, comments are appreciated.

        Robert Zuccherato.

------ =_NextPart_000_01BD4E97.E9C32330
Content-Type: text/plain; name="time01.txt"
Content-Transfer-Encoding: 7bit

                                          C. Adams(Entrust Technologies)
Internet Draft                                             P. Cain (BBN)
expires in six months                                   D. Pinkas (Bull)
                                     R. Zuccherato(Entrust Technologies)
                                                          March 12, 1998

                          Time Stamp Protocols

                    <draft-adams-time-stamp-01.txt>

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This document describes the format of the data returned by a Time
Stamp Authority and the protocols to be used when communicating with it.
The time stamping service can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]).  In order to reduce the amount of trust required of a TSA we
introduce (in Appendix C) the optional Temporal Data Authority (TDA)
whose function is to provide further corroborating evidence of the time
contained in the token.  We also give an example of how to place a
signature at a particular point in time, from which the appropriate
certificate status information (e.g. CRLs) may be checked.

1.  Introduction

In order to associate a message with a particular point in time, a
Time Stamp Authority (TSA) may need to be used.  This Trusted Third
Party provides a "proof-of-existence" for this particular message at an
instant in time.  A TSA may also be used when a trusted time reference
is required and when the local clock available cannot be trusted by all
parties.  The TSA's role is to time stamp a message to establish
evidence indicating the time before which the message was generated.
This can then be used, for example, to verify that a digital signature
was applied before the certificate was revoked thus allowing a revoked
public key certificate to be used for verifying signatures created prior
to the time of revocation.  This is an important public key

Document Expiration:  September 12, 1998                         Page 1

infrastructure operation.  The TSA can also be used to indicate the time
of submission when a deadline is critical, or to indicate the time of
transaction for entries in a log.  An exhaustive list of possible uses
of a TSA is beyond the scope of this document.

2. The TSA

The TSA is a TTP that creates time stamp tokens in order to indicate
that a message existed at a particular point in time.

For the remainder of this document a 'valid request' shall mean one that
can be decoded correctly, is of the form specified in Section 2.4 and
contains the correct TSA name.

2.1. Requirements of the TSA

The TSA is required:
     1. to only provide a trusted source of time.
     2. not to examine or verify the requesting entities in any way.
     3. not to examine the imprint being time stamped in any way.
     4. to include a monotonically incrementing value of the time of day
        into its time stamp token.
     5. to produce a time stamp token upon receiving a valid request
        from the requester.
     6. to include within each time stamp token an identifier to
        uniquely indicate the trust and validation policy under which
        the token was created.
     7. to only time stamp a hash representation of the message, i.e. a
        data imprint associated with a one-way collision resistant hash-
        function OID.
     8. to examine the OID of the one-way collision resistant hash-
        function and to verify that this function is "sufficient" (see
        Section 2.4).
     9. to sign each time stamp token using a key generated exclusively
        for this purpose and have this property of the key indicated on
        the corresponding certificate.
    10. to include supplementary temporal information in the time stamp
        token (from TDA's) if asked by the requester.  If this is not
        possible, the TSA shall respond with an error message.
    11. to provide a signed receipt (i.e. in the form of an
        appropriately defined time stamp token) to the requester, where
        appropriate, as defined by policy.

2.2. TSA Transactions

As the first message of this mechanism, the requesting entity requests a
time stamp token by sending a request (which is or includes a
TimeStampReq, as defined below) to the Time Stamping Authority.  As the
second message, the Time Stamping Authority responds by sending a
response (which is or includes a TimeStampToken, as defined below) to
the requesting entity.

Upon receiving the token, the requesting entity verifies its validity
by verifying the digital signature in the TimeStampToken and by
verifying that what was time stamped corresponds to what was requested
to be time stamped.  The requester should verify that the TimeStampToken

Document Expiration:  September 12, 1998                         Page 2

contains the correct TSA name, the correct data imprint and the correct
hash algorithm OID.  It should then verify the timeliness of the
response by verifying either the time included in the response against a
local trusted time reference, if one is available, and/or the value of
the nonce included in the response against the value included in the
request.  Since the TSA's certificate may have been revoked, the status
of the certificate should be checked (e.g. by checking the appropriate
ARL) to verify that the certificate is still valid.  If
TemporalDataToken's are included in the TimeStampToken, then these
should also be verified as was the TimeStampToken (see Appendix C).  The
token can now be used to establish a trusted time reference.

2.3. Identification of the TSA

The TSA must sign all time stamp messages with a key reserved
specifically for that purpose.  The corresponding certificate must
contain the extended key usage field extension as defined in [CCP]
Section 4.2.1.14 with KeyPurposeID having value id-kp-timeStamping.
This extension must be critical.

2.4. Request and Token Formats

A time stamping request is as follows.

TimeStampReq ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     requester                [0] GeneralName OPTIONAL,
     reqPolicy                [1] PolicyInformation OPTIONAL,
     tsa                      [2] GeneralName,
     tdas                         SEQUENCE OF GeneralName OPTIONAL,
     nonce                        Integer,
     messageImprint               MessageImprint
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
}

The requester field, if included indicates the name of the requester.
This value is not verified by the TSA, but blindly copied in the
response and may be also copied in the audit trail.

The reqPolicy field, if included, indicates the policy under which the
TimeStampToken should be provided.  PolicyInformation is defined in
Section 4.2.1.5 of [CCP].

The tsa field identifies the name of the TSA.  GeneralName is defined
in Section 4.2.1.7 of [CCP].

The tdas field identifies those TDAs which are requested to provide
supplementary temporal evidence in the time stamp token.  (See Appendix
C.)

MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }

Document Expiration:  September 12, 1998                         Page 3

The hash algorithm indicated in the hashAlgorithm field must be a strong
hash algorithm.  That means that it must be one-way and collision
resistant.  It is up to the Time Stamp Authority to decide whether or
not the given hash algorithm is "sufficient" (based on the current state
of knowledge in cryptanalysis and the current state of the art in
computational resources, for example).

The hashedMessage field should contain the hash of the message to be
time stamped.  The hash is represented as an OCTET STRING.

A TimeStampToken is as follows.  It is encapsulated as a SignedData
construct [CMS].  The content is of type TSTInfo, which is indicated by
the OID:

TSTInfo OBJECT IDENTIFIER  ::= { ??????  }

The time stamp token must contain only the signature of the TSA.  In
some environments, the CA might not perform a proof-of-possession of
the private key when issuing certificates.  In these instances, either
the certificate of the TSA, or the certificate issuer and serial number
shall be included as an authenticated attribute.

TSTInfo ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     policy                       PolicyInformation,
     status                       PKIStatusInfo,
     requester               [0]  GeneralName OPTIONAL,
       --must be present if the requester field is present in
       --TimeStampReq, and must be identical to that field
     tsa                     [1]  GeneralName,
     genTime                      GeneralizedTime,
     tdaTokens                    SEQUENCE OF TemporalDataToken
                                    OPTIONAL,
     nonce                        Integer,
       --this field must have the same value as the similar field
       --in TimeStampReq
     messageImprint               MessageImprint
       --this field must have the same value as the similar field
       --in TimeStampReq
}

PKIStatusInfo is defined in Section 3.2.3 of [CMP].  If the PKIStatus
field has value 'waiting' (3), then this token is a receipt, as defined
in Section 2.1.  Otherwise, the status field is present to indicate
whether or not the time stamping request was fulfilled and, if not, the
reason it was rejected. A valid time stamp token will always have value
0 (granted) in the PKIStatus field of PKIStatusInfo.  Since not all
environments will require the use of receipts, support for the value
'waiting' is optional.

The purpose of the tsa field is to identify the name of the TSA.  It
must correspond to one of the subject names included in the certificate
that is to be used to verify the token.

Document Expiration:  September 12, 1998                         Page 4

TemporalDataToken is defined in Appendix C of this document.  The
tdaTokens field contains the supplementary evidence requested in the
TimeStampReq.

CertId is defined in Section 3.2.4 of [CMP].

3. Transports

There is no mandatory transport mechanism in this document.  All
mechanisms are optional.

3.1. File Based Protocol

A file containing a time stamp message must contain only the DER
encoding of one PKI message, i.e. there must be no extraneous header or
trailer information in the file.

Such files can be used to transport time stamp messages using for
example, FTP.

3.2. Socket Based Protocol

The socket based protocol for time stamp messages is identical to that
used in [CMP] Section 5.2 except that port 309 must be used.

3.3. Time Stamp Protocol Using E-mail

This section specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 2 and Appendix C via
Internet mail.

A simple MIME object is specified as follows.

   Content-Type: application/timestamp
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded Time Stamp message, base64-encoded>>

This MIME object can be sent and received using common MIME processing
engines and provides a simple Internet mail transport for Time Stamp
messages.

3.4. Time Stamp Protocol via HTTP

This subsection specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 2 and Appendix C via the
HyperText Transfer Protocol.

A simple MIME object is specified as follows.

   Content-Type: application/timestamp

   <<the ASN.1 DER-encoded Time Stamp message>>

Document Expiration:  September 12, 1998                         Page 5

This MIME object can be sent and received using common HTTP processing
engines over WWW links and provides a simple browser-server transport
for Time Stamp messages.

4. Security Considerations

This entire document concerns security considerations.

When designing a TSA/TDA service, the following considerations have been
identified that have an impact upon the validity or "trust" in the time
stamp token.

     1. When there is a reason to believe that the TSA can no longer
        be trusted, the authority's certificate must be revoked and
        placed on the appropriate ARL.  Thus, at any future time the
        tokens signed with the corresponding key will not be valid.
     2. The TSA private key is compromised and the corresponding
        certificate is revoked.  In this case, any token signed by the
        TSA using that private key cannot be trusted.  For this
        reason, it is imperative that the TSA's private key be
        guarded with proper security and controls in order to minimize
        the possibility of compromise.  In case the private key does
        become compromised, an audit trail of all tokens generated by
        the TSA may provide a means to discriminate between genuine
        and false tokens.
     3. The TSA signing key must be of a sufficient length to allow
        for a sufficiently long lifetime.  Even if this is done, the key
        will have a finite lifetime.  Thus, any token signed by the
        TSA should be time stamped again (if authentic copies of old
        CRLs are available) or notarized (if they aren't) at a later
        date to renew the trust that exists in the TSA's signature.
        Time stamp tokens could also be kept with an Evidence Recording
        Authority to maintain this trust.
     4. Since the TSA does not verify message data or the identity of
        the entities, the requester field in TimeStampReq and
        TimeStampToken should be considered untrusted.  If
        authentication of this field is needed, it is recommended that
        the Notary Authority be used, as described in [NOTARY].
     5. An application using the TSA service should be concerned about
        the amount of time it is willing to wait for a response.  A
        `man-in-the-middle' attack can introduce delays.  Thus, any
        TimeStampToken that takes more than an acceptable period of time
        should be considered suspect.
     6. In certain circumstances, a TSA may not be able to
        produce a valid response to a request (for example, if it is
        unable to compute signatures for a period of time).  In these
        situations the TSA must wait until it is again able to produce a
        valid response before responding, if this is possible.  If this
        is not possible, it must ignore the requests and not respond.
        Under no circumstances shall a TSA produce an unsigned response
        to a request.
     7. This protocol assumes that the CA has conducted a test for proof
        of possession for each user's signing private key (including
        the TSA signing private key).  If this is not the case, or when
        additional assurances are required, the certificate or
        certificate serial number and issuer of the TSA shall be

Document Expiration:  September 12, 1998                         Page 6

        included in the encapsulation of the time stamp token as an
        authenticated attribute.

5. References

[CMP] C. Adams, S. Farrell, "Internet Public Key Infrastructure,
Certificate Management Protocols," draft-ietf-pkix-ipki3cmp-
0X.txt, 1997 (work in progress).

[NOTARY] C. Adams, R. Zuccherato, "Notary Protocols,"  draft-adams-
notary-0X.txt, 1998 (work in progress).

[CCP] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key
Infrastructure, X.509 Certificate and CRL Profile," draft-
ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress).

[ISONR] ISO/IEC 10181-5:  Security Frameworks in Open Systems.
Non-Repudiation Framework.

[CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).

6. Authors' Addresses

Carlisle Adams                        Pat Cain
Entrust Technologies                  BBN
750 Heron Road                        70 Fawcett Street
Ottawa, Ontario                       Cambridge, MA 02138
K1V 1A7                               U.S.A.
CANADA                                [email-masked]
[email-masked]

Denis Pinkas                          Robert Zuccherato
Bull S.A.                             Entrust Technologies
Rue Jean Jaures                       750 Heron Road
B.P. 68                               Ottawa, Ontario
78340 Les Clayes sous Bois            K1V 1A7
FRANCE                                CANADA
[email-masked]                 [email-masked]

Document Expiration:  September 12, 1998                         Page 7

APPENDIX A - Storage of Data and Token

A time stamp token is meaningless without its associated data.  Thus, a
method is required to allow users to store the data and token together
securely.  They may be stored as a PKCS #7 SignedData object as
described in [CMS].  That is, the contentType is signedData and
contentInfo is Data, which contains the message associated with the time
stamp token.  The SignedData object is signed by the person storing the
data and token.  This signature is to be used only for storage and for
verifying the integrity of the token and data. Anyone using the token
and data at some future time must verify the data and token at that
time.  This is just a method for keeping the two pieces of information
together, with some integrity.

For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute
type.  This attribute type specifies the time stamp token, which must be
included as an authenticated attribute of the SignedData object.  The
time stamp token attribute type has ASN.1 type TimeStampToken (as
defined in Section 2.4 of this document).  A time stamp token attribute
must have a single attribute value.

The object identifier timeStampToken identifies the time stamp token
attribute type.

timeStampToken ::= { pkcs-9 n <<To be supplied>> }

[CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).

[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City, California, November
1993 Release.

APPENDIX B - Placing a Signature At a Particular Point in Time

We present an example of a possible use of this general time stamping
service. It places a signature at a particular point in time, from
which the appropriate certificate status information (e.g. CRLs) must be
checked.  This application is intended to be used in conjunction with
evidence generated using a digital signature mechanism.

Signatures can only be verified according to a non-repudiation policy.
This policy may be implicit or explicit (i.e., indicated in the
evidence provided by the signer). The non-repudiation policy can
specify, among other things, the time period allowed by a signer to
declare the compromise of a signature key used for the generation of
digital signatures. Thus a signature may not be guaranteed to be valid
until the termination of this time period.

To verify a signature that incorporates an untrusted time, the following
basic technique may be used:

A) Time stamping information needs to be obtained by the signer or
a verifier.

Document Expiration:  September 12, 1998                         Page 8

     1) The signature is presented to the Time Stamping Authority (TSA).
        The TSA then returns a TimeStampToken (TST) upon that signature.
     2) The invoker of the service must then verify that the
        TimeStampToken is correct.

B) The validity of the evidence must be verified :

     1) The date/time indicated by the signer in the signature shall be
        compared with the date/time in the TST. If they are not close
        enough (e.g., less than a few hours) the evidence is considered
        to be invalid.
     2) The certificate included in the signed message should be
        verified to be valid at the time of the signature. It must
        first be verified and then the appropriate CRL must be
        checked.

The signature has now been placed at a particular point in time.  The
appropriate CRLs or other certificate status information mechanism may
be examined to determine the validity of the signature at that time.

Appendix C - The TDA

The Temporal Data Authority is a TTP that creates a temporal data
token.  This temporal data token associates a message with a particular
event and provides supplementary evidence for the time included in the
time stamp token.  For example,  a TDA could associate the message with
the most recent closing value of the Dow Jones Average.  The temporal
data with which the message is associated should be unpredictable in
order to prevent forward dating of tokens.  Authentic values of this
data should also be available from a large number of trustworthy sources
in order to make collusion or corruption of data more difficult.  For a
list of possible types of temporal data, see Appendix D.

C.1. Requirements of the TDA

The TDA is required:
     1. to only provide a trusted source of temporal data.
     2. not to examine the imprint being time stamped.
     3. to include the current data associated with a specific
        unpredictable event in each temporal data token.
     4. to produce a temporal data token upon receiving a valid request
        from the TSA.
     5. to only produce a temporal data token on a hash representation
        of the message.
     6. to sign each temporal data token using a key generated
        exclusively for this purpose and have this property of the key
        indicated on the corresponding certificate.

C.2. TDA Transactions

As the first message of this mechanism, the TSA requests a temporal data
token by sending a request (which is or includes a TemporalDataReq, as
defined below) to the TDA.  As the second message, the TDA responds by
sending a response (which is or includes a TemporalDataToken, as defined
below) to the TSA.

Document Expiration:  September 12, 1998                         Page 9

C.3. Verifying a TemporalDataToken

The TSA is required to verify the structure of the TemporalDataToken.
It must verify the digital signature in the TemporalDataToken and also
verify that what was signed corresponds to what was requested to be
signed.  The requester should verify that the TemporalDataToken contains
the correct TDA name, the correct data imprint and the correct hash
algorithm OID.  It should also verify the timeliness of the response by
verifying the value of the nonce included in the response against the
value included in the request (exact match needed). Since the TDA's
certificate may have been revoked, the status of the certificate should
be checked (e.g. by checking the appropriate ARL) to verify that the
certificate is still valid.

In order to verify the TemporalData inside a TemporalDataToken, it is
necessary to know the form of the temporal data that the TDA has
included in the token.

The TSA is not required to verify the TemporalData. However, either the
entity requesting a Time Stamping Token or an entity verifying a Time
Stamping Token containing temporal information may be interested in such
a verification.

In the first case, it is unlikely that the temporal information will be
available ahead of time and thus the entity requesting a Time Stamping
Token may need to enter into an online protocol with the TDA, or some
other entity, to obtain it. A secure link with that trusted source will
be necessary, i.e. the communication channel or the information itself
must be authenticated and integrity protected.  Such a protocol is TDA
dependent and is outside the scope of this document.

In the second case, if the verification occurs some time after the Time
Stamping Token has been produced, then it is possible to rely on an
authentic source (e.g. a newspaper or a CD-ROM) to verify it against.
The exact method of verification is TDA dependent and is thus outside
the scope of this document.

C.4. Identification of the TDA

The TDA must sign all temporal data tokens with a key reserved
specifically for that purpose.  The corresponding certificate must
contain the extended key usage field extension as defined in [CCP]
Section 4.2.1.14 with KeyPurposeID having value id-kp-temporalData.
This extension must be critical.

id-kp-temporalData    OBJECT IDENTIFIER ::= {id-kp  ??}
  -- Providing temporal data in support of time stamping services.  Key
  -- usage bits that may be consistent:  digitalSignature,
  -- nonRepudiation

C.5. Request and Token Formats

A temporal data request from a TSA is as follows.

TemporalDataReq ::= SEQUENCE  {
     version                      Integer  { v1(0) },

Document Expiration:  September 12, 1998                         Page 10

     tda                          GeneralName,
     nonce                        Integer,
       --must be the same value as the corresponding field in
       --TimeStampReq
     messageImprint               MessageImprint
       --a hash of the data to be time stamped, must be the same
       --value as the corresponding field in TimeStampReq
}

A TemporalDataToken is as follows.  It is encapsulated as a SignedData
construct [CMS].  The content is of type TDTInfo, which is indicated by
the OID:

TDTInfo OBJECT IDENTIFIER  ::= { ??????  }

The temporal data token must contain only the signature of the TDA. In
some environments, the CA might not perform a proof-of-possession of
the private key when issuing certificates.  In these instances, either
the certificate of the TDA, or the certificate issuer and serial number
shall be included as an authenticated attribute.

TDTInfo ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     tda                          GeneralName,
     nonce                        Integer,
       --must have the same value as the corresponding field in
       --TimeStampReq
     temporalData                 TemporalData,
     messageImprint               MessageImprint
       --must have the same value as the corresponding field in
       --TimeStampReq
}

The temporalData field contains the actual temporal data that will
be used as substantiating evidence in the time stamp token.

TemporalData ::= SEQUENCE  {
     format                       TEMPORALDATACLASS.&id,   --objid
     rawdata                      TEMPORALDATACLASS.&Type  --open type
}

TEMPORALDATACLASS ::= CLASS  {
     &id                          OBJECT IDENTIFIER UNIQUE,
     &Type                                                    }
WITH SYNTAX  { &Type IDENTIFIED BY &id }

C.6. Security Considerations

When designing a TDA service, the following considerations have been
identified that have an impact upon the validity or "trust" in the
temporal data token.

     1. When there is a reason to believe that the TDA can no longer
        be trusted, the authority's certificate must be revoked and
        placed on the appropriate ARL.  Thus, at any future time the

Document Expiration:  September 12, 1998                         Page 11

        tokens signed with the corresponding key will not be valid.
     2. The TDA private key is compromised and the corresponding
        certificate is revoked.  In this case, any token signed by the
        TDA using that private key cannot be trusted.  For this
        reason, it is imperative that the TDA's private key be
        guarded with proper security and controls in order to minimize
        the possibility of compromise.  In case the private key does
        become compromised, an audit trail of all tokens generated by
        the TDA may provide a means to discriminate between genuine
        and false tokens.
     3. The TDA signing key must be of a sufficient length to allow
        for a sufficiently long lifetime.  Even if this is done, the key
        will have a finite lifetime.  Thus, any time stamp token
        containing the TDA's signature should be time stamped again (if
        authentic copies of old CRLs are available) or notarized (if
        they aren't) at a later date to renew the trust that exists in
        the TDA's signature. Time stamp tokens could also be kept with
        an Evidence Recording Authority to maintain this trust.
     4. In certain circumstances, a TDA may not be able to produce a
        valid response to a request (for example, if it is unable to
        compute signatures for a period of time).  In these situations
        the TDA must wait until it is again able to produce a valid
        response before responding, if this is possible.  If this is not
        possible, it must ignore the requests and not respond.  Under no
        circumstances shall a TDA produce an unsigned response to a
        request.
     5. This protocol assumes that the CA has conducted a test for proof
        of possession for each user's signing private key (including
        the TDA signing private key)..  If this is not the case, or when
        additional assurances are required, the certificate or
        certificate serial number and issuer of the TDA shall be
        included in the encapsulation of the temporal data token as an
        authenticated attribute.

[CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).

APPENDIX D - Possible Types of Temporal Data

1)  Stock market information
2)  Sports results
3)  Official weather data for a specific location
4)  Lottery results
5)  Birth or death announcements in specific newspapers
6)  Headlines in specific newspapers
7)  Information linking the request with previous and subsequent requests
   (e.g. hash values) that can be verified against information that is
    made public by the TDA.
8) A signed packet from a secure time source.

Document Expiration:  September 12, 1998                         Page 12

------ =_NextPart_000_01BD4E97.E9C32330--

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Fri, 13 Mar 1998 13:04: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: Sharon Boeyen <[email-masked]>
Subject:      [IETF-PKIX] Revised draft-ietf-pkix-ipki2opp-07.txt
Comments: cc: harald alvestrand <[email-masked]>, keith moore <[email-masked]>
To: [email-masked]

The PKIX LDAPv2 protocol profile was not approved by the IESG. There
were two areas of
concern raised.

A revised version of the profile has just been submitted, which
addresses one of those
concerns (that the security considerations section recommend stronger
authentication for
the CA modification of PKI data and mention the risk of denial of
service attacks which can be mounted if stronger authentication is not
used). No other changes were made.

The other requirement is that at least a minimal schema specification be
completed to
accompany this profile. A draft will be submitted for that before the
deadline this afternoon
as well.

Sharon

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 13 Mar 1998 09:43:08 -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] Multiple certificates for same key?
To: [email-masked]

>Bob:
>
>I must disaree.  PKIX cannot provide non-repudiation.  PKIX provides
>necessary stuff, but the signing application must do other things that are
>beyond the scope of PKIX.  S/MIME is one such application.
>
>Russ

Russ, I don't disagree that PKIX cannot provide non-repudiation in and of itself.
The questions is whether PKIX is in fact providing the "necessary stuff", or
whether each application has to solve the problem of binding certificates to
documents, over and over again.

I don't believe this issue affects non-repudiation exclusively. I might have to
think for a second, but I think I could come up with a scenario where which
certificate is used would affect access controls and similar uses in SSL, IPSEC,
and other evolving protocols. so I don't want to relegate the issue to the S/MIME
group alone.

To say it another way, I think we (the technical community at large)
made a fundamental blunder in the past in not cryptographically binding the
certificate to the message, document, etc., at the time of signing.
And now I am suggesting that we consider whether, and how, we
could fix that fundamental problem.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Fri, 13 Mar 1998 09:33:04 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification and SEP protocol
To: [email-masked]

Hi Oronzo,

>----------
>From:  [email-masked][SMTP:[email-masked]]
>Sent:  Friday, March 13, 1998 5:19 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Cross Certification and SEP protocol
>
>I'm not a PKIX specialist and I need to check some information.
>
>Reading Entrust/Manager documentation I read:
>"....In Entrust, users receive a secure copy of the CA public key as
>part of the Secure Exchange Protocol (SEP). ..."
>
>AFAIK, SEP is an Entrust proprietary protocol used among CA server and
>clients, is this correct?
>
>If SEP is a proprietary protocol, is it correct to say that this should
>be solved in PKIX using PKIX-2 operational protocols
>specification?

No.  This is not an "operational protocols" issue; this is a
"certificate management protocols" issue (i.e., PKIX-CMP).  This is
exactly the reason that PKIX-CMP (which used to be called PKIX-3) was
invented and brought into the PKIX Working Group:  so that the protocols
and procedures necessary to achieve certificate management functionality
could be accomplished between PKI components (EE, CA, RA) in a
standards-compliant way.

SEP was created because back when we were first implementing full
certificate management functionality (over four years ago) there was no
other protocol that could be used.  However, we're not fond of
proprietary protocols and recognize that they have no benefit in terms
of encouraging interoperable components in a PKI.  This is why we have
been so vigorous in pursuing PKIX-3 within the IETF for more than two
years now.

Thanks for asking  --  I hope this helps to clarify things.

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

>From: Oronzo Berlen <[email-masked]>
Approved-By:  [email-masked]
Date:         Fri, 13 Mar 1998 11:19:02 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Organization: Olivetti Ricerca SCpA
Subject:      [IETF-PKIX] Cross Certification and SEP protocol
Comments: To: cert-talk <[email-masked]>
To: [email-masked]

I'm not a PKIX specialist and I need to check some information.

Reading Entrust/Manager documentation I read:
"....In Entrust, users receive a secure copy of the CA public key as
part of the Secure Exchange Protocol (SEP). ..."

AFAIK, SEP is an Entrust proprietary protocol used among CA server and
clients, is this correct?

If SEP is a proprietary protocol, is it correct to say that this should
be solved in PKIX using PKIX-2 operational protocols
specification?

Thanks in advance
--
____________________________________________________________________
Oronzo Berlen                   | tel. 080.635-2112
Olivetti Ricerca                | fax. 080.635-2089
S.S. 271 Contrada la Marchesa | Email:[email-masked]
70020 Bitritto (BA)             |

>From: Oronzo Berlen <[email-masked]>
Approved-By:  [email-masked]
Date:         Fri, 13 Mar 1998 09:49:19 +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]
Organization: Olivetti Ricerca SCpA
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: Bob Jueneman <[email-masked]>, Unix Security Italiana <[email-masked]>
Comments: cc: MSAF-ETSG <[email-masked]>
To: [email-masked]

In the italian draft legislation there is nothing like that; the only thing which is required for a CA
to operate is
to have a society form and available capital equal to that needed in Italy to operate as a Bank; this
recalls the liability
question, but not related to a specific certificate, but to the CA as a whole.

Bob Jueneman wrote:

> >What a reliance limit exactly is?
> >I know the Italian legislation which is going to be approved, where it seems there is nothing which
> >sound like what you need.
>
> Several people have asked "what's a reliance limit", so I guess I should
> have provided a definition.
>
> The Utah Digital Signature Act provides a means of limiting a
> CA's liability (and presumably the subscriber's liability), by putting
> a "Reliance Limit" in the certificate as a way of indicating the
> monetary value or upper limit of a transaction that might be
> considered "commercially reasonable":
>
> "46-3-309 Recommended reliance limits and liability
>
> (1) By specifying a recommended reliance limit in a certificate,
> the issuing certification authority and the accepting subscriber
> recommend that persons rely on the certificate only to the
> extent that the total amount at risk does not exceed the
> recommended reliance limit."
>
> Paragraph (2) of that section goes on at some length to define
> the limits of liability that would apply to a CA that is licensed under
> the Utah statute, and how someone can recover from the CA in
> the event someone is harmed. The Utah regulations also require
> that a CA provide a "suitable guaranty" in the form of surety bond
> or irrevocable letter of credit in an amount that is a percentage
> of the aggregate amount of the reliance limit of all currently valid
> certificates issued, in order to back up such liability limits. C.f.
> http://www.commerce.state.ut.us/web/commerce/digsig/act.htm,
> section 46-3-310 and 310.
>
> There are, of course, a number of problems that could occur in
> anything other than a closed loop system where the CA becomes
> involved in validating every certificate -- the CA normally has no
> knowledge of how many times the subscriber uses his digital
> signature, and even the subscriber may have no idea how many
> times even a given signature is validated, e.g., on a piece of
> operating system code signed by Microsoft, or a Java applet signed
> by some web server. Even if the Reliance Limit is 1 penny, the
> CA's liability is potentially infinity squared in that case.
>
> Nonetheless, even in an open loop, open PKI system, some
> form of caveat or limitation on a certificate is probably better than nothing.
>
> To date, no CA I am aware of includes a Reliance Limit attribute extension
> in their certificates. VeriSign in their CPS does claim an overall liability limit
> on a per certificate basis based on their certificate class, but they don't
> refer to it in their certificate, except by incorporating by reference their CPS.
> Whether such an aggregate liability limit would hold up in court without some
> form of statutory authority is an interesting question.
>
> We are considering  including a optional Reliance Limit attribute extension
> in certificates which our CA toolkit will produce, and at present I'm thinking
> about specifying both a per transaction and per certificate liability cap or
> reasonableness indicator, denominated in a particular ISO-country currency
> (user's choice), or perhaps in troy ounces of gold. When and if we do so, we will
> post an informational RFC defining the syntax and semantics of the attribute
> (along with others we are defining) so that browser vendors and others will know
> how to display the attribute. The attribute could be Critical or non-Critical at the
> user's choice, although marking it Critical would obviously limit interoperability.
>
> Although putting such an attribute into a certificate wouldn't be particularly
> difficult, translating the input screens and the corresponding display screens
> into all of the foreign languages that Novell supports worldwide does involve
> some effort, so the question is whether such a concept is worth implementing
> on a world-wide basis.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
>
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
>
> "The most dangerous strategy is to cross a chasm in two jumps."

--
____________________________________________________________________
Oronzo Berlen                   | tel. 080.635-2112
Olivetti Ricerca                | fax. 080.635-2089
S.S. 271 Contrada la Marchesa | Email:[email-masked]
70020 Bitritto (BA)             |

Approved-By:  Russ Housley <[email-masked]>
Date:         Fri, 13 Mar 1998 00:53:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Bob:

I must disaree.  PKIX cannot provide non-repudiation.  PKIX provides
necessary stuff, but the signing application must do other things that are
beyond the scope of PKIX.  S/MIME is one such application.

Russ

At 03:22 PM 3/11/98 -0700, Bob Jueneman wrote:
>Denis,
>
>I agree with you.  (Maybe you would like a framed and notarized copy? :-)
>
>Russ,
>
>Before we relegate this problem to the S/MIME group, I'd like to
>explore the possibility of a more general solution just a bit more. Although
>it may be that the overhead, impact, yada, yada, of slightly revising the
SIGNED
>macro (or defining a new signature oid) will be too great for some
>applications, the use of a specific signature algorithm OID would allow
>that to be controlled.
>
>Ideally, of course, the API calls wouldn't even change, except for the
>OID definition. That may be a bit much to hope for, unless all of the
>information is already in the certificate or can be obtained from the
>operating system without an API call (e.g., the date/time).
>
>But I would rather revise the one or two applications now to make use
>of a common interface, rather than wait and have to revise applcations
>one at a time later on.
>
>Bob
>
>
>>>> Denis Pinkas <[email-masked]> 03/11 3:04 PM >>>
>Stephen,
>
>As Russ said, this discussion also relates to the CMS document from the
>smime wg and we should schedule a time slot in the pkix wg to talk about
>it at the LA meeting.
>
>In addition I would like to make a few comments on your two E-mails from
>yesterday.
>
>> Bob,
>>
>> I feel that the discussion of "which cert goes with this signature" is
>> overblown.  I would argue that a relying party needs to acquire a cert that
>> is valid and that contains a public key that validates the signature of the
>> signed data.
>
>This is the wrong way. The signer has to indicate which certificate must
>be used. The verifier should have no free choice.
>
>> If there is a only ine cert with a key that conforms to these
>> requirements, we're done.
>
>No. I would not like to re-open the POP discussion ... but if the
>certificate identifier of the signer is part of the signed stuff, then
>we can do "real-time" POP.
>
>> if there's more than one, then the relying party
>> has been given the opportunity to choose whichever one he wants. Many
>> applications I know of send the end user cert as part of a transaction,
>> messages, or session establishment protocol.
>
>The basic question is whether the end user cert is signed or not.
>Currently, it is not signed and this is the problem.
>
>> Thus the relying party is
>> saved the trouble of having to guess, and ambuigity is avoided.  When
>> non-repudiation is an issue, then it is important to understand the
>> implications of multuiple certification and users and CAs should behave
>> accordingly.  However, if they choose poorly and create opportunities for
>> abmiguity and possible deception, I'd back the relying party if he can
>> produce a valid cert that is plausibly associated with the user and which
>> works from a signature validation perspective.
>>
>> Steve
>
>Second E-mail:
>
>(... stuff deleted ...)
>
>> Thus, I am not persuaded that we need to preclude multiple certification of
>> a public key in PKIX, but I am in favor of including a brief warning about
>> the possible pitfalls of this practice, and a suggestion that this practice

>> be avoided for end user certs in most circumstances.
>
>I do not think this is the right way to present the problem. You seem to
>assume that the single problem has to do with the same user with two
>certificates that contain the same public key. As indicated above, in
>addition, we need to consider two different users each one with a
>certificate that contains the same public key (the POP problem).
>
>The recommendation should be, for the non-repudiation case, to make sure
>that the signature at least includes the identifier of the certificate
>(or the certificate itself). It might also include a certification path
>(ie. a sequence of certificate identifiers).
>
>Denis
>
>--
>      Denis Pinkas     Bull S.A.          mailto:[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
>

Approved-By:  "Anil R. Gangolli" <[email-masked]>
Date:         Thu, 12 Mar 1998 15:44:08 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Anil R. Gangolli" <[email-masked]>
Organization: Structured Arts Computing Corp.
Subject:      [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

This is a multi-part message in MIME format.
--------------CD0945263BFD9E4F9EF0261A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Attached are some cursory comments on both the Malpani and
PKIX OCSP drafts.  Some additional notes pertaining only to
the Malpani draft are included at the end.

--a.

--
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:[email-masked]
--------------CD0945263BFD9E4F9EF0261A
Content-Type: text/plain; charset=us-ascii; name="ocsp-comments.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="ocsp-comments.txt"

Comments on the Malpani OCSP recommendation and PKIX OCSP

Full Validation vs. Revocation

There appears to be an implicit motivation in the PKIX OCSP
(draft-ietf-pkix-ocsp-02.txt) work that is missed by the Malpani spec.

The PKIX spec seems intended to support not only revocation checking
but full cert path validation for "thin clients" that might have only
one trust point defined and trust OCSP servers for all more general
cert path validation tasks.  I believe the PKIX OCSP spec requires
further elaboration if it is intended to support this, but the Malpani
spec doesn't provide for this at all.

Some of the wierd hacks in the PKIX OCSP may credibly be explained by
this motivation.  e.g. the avoidance of ASN.1 and the way the Cert ID
hash argument is formed by straight concatenation rather than DER
encoding a sequence.

Use of ASN.1 and/or HTTP

I expect that Malpani's revised OCSP using ASN.1 embedded within HTTP
will be a better framework for the request/response specification than
the PKIX OCSP scheme using ad hoc encodings over HTTP, but the "thin
client" issue needs to be discussed.  Is the PKIX scheme trying to
meet "thin client" requirements?  Is it succeeding?  What is the delta
between what is required in a thin client that uses certs at all and a
thin client that uses PKIX OCSP vs. Malpani OCSP?

If the current PKIX OCSP HTTP scheme is used, the URL encoding should
be brought more in line with current practice in browsers and other
HTTP clients.  Use the format of application/x-www-form-urlencoded for
attribute-value sets both in POSTed requests and all responses.
Similarly use the more common encoding conventions for GET urls, eg.
GET /ocsp/ver/1?arg1=value1&arg2=value2... in GET urls.

Validity Time

Both the current PKIX OCSP and the Malpani spec need clarification on
the interperetation of the time interval and the assertion that the
responder is making relative to these times.

First, I suggest that "producedAt" be replaced by "validAt", and it be
interpreted that way.

For example an OCSP responder may be producing a response based on a
CRL that was generated somewhat earlier.  It cannot reasonably extend
its assertion of validity beyond that of the CRL's "thisUpdate" time.

The validUntil name is also misleading.  It should, as for CRLs, be
"nextUpdate" or better "nextExpectedUpdate".

The validity assertion claimed by the response holds only at any the
"validAt" time.  In general the relying party must decide whether the
difference between its current time and the "validAt" time of response
meets its application requirements.

The time "nextExpectedUpdate" provides a hint to the relying party on
the time that new information is expected to be available from the
responder.  The responder MAY generate new information before the time
expressed in nextExpectedUpdate.  The responder SHOULD generate new
information no later than the time expressed in nextExpectedUpdate.

One might want to add:
        The relying party SHOULD NOT use a response indicating a
        certificate's validity beyond the nextExpectedUpdate time.
but one should considier that this might better be left to
application-level standards.  The only thing that may be important to
the application is the difference between current time and validAt
time, if the cost of getting updated information is too hight.  (see
related notes on Nonce below.)

Nonce

The assertion being claimed by a signed OCSP response is not changed
by replay.  So it would seem that the purpose of the nonce is not to
prevent replay attacks but rather to bind the response to a particular
request in order to allow the relying party later to claim some
sequence of events (e.g. the relying party must have done the OCSP
check specifically for transaction X, because it included hash(X) in
the nonce).

In general I believe that applications and application-level standards
should define a minimum requirement on revocation checking based on a
"maximum tolerance window" specifying the maximum allowed difference
between the current time and a revocation check on that certificate,
rather than a per-transaction check.

The nonce would be useful in situations where the application or
application-level standard requires a per-transaction check against
one of an approved set of responders.  I expect that this will prove
costly to scale up with OCSPs individually-signed responses.  This
starts becoming akin to the function of a notary.  It is not clear it
belongs in this spec, but I agree it is cheap to include.

Individual Signatures

I still have a lot of trouble believing that individually signed
responses, whether pre-computed or not will scale well for OCSP.
I think that the Malpani spec could be extended to include
alternate response mechanisms easily.

Additional Minor Notes on Malpani's spec
----------------------------------------

Here are some additional minor notes applying only to the Malpani
spec.

Computation of the hash value
        Be specific about the calculation of this value. e.g. The
        SHA-1 hash computed over the full DER encoding of the
        IssuerNameAndKey structure including identifier, length, and
        contents octets.

Response Syntax
        "The actual formatting of the message could vary..."  Insist
        on DER encoding at a minimum, or clarify that this is what you
        mean.

BasicOCSPResponse
        Switch the order of the signatureAlgorithm and ResponseData to
        conform to the convention of the X.509 SIGNED macro.

eventTime in SingleResponse
        I couldn't find a definition of this in the document.

CrlID
        CrlURL doesn't provide an adequate basis for defining a
        particular CRL.

Section 4 Reference to X.208
        DER encoding was defined originally in X.509 and updated in
        X.690.  It is not in X.208.

Section 4.4.4.4
        One needs to elaborate a bit on how the semantics of CRL entry
        extensions apply to the OCSP response.

--------------CD0945263BFD9E4F9EF0261A--

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 12 Mar 1998 16:20:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

Thanks, Marc.  The text is essentially the equivalent of the Utah text.

I'm still interested if anyone finds any others, but the next question is
whether any CA or CA toolkit is presently including such an attribute in their
certs.

Bob

Bob Jueneman <[email-masked]> scrawled:
>
> Is anyone aware of any legislation, passed or pending, which takes any legal
> recognition of a "Reliance Limit", other than the Utah Digital Signature Act?
>
> I would be particularly interested to learn of any non-US jurisdictions who m
> ight be interested in  this.
>

Last I saw it, the Washington State Electronic Authentication Act called for
reliance limits.  Surfez-vous to

        http://leginfo.leg.wa.gov/pub/rcw/title_19/chapter_034/

Reliance limits are specifically discussed in rcw_19_34_280.

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Thu, 12 Mar 1998 13:47:14 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      [IETF-PKIX] Bad signature? (was: Re: [IETF-PKIX] Reliance limits in statutes)
To: [email-masked]

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

Content-Type: text/plain; charset=us-ascii

It seems that something somewhere is mucking with my posts to this list.  In
any lines that start with one or more TAB characters, the TABs are
translated into spaces.  This, of course, invalidates my PGP signature on
the message.

Sigh.

           Marc (used spaces here this time)

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

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Thu, 12 Mar 1998 09:53:14 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

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

Content-Type: text/plain; charset=us-ascii

Bob Jueneman <[email-masked]> scrawled:
>
> Is anyone aware of any legislation, passed or pending, which takes any legal
> recognition of a "Reliance Limit", other than the Utah Digital Signature Act?
>
> I would be particularly interested to learn of any non-US jurisdictions who m
> ight be interested in  this.
>

Last I saw it, the Washington State Electronic Authentication Act called for
reliance limits.  Surfez-vous to

        http://leginfo.leg.wa.gov/pub/rcw/title_19/chapter_034/

Reliance limits are specifically discussed in rcw_19_34_280.

                Marc

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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 12 Mar 1998 09:59:20 -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] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

>What a reliance limit exactly is?
>I know the Italian legislation which is going to be approved, where it seems there is nothing which
>sound like what you need.

Several people have asked "what's a reliance limit", so I guess I should
have provided a definition.

The Utah Digital Signature Act provides a means of limiting a
CA's liability (and presumably the subscriber's liability), by putting
a "Reliance Limit" in the certificate as a way of indicating the
monetary value or upper limit of a transaction that might be
considered "commercially reasonable":

"46-3-309 Recommended reliance limits and liability

(1) By specifying a recommended reliance limit in a certificate,
the issuing certification authority and the accepting subscriber
recommend that persons rely on the certificate only to the
extent that the total amount at risk does not exceed the
recommended reliance limit."

Paragraph (2) of that section goes on at some length to define
the limits of liability that would apply to a CA that is licensed under
the Utah statute, and how someone can recover from the CA in
the event someone is harmed. The Utah regulations also require
that a CA provide a "suitable guaranty" in the form of surety bond
or irrevocable letter of credit in an amount that is a percentage
of the aggregate amount of the reliance limit of all currently valid
certificates issued, in order to back up such liability limits. C.f.
http://www.commerce.state.ut.us/web/commerce/digsig/act.htm,
section 46-3-310 and 310.

There are, of course, a number of problems that could occur in
anything other than a closed loop system where the CA becomes
involved in validating every certificate -- the CA normally has no
knowledge of how many times the subscriber uses his digital
signature, and even the subscriber may have no idea how many
times even a given signature is validated, e.g., on a piece of
operating system code signed by Microsoft, or a Java applet signed
by some web server. Even if the Reliance Limit is 1 penny, the
CA's liability is potentially infinity squared in that case.

Nonetheless, even in an open loop, open PKI system, some
form of caveat or limitation on a certificate is probably better than nothing.

To date, no CA I am aware of includes a Reliance Limit attribute extension
in their certificates. VeriSign in their CPS does claim an overall liability limit
on a per certificate basis based on their certificate class, but they don't
refer to it in their certificate, except by incorporating by reference their CPS.
Whether such an aggregate liability limit would hold up in court without some
form of statutory authority is an interesting question.

We are considering  including a optional Reliance Limit attribute extension
in certificates which our CA toolkit will produce, and at present I'm thinking
about specifying both a per transaction and per certificate liability cap or
reasonableness indicator, denominated in a particular ISO-country currency
(user's choice), or perhaps in troy ounces of gold. When and if we do so, we will
post an informational RFC defining the syntax and semantics of the attribute
(along with others we are defining) so that browser vendors and others will know
how to display the attribute. The attribute could be Critical or non-Critical at the
user's choice, although marking it Critical would obviously limit interoperability.

Although putting such an attribute into a certificate wouldn't be particularly
difficult, translating the input screens and the corresponding display screens
into all of the foreign languages that Novell supports worldwide does involve
some effort, so the question is whether such a concept is worth implementing
on a world-wide basis.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  [email-masked]
Date:         Thu, 12 Mar 1998 09:06:17 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Lynn Wheeler <[email-masked]>
Subject:      Re: [IETF-PKIX] Fwd: Re: [IETF-PKIX] Multiple Certificates (resend)
To: [email-masked]

... this is resend ..our corporate gateway switched to full first/last
mapping ... my nominal subscription
was under my firstname ... which doesn't come thru anymore & I've had to
resubscribe.

To:   [email-masked]
cc:   [email-masked], [email-masked],
      [email-masked], [email-masked]

re: gold & green card certificates;
note that the financial transanction includes the account number ... and
the digital signature signs the transaction (including the data element
that is the account number). The account number is the entity that
selects the card ... not the certificate. The certificate is
(theoritically) used to validate the signature (on the transaction); not to
select the identity.
the credit card flow for x9.59 transactions might make it a little clearer:
http://lists.commerce.net/lists/open/ansi-epay/msg00139.html
also see the rest of the discussion on account vis-a-vis certificate
validation of digital signatures at:
           http://www.garlic.com/~lynn/
In the set world ... since the account number can't be disclosed in the
certificate ... and the account number wouldn't be carried in the
transaction in the clear ... there is no way the merchant can determine
whether a particular certificate is in any way related to a specific
account. The best that can be determined is that the CA issuing the
certificate (pushed along with the transaction) had authenticated
something. Whatever that the authenticated something (by the CA) ... might
be useful in tracking back to a specific entity ... if after the fact,
somebody discovered that the (cloaked) account number (in the transaction)
was used incorrectly.
In x9.59 ... the transaction digital signature is authenticated at the
consumer's financial institution ... not with a public key registered in a
certificate ... but a public key registered in the consumer's account
record. It is somewhat clearer in X9.59 ... that a consumer's public key
might be registered in more than one place (account records &/or
certificates) ... but the number of places that a public key is registered
... is orthogonal to the transaction contents that have been signed with
that public key.

Also, in x9.59, since the account number doesn't have to be hidden, it
is in clear in the transaction ... and can optionally be included in a
certificate issued by a consumer's financial institution (at the time the
consumer's public key is registered). This opens the opportunity for
the merchant doing some prescreening on transaction by crosschecking
the account number specified in the transaction with one that might be
carried in a signed certificate from a financial institution.
In this scenerio, it is even more clear that even if the same public key is
carried in one hundred different certificates ... if the specific
certificate associated with the specific account number listed in the
transaction ... wasn't pushed along with the transaction ... the
transaction has high probability of being rejected (even if the digital
signature was validated by a merchant prescreening operation).

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 12 Mar 1998 09:24:02 -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] Cryptographic binding of certificates tosignatures
Comments: To: [email-masked]
To: [email-masked]

Lars, I appreciate your "European" hard-token perspective.
Certainly, how the keys are generated and how they are
incorporated into certificates can substantially change the risks.

Just to clarify one thing however. Although I mentioned the
possibility of changing the SIGNED macro, it was only to
highlight the original source of the problem. I realize that changing
the basic definition at this time is probably not a viable
possibility.

However, my final recommendation and conclusion was that we
consider creating a new set of signature algorithm IDs that would
end up using RSA, DSA, etc., but would also include additional
information such as the issuerName and serial number, or perhaps
just a hash of the certificate, so that the certificate to be used
is irrevocably tied to the signed text.

I also mention the desirability of including some additional information
such as date/time and possibly the identity of the platform on which
the signature was applied, for audit purposes.

(You might be particularly interested in the later, from your hard-token
perspective. Assuming that the token only generates the signature, and
maybe the message digest that goes into it, the token has no way of
knowing what the user saw on the screen that was supposed to be
signed, as opposed to what the application actually presented to be signed.
Unless the token is limited to only signing once per insertion, a rogue
merchant could cause the token to sign all sorts of things, while the
user thinks that she is only buying a dishrag. Including an authenticated
identification of the platform would help point a smoking gun in such cases.)

Other people may have their own pet ideas which should be considered.
For example, I foresee a time in the relatively near future where biometrics will
be combined with digital signatures to circumvent some of the control issues
that neither a password encrypted key nor a smart token solve, since either can
be given away.  It would no doubt be very useful to incorporate the biometric
indicia into the signature itself, so that it would later be validated against
the biometric template included in the certificate. Without supporting such a
basic mechanism now, while the industry is still in the process of writing lots of
new applications, adding such features would require modifications to a very large
number of individual applications -- an almost hopeless task.

But I'm not trying at this time to suggest precisely what ancillary information
should be included. We are still trying to sort out whether it should be
done at all. Of course, even if a new signature algorithm ID is
defined, it doesn't have to be used, so it would be optional from that
standpoint. For the sake of interoperability, however, it would be a new
algorithm that would have to be widely supported, unless we can figure
out a mechanism for making the additional parameters transparent.

I do believe that specifying the suite of signature algorithms that are to be
supported is one of the functions of this group, so I believe the discussion is
appropriate for this list.

Bob>
>
>
>>>> <[email-masked]> 03/12 1:56 AM >>>
>All,
>
>In order to deal with the situation that a key-holder have
>multiple certificates and signs a message without giving any
>reference to which certificate should be used by the relying
>party when verifying the signature, Bob have proposed a
>redefinition of the ASN.1 signature macro.
>
>I think that this is a particularly bad idea...
>
>I agree that it should be recommended to clearly state under
>which role/certificate one signs something. But that is the
>responsibility of the signer and not of the CA. Also, stipulations
>of this kind is, IMHO, an application-level issue, not part of the
>PKI (and outside of this WG's charter). It may even be unnecessary.
>
>Suppose that Mr. X have two certificates (of the same key)
>for his two roles: as a private person and as an employee of
>a big company. Now this Mr. X signs a contract for that big
>company (as being an employee) but forgets to state in the
>signature which certificate that should be used to verify the
>signature. If that contract is bad business for the big company,
>then it may want to try to claim that it was signed by the private
>person X, not by the employee.
>
>It's clear that it can't be proved (cryptographicly) in court
>which certificate that is the correct one. But remember that
>it's as hard for the opponent, the big company, to prove that
>it was the private person X that signed the contract as it is
>for Mr. X to prove that it was him as an employee. In the worst
>case, the signature (and contract) could be judged as being
>unresolved (which may be bad enough though).
>
>I think this shows that when dealing with valuable signatures,
>such as contracts, it is in both parties (the key holder and the
>relying party) interest to clearly state which certificate that should
>be used. Even if the certificate isn't contained in the message to
>be signed due to flaws in the application design it could be the
>signers' responsibility to include it anyway (e.g. as a signed
>attachment).
>
>Regards,
>/Lars Johansson
>Sweden Post

Approved-By:  "Phillip M. Hallam-Baker" <[email-masked]>
Date:         Thu, 12 Mar 1998 10:43:19 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

>Sorry for this late reaction but it's been quite a task
>just to read all the contributions to this thread. I think
>the discussion so far have been very biased to, let me say,
>the "American soft-token" perspective. So, being a native
>European, let me improve that situation slightly.

I am also a European. I have not noticed a bias towards
soft certificates.

VeriSign certificates can be loaded onto a smartcard
(Gemplus or Schlumberger), I have a card and reader
myself. As a practical matter however smartcards
and readers are not yet ubiquitous.

The ambiguity problem is considerably worse with a smart
card than a soft certificate. The one declarative action that
is possible with the chip in card format is to insert the device
into a reader. Any variation in semantics must be captured
by the terminal - which cannot be considered as secure as
the card itself.

On the other hand I don't think we should wire any prohibition
on dual certification of keys into the standard, the practical
reason being that such a prohibition could not be enforced.
People are bound to do it whether or not it is a good idea.
Therefore it would not be a good thing for clients to rely on
it not taking place.

If there is not going to be an impact on the specififcation we
do not need to discuss it.

        Phill

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Thu, 12 Mar 1998 10:32:26 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

Rich;

>----------
>From:  Rich Ankney[SMTP:[email-masked]]
>Sent:  Wednesday, March 11, 1998 12:42 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] New Notary Protocol Draft
>
>----------
>> From: Robert Zuccherato <[email-masked]>
>> To: [email-masked]'; [email-masked]'
>> Subject: RE: [IETF-PKIX] New Notary Protocol Draft
>> Date: Wednesday, March 11, 1998 9:55 AM
>>
>> Rich;
>>
>> Thanks for your comments.  My responses are below.
>>
>> >----------
>> >From:        Rich Ankney[SMTP:[email-masked]]
>> >Sent:        Tuesday, March 10, 1998 1:16 PM
>> >To:  Robert Zuccherato; [email-masked]
>> >Subject:     Re: [IETF-PKIX] New Notary Protocol Draft
>> >
>> >
>> >2.  Is it possible to verify multiple signatures in the "ns" case?  I'm
>> >thinking of the case where I send a message of type (CMS) signedData
>> >which has multiple signerInfos attached.
>>
>> This is something I hadn't thought about before.  I don't know if I
>> really see the utility of allowing this (presently only one signature is
>> allowed).  Do you have a particular application in mind.
>
>I was thinking of ANSI X9.45 and related standards in the healthcare
>arena that use PKCS #7 (now CMS) SignedData with multiple
>signatures quite extensively.  Granted, the most common case of
>SignedData has just one SignerInfo, but I see no reason to preclude
>the case where multiple SignerInfo's are present.

Okay, fair enough.  I think we can allow multiple signers.
>
>> >
>> >3.  The relationship between request type, SignedData, and the embedded
>> >data is a little murky.
>>
>> Yeah, the idea behind separating the two services was to allow one to
>> get someone else's signature notarized (use the embedded data), but also
>> to give a format for the requester to have just their possession of the
>> data notarized, and to combine the services.  Any other thoughts on this
>> would be appreciated.
>>
>
>I like the idea of separating the two services.  I just think the text
>could
>be a little clearer.  Having complained, I'll of course draft some text to
>(hopefully) make things clearer.

Thanks.
>
>> >6.  Should the notary be able to do full path validation per X.509 v3
>> >(and PKIX-1)?  I.e. should the requester be able to pass the initial
>> >policy set and other stuff to the notary, and receive the policy
>> >qualifiers etc. back?
>>
>> Yes, that is what we are trying to accomplish here.  If we are missing
>> anything from the protocol that would allow this to happen, let me know.
>
>I'll take a look at the X.509/PKIX path processing algorithm and see
>what additional inputs/outputs are needed.  Question:  is the policy in
>the NotaryRequest and NotaryResponse supposed to identify a
>certificate policy?  It's not clear from the current text.

Presently the document says that the policy should indicate either the
policy under which the notarization is requested or the policy for which
the certificate validity is to be reported.  I could imagine actually
having two policy fields in the request and response, one for the
notarization policy and one for the certificate policy, if people
thought that would be useful.

        Robert.
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 12 Mar 1998 09:05:32 -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] Multiple certificates for same key?
To: [email-masked]

> From: [email-masked]
>
> Some people have argued that there's too many security risks
> involved when dealing with multiple certificates of the same
> key that it should be prohibited (or at least not recommended :-).
> I could give you many reasons why there shouldn't be any such
> restrictions but let me just give you an alternative perspective.

Please list some reasons for preferring multiple certificates per
key - that is one of the critical items of information missing from
the discussion so far.

What precisely are the three or four most important advantages of
multiple certification of keys?  Saving memory on tokens has already
been mentioned.

> In my point of view, multiple certificates of the same public key
> is not the problem. I think this is entirely a policy issue. The
> problem is instead storing of the private keys in software.
>
> In the Swedish electronic ID-card project (www.seis.se) the
> private keys are centrally generated by the CA and stored in
> the key-holders smart card. The RSA operations are performed
> on the chip so the private key never leaves the card. It is even
> unknown to the key-holder. This is of course stated in the CA's
> policy and CPS.

Private key storage mechanisms and multiple certificates are
separate issues.  When you have one security weakness (software
key storage) it tends to exacerbate security problems in other
areas (multiple certification).  But saying (or requiring) keys
to always be stored on tokens does not make the other problems
go away.  Sure, the private key(s) cannot be extracted from the
token without perhaps destructive reverse engineering.  But the
token can still be used by malicious applications to sign things
the user didn't intend to have signed.  The only way to prevent
that is to allow segregation of keys by purpose, and not store
the sensitive keys on tokens that will be highly exposed.

Approved-By:  Dan Geer <[email-masked]>
Date:         Thu, 12 Mar 1998 09:03:37 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dan Geer <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
To: [email-masked]

Q:
"What is a PKI?"

A:
This being a world of competition and/or
marketectures, I'd imagine that for practical
purposes Lewis Carroll had it right:
  forall(I) "A word means what I choose it to mean"

If that sounds flip, one could say that just
as the final word in software documentation is
the source so, in like manner, the final word
in PKI definition will be precisely what finally
works well enough for someone important to
actually base a mission critical business on.
We are not there yet.

Were it not for electronic commerce, a PKI would
be of mere academic interest.  Investments in
EC are made to make money, largely on the cost
reduction side of the ledger (which is the easiest
money to make).  Since there is no commerce without
contract, no contract without recourse, no recourse
without evidence, no evidence without signature,
and no signature without PKI, it looks like EC
is Applied PKI to me.  The rest is just bits.

--dan

>From: Oronzo Berlen <[email-masked]>
Approved-By:  [email-masked]
Date:         Thu, 12 Mar 1998 11:25:40 +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]
Organization: Olivetti Ricerca SCpA
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

What a reliance limit exactly is?
I know the italian legislation which is giong to be approved, where it seems there is nothig which sound like what you need.

Anyway there is a good description of international laws about digital signature and related matters at:
http://www.qmw.ac.uk/~tl6345/index.htm

Bob Jueneman wrote:

> Is anyone aware of any legislation, passed or pending, which takes any legal recognition of a "Reliance Limit", other than the Utah Digital Signature Act?
>
> I would be particularly interested to learn of any non-US jurisdictions who might be interested in  this.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
>
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
>
> "The most dangerous strategy is to cross a chasm in two jumps."

--
____________________________________________________________________
Oronzo Berlen                   | tel. 080.635-2112
Olivetti Ricerca                | fax. 080.635-2089
S.S. 271 Contrada la Marchesa | Email:[email-masked]
70020 Bitritto (BA)             |

Approved-By:  [email-masked]
Date:         Thu, 12 Mar 1998 09:56:38 +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] Cryptographic binding of certificates to signatures
To: [email-masked]

All,

In order to deal with the situation that a key-holder have
multiple certificates and signs a message without giving any
reference to which certificate should be used by the relying
party when verifying the signature, Bob have proposed a
redefinition of the ASN.1 signature macro.

I think that this is a particularly bad idea...

I agree that it should be recommended to clearly state under
which role/certificate one signs something. But that is the
responsibility of the signer and not of the CA. Also, stipulations
of this kind is, IMHO, an application-level issue, not part of the
PKI (and outside of this WG's charter). It may even be unnecessary.

Suppose that Mr. X have two certificates (of the same key)
for his two roles: as a private person and as an employee of
a big company. Now this Mr. X signs a contract for that big
company (as being an employee) but forgets to state in the
signature which certificate that should be used to verify the
signature. If that contract is bad business for the big company,
then it may want to try to claim that it was signed by the private
person X, not by the employee.

It's clear that it can't be proved (cryptographicly) in court
which certificate that is the correct one. But remember that
it's as hard for the opponent, the big company, to prove that
it was the private person X that signed the contract as it is
for Mr. X to prove that it was him as an employee. In the worst
case, the signature (and contract) could be judged as being
unresolved (which may be bad enough though).

I think this shows that when dealing with valuable signatures,
such as contracts, it is in both parties (the key holder and the
relying party) interest to clearly state which certificate that should
be used. Even if the certificate isn't contained in the message to
be signed due to flaws in the application design it could be the
signers' responsibility to include it anyway (e.g. as a signed
attachment).

Regards,
/Lars Johansson
Sweden Post

Approved-By:  [email-masked]
Date:         Thu, 12 Mar 1998 09:38:13 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Sorry for this late reaction but it's been quite a task
just to read all the contributions to this thread. I think
the discussion so far have been very biased to, let me say,
the "American soft-token" perspective. So, being a native
European, let me improve that situation slightly.

(I've noted that this thread actually has been split up in two.
Therefore I'll respond to the issue of "cryptographic binding
of certificates to signatures" in a separate mail.)

Some people have argued that there's too many security risks
involved when dealing with multiple certificates of the same
key that it should be prohibited (or at least not recommended :-).
I could give you many reasons why there shouldn't be any such
restrictions but let me just give you an alternative perspective.

In my point of view, multiple certificates of the same public key
is not the problem. I think this is entirely a policy issue. The
problem is instead storing of the private keys in software.

In the Swedish electronic ID-card project (www.seis.se) the
private keys are centrally generated by the CA and stored in
the key-holders smart card. The RSA operations are performed
on the chip so the private key never leaves the card. It is even
unknown to the key-holder. This is of course stated in the CA's
policy and CPS.

Now, if another CA would issue an alternative certificate to the
same key-holder and the same key (e.g. containing a different
email-address) this wouldn't normally cause any problems.

Either the other CA could require the key-holder to present his
"base" certificate in the certificate request before a new certificate
could be issued. In that case, the 2nd CA could check the original
CA's policy and CPS to see how the key was generated. It would
also be a way of prohibiting the key-holder from getting a certificate
in another persons name.

Or, in the other case, the 2nd CA doesn't do any such checking
against any base certificate in which case the relying party could
chose not to trust that CA's policy. Identification of key-holders and
key generation is perhaps the two most important issues within a
policy or CPS document.

What's needed is an option of sending an older certificate within a
certificate request to the CA.

Obviously, things gets more complicated when dealing with soft
tokens. That’s why we've chose not to do that (primarily) in the
Swedish SEIS project.

Kind regards,
/Lars Johansson
Sweden Post

Approved-By:  "Anil R. Gangolli" <[email-masked]>
Date:         Wed, 11 Mar 1998 16:29:58 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Anil R. Gangolli" <[email-masked]>
Organization: Structured Arts Computing Corp.
Subject:      Re: [IETF-PKIX] PKIX questions (DH key and Key Identifier)
To: [email-masked]

> 2. My other question is partly related to the above discussion, but
> regarding the algorithm for calculation of key identifier extensions.
> Ipki-part1 describes only in one place the way of calculating the value of
> key identifier. It is in section 4.2.1.2:
>
>    "The subject key identifier extension provides a means of identifying
>    the particular public key used in an application.  Where a reference
>    to a public key identifier is needed (as with an Authority Key
>    Identifier) and one is not included in the associated certificate, a
>    SHA-1 hash of the subject public key shall be used.  The hash shall
>    be calculated over the value (excluding tag and length) of the
>    subject public key field in the certificate.  This extension should
>    be marked non-critical."

Unfortunately "subject public key field" here is ambiguous.  I think this should
be clarified.  The implementations I know of that already do this use the
hash over the DER encoding of the whole SubjectPublicKeyInfo.  I think this is
the best interpretation as it includes the algorithm info as well as the key
in the hash.

--a.

--
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:[email-masked]

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 11 Mar 1998 15:50:41 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
To: [email-masked]

Given the understanding that "mechanically verified signed data" implies both

(a) "data was held and signed by keyholder" and
(b) "data has not been altered between point-of-signing and point-of-verify,"

I would define a PKI as:

  "a collection of protocols and procedures supporting broad automation in
  the assurance that the given keyholder possesses the (identity, authority,
  or attributes) to so vouch for or represent the data submitted in a given
  transaction."

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 11 Mar 1998 15:28:09 -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] Reliance limits in statutes
To: [email-masked]

Is anyone aware of any legislation, passed or pending, which takes any legal recognition of a "Reliance Limit", other than the Utah Digital Signature Act?

I would be particularly interested to learn of any non-US jurisdictions who might be interested in  this.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 11 Mar 1998 15:22:02 -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] Multiple certificates for same key?
Comments: To: [email-masked], Russ Housley <[email-masked]>
To: [email-masked]

Denis,

I agree with you.  (Maybe you would like a framed and notarized copy? :-)

Russ,

Before we relegate this problem to the S/MIME group, I'd like to
explore the possibility of a more general solution just a bit more. Although
it may be that the overhead, impact, yada, yada, of slightly revising the SIGNED
macro (or defining a new signature oid) will be too great for some
applications, the use of a specific signature algorithm OID would allow
that to be controlled.

Ideally, of course, the API calls wouldn't even change, except for the
OID definition. That may be a bit much to hope for, unless all of the
information is already in the certificate or can be obtained from the
operating system without an API call (e.g., the date/time).

But I would rather revise the one or two applications now to make use
of a common interface, rather than wait and have to revise applcations
one at a time later on.

Bob

>>> Denis Pinkas <[email-masked]> 03/11 3:04 PM >>>
Stephen,

As Russ said, this discussion also relates to the CMS document from the
smime wg and we should schedule a time slot in the pkix wg to talk about
it at the LA meeting.

In addition I would like to make a few comments on your two E-mails from
yesterday.

> Bob,
>
> I feel that the discussion of "which cert goes with this signature" is
> overblown.  I would argue that a relying party needs to acquire a cert that
> is valid and that contains a public key that validates the signature of the
> signed data.

This is the wrong way. The signer has to indicate which certificate must
be used. The verifier should have no free choice.

> If there is a only ine cert with a key that conforms to these
> requirements, we're done.

No. I would not like to re-open the POP discussion ... but if the
certificate identifier of the signer is part of the signed stuff, then
we can do "real-time" POP.

> if there's more than one, then the relying party
> has been given the opportunity to choose whichever one he wants. Many
> applications I know of send the end user cert as part of a transaction,
> messages, or session establishment protocol.

The basic question is whether the end user cert is signed or not.
Currently, it is not signed and this is the problem.

> Thus the relying party is
> saved the trouble of having to guess, and ambuigity is avoided.  When
> non-repudiation is an issue, then it is important to understand the
> implications of multuiple certification and users and CAs should behave
> accordingly.  However, if they choose poorly and create opportunities for
> abmiguity and possible deception, I'd back the relying party if he can
> produce a valid cert that is plausibly associated with the user and which
> works from a signature validation perspective.
>
> Steve

Second E-mail:

(... stuff deleted ...)

> Thus, I am not persuaded that we need to preclude multiple certification of
> a public key in PKIX, but I am in favor of including a brief warning about
> the possible pitfalls of this practice, and a suggestion that this practice
> be avoided for end user certs in most circumstances.

I do not think this is the right way to present the problem. You seem to
assume that the single problem has to do with the same user with two
certificates that contain the same public key. As indicated above, in
addition, we need to consider two different users each one with a
certificate that contains the same public key (the POP problem).

The recommendation should be, for the non-repudiation case, to make sure
that the signature at least includes the identifier of the certificate
(or the certificate itself). It might also include a certification path
(ie. a sequence of certificate identifiers).

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  John Hughes <[email-masked]>
Date:         Wed, 11 Mar 1998 22:21:14 +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: John Hughes <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
To: [email-masked]

I have also, at a more detailed level, in an abstract way, defined it
as:

THE AUTHENTICATION FRAMEWORK:  the infrastructure used to provide
authentication services, such as digital signatures.

THE CONFIDENTIALITY FRAMEWORK:  the framework used to enable two
communicating entities to share a secret key for the purpose of
encrypting/decrypting data.

KEY GENERATION:  how and where the keys are generated:  public/private
key pair for signatures,  public/private pair for symmetric key
distribution and symmetric keys for encryption.

MECHANISMS:  the algorithms used to provide a number of the services.

PROTOCOLS:  the protocols used between entities to transfer information.

However one could also define it according to the PKI management entities
described in Part III - but the Part III definition does not touch upon
the above.

John

At 13:03 11/03/98 -0800, you wrote:

>>>>

<excerpt>I have a definition:

<paraindent><param>left,out</param><italic>A framework that mediates the
transfer of all and only the

information to all and only the participants in a transaction.

</italic></paraindent>

Unfortunately, most approaches to PKI don't meet this deceptively
simple

definition, which I admittedly created to emphasize this inability ;)

It's been argued that a framework able to accomplish the above goes

beyond the requirements of a PKI.  I'm still wrestling with that, but

point out that the Xcert approach to on-line validation meets the above

definition while remaining compliant with the standards in existence.

A less ambitious definition might be:

<paraindent><param>left</param><italic>A system for maintaining the
privacy of private keys and the

publicity of public keys in a public key cryptosystem.

</italic></paraindent>

At least, fewer arguments will result from the latter definition ;)

Andrew

At 20:22 3/11/98 +0000, John Hughes wrote:

>>>>

<excerpt>I know this is a strange question, but

<paraindent><param>left</param>"What is a PKI?

</paraindent>This question was sparked off by some e-mail exchanges with
my ex-Bull colleague Denis Pinkas.  Denis got me thinking and I looked
through a number of papers/books/documents and I could not find a
definition - at least not a succinct one (which was in the order of 1/2
page to 1 page).

I have been involved with PKI "many" years (including, as may of you will
know, with the SOS TDP) and also having issued to the list some months
ago (as part of the SOS TDP project) an overview/intro on PKIX - I have
to admit I've never had recourse to define what is a PKI.

Does any one have anything - or is it too difficult to define in more
than a few sentences and less than half a book.  And more importantly can
we agree on the definition!

John

<paraindent><param>left</param>

</paraindent>

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

| John Hughes             [email-masked]                 |

| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |

|                         Main Office Tel:       +44(0)181 876 8666 |

| www.entegrity.com       Mobile:                +44(0)468 055070   |

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

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

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

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

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

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

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

| John Hughes             [email-masked]                 |

| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |

|                         Main Office Tel:       +44(0)181 876 8666 |

| www.entegrity.com       Mobile:                +44(0)468 055070   |

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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 11 Mar 1998 15:09: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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
Comments: To: [email-masked]
To: [email-masked]

Andrew, your message comes though in a very awkward format -- no message body, but a part.000 attachment that contains the message in HTML (it appears).  I've have to click on the message to access it, and then it is difficult to read once netwcape comes up to interpret the html.

Could you see if you can train Eudora to send non-MIME message if the abilities are MIME aren't really needed?

bob

>>> Andrew Csinger <[email-masked]> 03/11 2:03 PM >>>

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 11 Mar 1998 14:14:27 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Fwd: Re: [IETF-PKIX] Multiple Certificates
Comments: To: [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

Thanks, Brian. That's in accord with my recollection, but I wasn't sure.

With regard to Tony's Green card/Gold card scenario, I understood
that to be more or an illustrative example or metaphor than an actual
attack against SET or whatever.  He was merely pointing out
an easily understood (if not technically accurate) scenario whereby
either the originator or the recipient of a transaction might have some
reason to misattribute a given transaction against a set of credentials.

One could conceivably come up with something similar involving the use of
a woman's married name (Mrs. John Smith) vs. personal name (Susy Smith),
perhaps involving liability for debts in a messy divorce. Again, it is the
example rather than letter of the law that is moe important here.

Bob

>>> Brian Korver <[email-masked]> 03/11 11:49 AM >>>
Bob Jueneman writes:
> +----------------------------------------------------------------------+
> This message was addressed to:  [email-masked]
> +----------------------------------------------------------------------+
> The following message was posted in a discussion on the IETF-PKIX list, in =
> connection with an ongoing discussion of the desirability of allowing/depre=
> cating the issuance of multiple certificates containing a common public =
> key.
>
> To what extent does SET uniquely identify the certificate that is supposed =
> to be used to validate a digital signature? I.e., is the certificate =
> cryptographically bound to the transaction, or could a different certificat=
> e be substituted?

Bob,

The certificate is not always cryptographically bound to a transaction.
BTW, SET states no opinion about whether a given public key can appear in
multiple certificates.  My guess is that this will occur.

For computing a signature across data, SET uses PKCS#7 SignedData, which
uses IssuerAndSerialNumber to uniquely identify the certificate that
contains the public key portion of the keypair that generated the
signature.  Neither the signature nor the IssuerAndSerialNumber contained
in a raw (unencrypted) PKCS#7 SignedData are cryptographically protected
against substitution.  That is, for raw SignedData, an attacker is free to
change the IssuerAndSerialNumber, or to take the inner content and
re-compute a different SignedData message.  If SET had wanted to
cryptographically bind the signature to a certificate using a general
mechanism, it would have been possible to put IssuerAndSerialNumber
(or some other unique identifier) into the AuthenticatedAttributes.
These attributes are contained in the signature.

As for attacks described by Tony....  The cardholder chooses which
credit card (and therefore brand) to use for a transaction.  So it
isn't very interesting that the cardholder can substitute a different
credit card for the one that he/she initially used.

Conversely, the merchant cannot alter the signature because the
signature (the SignedData) is encrypted for the bank.  The merchant merely
passes the encrypted blob ("payment instructions" in SET lingo) on
to the bank.

As for the bank, even if the cardholder has the same keypair for both
brand X and brand Y, the bank cannot switch brands on the transaction.  The
credit card for brand X has different credit card number from the card for
Brand Y.  The credit card number is cryptographically protected by
the signature (at least for signed transactions).  Of course, if you are
this paranoid about the banks, then you probably should be using credit
cards.

> I certainly don't remember any such binding while I was working on the =
> spec in the early days, but things might have changed since. Does SET use =
> the standard X.509 SIGNED macro definition?

SET only uses the X.509 SIGNED macro for keying material.  All "data"
signatures use PKCS#7 SignedData (which, as I mentioned above, doesn't
cryptographically bind the signature to a certificate either).

Approved-By:  Andrew Csinger <[email-masked]>
Date:         Wed, 11 Mar 1998 13:03:08 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Andrew Csinger <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
To: [email-masked]

I have a definition:

<paraindent><param>left,out</param><italic>A framework that mediates the
transfer of all and only the

information to all and only the participants in a transaction.

</italic></paraindent>

Unfortunately, most approaches to PKI don't meet this deceptively
simple

definition, which I admittedly created to emphasize this inability ;)

It's been argued that a framework able to accomplish the above goes

beyond the requirements of a PKI.  I'm still wrestling with that, but

point out that the Xcert approach to on-line validation meets the above

definition while remaining compliant with the standards in existence.

A less ambitious definition might be:

<paraindent><param>left</param><italic>A system for maintaining the
privacy of private keys and the

publicity of public keys in a public key cryptosystem.

</italic></paraindent>

At least, fewer arguments will result from the latter definition ;)

Andrew

At 20:22 3/11/98 +0000, John Hughes wrote:

>>>>

<excerpt>I know this is a strange question, but

<paraindent><param>left</param>"What is a PKI?

</paraindent>This question was sparked off by some e-mail exchanges with
my ex-Bull colleague Denis Pinkas.  Denis got me thinking and I looked
through a number of papers/books/documents and I could not find a
definition - at least not a succinct one (which was in the order of 1/2
page to 1 page).

I have been involved with PKI "many" years (including, as may of you will
know, with the SOS TDP) and also having issued to the list some months
ago (as part of the SOS TDP project) an overview/intro on PKIX - I have
to admit I've never had recourse to define what is a PKI.

Does any one have anything - or is it too difficult to define in more
than a few sentences and less than half a book.  And more importantly can
we agree on the definition!

John

<paraindent><param>left</param>

</paraindent>

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

| John Hughes             [email-masked]                 |

| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |

|                         Main Office Tel:       +44(0)181 876 8666 |

| www.entegrity.com       Mobile:                +44(0)468 055070   |

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

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

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

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

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

Approved-By:  Peter Whittaker <[email-masked]>
Date:         Wed, 11 Mar 1998 15:44: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: Peter Whittaker <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
To: [email-masked]

>From:  John Hughes[SMTP:[email-masked]]
>I know this is a strange question, but

>       "What is a PKI?
>
>This question was sparked off by some e-mail exchanges with
>my ex-Bull colleague Denis Pinkas.  Denis got me thinking and I looked
>through a number of papers/books/documents and I could not find a
>definition - at least not a succinct one (which was in the order of 1/2
>page to 1 page).
>
>I have been involved with PKI "many" years (including, as may of you will
>know, with the SOS TDP) and also having issued to the list some months
>ago (as part of the SOS TDP project) an overview/intro on PKIX - I have
>to admit I've never had recourse to define what is a PKI.
>
>Does any one have anything - or is it too difficult to define in more
>than a few sentences and less than half a book.  And more importantly can
>we agree on the definition!

The paper available at

        http://www.entrust.com/resources/pdf/pki.pdf

may be of interest.

pww

>

Approved-By:  John Hughes <[email-masked]>
Date:         Wed, 11 Mar 1998 20:22:18 +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: John Hughes <[email-masked]>
Subject:      [IETF-PKIX] What is a PKI
To: [email-masked]

I know this is a strange question, but

<paraindent><param>left</param>"What is a PKI?

</paraindent>This question was sparked off by some e-mail exchanges with
my ex-Bull colleague Denis Pinkas.  Denis got me thinking and I looked
through a number of papers/books/documents and I could not find a
definition - at least not a succinct one (which was in the order of 1/2
page to 1 page).

I have been involved with PKI "many" years (including, as may of you will
know, with the SOS TDP) and also having issued to the list some months
ago (as part of the SOS TDP project) an overview/intro on PKIX - I have
to admit I've never had recourse to define what is a PKI.

Does any one have anything - or is it too difficult to define in more
than a few sentences and less than half a book.  And more importantly can
we agree on the definition!

John

<paraindent><param>left</param>

</paraindent>

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

| John Hughes             [email-masked]                 |

| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |

|                         Main Office Tel:       +44(0)181 876 8666 |

| www.entegrity.com       Mobile:                +44(0)468 055070   |

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

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Wed, 11 Mar 1998 09:55:07 -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] New Notary Protocol Draft
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

Rich;

Thanks for your comments.  My responses are below.

>----------
>From:  Rich Ankney[SMTP:[email-masked]]
>Sent:  Tuesday, March 10, 1998 1:16 PM
>To:    Robert Zuccherato; [email-masked]
>Subject:       Re: [IETF-PKIX] New Notary Protocol Draft
>
>1.  Could we add an extension capability to the request and response?

Yes, we certainly could.  Would something like the "extensions" field in
v3 certificates be what you are looking for?  That can easily be added.

I don't know if we need to define any specific extensions in this
document, we could just let people define their own.  Any thoughts?
>
>2.  Is it possible to verify multiple signatures in the "ns" case?  I'm
>thinking of the case where I send a message of type (CMS) signedData
>which has multiple signerInfos attached.

This is something I hadn't thought about before.  I don't know if I
really see the utility of allowing this (presently only one signature is
allowed).  Do you have a particular application in mind.
>
>3.  The relationship between request type, SignedData, and the embedded
>data is a little murky.

Yeah, the idea behind separating the two services was to allow one to
get someone else's signature notarized (use the embedded data), but also
to give a format for the requester to have just their possession of the
data notarized, and to combine the services.  Any other thoughts on this
would be appreciated.

>I interpret it as the following:
>
>   a)  All requests and responses are contained in SignedData.
>   For the ns and nc cases, this need not actually contain a
>   signature (SignerInfo); for npd and responses, it must contain
>   one SignerInfo.

Correct.
>
>   b)  For npd, the data must be of type "message".  For ns, the data
>   may be "message" or "messageImprint".  For nc, the data is "cert".

Not quite.  For npd, the data could be either "message",
"messageImprint" or "cert".  For this service the Notary Authority
doesn't examine the data, so it can be anything.  This service just
provides evidence that the requester possessed the data (and the
signature key) at that time.  The use of "messageImprint" allows this
evidence to be produced for private data.  The utility of using "cert"
in this situation is dubious, but it isn't disallowed.

Also, for ns the data must be of type "message".  For this service the
signature is contained in the "message", so it is not possible to use
"messageImprint"
>
>4.  It might be good to mention some useful formats in the Message
>structure, such as id-data and id-signedData.

Certainly.  Are there any others that should be included.
>
>5.  Since I may have multiple signatures on a message, can the "cert"
>option be extended to request status on multiple (signer) certificates?
>E.g. something like:
>
>       SEQUENCE {
>               targets         SEQUENCE OF Certificate,
>               chains          SEQUENCE OF Certificate }
>
>where targets are what I want status for, and chains contains the
>certificates needed to build the paths from targets to a trusted root.

That is a very good idea.  Yes, it can.
>
>6.  Should the notary be able to do full path validation per X.509 v3
>(and PKIX-1)?  I.e. should the requester be able to pass the initial
>policy set and other stuff to the notary, and receive the policy
>qualifiers etc. back?

Yes, that is what we are trying to accomplish here.  If we are missing
anything from the protocol that would allow this to happen, let me know.

        Robert.
>

Approved-By:  Rich Ankney <[email-masked]>
Date:         Wed, 11 Mar 1998 12:42:44 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
Comments: To: Robert Zuccherato <[email-masked]>
To: [email-masked]

----------
> From: Robert Zuccherato <[email-masked]>
> To: [email-masked]'; [email-masked]'
> Subject: RE: [IETF-PKIX] New Notary Protocol Draft
> Date: Wednesday, March 11, 1998 9:55 AM
>
> Rich;
>
> Thanks for your comments.  My responses are below.
>
> >----------
> >From:        Rich Ankney[SMTP:[email-masked]]
> >Sent:        Tuesday, March 10, 1998 1:16 PM
> >To:  Robert Zuccherato; [email-masked]
> >Subject:     Re: [IETF-PKIX] New Notary Protocol Draft
> >
> >1.  Could we add an extension capability to the request and response?
>
> Yes, we certainly could.  Would something like the "extensions" field in
> v3 certificates be what you are looking for?  That can easily be added.
>
> I don't know if we need to define any specific extensions in this
> document, we could just let people define their own.  Any thoughts?

The extensions field from the v3 certificate would be fine.  We have some
application-specific things in mind, but I don't think they need to be
standardized.

> >
> >2.  Is it possible to verify multiple signatures in the "ns" case?  I'm
> >thinking of the case where I send a message of type (CMS) signedData
> >which has multiple signerInfos attached.
>
> This is something I hadn't thought about before.  I don't know if I
> really see the utility of allowing this (presently only one signature is
> allowed).  Do you have a particular application in mind.

I was thinking of ANSI X9.45 and related standards in the healthcare
arena that use PKCS #7 (now CMS) SignedData with multiple
signatures quite extensively.  Granted, the most common case of
SignedData has just one SignerInfo, but I see no reason to preclude
the case where multiple SignerInfo's are present.

> >
> >3.  The relationship between request type, SignedData, and the embedded
> >data is a little murky.
>
> Yeah, the idea behind separating the two services was to allow one to
> get someone else's signature notarized (use the embedded data), but also
> to give a format for the requester to have just their possession of the
> data notarized, and to combine the services.  Any other thoughts on this
> would be appreciated.
>

I like the idea of separating the two services.  I just think the text
could
be a little clearer.  Having complained, I'll of course draft some text to
(hopefully) make things clearer.

> >I interpret it as the following:
> >
> >   a)  All requests and responses are contained in SignedData.
> >   For the ns and nc cases, this need not actually contain a
> >   signature (SignerInfo); for npd and responses, it must contain
> >   one SignerInfo.
>
> Correct.
> >
> >   b)  For npd, the data must be of type "message".  For ns, the data
> >   may be "message" or "messageImprint".  For nc, the data is "cert".
>
> Not quite.  For npd, the data could be either "message",
> "messageImprint" or "cert".  For this service the Notary Authority
> doesn't examine the data, so it can be anything.  This service just
> provides evidence that the requester possessed the data (and the
> signature key) at that time.  The use of "messageImprint" allows this
> evidence to be produced for private data.  The utility of using "cert"
> in this situation is dubious, but it isn't disallowed.
>
> Also, for ns the data must be of type "message".  For this service the
> signature is contained in the "message", so it is not possible to use
> "messageImprint"

OK.  I get it now...

> >
> >4.  It might be good to mention some useful formats in the Message
> >structure, such as id-data and id-signedData.
>
> Certainly.  Are there any others that should be included.

Those are the only two I can think of right now.

> >
> >5.  Since I may have multiple signatures on a message, can the "cert"
> >option be extended to request status on multiple (signer) certificates?
> >E.g. something like:
> >
> >     SEQUENCE {
> >             targets         SEQUENCE OF Certificate,
> >             chains          SEQUENCE OF Certificate }
> >
> >where targets are what I want status for, and chains contains the
> >certificates needed to build the paths from targets to a trusted root.
>
> That is a very good idea.  Yes, it can.
> >
> >6.  Should the notary be able to do full path validation per X.509 v3
> >(and PKIX-1)?  I.e. should the requester be able to pass the initial
> >policy set and other stuff to the notary, and receive the policy
> >qualifiers etc. back?
>
> Yes, that is what we are trying to accomplish here.  If we are missing
> anything from the protocol that would allow this to happen, let me know.

I'll take a look at the X.509/PKIX path processing algorithm and see
what additional inputs/outputs are needed.  Question:  is the policy in
the NotaryRequest and NotaryResponse supposed to identify a
certificate policy?  It's not clear from the current text.

>
>       Robert.
> >

Regards,
Rich

Approved-By:  David Boyce <[email-masked]>
Date:         Wed, 11 Mar 1998 15:36:36 +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] PKIX questions (DH key and Key Identifier)
To: [email-masked]

I wrote:
>
>For a BIT STRING, the unused bits octet is part of the length field and should
> therefore be omitted.

I then decided to check the standard.  That octet is part of the content octets rather than the length field, as I had erroneously stated.  So Nada's question still stands.

My apologies for speaking too soon.
--
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;

Approved-By:  David Boyce <[email-masked]>
Date:         Wed, 11 Mar 1998 15:27:13 +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] PKIX questions (DH key and Key Identifier)
To: [email-masked]

John Hughes writes on behalf of Nada (no email address supplied):

>In other words, there is a difference in the first byte of the bit string
>coding that tells how many bits in the last byte are unused (in the case of
>sequence none - hence the zero byte to start bit string with).
>
>My question is which of these two values should be used for the calculation
>of key identifier?

For a BIT STRING, the unused bits octet is part of the length field and should therefore be omitted.

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

Approved-By:  John Hughes <[email-masked]>
Date:         Wed, 11 Mar 1998 14:22:44 +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: John Hughes <[email-masked]>
Subject:      [IETF-PKIX] PKIX questions (DH key and Key Identifier)
To: [email-masked]

Nada has asked me to post the following questions.  For some reason she is
prevented from talking on the list.

John

________________________________________________

To authors of part 1 on certificate and CRL profile,

I have two questions:

1. The first one is regarding the coding of SubjectPublicKey in case of DSA
and DH keys.
Section 7.3.3 states that:

   "The DSA public key shall be ASN.1 encoded as an INTEGER; this
   encoding shall be used as the contents (i.e., the value) of the
   subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
   data element.

        DSAPublicKey ::= INTEGER -- public key Y"

However, section 7.3.2 uses completely different rules for coding
Diffe-Hellman public key, which is also an integer:

   "The Diffie-Hellman public key (an INTEGER) is mapped to a
   subjectPublicKey (a BIT STRING) as follows: the most significant bit
   (MSB) of the INTEGER becomes the MSB of the BIT STRING; the least
   significant bit (LSB) of the INTEGER becomes the LSB of the BIT
   STRING."

Is there any reason for this inconsistency?
It would be natural to code DH key in the same way as DSA key (and RSA key
which is a sequence of two ASN.1 coded integers).

2. My other question is partly related to the above discussion, but
regarding the algorithm for calculation of key identifier extensions.
Ipki-part1 describes only in one place the way of calculating the value of
key identifier. It is in section 4.2.1.2:

   "The subject key identifier extension provides a means of identifying
   the particular public key used in an application.  Where a reference
   to a public key identifier is needed (as with an Authority Key
   Identifier) and one is not included in the associated certificate, a
   SHA-1 hash of the subject public key shall be used.  The hash shall
   be calculated over the value (excluding tag and length) of the
   subject public key field in the certificate.  This extension should
   be marked non-critical."

I have a problem interpreting the sentence "The hash shall be calculated
over the value (excluding tag and length) of the subject public key field
in the certificate."

SubjectPublicKey is defined as a BIT STRING:

   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

and a value of the BIT STRING depends on the type of the public key. For
example for RSA keys it is:

      RSAPublicKey ::= SEQUENCE {
         modulus       INTEGER, -- n
         publicExponent     INTEGER  -- e }

So, I guess one should just take the value of bit string without its tag
and length. However, this value does not necessarily have to be the same as
the DER coding of RSAPublicKey.

>From an example RSA certificate in appendix D.3 subject public key is coded
as follows (page 107):

             { subject's public key }
             03 6b  BIT STRING length 107 bytes (856 bits)
                               0030 6802 6100 beaa 8b77 54a3 afca 779f
                               2fb0 cf43 88ff a66d 7955 5b61 8c68 ec48
                               1e8a 8638 a4fe 19b8 6217 1d9d 0f47 2cff
                               638f 2991 04d1 52bc 7f67 b6b2 8f74 55c1
                               3321 6c8f ab01 9524 c8b2 7393 9d22 6150
                               a935 fb9d 5750 32ef 5652 5093 abb1 8894
                               7856 15c6 1c8b 0203 0100 01

So, the value of bit string, without its tag and length, is:

                               0030 6802 6100 beaa 8b77 54a3 afca 779f
                               2fb0 cf43 88ff a66d 7955 5b61 8c68 ec48
                               1e8a 8638 a4fe 19b8 6217 1d9d 0f47 2cff
                               638f 2991 04d1 52bc 7f67 b6b2 8f74 55c1
                               3321 6c8f ab01 9524 c8b2 7393 9d22 6150
                               a935 fb9d 5750 32ef 5652 5093 abb1 8894
                               7856 15c6 1c8b 0203 0100 01

However, the coding of RSAPublicKey is only the part:

                               30 6802 6100 beaa 8b77 54a3 afca 779f
                               2fb0 cf43 88ff a66d 7955 5b61 8c68 ec48
                               1e8a 8638 a4fe 19b8 6217 1d9d 0f47 2cff
                               638f 2991 04d1 52bc 7f67 b6b2 8f74 55c1
                               3321 6c8f ab01 9524 c8b2 7393 9d22 6150
                               a935 fb9d 5750 32ef 5652 5093 abb1 8894
                               7856 15c6 1c8b 0203 0100 01

In other words, there is a difference in the first byte of the bit string
coding that tells how many bits in the last byte are unused (in the case of
sequence none - hence the zero byte to start bit string with).

My question is which of these two values should be used for the calculation
of key identifier?

I apologize for giving so many details, but I felt this is the easiest way
to explain the problem.

Regards,

Nada

 -------------------------------------------------------------------
| John Hughes             [email-masked]                 |
| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |
|                         Main Office Tel:       +44(0)181 876 8666 |
| www.entegrity.com       Mobile:                +44(0)468 055070   |
 -------------------------------------------------------------------

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Wed, 11 Mar 1998 14:04:40 -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] Multiple certificates for same key?
To: [email-masked]

Stephen,

As Russ said, this discussion also relates to the CMS document from the
smime wg and we should schedule a time slot in the pkix wg to talk about
it at the LA meeting.

In addition I would like to make a few comments on your two E-mails from
yesterday.

> Bob,
>
> I feel that the discussion of "which cert goes with this signature" is
> overblown.  I would argue that a relying party needs to acquire a cert that
> is valid and that contains a public key that validates the signature of the
> signed data.

This is the wrong way. The signer has to indicate which certificate must
be used. The verifier should have no free choice.

> If there is a only ine cert with a key that conforms to these
> requirements, we're done.

No. I would not like to re-open the POP discussion ... but if the
certificate identifier of the signer is part of the signed stuff, then
we can do "real-time" POP.

> if there's more than one, then the relying party
> has been given the opportunity to choose whichever one he wants. Many
> applications I know of send the end user cert as part of a transaction,
> messages, or session establishment protocol.

The basic question is whether the end user cert is signed or not.
Currently, it is not signed and this is the problem.

> Thus the relying party is
> saved the trouble of having to guess, and ambuigity is avoided.  When
> non-repudiation is an issue, then it is important to understand the
> implications of multuiple certification and users and CAs should behave
> accordingly.  However, if they choose poorly and create opportunities for
> abmiguity and possible deception, I'd back the relying party if he can
> produce a valid cert that is plausibly associated with the user and which
> works from a signature validation perspective.
>
> Steve

Second E-mail:

(... stuff deleted ...)

> Thus, I am not persuaded that we need to preclude multiple certification of
> a public key in PKIX, but I am in favor of including a brief warning about
> the possible pitfalls of this practice, and a suggestion that this practice
> be avoided for end user certs in most circumstances.

I do not think this is the right way to present the problem. You seem to
assume that the single problem has to do with the same user with two
certificates that contain the same public key. As indicated above, in
addition, we need to consider two different users each one with a
certificate that contains the same public key (the POP problem).

The recommendation should be, for the non-repudiation case, to make sure
that the signature at least includes the identifier of the certificate
(or the certificate itself). It might also include a certification path
(ie. a sequence of certificate identifiers).

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Russ Housley <[email-masked]>
Date:         Wed, 11 Mar 1998 04:51:32 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Denis:

I suggest that the [email-masked] lists is the place for this
discussion.  PLease raise this issue there, and we can discuss it ...

Russ

At 03:11 PM 3/9/98 -0800, Denis Pinkas wrote:
>David,
>
>You posted a VERY important E-mail last week and I am bringing my
>support to it.
>
>> The X.509 "SIGNED" macro might not have been designed with the intent
>> of supporting this purpose, and so may be excused for not including
>> a method of binding a certificate to the signed data.
>>
>> However, the IETF CMS specification (aka PKCS#7) was designed for
>> precisely this purpose (providing non-repudiation grade signatures over
>> generic content), yet it still does not provide a clean method of
>> binding the signer's certificate to the content.
>
>True.
>
>> The CMS definition of SignedData includes {content, certs, crls,
>> signerInfos}, and some other fields.  There may be multiple signatures
>> applied to the content, each represented by a SignerInfo.  Each
>> SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
>> Because the issuerAndSerialNumber field, which uniquely identifies the
>> certificate used by the signer, is not covered by the signature, it is
>> not bound to the content.  I'm not sure why PKCS#7 was designed that
>> way, but it was, and so is CMS.
>
>I believe that at the time, PKCS#7 was written, the authors had not
>non-repudiation in mind, but simply using a digital signature for
>authenticating a message in real time. For that purpose, the format was
>fine.
>
>> It would have been preferable to define an issuerAndSerialNumber
>> attribute, which could have been included either in
>> authenticateAttributes to bind it with the signature, or in
>> unauthenticatedAttributes if the current semantics of not binding the
>> signer's cert to the signed content is desired.
>
>As the CMS standard is being rewritten in the smime working group,
>(draft-ietf-smime-cms-03.txt) and since the editor is Russ Housley also
>a member of the PKIX working group I think it is the perfect time to
>suggest to make changes. What do you think Russ ?
>
>> Perhaps defining a redundant copy of issuerAndSerialNumber, to be
>> included in authenticatedAttributes, could address the requirement
>> without breaking backward compatibility.  (It only covers the signer's
>> cert, not the full path, but it's a start.)
>
>Yes. Without breaking compatibility we could also support a SEQUENCE OF
>issuerAndSerialNumber. The simple change that is needed is to add this
>attribute in the section 11 (Useful Attributes) from the CMS document.
>In addition we should mandate the support of such an attribute, if the
>signed data is to be used in a non-repudiation process.
>
>> The uglier alternative is  is to double-sign everything, encapsulating a
>> signedData within another signedData for each parallel signature.
>>
>> Since CMS is intended to be a generic security encapsulation mechanism,
>> not just an S/MIME-specific structure, those who feel that this
>> requirement is important (to address either multiple certification of
>> keys or proof-of-possession) should discuss it in the S/MIME working
>> group.  (A SigningTime attribute is already defined in CMS, but a
>> "location" attribute is not.)
>

>Unfortunately I am not yet on this mailing list, so why I respond here.
>
>Denis
>
>--
> ***  Please note that the E-mail address has changed ! Update it.  ***
>      Denis Pinkas     Bull S.A.          mailto:[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
>

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 11 Mar 1998 00:33: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

Bob,

I feel that the discussion of "which cert goes with this signature" is
overblown.  I would argue that a relying party needs to acquire a cert that
is valid and that contains a public key that validates the signature of the
signed data.  If there is a only ine cert with a key that conforms to these
requirements, we're done.  if there's more than one, then the relying party
has been given the opportunity to choose whichever one he wants. Many
applications I know of send the end user cert as part of a transaction,
messages, or session establishment protocol.  Thus the relying party is
saved the trouble of having to guess, and ambuigity is avoided.  When
non-repudiation is an issue, then it is important to understand the
implications of multuiple certification and users and CAs should behave
accordingly.  However, if they choose poorly and create opportunities for
abmiguity and possible deception, I'd back the relying party if he can
produce a valid cert that is plausibly associated with the user and which
works from a signature validation perspective.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 11 Mar 1998 00:33:45 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

Folks,

Here is my take on the multiple certs with the same key issue:

        - there are legitimate circumstances when this will happen, e.g.,
unidirectional cross-certification and cert reissuance

        - there are circumstances where this is a terrible idea, e.g.,
conflicting key usage constraints or in some non-repudiation contexts

        - some complaints about the problem in a non-repudiation context
are overblown, i.e., one can argue that if you manage to have the same key
in multiple certs with different liability or authorization implications,
then a "relying party" can produce the cert of its choice to substantiate
why a signed message/document was accepted and in many cases the user will
not be able to refute this assertion.  in such cases, the user gets what he
deserves for having  allowed a key to be legitimately, multiply certified!

        - most software we use today avoids this problem, by default, as do
some (most) crypto tokens

        - smart cards may want to make use of this feature because of
storage limitations

        - a CA who insists on not multiplying certifying a key should state
so in a CPS, and/or embody technical measures o minimize the likelihood
that this will happen

        - it would be hard to enumerate the circumstances where multiple
certification it's OK, vs. not OK

Thus, I am not persuaded that we need to preclude multiple certification of
a publci key in PKIX, but I am in favor of including a brief warning about
the possiboe pitfalls of this practice, and a suggestion that this practice
be avoided for end user certs in mosy circumstances.

Steve

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 10 Mar 1998 19:34:09 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Tony,
>
>I am curious that no one took me up on what might be another source of
>key-overloading;  A "low-cost CA" willing to issue a narrow attribute,
>role or authorization certificate, and relying upon the existence of a
>"classy ID certificate" for its validity, the CA essentially riding
>piggy-back upon the due diligence of the more reputable CA.
>Good examples don't come to mind, but I just get a feeling...

Here's one: A company collects code signing certificates issued by
VeriSign for Netscape or Microsoft browsers, extracts the public
keys, and creates certificates granting "Pond-Scum Platinum"
status to the company which was issued the code-signing certificate.

Unfortunately, the software vendor, believing that the only exposure
which he might face in connection with the use of his certificate lay in
erroneously signing code containing bugs, has very carefully isolated
the use of the key to within the QC department, but has not implemented
any other procedures.  Now a evil malefactor in QC decides to use his
new Platinum card certificate and the code signing key to which he has
legitimate access to order a brand new Lear jet. It is charged to
the company card and is to be delivered to a small private airstrip in the
New Mexico desert. He flies off, laughing, never to be seen again.
Pond-scum Platinum says to the company, "You digitally signed
for it, ergo you bought it. What happened then isn't our concern."

The company retorts that they never requested the issuance of the certificate,
but the CA claims that the missing employee gave the verbal OK.

Bob

Approved-By:  Dan Geer <[email-masked]>
Date:         Tue, 10 Mar 1998 19:55: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: Dan Geer <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

    >>>>> "David" == David P Kemp <[email-masked]> writes:

     David> Tony's characterization is eloquent enough that it cannot be
     David> improved upon, but merely restated.  By following the "wallet
     David> and paper signature" model and having a single public key
     David> which announces "This Is Me!", users would be voluntarily
     David> adopting the very thing they refuse to have imposed upon them
     David> externally: a national ID.

    That it true if one were to adopt a restriction that any particular
    user MUST have exactly one key.  But I don't believe that has been
    proposed.

yeah, here we go again.  if the name and the key
don't have many to many mappings, you lose liberty.

--dan

MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Approved-By:  Frank O'Dwyer <[email-masked]>
Date:         Tue, 10 Mar 1998 22:04:15 -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: "Frank O'Dwyer" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

>Few application protocols (and according to the chair of the S/MIME
>working group, *no* email protocols) include any means of preventing
>certificate substitution, so key sharing is a vulnerability.
>
>Am I missing something?

Well, it can equally be argued that having one key per certificate
introduces a single point of failure and violates the principle
of least privilege (from the perspective of a relying party attempting
to minimise threats due to trusting CAs).

In other words, assuming that there could be two or more
independent certificates for the same key, then a relying party could
require several certs before accepting a key (protecting against rogue
CAs), and can also temporarily "fly on one engine" should one of the
CAs be compromised or otherwise break down. The CAs are also
individually less attractive targets for an attacker.

Also as you point out the case you raise can be addressed by
having different key pairs per context, or by binding certificates
to messages (actually I think it would be better to just bind
selected attributes to messages, as in general a signer has
no way of predicting which certificate(s) relying parties will
trust).

Cheers,
Frank O'Dwyer.

MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Approved-By:  Frank O'Dwyer <[email-masked]>
Date:         Tue, 10 Mar 1998 22:01:02 -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: "Frank O'Dwyer" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

>But do we sign with a certificate, or with a key?  I don't think that key
>and certificate are synonymous.  If the context of the certificate matters
>to the signature, then I should include the certificate in the signed
>message.

Unfortunately in general a signer has no reliable means
of predicting which certificate(s) a verifier will trust. For
example it is pointless to demand that verifiers use your
Verisign certificate if some of your audience simply don't
trust Verisign.

What really seems intended, and what might work instead,
would be to include the intended certified attributes in the
signature - in effect the signer would say "I intend to make
this signature as Joe Bloggs with extension OIDs a.b.c=foo,
x.y.z=bar".  Then it would be up to each verifier to find some
certificate(s) that authenticated those attributes for it.  The
signer could include some certificates as hints perhaps,
and/or as a convenient syntax for asserting the desired
attributes.

The above seems like an application matter, though. Also
it may be simpler to just use a different private key for
each context.

Cheers,
Frank O'Dwyer.

Approved-By:  "Brian M. Thomas" <[email-masked]>
Date:         Tue, 10 Mar 1998 14:10:02 -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] Cryptographic binding of certificates to signatures
To: [email-masked]

David Kemp wrote:
> I look at it somewhat differently.  Issuing a single certificate
> per key provides the cryptographic binding between the signature
> and the certificate; proposals to share keys between certificates
> reduce that to a binding between the signature and the union of
> all certificates which share the key.
>

Unless I really misunderstand you here, I must say that this is simply
false.  *Proof* of the issuance of a single certificate per key could
provide the cryptographic binding of signature to certificate; I invite
the cryptographers to show me how this could be accomplished.

What am I missing?

brian

Approved-By:  John Pawling <[email-masked]>
Date:         Tue, 10 Mar 1998 14:35:46 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: John Pawling <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

All,

Does anybody have a patent regarding the protocols described in the Notary
Protocols I-D (draft-adams-notary-01.txt)??  Is there anybody who is in the
process of applying for a patent regarding the Notary Protocols described in
the draft??  Is there anybody that believes that he/she/it has intellectual
property in this area and plans to apply for a patent regarding the Notary
Protocols described in the draft??

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

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Tue, 10 Mar 1998 11:13:56 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP using ASN.1
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

Hi Mike (and All),
    Didn't ever want to imply that the OCSP draft I posted had your
endorsement (I thought my preamble made that clear, but perhaps I should
have been clearer). Since I took a lot of material from your original
draft,
I didn't feel right about removing your name from the author list. If
this
was a breach of protocol, I apologize. I'll remove your name from the
author list in any future posts.

Would still be interested in your comments about the writeup itself.

Regards,
Ambarish

Michael Myers wrote:
>
> All,
>
> I want folks to know that the OCSP draft distributed by Ambarish does not
> have my endorsement.  My name was placed on it without my consent.  As the
> primary author of OCSP, I wish to point out that Ambarish's draft should be
> considered an individual submission.  The standards-track OCSP draft is
> available for review on the IETF web site.
>
> I have discussed the basis of the ASN.1 requirement with Rich Ankney, my
> co-author on the OCSP standards-track draft.  We agree that OCSP is and
> should remain a very simple protocol to solve a very simple problem and that
> the current OCSP syntax is sufficient for the requirements being addressed.
> We recognize however that it may not provide all the capabilities that an
> ASN.1-based version could address.  We further agree that the scope of
> problems addressed by this counter-proposal would actually be better couched
> as extensions to the Notary Protocol draft.
>
> Mike

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Tue, 10 Mar 1998 11:10:32 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
Comments: cc: "David P. Kemp" <[email-masked]>
To: [email-masked]

At 09:32 AM 3/10/98 -0500, you wrote:
>> From: "Balluffi, Frank" <[email-masked]>
>>
>> What is the foundation or context for this discussion: WHAT ATTACKS ARE
>> WE CONCERNED ABOUT?
>
>
>In addition to the four operational disadvantages listed in a prior
>message, I thought up the following actual attack this morning
>in the shower :-)
>
>Consider two credit cards with different policies: the Green card
>is free and offers no benefits; the Gold card costs .1% per transaction
>but offers replacement insurance up to $1000 on goods purchased.
>
>It is in the user's interest to use the Green card for every transaction,
>unless the goods received turn out to be defective, in which case the
>user might try to substitute the Gold card on the purchase transaction.
>
>The credit card company has the opposite incentive, to switch all
>transactions to the Gold card.  And if the merchant pays a different
>fee or gets a different commission from the two cards, the merchant
>has an incentive to swap certificates too.
>
>Certificate substitution would be prevented by using different keys,
>by binding the cert to the transaction, or both.  In the case of
>credit cards, any reasonable commerce protocol would bind the cert
>into the transaction.  But the attack applies whenever there
>are certificates with a shared key and conflicting incentives;
>the incentives could be information-based rather than monetary.
>Few application protocols (and according to the chair of the S/MIME
>working group, *no* email protocols) include any means of preventing
>certificate substitution, so key sharing is a vulnerability.
>
>Am I missing something?

No.  And I really like this example!  It neatly illustrates motivations
for certificate substitution in both directions.  And your last paragraph
addresses most of my questions regarding your point in the previous letter
concerning varied key expirations - linking usage to certificate would
largely obviate the problem, true?

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Tue, 10 Mar 1998 10:53:41 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: cc: "David P. Kemp" <[email-masked]>
To: [email-masked]

Dave,

At 08:57 AM 3/10/98 -0500, David Kemp wrote, in part:
>
>Tony's characterization is eloquent enough that it cannot be improved
>upon, but merely restated.  By following the "wallet and paper signature"
>model and having a single public key which announces "This Is Me!", users
>would be voluntarily adopting the very thing they refuse to have
>imposed upon them externally: a national ID.

Thank you for the generous characterization.

>My primary objection to multiple certification is the lack of handling
>flexibility, not usage tracking.  If certificates are analogous to the
>contents of a wallet, then I would like to be able to dynamically decide
>what to carry in my wallet depending on where I'm going.  Normally I'd
>carry everything, for convenience.  But if I'm going on a trip, I'd
>remove the cards I'm not expecting to need so that if the wallet is
>lost or stolen, I don't have to cancel everything.

[minor snip]

>I might normally want to keep my "AMEX Platinum" key on my smartcard,
>but if I were going to plug that smartcard into a mall kiosk or an IETF
>terminal room machine, I'd rather take the AMEX key off and leave just
>an S/MIME email key on the card.

Agreed.  This is another Very Good Reason for separate keys.

>The third objection to multiple certification is that it leads
>inexorably to a permanent key that cannot be updated.  Although it is
>impossible for a single CA to verify that a key has not been certified
>somewhere else, it is certainly possible and often desirable for that
>CA to ensure that the key is changed at renewal.  But if a single key
>is used for all certificates, and the validity dates for all CAs are
>not synchronized, then it is impossible for any CA to rekey it's own
>subjects' certificates, much less establish rekey periods that are
>appropriate for the purpose of the certificates.

This is the one point I don't quite follow.  If a CA feels that the time
has come to expire *its certification* of a key, and to require that the
owner have a new key certified, I don't quite see how independent
certifications that have not expired need to be factored in.

At least, not "in principle."  Of course, this assumes that the relying
party can demand the key possesses a valid certificate suitable for the
*purposes of the transaction*, and did so at the time of the signing.
This "missing linkage" of signature to certificate, and how to address it,
is being debated by Bob Jueneman and Denis Pinkas at present.

And as Dwight Arthur pointed out, "cross certification" cannot exist
without there being multiple certificates on a single key, and so the
protocol must deal with the situation.  If in particular, then perhaps
best in general.  Granted that in this case, the certificates may be
considered "equipotent" and so the issue of "which one" is less pressing.

Personally, I would avoid overloading any key, of course, for the other
reasons you have given.

I am curious that no one took me up on what might be another source of
key-overloading;  A "low-cost CA" willing to issue a narrow attribute,
role or authorization certificate, and relying upon the existence of a
"classy ID certificate" for its validity, the CA essentially riding
piggy-back upon the due diligence of the more reputable CA.
Good examples don't come to mind, but I just get a feeling...

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 10 Mar 1998 13:48: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] Cryptographic binding of certificates to signatures
To: [email-masked]

> From: Bob Jueneman <[email-masked]>
>
> If we were able to somehow add cryptographic binding of
> the digital signature to the specific certificate that is s
> supposed to be used to validate it, virtually all of my objections
> to issuing more than one certificate per key would disappear,
> and we would be left with some of the positive virtues of that
> approach that others have mentioned.

I look at it somewhat differently.  Issuing a single certificate
per key provides the cryptographic binding between the signature
and the certificate; proposals to share keys between certificates
reduce that to a binding between the signature and the union of
all certificates which share the key.

I agree that it would be desirable to increase assurance by creating new
signature algorithms and/or new application-protocol capabilities to
bind the cert to the signature.  But that won't happen overnight.

What are the positive virtues of shared keys?  The only ones I've
seen are the possibility of saving some memory, and the gut feeling
that it would be nice to have one signature key represent one person.

There are some circumstances where using the same key in multiple
certificates is reasonable:

* cross-certification: the union of all certificates with the same
  CA as a subject offers no advantage over any particular single
  certificate, thus there's no benefit to be gained by swapping
  certs.  The purpose of a CA key is to sign certificates and CRLs
  which can later be validated - if more than one path leading through
  a particular CA can be constructed and validated, then the properties
  of any single path are not affected by whether other paths use the
  same key.

* renewal: if certificates are issued periodically with no change
  in contents except the validity period, then there is no vulnerability
  (except increased key lifetime) introduced by recertifying the
  same key.  Or, to put it another way, if a key is used for a fixed
  period (say 5 years), then there is no difference between issuing
  a single cert with 5 year validity or 5 otherwise identical certs
  with 1 year validities.  Since shorter validities may make CRLs
  shorter, recertifying the same key is useful.

Once you get beyond the cases where sharing keys is clearly harmless,
things get more difficult to understand.  Is it OK to recertify a
key if just the person's name changed?  I dunno. It seems reasonable
that a person would have the identical liabilities and obligations
regardless of what name that person used.  But if there were some
instance where Alice Smith has different legal responsibilities
than Mrs. Alice Smith-Jones, then they should use different keys
lest either Alice or an adversary would find it profitable to
swap certs on some signed item.

Approved-By:  John Pawling <[email-masked]>
Date:         Tue, 10 Mar 1998 13:38:22 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: John Pawling <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

Robert,

Does Nortel/Entrust have a patent on the protocols described in the Notary
Protocols I-D (draft-adams-notary-01.txt)??  Is Nortel/Entrust in the
process of applying for a patent on the Notary Protocols described in the
draft??  Does Nortel/Entrust have any plans to apply for a patent on the
Notary Protocols described in the draft??

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

Approved-By:  "Brian M. Thomas" <[email-masked]>
Date:         Tue, 10 Mar 1998 11:56:20 -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] Multiple Certificates
To: [email-masked]

> In addition to the four operational disadvantages listed in a prior
> message, I thought up the following actual attack this morning
> in the shower :-)

Those are the best kind.

> Consider two credit cards with different policies: the Green card
> is free and offers no benefits; the Gold card costs .1% per transaction
> but offers replacement insurance up to $1000 on goods purchased.
>
> It is in the user's interest to use the Green card for every transaction,
> unless the goods received turn out to be defective, in which case the
> user might try to substitute the Gold card on the purchase transaction.
>
> The credit card company has the opposite incentive, to switch all
> transactions to the Gold card.  And if the merchant pays a different
> fee or gets a different commission from the two cards, the merchant
> has an incentive to swap certificates too.
>
> Certificate substitution would be prevented by using different keys,
> by binding the cert to the transaction, or both.  In the case of
> credit cards, any reasonable commerce protocol would bind the cert
> into the transaction.  But the attack applies whenever there
> are certificates with a shared key and conflicting incentives;
> the incentives could be information-based rather than monetary.
> Few application protocols (and according to the chair of the S/MIME
> working group, *no* email protocols) include any means of preventing
> certificate substitution, so key sharing is a vulnerability.
>
> Am I missing something?
>

I don't think you're missing anything, really.  In my yet-incipient
concepts of electronic transactions, it seems absolutely essential that
all terms of an agreement be explicit, incorporated by reference, or
legally inferrable from the transaction itself.  The key itself offers
no such evidence; only the certificates that confer the authorization
to spend the money in the accounts.  Therefore the transaction does not
say merely "I will give you some money" but "I authorize payment by this
means and under these terms ..." specifying the payment mechanisms, account
numbers, etc.  The other party would only accept the contract if these were
all spelled out as part of the contract.  So I would agree with the notion
that the authorizing certificate needs to be a part of any signed contract,
irrespective of your position on multiple certs per key.

brian

Brian Thomas, CISSP - Distributed Systems Architect  [email-masked]
Southwestern Bell                                    [email-masked]
One Bell Center,  Room 34G3                          Tel: 314 235 3141
St. Louis, MO 63101                                  Fax: 314 235 0162

Approved-By:  Rich Ankney <[email-masked]>
Date:         Tue, 10 Mar 1998 13:16:53 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
Comments: To: [email-masked]
To: [email-masked]

A few comments on the new draft:

1.  Could we add an extension capability to the request and response?

2.  Is it possible to verify multiple signatures in the "ns" case?  I'm
thinking of the case where I send a message of type (CMS) signedData
which has multiple signerInfos attached.

3.  The relationship between request type, SignedData, and the embedded
data is a little murky.  I interpret it as the following:

   a)  All requests and responses are contained in SignedData.
   For the ns and nc cases, this need not actually contain a
   signature (SignerInfo); for npd and responses, it must contain
   one SignerInfo.

   b)  For npd, the data must be of type "message".  For ns, the data
   may be "message" or "messageImprint".  For nc, the data is "cert".

4.  It might be good to mention some useful formats in the Message
structure, such as id-data and id-signedData.

5.  Since I may have multiple signatures on a message, can the "cert"
option be extended to request status on multiple (signer) certificates?
E.g. something like:

        SEQUENCE {
                targets         SEQUENCE OF Certificate,
                chains          SEQUENCE OF Certificate }

where targets are what I want status for, and chains contains the
certificates needed to build the paths from targets to a trusted root.

6.  Should the notary be able to do full path validation per X.509 v3
(and PKIX-1)?  I.e. should the requester be able to pass the initial
policy set and other stuff to the notary, and receive the policy
qualifiers etc. back?

Regards,
Rich

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 10 Mar 1998 09:01:47 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using ASN.1
Comments: To: Ambarish Malpani <[email-masked]>
To: [email-masked]

All,

I want folks to know that the OCSP draft distributed by Ambarish does not
have my endorsement.  My name was placed on it without my consent.  As the
primary author of OCSP, I wish to point out that Ambarish's draft should be
considered an individual submission.  The standards-track OCSP draft is
available for review on the IETF web site.

I have discussed the basis of the ASN.1 requirement with Rich Ankney, my
co-author on the OCSP standards-track draft.  We agree that OCSP is and
should remain a very simple protocol to solve a very simple problem and that
the current OCSP syntax is sufficient for the requirements being addressed.
We recognize however that it may not provide all the capabilities that an
ASN.1-based version could address.  We further agree that the scope of
problems addressed by this counter-proposal would actually be better couched
as extensions to the Notary Protocol draft.

Mike

Approved-By:  Paul Koning <[email-masked]>
Date:         Tue, 10 Mar 1998 11:45:58 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

 David> Tony's characterization is eloquent enough that it cannot be
 David> improved upon, but merely restated.  By following the "wallet
 David> and paper signature" model and having a single public key
 David> which announces "This Is Me!", users would be voluntarily
 David> adopting the very thing they refuse to have imposed upon them
 David> externally: a national ID.

That it true if one were to adopt a restriction that any particular
user MUST have exactly one key.  But I don't believe that has been
proposed.

What was proposed instead is that it should be up to user discretion
as to how many keys there are for that user.  It might be one, it
might be as many as the number of certificates held by that user.  If
the choice is up to the user, my expectation is that the average
number will be higher than one but probably not a great deal higher.
Certainly you give a good reason why the average would be higher than
one.

        paul

--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, C-24183
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: [email-masked]
! Pgp:   27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859

Approved-By:  "Phillip M. Hallam-Baker" <[email-masked]>
Date:         Tue, 10 Mar 1998 11:38: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: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

>(personally, I'd consider "is to:" as being a lot nearer "MUST" than
>"MAY" - so it does make quite a difference to the way I perceive what
>this point is saying (feel free to tell me why I'm wrong though))

No, it must be either a MUST or a MAY or a SHOULD. The whole point
of using this language form is to avoid the ambiguities of constructs like
"is to".

        Phill

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Tue, 10 Mar 1998 11:27:37 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

Stephen;

My apologies on these typos.  My global search and replace skills need
some work, I guess.:-)

Both of the mentioned MAY's should be REQUIRED's.

        Robert.

>----------
>From:  Stephen P. Wilson[SMTP:[email-masked]]
>Sent:  Tuesday, March 10, 1998 11:16 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] New Notary Protocol Draft
>
>Robert Zuccherato wrote:
>>
>> 2. Requirements of the Notary Authority
>>
>> The Notary Authority is MAY to:
>
>What does this mean? - should it either read "is to:" or "MAY:" ?
>
>(personally, I'd consider "is to:" as being a lot nearer "MUST" than
>"MAY" - so it does make quite a difference to the way I perceive what
>this point is saying (feel free to tell me why I'm wrong though))
>
>> 7.  Security Considerations
>>
>> This entire document discusses security considerations.
>>
>> When designing a notary service, the following considerations have
>> been identified that have an impact upon the validity or "trust" in
>> the notary token.
>>
>> 1.  The enclosed certificate is revoked or the signer's key is
>>     compromised and the corresponding certificate is revoked before
>>     the notary acts upon the request. The notary is MAY to validate
>>     appropriate information within the request before it constructs
>>     the notary token.  It is therefore mandated that the NA have
>>     access to current information regarding certificate status before
>>     it creates the token.  In this situation, the notarization process
>>     would produce an error.
>
>"is MAY to" again.
>
>Stephen.
>
>--
>+-----------------------------------------+----------------------------+
>| Stephen Wilson. BSc (hons), AMIEE.      | [email-masked]  |
>| Defence Evaluation & Research Agency,   | http://www.dera.gov.uk/    |
>| St Andrews Road,                        |                            |
>| Malvern,                                | Tel: +44 (0)1684 894153.   |
>| WR14 3PS.                               | Fax: +44 (0)1684 896113.   |
>| United Kingdon.                         |                            |
>+-----------------------------------------+----------------------------+
>| Standard disclaimer: "The Information contained in this E-Mail and   |
>| any subsequent correspondence is private and is intended solely for  |
>| the intended recipient(s). For those other than the intended         |
>| recipient any disclosure, copying, distribution, or any action taken |
>| or omitted to be taken in reliance on such information is prohibited |
>| and may be unlawful."                                                |
>+----------------------------------------------------------------------+
>

Approved-By:  "Stephen P. Wilson" <[email-masked]>
Date:         Tue, 10 Mar 1998 16:16:49 +0000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Stephen P. Wilson" <[email-masked]>
Organization: Defence Evaluation & Research Agency.
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

Robert Zuccherato wrote:
>
> 2. Requirements of the Notary Authority
>
> The Notary Authority is MAY to:

What does this mean? - should it either read "is to:" or "MAY:" ?

(personally, I'd consider "is to:" as being a lot nearer "MUST" than
"MAY" - so it does make quite a difference to the way I perceive what
this point is saying (feel free to tell me why I'm wrong though))

> 7.  Security Considerations
>
> This entire document discusses security considerations.
>
> When designing a notary service, the following considerations have
> been identified that have an impact upon the validity or "trust" in
> the notary token.
>
> 1.  The enclosed certificate is revoked or the signer's key is
>     compromised and the corresponding certificate is revoked before
>     the notary acts upon the request. The notary is MAY to validate
>     appropriate information within the request before it constructs
>     the notary token.  It is therefore mandated that the NA have
>     access to current information regarding certificate status before
>     it creates the token.  In this situation, the notarization process
>     would produce an error.

"is MAY to" again.

Stephen.

--
+-----------------------------------------+----------------------------+
| Stephen Wilson. BSc (hons), AMIEE.      | [email-masked]  |
| Defence Evaluation & Research Agency,   | http://www.dera.gov.uk/    |
| St Andrews Road,                        |                            |
| Malvern,                                | Tel: +44 (0)1684 894153.   |
| WR14 3PS.                               | Fax: +44 (0)1684 896113.   |
| United Kingdon.                         |                            |
+-----------------------------------------+----------------------------+
| Standard disclaimer: "The Information contained in this E-Mail and   |
| any subsequent correspondence is private and is intended solely for  |
| the intended recipient(s). For those other than the intended         |
| recipient any disclosure, copying, distribution, or any action taken |
| or omitted to be taken in reliance on such information is prohibited |
| and may be unlawful."                                                |
+----------------------------------------------------------------------+

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 10 Mar 1998 10:57:31 -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] Cryptographic binding of certificates to signatures
To: [email-masked]

Bob,
  I'm sorry not to have replied sooner.  The approach sounds promising,
but I haven't thought about the details enough to comment substantially.
Offhand, I don't see a problem with defining new signature algorithms,
with new OIDs, which compute signatures over the concatenation of
the ToBeSigned message digest and the ancillary information.

I do see a problem with including salt (randomized padding) in the
signature computation - it would have to be transmitted as part of the
signature value, which would expand the size of the signature: DSA
signatures would become something like:

  DSASignatureValue ::= SEQUENCE {
      r      INTEGER,
      s      INTEGER,
      salt   OCTET STRING }

Can't this "problem", if it exists, be addressed at the application
layer?

Dave Kemp

> From: Bob Jueneman <[email-masked]>
>
> What I'm proposing is that we define a new series of digital signature
> algorithm OIDs, which would include the additional information that
> is needed as part of the COMPONENTS.
>
>   [...]
>
> The other approach, which could be extended to arbitrarily long
> information, would be to effectively append the existing ToBeSigned
> information (normally a message digest) to the ancillary information, and
> then compute a super message digest over the entire collection. That
> super message digest, plus any additional randomized padding (we
> ought to fix that problem while we are at it) would then be the input
> to the actual signing operation. This would support signature algorithms
> and key lengths which only allow as little as 160 bits of input (or even
> 128 bits, for MD5)).

Approved-By:  "Stephen P. Wilson" <[email-masked]>
Date:         Tue, 10 Mar 1998 16:00: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: "Stephen P. Wilson" <[email-masked]>
Organization: Defence Evaluation & Research Agency.
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

Robert Zuccherato wrote:
>
> Comments are appreciated.
>
>         Robert Zuccherato.
>
>   ---------------------------------------------------------------
>                                      C. Adams(Entrust Technologies)
> Internet Draft                  R. Zuccherato(Entrust Technologies)
> expires in six months                             February 27, 1997

OK, so I'm just being really pedantic - but according to this, this
document has already expired (unless I've gone back in a timewarp or
something)  :-)

My first post to the group, and it's such a silly one... let's hope I
can improve next time...

Stephen.

--
+-----------------------------------------+----------------------------+
| Stephen Wilson. BSc (hons), AMIEE.      | [email-masked]  |
| Defence Evaluation & Research Agency,   | http://www.dera.gov.uk/    |
| St Andrews Road,                        |                            |
| Malvern,                                | Tel: +44 (0)1684 894153.   |
| WR14 3PS.                               | Fax: +44 (0)1684 896113.   |
| United Kingdon.                         |                            |
+-----------------------------------------+----------------------------+
| Standard disclaimer: "The Information contained in this E-Mail and   |
| any subsequent correspondence is private and is intended solely for  |
| the intended recipient(s). For those other than the intended         |
| recipient any disclosure, copying, distribution, or any action taken |
| or omitted to be taken in reliance on such information is prohibited |
| and may be unlawful."                                                |
+----------------------------------------------------------------------+

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Tue, 10 Mar 1998 09:56: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: Robert Zuccherato <[email-masked]>
Subject:      [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BD4C0A.BD78B3B0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello All;

For those of you that are interested, we have submitted a new version of
our Notary Protocols Internet Draft.  It is now available at:
ftp://ds.internic.net/internet-drafts/draft-adams-notary-01.txt
I have also included the document with this email.

We submitted it, again, as an independent draft since changes to the
PKIX charter that would allow this haven't been made yet.  The changes
to this draft include:
1) CMS (PKCS #7) encapsulation.
2) Removal of the "Notarize Data" service.  The protocol now only
supports notarization of signatures (possession of data) and
certificates.
3) Inclusion of a version number and nonce.

Comments are appreciated.

        Robert Zuccherato.

------ =_NextPart_000_01BD4C0A.BD78B3B0
Content-Type: text/plain; name="notary012.txt"
Content-Transfer-Encoding: 7bit

                                          C. Adams(Entrust Technologies)
Internet Draft                       R. Zuccherato(Entrust Technologies)
expires in six months                                  February 27, 1997

                          Notary Protocols

                     <draft-adams-notary-01.txt>

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This document describes a general notary service and the protocols to
be used when communicating with it.  The Notary Authority is a Trusted
Third Party (TTP) that can be used as one component in building reliable
non-repudiation services (see [ISONR]).  Useful Notary Authority
responsibilities in a PKI are to validate signatures and to provide up-
to-date information regarding the status of certificates.  We give
examples of how to use the notary to extend the lifetime of a signature
beyond key expiry or revocation and to query the notary regarding the
status of a certificate.

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119 [RFC2119].

1. Introduction

A Notary Authority (NA) is a Trusted Third Party that verifies the
correctness of specific data submitted to it.  The Notary Authority
provides the notary service in order that non-repudiation evidence may
be constructed relating to the validity and correctness of an entity's
claim to possess data, the validity and revocation status of an entity's
public key certificate and/or the validity and correctness of another
entity's signature.  When notarizing possession of data or another
entity's signature, the NA verifies the mathematical correctness of the
actual signature value contained in the request and also checks the full

Document Expiration:  August 27, 1998                            Page 1

certification path from the signing entity to a trusted point (e.g., the
NA's CA, or the root CA in a hierarchy).  The NA MAY be able to rely on
all relevant CRLs and ARLs, or the NA MAY need to supplement this with
access to more current status information from the CA.  It then includes

a trusted time and creates a notary token.  (See Appendix B.)

When notarizing a certificate, the NA verifies that the certificate
included in the request is a valid certificate and determines its
revocation status at a specified time.  Again, it checks the full
certification path from the certificate signing entity to a trusted
point.  The NA MAY be able to rely on all relevant CRLs and ARLs, or the
NA MAY need to supplement this with access to more current status
information from the CA.  It includes this information, along with a
trusted time, to create a Notary Token.  (See Appendix C.)

The presence of a notary token supports non-repudiation in two ways.
It provides evidence that a signature or certificate was valid at the
time of notarization.  This token can be used even after the
corresponding certificate expires and its revocation information is
no longer available on CRLs (for example).  The production of a notary
token in response to a signed request for notarization of another
signature or certificate also provides evidence that due diligence
was performed by the requester in validating the signature or
certificate.

In all cases, the trust that PKI entities have in the Notary Authority
is transferred to the contents of the notary token (just as trust in a
CA is transferred to the certificates that it issues).  As a particular
example, a notary token pertaining to a signature may be useful for
extending the life of that signature beyond the expiry or subsequent
revocation of its corresponding verification certificate.

2. Requirements of the Notary Authority

The Notary Authority is MAY to:

     1. verify the correctness of the enclosed digital signature using
        all appropriate status information and public key certificates
        and produce a signed notary token attesting to the validity of
        the signature, if asked by the requester.
     2. verify the validity (according to [CCP]) of the enclosed
        certificate and its revocation status at the specified time
        using all appropriate status information and public key
        certificates and produce a signed notary token attesting to the
        validity and revocation status of the certificate, if asked by
        the requester.
     3. include a monotonically incrementing value of the time of day
        or a time stamp token into its notary token.
     4. include within each signed notary token an identifier to
        uniquely determine the trust and validation policy used for this
        signature.
     5. sign each notary token using a key generated exclusively for
        this purpose and have this property of the key indicated on the
        corresponding certificate.

Document Expiration:  August 27, 1998                            Page 2

     6. indicate in the token whether or not the signature or
        certificate verified, and if not, the reason the verification
        failed.
     7. provide a signed receipt (i.e., in the form of an appropriately
        defined notary token) to the requester, where appropriate, as
        defined by policy.

3. Notary Transactions

As the first transaction of this mechanism, the requesting entity
requests a notarization by sending a request (which is or includes a
notary request, as defined below), including the data for which validity
and/or possession is to be notarized, to the Notary Authority.  Upon
receiving the request, the Notary Authority reviews and checks the
validity of the request.  A valid request is of the form described in
Section 5 of this document and can be properly decoded.  If the request
is valid, the Notary Authority performs the notarization and sends a
response (which is or includes a notary token, as defined below) to the
requesting entity.  Otherwise, the Notary Authority returns an error
message (i.e., in the form of an appropriately defined notary token).

Upon receiving the token, the requesting entity verifies its validity.
The requester SHOULD verify that it contains the correct time, the
correct name for the NA, the correct data imprint, a valid signature,
and satisfactory status, service and policy fields.  Since the NA's
certificate may have been revoked, the appropriate status information
SHOULD be checked to verify that the certificate is still valid.  The
token can now be used to authenticate the correctness or possession of
the corresponding data.

4. Identification of the NA

The NA MUST sign all notary messages with a key reserved specifically
for that purpose.  The corresponding certificate MUST contain the
extended key usage field extension as defined in [CCP] Section
4.2.1.14 with KeyPurposeID having value id-kp-notary.  This extension
MUST be critical.

id-kp-notary    OBJECT IDENTIFIER ::= {id-kp  ??}
  -- Notarizing the validity of certain information.  Key usage bits
  -- that may be consistent:  digitalSignature, nonRepudiation

5. Request and Token Formats

The ServiceType type indicates which type of Notary Service is required.

ServiceType ::= INTEGER  { npd(1), ns(2), nc(3) }

The value npd (Notarize Possession of Data) is used when only the
signature on the notary request (i.e., possession of the data in the
request) is to be verified.  In this case the Notary Authority would be
merely providing evidence that the requester possessed the data in the
request and a valid signature key at the time indicated.  This is really
an extension of the Time Stamp Authority [TSA] in that we are given the
additional assurance about the validity of the signature, as well as the
time before which it was applied.  The value ns (Notarize Signature) is

Document Expiration:  August 27, 1998                            Page 3

used when another entity's signature is to be validated.  The resulting
token can then be used to support non-repudiation services or to allow
use of the signature beyond certificate revocation or expiry.

The value nc (Notarize Certificate) is used when the validity and
revocation status of the certificate included in the request is to be
verified.  This service can be used to supplement the use of CRLs when
timely information regarding a certificate's revocation state is
required (e.g. high value funds transfer or the compromise of a highly
sensitive key) or when evidence supporting non-repudiation is required.
A given NA MAY support any subset of the above services.

Upon receiving a signed request for either service ns or nc the NA MUST
also verify the signature on the request as is done for the npd service.
Note however, that signed requests for the ns or nc service are not
required.

A notary request is as follows.  It is encapsulated as a SignedData
construct [CMS].  The content is of type NotaryReqData, which is
indicated by the OID:

NotaryReqData OBJECT IDENTIFIER  ::= { ??????  }

The notary request MUST contain only the signature of the requester.

The data and information that will be notarized are contained in the
content field of the SignedData content type.

NotaryReqData ::= SEQUENCE  {
     notaryReqInfo                NotaryReqInfo,
     data                         Data
       --the data to be notarized
       --this field MUST be of type Message if the service type is ns
       --and of type SEQUENCE OF Certificate if the service type is nc
}

The notaryReqInfo field contains information pertaining to the notary
request.

NotaryReqInfo ::= SEQUENCE  {
     version                      Integer { v1(0) },
     service                      ServiceType,
     requester                    GeneralName OPTIONAL,
      --MUST be present if the service field is npd
      --MUST match the identity (subjectName or subjectAltName
      --extension) for the corresponding signing certificate
     reqPolicy                    PolicyInformation OPTIONAL,
     notary                       GeneralName,
     nonce                        Integer,
     reqTime                      ReqTime OPTIONAL   }

ReqTime ::= CHOICE  {
     genTime                      GeneralizedTime,
     timeStampToken               TimeStampToken   }

Document Expiration:  August 27, 1998                            Page 4

In situations where the Notary Authority will verify the identity of the
requester (i.e., when the service field is npd), the notary request MUST
be signed by the requester using the signerInfos field.

Similarly, in situations where the Notary Authority will certify the
time included in the request (i.e., when stipulated by the policy of the
Notary Authority), the notary request MUST include the reqTime field in
NotaryReqInfo. Thus, when verifying a certificate, the presence of this
field indicates the time for which the validity and revocation status of
the certificate SHOULD be reported.  If this field is not present, the
current time is assumed. TimeStampToken is defined in Sect 2.4 of [TSA].

PolicyInformation is defined in Section 4.2.1.5 of [CCP].  The
reqPolicy field SHOULD indicate the policy under which the notarization
is requested or the policy for which certificate validity is to be
reported.  This field MUST be checked by the NA to verify agreement
with its own policy or to determine certificate validity.  The absence
of this field indicates that any policy is acceptable.

The Data type is defined to be either the message itself, a hash of
the message (this allows a signature indicating possession of private
data to be notarized) or the certificate to be verified.

Data ::= CHOICE  {
     message                [0]  Message,
     messageimprint         [1]  MessageImprint,
     cert                   [2]  SEQUENCE SIZE (1..MAX) OF Certificate
}

In order to specify the format (i.e. the type) of the message so that
it may be parsed and understood by the NA or any verifying entity, we
define the Message data type.

Message ::= SEQUENCE  {
     format                       MESSAGECLASS.&id,   --objid
     rawdata                      MESSAGECLASS.&Type  --open type
}

MESSAGECLASS ::= CLASS  {
     &id                          OBJECT IDENTIFIER UNIQUE,
     &Type                                                    }
WITH SYNTAX  { &Type IDENTIFIED BY &id }

If the requester prefers to send a hash of the message instead, the
MessageImprint data type SHOULD be used.

MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }

The hash algorithm indicated in the hashAlgorithm field SHOULD be a
"strong" hash algorithm (that is, it SHOULD be one-way and collision
resistant).  It is up to the Notary Authority to decide whether or not
the given hash algorithm is sufficiently "strong" (based on the current
state of knowledge in cryptanalysis and the current state of the art in
computational resources, for example).

Document Expiration:  August 27, 1998                            Page 5

The hashedMessage field SHOULD contain the hash of the DER encoding of
the message expressed as a Message data type.  The hash is represented
as an OCTET STRING.

The cert field SHOULD contain the certificate to be notarized.  If the
sequence has length greater than 1, then the certificates MUST indicate
a chain of trust to be used when notarizing the certificate.

A notary token is as follows.  It is encapsulated as a SignedData
construct [CMS].  The content is of type NotaryInfo, which is indicated
by the OID:

NotaryInfo OBJECT IDENTIFIER  ::= { ??????  }

The notary token MUST contain only the signature of the NA.

NotaryInfo ::= SEQUENCE  {
     notaryReqInfo                NotaryReqInfo,
       --MUST be the same value as the notaryReqInfo field in
       --NotaryReqData
     messageImprint               MessageImprint,
       --if the data field in NotaryReqData is MessageImprint, this
       --MUST contain that same value, otherwise it contains a hash of
       --the data field in NotaryReqData using the hash algorithm
       --specified in the digestAlgorithm parameter of SignerInfo in
       --the notary token
     reqSignature                 SignerInfo OPTIONAL,
       --MUST be present if service field of notaryReqInfo is npd
       --MUST be the same value as the signerInfo field in notary
request
     policy                       PolicyInformation,
     status                       PKIStatusInfo,
     time                         NotaryTime,
     chainCerts              [0]  SEQUENCE OF Certificate OPTIONAL,
       --if present, MUST indicate the chain of trust that was used by
       --the NA to verify the signature or certificate in NotaryReqData
     crls                    [2]  SEQUENCE OF CertificateList OPTIONAL
   }

NotaryTime ::= CHOICE  {
     genTime                      GeneralizedTime,
     timeStampToken               TimeStampToken   }

PKIStatusInfo is defined in Section 3.2.3 of [CMP].  If the PKIStatus
field has value `waiting' (3), then this token is a receipt, as defined
in Section 2.  Otherwise, the status field indicates whether or not the
notary request was fulfilled and, if not, failInfo indicates the reason
it was rejected.  A valid notary token will have a PKIStatus field with
value `granted' (0).  For the purposes of the NA, we define
PKIFailureInfo for use in PKIStatusInfo.

PKIFailureInfo ::= BITSTRING  {
    badAlg           (0),
      -- unrecognized or unsupported Algorithm Identifier
    badMessageCheck  (1),
      -- integrity check failed (e.g., signature did not verify)

Document Expiration:  August 27, 1998                            Page 6

    badRequest       (2),
      -- transaction not permitted or supported
    badTime          (3),
      -- messageTime was not sufficiently close to the system time,
      -- as defined by local policy
    badCertId        (4),
      -- no certificate could be found matching the provided criteria
    badDataFormat    (5),
      -- the data submitted has the wrong format
    wrongAuthority   (6),
      -- the authority indicated in the request is different from the
      -- one creating the response token
    incorrectData    (7),
      --the requester's data (i.e. signature) is incorrect
      --(i.e. invalid)
    missingTimeStamp (8),
      -- when the timestamp is missing but should be there (by policy)
    certInvalid      (9),
      -- the certificate fails to validate against Section 6 of [CCP]
    certRevoked      (10),
      -- the certificate is revoked
    certExpired      (11),
      -- the certificate has expired
    certOnHold       (12),
      -- the certificate has been operationally suspended
    certNotActive    (13)
      -- the certificate was not active at the given time
}

The statusString field of PKIStatusInfo can be used to include reason
text such as "CA's public key revoked".

CertId is defined in Section 7.5 of [CRMF].

The crls field (if present) SHOULD contain a sequence of certificate and
authority revocation lists that is sufficient to verify the chain of
trust indicated in the chainCerts field.

The reqSignature, chainCerts and crls fields are included as OPTIONAL.
They SHOULD be present, when policy dictates, for use as supplementary
evidence when resolving possible disputes.  Dispute resolution would
most likely be handled by one or more humans, in an off-line
environment, and is beyond the scope of this document.

6. Transports

6.1. File Based Notary Protocol

A file containing a notary message MUST contain only the DER encoding of
one PKI message, i.e. there MUST be no extraneous header or trailer
information in the file.

Such files can be used to transport notary messages using for example,
FTP.

Document Expiration:  August 27, 1998                            Page 7

6.2. Socket Based Notary Protocol

The socket based protocol for notary messages is identical to that used
in [CMP] Section 5.2 except that port 309 MUST be used.

6.3. Notary Protocol Using Email

This section specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 4 via Internet mail.

A simple MIME object is specified as follows.

   Content-Type: application/notary
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded Notary message, base64-encoded>>

This MIME object can be sent and received using MIME processing engines
and provides a simple Internet mail transport for Notary messages.

6.4. Notary Protocol via HTTP

This subsection specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 4 via the HyperText
Transfer Protocol.

A simple MIME object is specified as follows.

   Content-Type: application/notary

   <<the ASN.1 DER-encoded Notary message>>

This MIME object can be sent and received using common HTTP processing
engines over WWW links and provides a simple browser-server transport
for Notary messages.

7.  Security Considerations

This entire document discusses security considerations.

When designing a notary service, the following considerations have been
identified that have an impact upon the validity or "trust" in the
notary token.

1.  The enclosed certificate is revoked or the signer's key is
        compromised and the corresponding certificate is revoked before
        the notary acts upon the request. The notary is MAY to
        validate appropriate information within the request before it
        constructs the notary token.  It is therefore mandated that the
        NA have access to current information regarding certificate
        status before it creates the token.  In this situation, the
        notarization process would produce an error.
     2. The enclosed certificate is revoked or the signer's key is
        compromised and the corresponding certificate is revoked after
        the notary acts upon the request. This is not a concern to the
        NA once the notary has constructed the token, as long as the

Document Expiration:  August 27, 1998                            Page 8

        compromise date in the CRL is not before the time of
        notarization.  If it is, this situation would have to be
        handled by off-line, possibly human-aided, means specific to the
        situation at hand.
     3. The notary's private key is compromised and the corresponding
        certificate is revoked.  In this case, any token signed by the
        notary cannot be trusted.  For this reason, it is imperative
        that the notary's key be guarded with proper security and
        controls in order to minimize the possibility of compromise.
        Nevertheless, in case the private key does become compromised,
        an audit trail of all the tokens generated by the NA SHOULD be
        kept as a means to help discriminate between genuine and false
        tokens.
     4. The NA signing key MUST be of a sufficient length to allow for
        a sufficiently long lifetime.  Even if this is done, the key
        will have a finite lifetime.  Thus, any token signed by the NA
        SHOULD be time stamped (if authentic copies of old CRLs
        are available) or notarized again (if they aren't) at a later
        date to renew the trust that exists in the NA's signature.
        Notary tokens could also be kept with an Evidence Recording
        Authority [ISONR] to maintain this trust.
     5. When there is a reason to believe that the NA can no longer
        be trusted, the authority's certificate MUST be revoked and
        placed on the appropriate ARL.  Thus, at any future time the
        tokens signed with the corresponding key will not be trusted.
6.  In certain circumstances, an NA may not be able to produce a
        valid response to a request (for example, if it is unable to
        compute signatures for a period of time).  In these situations
        the NA MUST wait until it is again able to produce a valid
        response and then respond to the request.  Under no
        circumstances shall an NA produce an unsigned response to a
        request.
7.  This protocol assumes that the CA has conducted a test for proof
        of possession for each user's signing private key.  If this is
        not the case, or when additional assurances are required, the
        certificate of the reqester (resp. NA) SHALL be included in the
        encapsulation of the notary request (resp. notary token) as an
        authenticated attribute.

8. References

[TSA] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, "Time Stamp
Protocols," draft-adams-time-stamp-0X.txt, 1997 (work in progress).

[CMP] C. Adams, S. Farrell, "Internet Public Key Infrastructure,
Certificate Management Protocols," draft-ietf-pkix-ipki3cmp-
0X.txt, 1997 (work in progress).

[CRMF] C. Adams, "Internet Public Key Infrastructure, Certificate
Request Message Format," draft-ietf-pkix-crmf-0X.txt, 1998 (work in
progress).

[CCP] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key
Infrastructure, X.509 Certificate and CRL Profile," draft-
ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress).

Document Expiration:  August 27, 1998                            Page 9

[CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).

[ISONR] ISO/IEC 10181-5:  Security Frameworks in Open Systems.
Non-Repudiation Framework.

[RFC2119] Key works for use in RFCs to Indicate Requirement Levels,
S. Bradner, RFC 2119, March 1997.

9. Authors' Addresses

Carlisle Adams
Entrust Technologies
750 Heron Road
Ottawa, Ontario
K1V 1A7
CANADA
[email-masked]

Robert Zuccherato
Entrust Technologies
750 Heron Road
Ottawa, Ontario
K1V 1A7
CANADA
[email-masked]

Document Expiration:  August 27, 1998                            Page 10

APPENDIX A - Storage of Data and Token

A notary token is useless without the data to which it applies.  For
this reason tokens and their related data MUST be securely stored
together.  The change of a single bit in either the data or the token
renders the entire notarization process for that data meaningless.
Storage of tokens and data in a secure (e.g., tamper proof) environment
is strongly RECOMMENDED.

When data and notary tokens are stored together, the following ASN.1
data type MAY be used.

DataAndToken ::= SEQUENCE  {
     message                      Message,
     notaryToken                  Content Info  }

Note that this object does not need to be signed, as the notary token
already verifies the integrity of the data in the message.  Any
supplementary information whose integrity needs to be protected SHOULD
be part of the message or token.

APPENDIX B - Extending the Life of a Signature

We present an example of a possible use of this notary service.
It produces a stand-alone token that can be used to extend the life of a
signature.  This example assumes that we have total trust in the Notary
Authority.

Signature algorithms and keys have a definite lifetime.  Therefore,
signatures have a definite lifetime.  The Notary Authority can be used
to extend the lifetime of a signature.

In order to extend the lifetime of a signature in this way, the
following technique MAY be used.

A) The signature needs to be notarized.

     1) The signed message is presented to the Notary in the data
        field of NotaryReqInfo under service type ns and an appropriate
        policy.

     2) The Notary verifies that the signature and verification key are
        valid at that time by checking expiry dates and status
        information, and returns a notary token.

B)  The notarized signature MUST be verified.

     1) The signature of the Notary in notary token SHALL be verified
        using the Notary's valid verification key.

In this situation the signer's signing key (and therefore, its
signature) is only valid until some specified time T1.  The NA's
signing key (and therefore, its signature) is valid until some specified
time T2 that is (usually) after time T1.  Without notarization, the

Document Expiration:  August 27, 1998                            Page 11

signer's signature would only be valid until time T1.  With
notarization, the signer's signature remains valid until time T2,
regardless of subsequent revocation or expiry at time T1.

If the signature of the NA is valid, the trust we have in the NA allows
us to conclude that the original signature on the data was valid at
the time included in the notaryInfo field of the notary token.

APPENDIX C - Verifying the Status of a Certificate

We now present an example of how to produce a stand-alone token that can
be used to confirm the revocation status of a certificate.

CRLs and ARLs are updated according to a schedule at regular intervals.
For some purposes, the granularity provided by the CRLs and ARLs is not
fine enough.  Up-to-date revocation status may be needed before the next
CRL or ARL update.  Since the NA MUST have access to current information
regarding certificate status, it can be used to verify the revocation
status of a certificate in this situation.

In order to produce such a token, the following technique MAY be used.

A) The certificate needs to be notarized.

     1) The certificate is presented to the Notary in the data field of
        NotaryReqInfo under service type nc and an appropriate policy.

2)  The Notary verifies that the certificate is valid and that it
        hasn't been revoked and then returns a notary token.

B)  The notary token MUST be verified.

     1) The signature of the Notary in notary token SHALL be verified
        using the Notary's valid verification key.

This notary token can now be used when verifying signatures using the
key corresponding to the certificate.  This service provided by the
NA can be thought of as a supplement to the usual method of checking
revocation status.

Document Expiration:  August 27, 1998                            Page 12

------ =_NextPart_000_01BD4C0A.BD78B3B0--

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 10 Mar 1998 09:32:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

> From: "Balluffi, Frank" <[email-masked]>
>
> What is the foundation or context for this discussion: WHAT ATTACKS ARE
> WE CONCERNED ABOUT?

In addition to the four operational disadvantages listed in a prior
message, I thought up the following actual attack this morning
in the shower :-)

Consider two credit cards with different policies: the Green card
is free and offers no benefits; the Gold card costs .1% per transaction
but offers replacement insurance up to $1000 on goods purchased.

It is in the user's interest to use the Green card for every transaction,
unless the goods received turn out to be defective, in which case the
user might try to substitute the Gold card on the purchase transaction.

The credit card company has the opposite incentive, to switch all
transactions to the Gold card.  And if the merchant pays a different
fee or gets a different commission from the two cards, the merchant
has an incentive to swap certificates too.

Certificate substitution would be prevented by using different keys,
by binding the cert to the transaction, or both.  In the case of
credit cards, any reasonable commerce protocol would bind the cert
into the transaction.  But the attack applies whenever there
are certificates with a shared key and conflicting incentives;
the incentives could be information-based rather than monetary.
Few application protocols (and according to the chair of the S/MIME
working group, *no* email protocols) include any means of preventing
certificate substitution, so key sharing is a vulnerability.

Am I missing something?

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 10 Mar 1998 08:57: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] Multiple certificates for same key?
To: [email-masked]

The PKIX list server seems to be back up, but this message from Monday
hasn't popped out yet, so we'll try again.

   dpk

----- Begin Included Message -----

> From: Tony Bartoletti <[email-masked]>
>
> > From: [email-masked]
> >
> >Wrong mailing list.  What you said above is the SPKI notion, but it's not
> >the PKIX notion, of the semantics of the subject name field in a
> >certificate.
> >
> >Steve
>
> I agree with your characterization of subject name SPKI vis-a-vis PKIX.
>
> Dan makes a secondary point, in that the cost of carrying different keys
> for every usage (identification or authorization, I suppose) be weighed
> against the potential privacy concern of having one key (especially in
> the case of an identity role) employed so widely that tracking usage on
> the one key produces a virtual dossier on the owner.

Tony's characterization is eloquent enough that it cannot be improved
upon, but merely restated.  By following the "wallet and paper signature"
model and having a single public key which announces "This Is Me!", users
would be voluntarily adopting the very thing they refuse to have
imposed upon them externally: a national ID.

My primary objection to multiple certification is the lack of handling
flexibility, not usage tracking.  If certificates are analogous to the
contents of a wallet, then I would like to be able to dynamically decide
what to carry in my wallet depending on where I'm going.  Normally I'd
carry everything, for convenience.  But if I'm going on a trip, I'd
remove the cards I'm not expecting to need so that if the wallet is
lost or stolen, I don't have to cancel everything.

In a token or key database, if every certificate's copy of the
private key has the same value (or in Paul Koning's model, which I
haven't heard of being supported in commercially available tokens or
applications, every certificate refers to the same storage location for
the private key), then the assignment of certificates to storage
modules is done once at issuance.  But if every certificate uses a
different private key, then those keys can be moved in and out of the
storage module as needed to accommodate where the module will be used.
I might normally want to keep my "AMEX Platinum" key on my smartcard,
but if I were going to plug that smartcard into a mall kiosk or an IETF
terminal room machine, I'd rather take the AMEX key off and leave just
an S/MIME email key on the card.

The third objection to multiple certification is that it leads
inexorably to a permanent key that cannot be updated.  Although it is
impossible for a single CA to verify that a key has not been certified
somewhere else, it is certainly possible and often desirable for that
CA to ensure that the key is changed at renewal.  But if a single key
is used for all certificates, and the validity dates for all CAs are
not synchronized, then it is impossible for any CA to rekey it's own
subjects' certificates, much less establish rekey periods that are
appropriate for the purpose of the certificates.

In summary, the disadvantages of a shared key across certificates include:

* inability of the user to change the contents of a storage module
* inability for any CA to establish a policy of rekeying on reissuance
* enables usage tracking
* not supported by current applications (counterexamples welcome)

The advantages include:

* might save memory (if each cert doesn't keep it's own copy of the
  private key).

With regard to comments that a standard requiring users not to share
keys is "unenforceable":  so is any standard recommending behavior that
is in the user's interest.  No one is going to jail for failing
to eat their Recommended Daily Allowance of Vitamin A.  But it is
nonetheless useful to publish RDA numbers ("standards") for vitamins
and minerals to allow consumers to make educated decisions based on
information published by nutrition experts and food producers.

PKIX is an information resource, not just a technical interoperability
specification.  Let's write security considerations that provide some
useful guidance on choosing a key sharing policy.

Dave Kemp

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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Tue, 10 Mar 1998 14:54:09 -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] Multiple certificates for same key?
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

> Denis, David was responding to my original post, which pointed out that
> most of the difficulties we are having with mutliple certificates for the same
> key is due to the fact that the certificate information is not cryptographically
> bound to the message itself.
>
> But did you see my follow up back to him?  I'm somewhat surprised that
> no one responded to it. I suggested that instead of solving this problem
> over and over again for each separate application we should fix
> the root cause, the SIGNED macro itself.

Bob, I am sorry and I should have responded to your message as well.
When I read your message (I did see it), I was not very enthusiastic
with your first proposal (i.e. modifying the SIGNED MACRO) and ... did
not go until the end, so I missed the second proposal which is much
better.

> I then proposed a way of doing that which would not invalidate existing
> code, but would merely require the definition of a new set of signature
> algorithm IDs, where the additional information we might like to cryptographically
> bind would be snuck in as COMPONENTS of the signature. We might even
> be able to find a way to make those additional components optional.
>
> Such components should include the issuer and serial number at a minimum,

You mean issuer name and serial number (not issuer serial number).

> and I
> could come up with a list of additional information that could at least
> be debated as to whether it was worthy of being included. Date/time would be
> certainly be worth discussing, as would some indication of the platform on which
> the signature was created (for audit purposes).

Don't put too much !

> If biometrics were used there
> might be some additional information that would be useful, etc., etc., etc.
>
> If you didn't see the original message, I'd be happy to send it again -- my
> e-mail system was rather flakey that particular evening.

Hereafter is your original message again :

> David,
>
> If we were able to somehow add cryptographic binding of
> the digital signature to the specific certificate that is s
> supposed to be used to validate it, virtually all of my objections
> to issuing more than one certificate per key would disappear,
> and we would be left with some of the positive virtues of that
> approach that others have mentioned.
>
> However, I do NOT think that we should insist that each and
> every protocol reinvent the wheel. Some will do it wrong (as per
> your examples), and some just won't do it at all.
>
> Unfortunately, the SIGNED macro doesn't include a version
> indicator (will we _never_ learn?), so we can't do the version 3
> trick that we pulled when we found that the X.509 certificate
> wasn't adequate for our new extended purpose.
>
> However, I think there is a way out, although from a purist
> architectural standpoint it is an ugly hack. But hey, MISSI did
> it, and what's good enough for the US Government ought to be
> good enough for the rest of us, right?

Let us skip this and go directly to the second proposal.

> What I'm proposing is that we define a new series of digital signature
> algorithm OIDs, which would include the additional information that
> is needed as part of the COMPONENTS.
>
> We can debate the precise information that we might like to include later,
> along with the optimum syntax, but this is the approach that as I
> recall MISSI took to include clearance information and other parameters
> that they had no place to put in the old V1 certificate format. Like I said,
> an ugly, but noble hack.
>
> One potential problem is that although currently in-vogue RSA and
> DSA key lengths (1024 and 2048 bits) would probably be long enough
> to directly include most of what we might like, the 512 bit lengths allowed
> by US export (and some import) regulations might be pretty tight, and
> would be extremely tight for elliptic curves.
>
> One approach to solving this problem would be to use two message digests,
> one for the ToBeSigned, and the other for the ancillary signature data (someone
> has to think of a snappy attribute name ¯ I refuse to be blamed for
> "ancillarySignatureData"), and then include both message digests
> within the signature.  This would work for algorithms of up to 320 bits
> in length, which might still be tight for some elliptic curve algorithms.

Here starts the second proposal.

> The other approach, which could be extended to arbitrarily long
> information, would be to effectively append the existing ToBeSigned
> information (normally a message digest) to the ancillary information, and
> then compute a super message digest over the entire collection. That
> super message digest, plus any additional randomized padding (we
> ought to fix that problem while we are at it) would then be the input
> to the actual signing operation. This would support signature algorithms
> and key lengths which only allow as little as 160 bits of input (or even
> 128 bits, for MD5)).

I agree in principle with the approach. We need to consider two one-way
functions.

> The second approach is obviously superior to the first, assuming
> that the time for a second hash is considered negligible. But can
> anyone think of an even better method?
>
> The benefit of this scheme is that by simply implementing one
> or more new enhanced signature algorithms (e.g., "RSA with
> SHA-1 and ancillary data") within the underlying toolkits,
> virtually all applications would benefit, with virtually no effort at all.

I see it slightly differently. If I want to sign a message with a length
of 1 Mo together with ancillary information, I would like to sign the
message digest of the message instead of the message.

Considering that we are not going to optimize the scheme for messages
smaller than 160 bits, we could always consider to sign the hash of the
message, instead of the message itself. Thus we would sign what is
sometimes called the "imprint" of the message. What is nice is that the
imprint of a message is a characteristic of the message that can be
computed independently of the context of the signature. It can be
generated or check in advance or in parallel. The last step would then
be to compute a hash over that message imprint and the ancillary
information. If there no ancillary information this appears useless, but
there will be !

I do not see this as a replacement to what exists today, but as a new
format "to be used where necessary". To make it clear, instead of "RSA
with SHA-1 and ancillary data" I would prefer to keep "RSA with SHA-1"
but sign an explicit message digest plus ancillary data. When looking
again to the E-mail I sent yesterday, although the addition of
authenticated attributes solves the problem from a security point of
view, it suffers from the performance mentionned above. If you want to
take a look at the CMS specification, it is available at :
ftp://ietf.org/internet-drafts/draft-ietf-smime-cms-03.txt

> And if we do it right, we might even be able to achieve some degree of
> backward compatibility by some sort of slight of hand involving
> mapping the algorithm OIDs to existing algorithms
> in such a way as to ignore the added information if the code doesn't yet
> support it. Maybe some ASN.1 genius can think of a slick trick.

I would prefer a solution without the help of an ASN.1 genius so that
everyone can understand it.  :-)

> Let me let this sink in before I start talking about all of the stuff I
> would like to see included. Hopefully this time we would do it right,
> probably by defining the information to be included in ASN.1 with
> strong typing, so that we additional information is proposed to be
> added it will be simple to do. But that is tomorrow's homework
> assignment.
>
> At a minimum, however, it would have to include some form of
> unique identification of the certificate to be used to validate the
> signature, either issuerName and serial,

This is indeed the minimum, although a SEQUENCE would be more
appropriate and solve the problem of unique names.

> authorityKeyId, or at
> the very least a hash of the certificate contents (although that
> wold cause some problems of circular definition if used within
> the certificate itself.)  Certainly a URL or some other kind of hint
> as to where to actually find the certificate would be a nice touch,
> but we can discuss that independently of the primary issue.

Don't put too much in the same boat ...  :-)

> Whaddaya think about the basic concept?
> Bob

You are certainly on the right track, but do not overload the boat ...

Denis

P.S. My original E-mail follows.

> >David,
> >
> >You posted a VERY important E-mail last week and I am bringing my
> >support to it.
> >
> >> The X.509 "SIGNED" macro might not have been designed with the intent
> >> of supporting this purpose, and so may be excused for not including
> >> a method of binding a certificate to the signed data.
> >>
> >> However, the IETF CMS specification (aka PKCS#7) was designed for
> >> precisely this purpose (providing non-repudiation grade signatures over
> >> generic content), yet it still does not provide a clean method of
> >> binding the signer's certificate to the content.
> >
> >True.
> >
> >> The CMS definition of SignedData includes {content, certs, crls,
> >> signerInfos}, and some other fields.  There may be multiple signatures
> >> applied to the content, each represented by a SignerInfo.  Each
> >> SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
> >> Because the issuerAndSerialNumber field, which uniquely identifies the
> >> certificate used by the signer, is not covered by the signature, it is
> >> not bound to the content.  I'm not sure why PKCS#7 was designed that
> >> way, but it was, and so is CMS.
> >
> >I believe that at the time, PKCS#7 was written, the authors had not
> >non-repudiation in mind, but simply using a digital signature for
> >authenticating a message in real time. For that purpose, the format was
> >fine.
> >
> >> It would have been preferable to define an issuerAndSerialNumber
> >> attribute, which could have been included either in
> >> authenticateAttributes to bind it with the signature, or in
> >> unauthenticatedAttributes if the current semantics of not binding the
> >> signer's cert to the signed content is desired.
> >
> >As the CMS standard is being rewritten in the smime working group,
> >(draft-ietf-smime-cms-03.txt) and since the editor is Russ Housley also
> >a member of the PKIX working group I think it is the perfect time to
> >suggest to make changes. What do you think Russ ?
> >
> >> Perhaps defining a redundant copy of issuerAndSerialNumber, to be
> >> included in authenticatedAttributes, could address the requirement
> >> without breaking backward compatibility.  (It only covers the signer's
> >> cert, not the full path, but it's a start.)
> >
> >Yes. Without breaking compatibility we could also support a SEQUENCE OF
> >issuerAndSerialNumber. The simple change that is needed is to add this
> >attribute in the section 11 (Useful Attributes) from the CMS document.
> >In addition we should mandate the support of such an attribute, if the
> >signed data is to be used in a non-repudiation process.
> >
> >> The uglier alternative is  is to double-sign everything, encapsulating a
> >> signedData within another signedData for each parallel signature.
> >>
> >> Since CMS is intended to be a generic security encapsulation mechanism,
> >> not just an S/MIME-specific structure, those who feel that this
> >> requirement is important (to address either multiple certification of
> >> keys or proof-of-possession) should discuss it in the S/MIME working
> >> group.  (A SigningTime attribute is already defined in CMS, but a
> >> "location" attribute is not.)
> >
> >Unfortunately I am not yet on this mailing list, so why I respond here.
> >
> >Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Peter Sylvester <[email-masked]>
Date:         Tue, 10 Mar 1998 11:30:53 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Sylvester <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using ASN.1
To: [email-masked]

hello,

For the mapping to HTTP I think one should not underestimate the
simplicity of a html page containing something like:

<form action="http://www.edelweb.fr/cgi-bin/eurotrust/certificat-validation" method="post">

  <input type="hidden" name="response-type" value="html">
  <table>

  <tr><td>Hash of IssuerNameAndKey<td><input type="text" name="hash" size=60><br>
  <tr><td>CertificateSerialNumber<td><input type="text" name="serialnumber" size=15>

  <tr><td><td><input type="submit" name="request" value="Submit Request">

  </table>
</form>

Thus a real mapping to HTTP/HTML constructs and not just an encapsulation
might be another appendix of that document?

Peter Sylvester -- EdelWeb France

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Mon, 9 Mar 1998 10:36:18 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP in ASN.1
Comments: cc: "[email-masked]" <[email-masked]>
To: [email-masked]

This is a multi-part message in MIME format.
--------------59992754DCE81649B0461645
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Mike,

Given the number of people requesting (1) OCSP provide better support
for ASN.1 (2) OCSP not be necessarily tied to HTTP (but be able to
benefit from HTTP),  I have taken the liberty making some fairly major
changes to the OCSP spec and would like to offer it up as a basis for
moving forward.

 I believe this re-write has technical merit on the following grounds:

(1) It separates OCSP from HTTP but at the same time the protocol can
be implemented using HTTP (both GET and POST).
(2) It is easier to implement (a new ABNF parser is not required --
uses standard ASN.1)
(3) It is more extensible and more consistent with existing crypto
applications (by virtue of using ASN.1).
(4) It allows multiple cryptographic algorithms in the response (RSA
signatures, Diffie Hellman signatures, revocation tree based responses,
iterated hashing based responses etc.)

There are some other minor changes which I think are important but
details (a) certificate status uses notRevoked instead of valid (since
this protocol just checks revocation status - not validity for
a particular task)
(b) usage of both SHA and MD5 is changed to just a hashing algorithm
(preferrably SHA)
(c) certs are identified by both issuer DN and issuer public key
(explanation in the text) and the serial number.
(d) post is a default method
(e) multiple certificates can be supported in a single request.

Eager to receive your feedback (and also others on the net).

Regards,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303
--------------59992754DCE81649B0461645
Content-Type: text/plain; charset=us-ascii; name="draft-ietf-pkix-ocsp-03.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="draft-ietf-pkix-ocsp-03.txt"

PKIX Working Group                                Mike Myers (VeriSign)
draft-ietf-pkix-ocsp-03.txt                        Rich Ankney (CertCo)
Expires in 6 months                          Ambarish Malpani(ValiCert)
                                              Slava Galperin (Netscape)
                                                             March 1998

                  Internet Public Key Infrastructure
              Online Certificate Status Protocol - OCSP
                    <draft-ietf-pkix-ocsp-03.txt>

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups MAY also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and MAY be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories  on  ftp.is.co.za  (Africa),  nic.nordu.net  (Europe),
munnari.oz.au  (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

1. Abstract

The protocol conventions described in this document satisfy some of
the operational requirements of the Internet Public Key Infrastructure
(PKI). This document specifies a protocol useful in determining the
current status of a digital certificate without the use of CRLs.
Additional mechanisms addressing PKIX operational requirements are
specified in separate documents.

Section 2 provides an overview of the protocol. Section 3 goes through
the functional requirements, while section 4 provides the details of
the protocol. In section 5 we cover security issues with the
protocol. Appendix A demonstrates OCSP over HTTP.

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

2. Protocol Overview

In lieu of or as a supplement to checking against a periodic CRL, it MAY
be necessary to obtain timely status regarding a certificate's
revocation status (cf. PKIX Part 1, Section 3.3). Examples include high-
value fund transfers or the compromise of a highly sensitive key.

The Online Certificate Status Protocol (OCSP) enables applications to
determine the validity and revocation state of an identified
certificate. An OCSP client issues a status request to an OCSP
responder and suspends acceptance of the subject certificate until the
responder provides a response.

This protocol specifies the data that needs to be exchanged between an
application checking the revocation status of a certificate and the
server providing that status.

2.1 Request

An OCSP request contains the following data:

- protocol version
- service request
- target identifier for one or more certificates to be checked
- optional extensions which MAY be processed by the OCSP responder

Upon receipt of a request, an OCSP responder determines if: 1) the
message is well formed, 2) the responder is configured to provide the
requested service, and 3) the responder can perform the requested
service for the certificate in question. If any of the prior
conditions are not met, the OCSP responder produces an error message;
otherwise, it returns a definitive response.

2.2 Response

All definitive responses SHALL be digitally signed. The key
used to sign definitive responses need not be the same key
used to sign the certificate. The key used to sign the response can
belong to one of the following:

- a Trusted Responder, whose key is already embedded in the application
- the CA who issued the certificate in question
- an Authorized Responder, with a certificate which has a special extension
authorizing it to sign OCSP responses

A definitive response message is composed of:

- response type identifier (to allow for different response types)
- response validity interval
- target certificate identifier
- certificate status value
- identification of public key needed to validate the signature
- signature algorithm OID
- optional extensions
- signature computed across hash of previous six values

This specification defines the following definitive response indicators
for use in the certificate status value:

- notRevoked
- revoked
- onHold

The notRevoked state indicates that the certificate is not revoked. It
does not necessarily mean that the certificate was ever issued. Nor
does it mean that the certificate is in its validity interval. A
notRevoked state by an OCSP responder DOES NOT absolve the application
checking the certificate from checking its validity period and
signature.

The revoked state indicates that the certificate has been revoked.

The onHold state corresponds to valid certificates that are
operationally suspended in accordance with PKIX Part 1.

In case of errors, the OCSP Responder may return an error message. Errors
can be of the following types:

- malformedRequest
- requestorUnauthorized
- internalError
- tryLater

A server produces the malformedRequest response if the request received
does not conform to the OCSP syntax.

The response requestorUnauthorized is used in cases where the server
does not consider the client authorized to query it. Authorization
data is not explicitly a part of the request or this protocol.
However, certain responders may choose to require clients to ship an
authorization token with the request and may choose to refuse service
to clients that do not ship a correct authorization token.

The response internalError indicates that the OCSP responder reached
and inconsistent internal state. The query should be retried, potentially
with another responder.

The response tryLater is produced in any circumstance in which the
server has received a well formed OCSP request but is unable to process
it.

2.3 Response Pre-production

The response validity interval noted in the prior section is composed of
a {produced-at, valid-until} pair of elements in the response syntax.
Section 4.2 provides details of the response syntax.

OCSP responders MAY pre-produce signed responses reflecting the current
status of certificates at the time the response was produced. The time
at which the response was produced SHALL be reflected in the produced-at
field of the response.

The producer of the response MAY include a value for valid-until. The
exact interval between produced-at and valid-until for a given
response is a matter of local security and operational policy. If the
valid-until field is not present, the response was known to be correct
at the produced-at time. No assertions are being made about the
current state of the certificate.

If responses are pre-produced, then for a given certificate, the
periodicity of this pre-production SHOULD match the response validity
interval of the most recently produced response.

3. Functional Requirements

3.1 Certificate Content

In order to convey to OCSP clients a well-known point of information
access, CAs SHALL provide the capability to include the
AuthorityInfoAccess extension (defined in PKIX Part 1, section
4.2.2.1) in certificates intended to be applied to the service.

CAs that support an OCSP service, either hosted locally or provided by a
Trusted Third Party, SHALL provide a value for a
uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp
for the accessMethod in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate
corresponds to the URL placed into an OCSP request.

3.2 Error Responses

Upon receipt of a request which fails to parse, the receiving OCSP
responder SHALL respond with an error message. Error responses MAY be
signed.

3.3 Signed Response Acceptance Requirements

Prior to accepting a signed response as valid, OCSP clients SHALL
confirm that:

- The certificate identified in a received response corresponds to
that which was identified in a former request.
- The signature on the response is valid.
- The identity of the signer matches the intended recipient of the
request.
- The signer is currently authorized to sign the response.

4. Detailed Protocol

The ASN.1 syntax imports terms defined in the X.509 Certificate and CRL
Profile Internet Draft. For signature calculation, the data to be signed is
encoded using the ASN.1 distinguished encoding rules (DER) [X.208].

ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.

The terms imported from elsewhere are:
Version, Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name,
AlgorithmIdentifier, GeneralizedTime

4.1 Request Syntax

OCSPRequest     ::=     SEQUENCE {
        version                 [0]     EXPLICIT Version DEFAULT v1,
        hash                            AlgorithmIdentifier,
        requestList                     SEQUENCE OF Request,
        requestExtensions       [1]     EXPLICIT Extensions OPTIONAL
}

Request                 ::=     SEQUENCE {
        issuerNameAndKeyHash            Hash,
        serialNumber                    CertificateSerialNumber,
        cert                    [0]     EXPLICIT Certificate OPTIONAL
}

IssuerNameAndKey                ::=     SEQUENCE {
        issuer                          Name,
        issuerPublicKey                 SubjectPublicKeyInfo
}

Hash                    ::=     OCTET STRING --hash of IssuerNameAndKey--

The issuerNameAndKeyHash is computed by hashing an IssuerNameAndKey
field constructed for the CA in question using a cryptographic hash
function (e.g., SHA-1) specified as the hash algorithm in the request.
There are two reasons to use both the name and the public key to identify the
issuer.

- The Name may be NULL.
- It is possible that two CAs may choose to use the same Name
(uniqueness in the Name is a recommendation that cannot be enforced).
Two CAs will never, however, have the same public key unless the CAs
either explicitly decided to share their private key, or the key of
one of the CAs was compromised).

Support for extensions is OPTIONAL. The critical flag SHOULD NOT be
set for any of them. This standard suggests several useful extensions
in Section 4.4. Additional extensions MAY be defined in additional
RFCs. Unrecognized extensions SHOULD be ignored.

4.2 Response Syntax

This section specifies the ASN.1 specification for a confirmation
response. The actual formatting of the message could vary depending on
the transport mechanism used (http, smtp, ldap, etc.).

4.2.1 ASN.1 Specification of the OCSP Response

OCSPResponse            ::=     SEQUENCE {
        responseStatus                  OCSPResponseStatus,
        responseBytes           [0]     EXPLICIT ResponseBytes OPTIONAL
}

OCSPResponseStatus      ::=     ENUMERATED {
        successful              ( 0 ),  --Response has valid confirmations--
        malformedRequest        ( 1 ),  --Illegal confirmation request--
        requestorUnauthorized   ( 2 ),  --User not authorized to use issuer--
        internalError           ( 3 ),  --Internal error in issuer--
        unsupportedRequest      ( 4 ),  --Server can't support the request--
        tryLater                ( 5 )   --Try again later--
}

ResponseBytes           ::=     SEQUENCE {
        responseType                    OBJECT IDENTIFIER,
        response                        OCTET STRING
}

If the responseStatus is one of the error conditions, responseBytes
are not set.

For a basic OCSP responder, responseType will be id-pkix-ocsp-basic, where:
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-pkix ? }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }

The response will be the DER encoding of BasicOCSPResponse

BasicOCSPResponse       ::=     SEQUENCE {
        version                 [0]     EXPLICIT Version DEFAULT v1,
        signatureAlgorithm              AlgorithmIdentifier,
        responseData                    ResponseData,
        signature                       BIT STRING
}

ResponseData            ::=     SEQUENCE {
        responses                       SEQUENCE OF SingleResponse,
        responseExtensions      [0]     EXPLICIT Extensions OPTIONAL
}

SingleResponse          ::=     SEQUENCE {
        request                         Request,
        certStatus                      CertStatus,
        producedAt                      GeneralizedTime,
        validUntil              [0]     EXPLICIT GeneralizedTime OPTIONAL,
        eventTime               [1]     EXPLICIT GeneralizedTime OPTIONAL,
        singleExtensions        [2]     EXPLICIT Extensions OPTIONAL
}

CertStatus              ::=     CHOICE {
        certStatusType          [0]    EXPLICIT CertStatusType
                                        (notRevoked | onHold),
        statusWithTime          [1]    EXPLICIT StatusWithTime
}

StatusWithTime          ::=     SEQUENCE {
        certStatusType                  CertStatusType (revoked),
        time                            GeneralizedTime
}

CertStatusType          ::=     ENUMERATED {
        notRevoked              (0),    --This serial number is not revoked--
        revoked                 (1),    --Serial number was revoked--
        onHold                  (2),    --Cert is on hold--
}

The semantics of time in StatusWithTime are:
- for revoked, time is the time of revocation

The producedAt and validUntil fields define a validity interval. This
interval corresponds to the {thisUpdate, nextUpdate} CRL validity
interval. Responses whose validUntil value is earlier than the local
system time value SHOULD be considered unreliable. Responses where the
validUntil value is not set are equivalant to a CRL with no time for
nextUpdate.

4.3 Mandatory and Optional Cryptographic Algorithms

Clients that request OCSP services SHALL be capable of processing
responses signed used DSA keys identified by the DSA sig-alg-oid
specified in section 7.2.2 of PKIX Part 1. Clients SHOULD also be
capable of processing RSA signatures as specified in section 7.2.1 of
PKIX Part 1. OCSP responders SHALL support the SHA1 hash algorithm.

4.4 Extensions

This section defines the way to support some commonly requested
tasks. Support for all extensions is OPTIONAL.

4.4.1 Nonce

The nonce cryptographically binds a request and response, to prevent
replay attacks. The nonce is included as one of the requestExtensions,
in requests, while in response it would be included as one of the
responseExtensions.  In both the request and the response, the nonce
will be identified by the object identifier id-pkix-ocsp-nonce, while
the extnValue is the value of the nonce.

id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }

4.4.2 Signed Requests

This extension allows the requestor to sign the request. The
requestor includes an extension that has the signatureIdentifier, the
actual bits of the signature and a sequence of certificates to allow
the OCSP responder to verify the signature. The data to be
signed is just the basic request (none of the extensions). The OCSP
Responder can verify the signature, potentially using certificates
that have been included with the extension. The signature on a request
will be identified by id-pkix-ocsp-signature, while the value will
be SignatureData, where:

id-pkix-ocsp-signature OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }
SignatureData           ::=     SEQUENCE {
        signatureAlgorithm      AlgorithmIdentifier,
        signature               BIT STRING,
        certs           [0]     EXPLICIT SEQUENCE OF Certificate OPTIONAL
}

4.4.3 CRL References

It MAY be desirable for the OCSP responder to indicate the CRL on which
a revoked or held certificate is found. This can be useful where OCSP
is used between repositories, and also as an auditing mechanism. The
CRL may be specified by a URL (the URL at which the CRL is available),
a number (CRL number) or a time (the time at which the relevant CRL
was created). These extensions will be specified as singleExtensions.
The identifier for this extension will be id-pkix-ocsp-crl, while the value
will be CrlID.

id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }
CrlID           ::=     SEQUENCE {
        crlUrl          [0]     EXPLICIT IA5String OPTIONAL,
        crlNum          [1]     EXPLICIT INTEGER OPTIONAL,
        crlTime         [2]     EXPLICIT GeneralizedTime OPTIONAL
}

For the choice crlUrl, the IA5String will specify the URL at which the
CRL is available. For crlNum, the INTEGER will specify the value of the CRL
number extension of the relevant CRL. For crlTime, the GeneralizedTime
will indicate the time at which the relevant CRL was issued.

4.4.4 Other Extensions

CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are also
supported as singleExtensions.

5. Security Considerations

For this service to be effective, systems using certificates must
connect to the certificate status service provider. In the event such
a connection cannot be obtained, these systems could implement CRL
processing logic as a fall-back position.

If a CA authorizes another public key to sign OCSP responses,
compromise of that key is as serious as the compromise of the CA's key
as long as the authorization is valid.

A denial of service vulnerability is evident with respect to a flood
of queries constructed to produce error responses. The production of a
cryptographic signature significantly affects response generation
cycle time, thereby exacerbating the situation. Unsigned error
responses provide a reasonable tradeoff against this particular
attack.

Unsigned error responses open up the protocol to a denial of
service attack, where the attacker sends false error responses.

The use of precomputed responses may allow replay attacks in which
an old (notRevoked) response is replayed prior to its expiration but after
the certificate has been revoked.

This data is information which may conceivably be used to enforce
legal contracts, resolve disputes or transfer financial risk from one
party to another. The design of software that processes this type
should be trustworthy in its design and operations.

6. References

[HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee,
       R. Fielding & H. Frystyk, RFC 1945, May 1996.

[MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels,
 S. Bradner, RFC 2119, March 1997.

[URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter,
M.  McCahill, RFC 1738, December 1994.

7. Author's Address

Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019
[email-masked]

Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA  20151
[email-masked]

Ambarish Malpani
ValiCert, Inc.
3160 W. Bayshore Drive
Palo Alto, CA 94303
[email-masked]

Appendix A

A.1 OCSP over HTTP

This section describes the formatting that will be done to the request and
response to support HTTP.

A.1.1 Request

An OCSP request is an HTTP 1.0 POST method. The Content-Type header
has the value "application/ocsp-request", while the body of the
message is the DER encoding of the OCSPRequest.

A.1.2 Response

An HTTP-based OCSP response is composed of the appropriate HTTP headers,
followed by the DER encoding of the OCSPResponse. The Content-Type
header has the value "application/ocsp-response". The Content-Length
header SHOULD specify the length of the response. Other HTTP headers
MAY be present and MAY be ignored if not understood by the requestor.

Published specification: This document.

--------------59992754DCE81649B0461645--

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 9 Mar 1998 20:24:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Denis, David was responding to my original post, which pointed out that
most of the difficulties we are having with mutliple certificates for the same
key is due to the fact that the certificate information is not cryptographically
bound to the message itself.

But did you see my follow up back to him?  I'm somewhat surprised that
no one responded to it. I suggested that instead of solving this problem
over and over again for each separate application we should fix
the root cause, the SIGNED macro itself.

I then proposed a way of doing that which would not invalidate existing
code, but would merely require the definition of a new set of signature
algorithm IDs, where the additional information we might like to cryptographically
bind would be snuck in as COMPONENTS of the signature. We might even
be able to find a way to make those additional components optional.

Such components should include the issuer and serial number at a minimum, and I
could come up with a list of additional information that could at least
be debated as to whether it was worthy of being included. Date/time would be
certainly be worth discussing, as would some indication of the platform on which
the signature was created (for audit purposes). If biometrics were used there
might be some additional information that would be useful, etc., etc., etc.

If you didn't see the original message, I'd be happy to send it again -- my
e-mail system was rather flakey that particular evening.

Bob

>David,
>
>You posted a VERY important E-mail last week and I am bringing my
>support to it.
>
>> The X.509 "SIGNED" macro might not have been designed with the intent
>> of supporting this purpose, and so may be excused for not including
>> a method of binding a certificate to the signed data.
>>
>> However, the IETF CMS specification (aka PKCS#7) was designed for
>> precisely this purpose (providing non-repudiation grade signatures over
>> generic content), yet it still does not provide a clean method of
>> binding the signer's certificate to the content.
>
>True.
>
>> The CMS definition of SignedData includes {content, certs, crls,
>> signerInfos}, and some other fields.  There may be multiple signatures
>> applied to the content, each represented by a SignerInfo.  Each
>> SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
>> Because the issuerAndSerialNumber field, which uniquely identifies the
>> certificate used by the signer, is not covered by the signature, it is
>> not bound to the content.  I'm not sure why PKCS#7 was designed that
>> way, but it was, and so is CMS.
>
>I believe that at the time, PKCS#7 was written, the authors had not
>non-repudiation in mind, but simply using a digital signature for
>authenticating a message in real time. For that purpose, the format was
>fine.
>
>> It would have been preferable to define an issuerAndSerialNumber
>> attribute, which could have been included either in
>> authenticateAttributes to bind it with the signature, or in
>> unauthenticatedAttributes if the current semantics of not binding the
>> signer's cert to the signed content is desired.
>
>As the CMS standard is being rewritten in the smime working group,
>(draft-ietf-smime-cms-03.txt) and since the editor is Russ Housley also
>a member of the PKIX working group I think it is the perfect time to
>suggest to make changes. What do you think Russ ?
>
>> Perhaps defining a redundant copy of issuerAndSerialNumber, to be
>> included in authenticatedAttributes, could address the requirement
>> without breaking backward compatibility.  (It only covers the signer's
>> cert, not the full path, but it's a start.)
>
>Yes. Without breaking compatibility we could also support a SEQUENCE OF
>issuerAndSerialNumber. The simple change that is needed is to add this
>attribute in the section 11 (Useful Attributes) from the CMS document.
>In addition we should mandate the support of such an attribute, if the
>signed data is to be used in a non-repudiation process.
>
>> The uglier alternative is  is to double-sign everything, encapsulating a
>> signedData within another signedData for each parallel signature.
>>
>> Since CMS is intended to be a generic security encapsulation mechanism,
>> not just an S/MIME-specific structure, those who feel that this
>> requirement is important (to address either multiple certification of
>> keys or proof-of-possession) should discuss it in the S/MIME working
>> group.  (A SigningTime attribute is already defined in CMS, but a
>> "location" attribute is not.)
>
>Unfortunately I am not yet on this mailing list, so why I respond here.
>
>Denis
>
>--
> ***  Please note that the E-mail address has changed ! Update it.  ***
>      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Mon, 9 Mar 1998 17:23:15 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP using ASN.1
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

This is a multi-part message in MIME format.
--------------C02ED1D918D2DB363986E6E7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If you have already received this message, I appologize - it didn't
seem to ever come back to me.

Ambarish

Hi Mike,

Given the number of people requesting (1) OCSP provide better support
for ASN.1 (2) OCSP not be necessarily tied to HTTP (but be able to
benefit from HTTP),  I have taken the liberty making some fairly major
changes to the OCSP spec and would like to offer it up as a basis for
moving forward.

 I believe this re-write has technical merit on the following grounds:

(1) It separates OCSP from HTTP but at the same time the protocol can
be implemented using HTTP (both GET and POST).
(2) It is easier to implement (a new ABNF parser is not required --
uses standard ASN.1)
(3) It is more extensible and more consistent with existing crypto
applications (by virtue of using ASN.1).
(4) It allows multiple cryptographic algorithms in the response (RSA
signatures, Diffie Hellman signatures, revocation tree based responses,
iterated hashing based responses etc.)

There are some other minor changes which I think are important but
details (a) certificate status uses notRevoked instead of valid (since
this protocol just checks revocation status - not validity for
a particular task)
(b) usage of both SHA and MD5 is changed to just a hashing algorithm
(preferrably SHA)
(c) certs are identified by both issuer DN and issuer public key
(explanation in the text) and the serial number.
(d) post is a default method
(e) multiple certificates can be supported in a single request.

Eager to receive your feedback (and also others on the net).

Regards,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303
--------------C02ED1D918D2DB363986E6E7
Content-Type: text/plain; charset=us-ascii; name="draft-ietf-pkix-ocsp-03.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="draft-ietf-pkix-ocsp-03.txt"

PKIX Working Group                                Mike Myers (VeriSign)
draft-ietf-pkix-ocsp-03.txt                        Rich Ankney (CertCo)
Expires in 6 months                          Ambarish Malpani(ValiCert)
                                              Slava Galperin (Netscape)
                                                             March 1998

                  Internet Public Key Infrastructure
              Online Certificate Status Protocol - OCSP
                    <draft-ietf-pkix-ocsp-03.txt>

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups MAY also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and MAY be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories  on  ftp.is.co.za  (Africa),  nic.nordu.net  (Europe),
munnari.oz.au  (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

1. Abstract

The protocol conventions described in this document satisfy some of
the operational requirements of the Internet Public Key Infrastructure
(PKI). This document specifies a protocol useful in determining the
current status of a digital certificate without the use of CRLs.
Additional mechanisms addressing PKIX operational requirements are
specified in separate documents.

Section 2 provides an overview of the protocol. Section 3 goes through
the functional requirements, while section 4 provides the details of
the protocol. In section 5 we cover security issues with the
protocol. Appendix A demonstrates OCSP over HTTP.

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

2. Protocol Overview

In lieu of or as a supplement to checking against a periodic CRL, it MAY
be necessary to obtain timely status regarding a certificate's
revocation status (cf. PKIX Part 1, Section 3.3). Examples include high-
value fund transfers or the compromise of a highly sensitive key.

The Online Certificate Status Protocol (OCSP) enables applications to
determine the validity and revocation state of an identified
certificate. An OCSP client issues a status request to an OCSP
responder and suspends acceptance of the subject certificate until the
responder provides a response.

This protocol specifies the data that needs to be exchanged between an
application checking the revocation status of a certificate and the
server providing that status.

2.1 Request

An OCSP request contains the following data:

- protocol version
- service request
- target identifier for one or more certificates to be checked
- optional extensions which MAY be processed by the OCSP responder

Upon receipt of a request, an OCSP responder determines if: 1) the
message is well formed, 2) the responder is configured to provide the
requested service, and 3) the responder can perform the requested
service for the certificate in question. If any of the prior
conditions are not met, the OCSP responder produces an error message;
otherwise, it returns a definitive response.

2.2 Response

All definitive responses SHALL be digitally signed. The key
used to sign definitive responses need not be the same key
used to sign the certificate. The key used to sign the response can
belong to one of the following:

- a Trusted Responder, whose key is already embedded in the application
- the CA who issued the certificate in question
- an Authorized Responder, with a certificate which has a special extension
authorizing it to sign OCSP responses

A definitive response message is composed of:

- response type identifier (to allow for different response types)
- response validity interval
- target certificate identifier
- certificate status value
- identification of public key needed to validate the signature
- signature algorithm OID
- optional extensions
- signature computed across hash of previous six values

This specification defines the following definitive response indicators
for use in the certificate status value:

- notRevoked
- revoked
- onHold

The notRevoked state indicates that the certificate is not revoked. It
does not necessarily mean that the certificate was ever issued. Nor
does it mean that the certificate is in its validity interval. A
notRevoked state by an OCSP responder DOES NOT absolve the application
checking the certificate from checking its validity period and
signature.

The revoked state indicates that the certificate has been revoked.

The onHold state corresponds to valid certificates that are
operationally suspended in accordance with PKIX Part 1.

In case of errors, the OCSP Responder may return an error message. Errors
can be of the following types:

- malformedRequest
- requestorUnauthorized
- internalError
- tryLater

A server produces the malformedRequest response if the request received
does not conform to the OCSP syntax.

The response requestorUnauthorized is used in cases where the server
does not consider the client authorized to query it. Authorization
data is not explicitly a part of the request or this protocol.
However, certain responders may choose to require clients to ship an
authorization token with the request and may choose to refuse service
to clients that do not ship a correct authorization token.

The response internalError indicates that the OCSP responder reached
and inconsistent internal state. The query should be retried, potentially
with another responder.

The response tryLater is produced in any circumstance in which the
server has received a well formed OCSP request but is unable to process
it.

2.3 Response Pre-production

The response validity interval noted in the prior section is composed of
a {produced-at, valid-until} pair of elements in the response syntax.
Section 4.2 provides details of the response syntax.

OCSP responders MAY pre-produce signed responses reflecting the current
status of certificates at the time the response was produced. The time
at which the response was produced SHALL be reflected in the produced-at
field of the response.

The producer of the response MAY include a value for valid-until. The
exact interval between produced-at and valid-until for a given
response is a matter of local security and operational policy. If the
valid-until field is not present, the response was known to be correct
at the produced-at time. No assertions are being made about the
current state of the certificate.

If responses are pre-produced, then for a given certificate, the
periodicity of this pre-production SHOULD match the response validity
interval of the most recently produced response.

3. Functional Requirements

3.1 Certificate Content

In order to convey to OCSP clients a well-known point of information
access, CAs SHALL provide the capability to include the
AuthorityInfoAccess extension (defined in PKIX Part 1, section
4.2.2.1) in certificates intended to be applied to the service.

CAs that support an OCSP service, either hosted locally or provided by a
Trusted Third Party, SHALL provide a value for a
uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp
for the accessMethod in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate
corresponds to the URL placed into an OCSP request.

3.2 Error Responses

Upon receipt of a request which fails to parse, the receiving OCSP
responder SHALL respond with an error message. Error responses MAY be
signed.

3.3 Signed Response Acceptance Requirements

Prior to accepting a signed response as valid, OCSP clients SHALL
confirm that:

- The certificate identified in a received response corresponds to
that which was identified in a former request.
- The signature on the response is valid.
- The identity of the signer matches the intended recipient of the
request.
- The signer is currently authorized to sign the response.

4. Detailed Protocol

The ASN.1 syntax imports terms defined in the X.509 Certificate and CRL
Profile Internet Draft. For signature calculation, the data to be signed is
encoded using the ASN.1 distinguished encoding rules (DER) [X.208].

ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.

The terms imported from elsewhere are:
Version, Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name,
AlgorithmIdentifier, GeneralizedTime

4.1 Request Syntax

OCSPRequest     ::=     SEQUENCE {
        version                 [0]     EXPLICIT Version DEFAULT v1,
        hash                            AlgorithmIdentifier,
        requestList                     SEQUENCE OF Request,
        requestExtensions       [1]     EXPLICIT Extensions OPTIONAL
}

Request                 ::=     SEQUENCE {
        issuerNameAndKeyHash            Hash,
        serialNumber                    CertificateSerialNumber,
        cert                    [0]     EXPLICIT Certificate OPTIONAL
}

IssuerNameAndKey                ::=     SEQUENCE {
        issuer                          Name,
        issuerPublicKey                 SubjectPublicKeyInfo
}

Hash                    ::=     OCTET STRING --hash of IssuerNameAndKey--

The issuerNameAndKeyHash is computed by hashing an IssuerNameAndKey
field constructed for the CA in question using a cryptographic hash
function (e.g., SHA-1) specified as the hash algorithm in the request.
There are two reasons to use both the name and the public key to identify the
issuer.

- The Name may be NULL.
- It is possible that two CAs may choose to use the same Name
(uniqueness in the Name is a recommendation that cannot be enforced).
Two CAs will never, however, have the same public key unless the CAs
either explicitly decided to share their private key, or the key of
one of the CAs was compromised).

Support for extensions is OPTIONAL. The critical flag SHOULD NOT be
set for any of them. This standard suggests several useful extensions
in Section 4.4. Additional extensions MAY be defined in additional
RFCs. Unrecognized extensions SHOULD be ignored.

4.2 Response Syntax

This section specifies the ASN.1 specification for a confirmation
response. The actual formatting of the message could vary depending on
the transport mechanism used (http, smtp, ldap, etc.).

4.2.1 ASN.1 Specification of the OCSP Response

OCSPResponse            ::=     SEQUENCE {
        responseStatus                  OCSPResponseStatus,
        responseBytes           [0]     EXPLICIT ResponseBytes OPTIONAL
}

OCSPResponseStatus      ::=     ENUMERATED {
        successful              ( 0 ),  --Response has valid confirmations--
        malformedRequest        ( 1 ),  --Illegal confirmation request--
        requestorUnauthorized   ( 2 ),  --User not authorized to use issuer--
        internalError           ( 3 ),  --Internal error in issuer--
        unsupportedRequest      ( 4 ),  --Server can't support the request--
        tryLater                ( 5 )   --Try again later--
}

ResponseBytes           ::=     SEQUENCE {
        responseType                    OBJECT IDENTIFIER,
        response                        OCTET STRING
}

If the responseStatus is one of the error conditions, responseBytes
are not set.

For a basic OCSP responder, responseType will be id-pkix-ocsp-basic, where:
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-pkix ? }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }

The response will be the DER encoding of BasicOCSPResponse

BasicOCSPResponse       ::=     SEQUENCE {
        version                 [0]     EXPLICIT Version DEFAULT v1,
        signatureAlgorithm              AlgorithmIdentifier,
        responseData                    ResponseData,
        signature                       BIT STRING
}

ResponseData            ::=     SEQUENCE {
        responses                       SEQUENCE OF SingleResponse,
        responseExtensions      [0]     EXPLICIT Extensions OPTIONAL
}

SingleResponse          ::=     SEQUENCE {
        request                         Request,
        certStatus                      CertStatus,
        producedAt                      GeneralizedTime,
        validUntil              [0]     EXPLICIT GeneralizedTime OPTIONAL,
        eventTime               [1]     EXPLICIT GeneralizedTime OPTIONAL,
        singleExtensions        [2]     EXPLICIT Extensions OPTIONAL
}

CertStatus              ::=     CHOICE {
        certStatusType          [0]    EXPLICIT CertStatusType
                                        (notRevoked | onHold),
        statusWithTime          [1]    EXPLICIT StatusWithTime
}

StatusWithTime          ::=     SEQUENCE {
        certStatusType                  CertStatusType (revoked),
        time                            GeneralizedTime
}

CertStatusType          ::=     ENUMERATED {
        notRevoked              (0),    --This serial number is not revoked--
        revoked                 (1),    --Serial number was revoked--
        onHold                  (2),    --Cert is on hold--
}

The semantics of time in StatusWithTime are:
- for revoked, time is the time of revocation

The producedAt and validUntil fields define a validity interval. This
interval corresponds to the {thisUpdate, nextUpdate} CRL validity
interval. Responses whose validUntil value is earlier than the local
system time value SHOULD be considered unreliable. Responses where the
validUntil value is not set are equivalant to a CRL with no time for
nextUpdate.

4.3 Mandatory and Optional Cryptographic Algorithms

Clients that request OCSP services SHALL be capable of processing
responses signed used DSA keys identified by the DSA sig-alg-oid
specified in section 7.2.2 of PKIX Part 1. Clients SHOULD also be
capable of processing RSA signatures as specified in section 7.2.1 of
PKIX Part 1. OCSP responders SHALL support the SHA1 hash algorithm.

4.4 Extensions

This section defines the way to support some commonly requested
tasks. Support for all extensions is OPTIONAL.

4.4.1 Nonce

The nonce cryptographically binds a request and response, to prevent
replay attacks. The nonce is included as one of the requestExtensions,
in requests, while in response it would be included as one of the
responseExtensions.  In both the request and the response, the nonce
will be identified by the object identifier id-pkix-ocsp-nonce, while
the extnValue is the value of the nonce.

id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }

4.4.2 Signed Requests

This extension allows the requestor to sign the request. The
requestor includes an extension that has the signatureIdentifier, the
actual bits of the signature and a sequence of certificates to allow
the OCSP responder to verify the signature. The data to be
signed is just the basic request (none of the extensions). The OCSP
Responder can verify the signature, potentially using certificates
that have been included with the extension. The signature on a request
will be identified by id-pkix-ocsp-signature, while the value will
be SignatureData, where:

id-pkix-ocsp-signature OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }
SignatureData           ::=     SEQUENCE {
        signatureAlgorithm      AlgorithmIdentifier,
        signature               BIT STRING,
        certs           [0]     EXPLICIT SEQUENCE OF Certificate OPTIONAL
}

4.4.3 CRL References

It MAY be desirable for the OCSP responder to indicate the CRL on which
a revoked or held certificate is found. This can be useful where OCSP
is used between repositories, and also as an auditing mechanism. The
CRL may be specified by a URL (the URL at which the CRL is available),
a number (CRL number) or a time (the time at which the relevant CRL
was created). These extensions will be specified as singleExtensions.
The identifier for this extension will be id-pkix-ocsp-crl, while the value
will be CrlID.

id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }
CrlID           ::=     SEQUENCE {
        crlUrl          [0]     EXPLICIT IA5String OPTIONAL,
        crlNum          [1]     EXPLICIT INTEGER OPTIONAL,
        crlTime         [2]     EXPLICIT GeneralizedTime OPTIONAL
}

For the choice crlUrl, the IA5String will specify the URL at which the
CRL is available. For crlNum, the INTEGER will specify the value of the CRL
number extension of the relevant CRL. For crlTime, the GeneralizedTime
will indicate the time at which the relevant CRL was issued.

4.4.4 Other Extensions

CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are also
supported as singleExtensions.

5. Security Considerations

For this service to be effective, systems using certificates must
connect to the certificate status service provider. In the event such
a connection cannot be obtained, these systems could implement CRL
processing logic as a fall-back position.

If a CA authorizes another public key to sign OCSP responses,
compromise of that key is as serious as the compromise of the CA's key
as long as the authorization is valid.

A denial of service vulnerability is evident with respect to a flood
of queries constructed to produce error responses. The production of a
cryptographic signature significantly affects response generation
cycle time, thereby exacerbating the situation. Unsigned error
responses provide a reasonable tradeoff against this particular
attack.

Unsigned error responses open up the protocol to a denial of
service attack, where the attacker sends false error responses.

The use of precomputed responses may allow replay attacks in which
an old (notRevoked) response is replayed prior to its expiration but after
the certificate has been revoked.

This data is information which may conceivably be used to enforce
legal contracts, resolve disputes or transfer financial risk from one
party to another. The design of software that processes this type
should be trustworthy in its design and operations.

6. References

[HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee,
       R. Fielding & H. Frystyk, RFC 1945, May 1996.

[MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels,
 S. Bradner, RFC 2119, March 1997.

[URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter,
M.  McCahill, RFC 1738, December 1994.

7. Author's Address

Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019
[email-masked]

Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA  20151
[email-masked]

Ambarish Malpani
ValiCert, Inc.
3160 W. Bayshore Drive
Palo Alto, CA 94303
[email-masked]

Appendix A

A.1 OCSP over HTTP

This section describes the formatting that will be done to the request and
response to support HTTP.

A.1.1 Request

An OCSP request is an HTTP 1.0 POST method. The Content-Type header
has the value "application/ocsp-request", while the body of the
message is the DER encoding of the OCSPRequest.

A.1.2 Response

An HTTP-based OCSP response is composed of the appropriate HTTP headers,
followed by the DER encoding of the OCSPResponse. The Content-Type
header has the value "application/ocsp-response". The Content-Length
header SHOULD specify the length of the response. Other HTTP headers
MAY be present and MAY be ignored if not understood by the requestor.

Published specification: This document.

--------------C02ED1D918D2DB363986E6E7--

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 9 Mar 1998 20:11:19 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

>If I understand correctly, there is a scenario for cross-certification
>whereby I retrieve your public key from a directory (where it may be
>stored as a key, or it may be sealed into a certificate) and then I
>issue a certificate containing your public key signed by me.
>
>If this is accurate, it follows that there will be many certificates
>extant containing the same public key.
>
>Another issue: any ambiguity which may proceed from the intentional
>issuance of two different certs against one key pair, will also apply
>whenever random processes or operational errors produce identical key
>pairs for different users. Although we can prefer that this not happen
>we cannot prevent it by mandate, therefore the infrastructure must be
>sufficiently robust that it not fail when this condition is encountered.
>
>-Dwight

Both valid points, and among the reasons why I didn't say "never".

Bob

Approved-By:  Michael Leahy <[email-masked]>
Date:         Mon, 9 Mar 1998 16:13:58 UT
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: Michael Leahy <[email-masked]>
Subject:      [IETF-PKIX] registering company object identifiers
To: [email-masked]

Hi

To register an object identifier for a company I assume you contact (if in the USA)
http://www.ansi.org but who is the appropriate organization for Europe ?

Also the URL http://www.ansi.org  appears to be down at the moment - have ANSI moved there Web site or what's up ?

Regards
Michael Leahy
ISOCOR

Approved-By:  Dwight Arthur <[email-masked]>
Date:         Mon, 9 Mar 1998 17:12:56 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dwight Arthur <[email-masked]>
Subject:      [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

If I understand correctly, there is a scenario for cross-certification
whereby I retrieve your public key from a directory (where it may be
stored as a key, or it may be sealed into a certificate) and then I
issue a certificate containing your public key signed by me.

If this is accurate, it follows that there will be many certificates
extant containing the same public key.

Another issue: any ambiguity which may proceed from the intentional
issuance of two different certs against one key pair, will also apply
whenever random processes or operational errors produce identical key
pairs for different users. Although we can prefer that this not happen
we cannot prevent it by mandate, therefore the infrastructure must be
sufficiently robust that it not fail when this condition is encountered.

-Dwight

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 9 Mar 1998 15:11:42 -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] Multiple certificates for same key?
Comments: cc: [email-masked]
To: [email-masked]

David,

You posted a VERY important E-mail last week and I am bringing my
support to it.

> The X.509 "SIGNED" macro might not have been designed with the intent
> of supporting this purpose, and so may be excused for not including
> a method of binding a certificate to the signed data.
>
> However, the IETF CMS specification (aka PKCS#7) was designed for
> precisely this purpose (providing non-repudiation grade signatures over
> generic content), yet it still does not provide a clean method of
> binding the signer's certificate to the content.

True.

> The CMS definition of SignedData includes {content, certs, crls,
> signerInfos}, and some other fields.  There may be multiple signatures
> applied to the content, each represented by a SignerInfo.  Each
> SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
> Because the issuerAndSerialNumber field, which uniquely identifies the
> certificate used by the signer, is not covered by the signature, it is
> not bound to the content.  I'm not sure why PKCS#7 was designed that
> way, but it was, and so is CMS.

I believe that at the time, PKCS#7 was written, the authors had not
non-repudiation in mind, but simply using a digital signature for
authenticating a message in real time. For that purpose, the format was
fine.

> It would have been preferable to define an issuerAndSerialNumber
> attribute, which could have been included either in
> authenticateAttributes to bind it with the signature, or in
> unauthenticatedAttributes if the current semantics of not binding the
> signer's cert to the signed content is desired.

As the CMS standard is being rewritten in the smime working group,
(draft-ietf-smime-cms-03.txt) and since the editor is Russ Housley also
a member of the PKIX working group I think it is the perfect time to
suggest to make changes. What do you think Russ ?

> Perhaps defining a redundant copy of issuerAndSerialNumber, to be
> included in authenticatedAttributes, could address the requirement
> without breaking backward compatibility.  (It only covers the signer's
> cert, not the full path, but it's a start.)

Yes. Without breaking compatibility we could also support a SEQUENCE OF
issuerAndSerialNumber. The simple change that is needed is to add this
attribute in the section 11 (Useful Attributes) from the CMS document.
In addition we should mandate the support of such an attribute, if the
signed data is to be used in a non-repudiation process.

> The uglier alternative is  is to double-sign everything, encapsulating a
> signedData within another signedData for each parallel signature.
>
> Since CMS is intended to be a generic security encapsulation mechanism,
> not just an S/MIME-specific structure, those who feel that this
> requirement is important (to address either multiple certification of
> keys or proof-of-possession) should discuss it in the S/MIME working
> group.  (A SigningTime attribute is already defined in CMS, but a
> "location" attribute is not.)

Unfortunately I am not yet on this mailing list, so why I respond here.

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Fri, 6 Mar 1998 17:22:19 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: cc: Stephen Kent <[email-masked]>
To: [email-masked]

Stephen,

At 12:07 PM 3/6/98 -0500, you wrote:
>Dan,
>
>>Let's get this straight -- the key is the identity,
>>your name is a handle.  If liberty means anything, you
>>can call yourself what you want hence identity-to-handle
>>mapping will be many to many.  The tradeoff is your
>>complexity eval of managing O(10**2) keys versus your
>>exposure eval of published cross correlation of the key
>>sharing amongst certs.
>
>Wrong mailing list.  What you said above is the SPKI notion, but it's not
>the PKIX notion, of the semantics of the subject name field in a
>certificate.
>
>Steve

I agree with your characterization of subject name SPKI vis-a-vis PKIX.

Dan makes a secondary point, in that the cost of carrying different keys
for every usage (identification or authorization, I suppose) be weighed
against the potential privacy concern of having one key (especially in
the case of an identity role) employed so widely that tracking usage on
the one key produces a virtual dossier on the owner.

Being primarily a theoretic type, I imagine infinite cpu, storage and
bandwidth are available now, or will be next Tuesday, so I tend to ignore
spacetime considerations at my peril.

P.S.  Hope to hear you speak in Reston at the FPKI thing.

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Russ Housley <[email-masked]>
Date:         Thu, 5 Mar 1998 18:50:27 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

At 06:32 PM 3/5/98 +0200, Mark Shuttleworth wrote:
>> Let's get this straight -- the key is the identity,
>> your name is a handle.  If liberty means anything, you
>> can call yourself what you want hence identity-to-handle
>> mapping will be many to many.  The tradeoff is your
>> complexity eval of managing O(10**2) keys versus your
>> exposure eval of published cross correlation of the key
>> sharing amongst certs.
>
>Gotta disagree.  The name is your identity (and potentially your
>authority).  The key is merely a way to tie an action (signature) to that
>identity.  The problem is tht one-key-many-certs can mean that an action
>is tied to multiple identities.  It's not a huge problem.
>
If a certificate includes more than one AltSubjectName, then action is tied
to multiple identities using one certificate.  Why is it a problem that the
same thing can be accomplished with more than one certificate.

Russ

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Fri, 6 Mar 1998 15:06:27 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

All,

Please note that in the scenarios I have given regarding government
requirements for crypto key recovery, I intend this meaning to apply
to PKI keys *used* by government for government business, and not
necessarily for recovery of private-use crypto keys.  My personal
feelings are that key recovery should be a "local policy" issue.

Regarding David Kemp's response to Paul Koning, I think that we can
all agree that two identical strings of bits are the *same* key,
regardless of how disparately generated.  I am sure Paul meant as
much.  The "second" certification of a key, contrary in use to a
policy specified in the first certification, represents a "null-
policy-intersection" for the use of that key.  In other words, the
key cannot be used without the user being in violation of policy.

Government wants to know how to deter and/or detect such violation.

Where a policy-intersection is non-null, use should be valid where
such usage lies properly in this intersection.  Else again there is
a violation of some policy.

I am sure that Paul did not mean to imply that a key separately
certified was a "different key" and that "null-intersection" meant
freedom to use each key according to (effectively) the union of the
usage policies.

___TONY___

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Paul Koning <[email-masked]>
Date:         Fri, 6 Mar 1998 17:48: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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

...
 David> More realistically, if one CA's Certification Practices
 David> Statement says that subscribers will be required to keep their
 David> private keys in a FIPS-140 rated module, and another CA allows
 David> subscribers to keep them in unencrypted hard disk files, then
 David> if I happen to request certification of two keys which happen
 David> to have the same bit pattern from the two CAs, one of the CA's
 David> policies may have been violated.
 >>  That doesn't follow at all.  You only get into trouble if the
 >> intersection of the requirements of the various CAs is null.

 David> That's a contrived example - requiring the subscriber to adopt
 David> the Clintonesque attitude that there are really two keys.
 David> (The two keys just happen to have the same bits.)  They are
 David> two different pieces of data stored in two different
 David> locations.  If key B is stored in the clear, that doesn't
 David> technically violate CA A's restriction.  But if key A and key
 David> B happen to have the same value, the adverse effect on
 David> security is the same as if key A were stored in the clear,
 David> violating CA A's restriction.

I must be missing something very basic here.

You seem to be saying that I would store the *private* key in two
places because I have two certificates for that same key.

That doesn't compute.  Clearly I would store the private key only
once.  That after all was the reason I wanted it to be one key and not
two...  And furthermore, given that I'm a good responsible person :-)
I'll store it in conformance with the strictest rules for protecting
secret keys that apply to me.

In the example, that would mean using a FIPS-140 module, which will
satisfy the requirements of both CAs.

        paul

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Fri, 6 Mar 1998 14:31:19 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
Comments: cc: Paul Koning <[email-masked]>
To: [email-masked]

At 04:10 PM 3/6/98 -0500, responding to David Kemp, Paul Koning wrote, in
part:

> David> More realistically, if one CA's Certification Practices
> David> Statement says that subscribers will be required to keep their
> David> private keys in a FIPS-140 rated module, and another CA allows
> David> subscribers to keep them in unencrypted hard disk files, then
> David> if I happen to request certification of two keys which happen
> David> to have the same bit pattern from the two CAs, one of the CA's
> David> policies may have been violated.
>
>That doesn't follow at all.  You only get into trouble if the
>intersection of the requirements of the various CAs is null.
>
>In the example you quoted, all that's needed is that the private key
>has to be in a rated module, since one of the CAs requires that.  So
>long as the other CA doesn't have a policy *forbidding* the use of a
>rated module, you're all set.

I tend to agree.  More interesting, however, is the case given by David
that you did not explicitly address.  This is where the two certs demand
crypto-only and signature-only usage, respectively.  Granted, as such
the usage intersection should prove to be null, but this intersection
(as in the previous storage example) occurs in execution of policy, and
not in code.  Consider as well these two scenarios:

1.  Government usage for crypto will demand provision for key recovery.
Suppose they are silent on recovery of signature key usage.  In such case,
one would be conforming only if key recovery is available in both usages.
Not a great idea.  (Actually, a very bad idea.)

2.  Government usage for crypto demands provision for key recovery, but
also mandates strict guarantees against the possibility of key recovery
for signature keys (we should all demand this in my personal opinion.)
Such a demand precludes the use of a key for both purposes, and any
such dual-certification should produce the "empty intersection" that
you spoke of previously.  The question becomes one of enforcement.
Under such circumstances, it should be impossible to use the key, or
to have the second use certified.  At the very least, government should
demand that attempted dual use be detectable.

But how is software to know what other certifications a key may have?

>Using certificates to describe authorization means of course that I
>won't just check whether there exists a certificate that validates a
>signature -- I'd also check that the certificate is one that grants
>the kind of authorization I'm interested in.  For example, to
>validate, say, a dialup access attempt, I might look for a certificate
>issued by my company.

This principle I agree with as well.

>        paul
>

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 6 Mar 1998 17:10:35 -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] Multiple Certificates
To: [email-masked]

>  David> If some other person gets a copy of my private key, that is a
>  David> key compromise.  If I have a keypair certified for one
>  David> purpose, and I take that private key and request that it be
>  David> certified for a different purpose, that is a key compromise
>  David> from one of my schizophrenic personalities to another :-).
>
> I don't see the issue.
>
> If your private key is compromised, your private key is compromised,
> and the validity of all signatures made by that key is thrown in
> doubt.  Whether the corresponding public key is attested by one or by
> a million certificates makes no difference.

Let me try to put it another way, make a different analogy that
might help, or might just confuse.

I like using Unix because it has multiple users.  If I administer
a machine (say my own personal machine at home), I know the root
password and the passwords for any number of users.  But I only
log in using the root password infrequently to do important stuff.
Most of the time I use my normal user account.  And when I want
to do something especially dangerous, like running a program picked
up off the Internet, I log in as a different user with minimal privileges
so it can't read or write my normal files.
Do you agree that this is prudent?

Now say I have three certs, one for doing important stuff (signing
contracts), one for doing regular stuff (signing email), and one for
testing.  I keep the important private key in a token that isn't normally
plugged in to the machine.  I keep the normal key in a disk file, encrypted.
And the test key is kept in whatever form is most useful for testing
software, unencrypted.

If all three keys have the same value, then anyone who gets onto the
machine and gets a copy of the test key now has a copy of the key I am
very careful to store on a token.
Do you agree that this is a bad situation?

Do you agree that if I have a million certs, each with a different
key, then compromising one of them leaves the other 999,999 unaffected?

>  David> More realistically, if one CA's Certification Practices
>  David> Statement says that subscribers will be required to keep their
>  David> private keys in a FIPS-140 rated module, and another CA allows
>  David> subscribers to keep them in unencrypted hard disk files, then
>  David> if I happen to request certification of two keys which happen
>  David> to have the same bit pattern from the two CAs, one of the CA's
>  David> policies may have been violated.
>
> That doesn't follow at all.  You only get into trouble if the
> intersection of the requirements of the various CAs is null.

That's a contrived example - requiring the subscriber to adopt the
Clintonesque attitude that there are really two keys.  (The two
keys just happen to have the same bits.)  They are two different
pieces of data stored in two different locations.  If key B is stored
in the clear, that doesn't technically violate CA A's restriction.  But
if key A and key B happen to have the same value, the adverse effect
on security is the same as if key A were stored in the clear, violating
CA A's restriction.

> It seems to me that, given that many people view certificates as
> things that describe authority (roles) and not identity, you're going
> to have a pile of them.  And if you do, there are good reasons to want
> to minimize the number of private keys.

What is one good reason to minimize the number of private keys?

You aren't going to save much money by skimping on memory to store
private keys.  And you aren't going to gain any convenience; when you
pick a cert you get the private key that goes with it, whether that
is the same value or a different value than the keys for your other
certs.

> To apply one of the standard analogies again: while I have one
> identity, I have a lot of different authorizations (roles), and lots
> of different pieces of plastic and paper attesting to these.  But my
> signature on all of them is the same scribble.

This is a meaningless analogy.  If your digital signature was always
the same electronic scribble, it wouldn't be very hard for anyone
to forge your signature, would it.

Approved-By:  "Arsenault, Al W." <[email-masked]>
Date:         Fri, 6 Mar 1998 16:56: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: "Arsenault, Al W." <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

Sorry to jump in late, but I've been away at other jobs for a while, and
I'm just catching up :-)

>From one of Dave Kemp's messages:

>> What is the foundation or context for this discussion: WHAT ATTACKS ARE
>> WE CONCERNED ABOUT?
>
>
>Key compromise.
>
>If some other person gets a copy of my private key, that is a key compromise.
>If I have a keypair certified for one purpose, and I take that private key
>and request that it be certified for a different purpose, that is a key
>compromise from one of my schizophrenic personalities to another :-).

AWA comment:  it's only a "compromise" if it's unauthorized - against
the rules established by one or more CAs.
>
>More realistically, if one CA's Certification Practices Statement says
>that subscribers will be required to keep their private keys in a
>FIPS-140 rated module, and another CA allows subscribers to keep them
>in unencrypted hard disk files, then if I happen to request certification
>of two keys which happen to have the same bit pattern from the two CAs,
>one of the CA's policies may have been violated.

AWA comment:  if you the user do this intentionally, then you the user
are at fault for violating the CA's requirements.  (Danger: analogy
ahead)  If you the user give your hardware token and the PIN to it to
another carbon-based life form, and that carbon-based life form signs
something as you, you have likely also vioated the CA's requirements.
Same thing if you let another carbon-based life form log in to your
computer as you.  The CA can't ensure everything, which is why all CAs I
know of make users sign agreements stipulating the user
responsibilities.  If you violate your responsibilities, the CA
disclaims any liability for your actions.

(If the dual certification of the same key happens by
incredibly-unlikely random chance (your key generator generated the same
key pair twice), then there's nothing any system can do about it.)

>That is an extreme example, but it applies anytime there are differences
>in the purposes for which a certificate is issued. To be less extreme,
>say the FPKI profile says that certs shall not contain keyUsage bits
>set which allow both signature and encryption.  If the same key is certified
>twice, once for each purpose, then both certs are compliant with the
>policy but the end result is not.

AWA comment:  again, if the user does this intentionally to evade the
rules, the fault lies with the user vice the CA.

>It is impossible to analyze the interactions of all possible combinations
>of certification practices and certificate attributes to determine whether
>any two pairs result in unintended consequences.  Therefore, the safe
>thing to do is to not multiply-certify a single key unless you have
>analyzed and understand the results.
>
>
>> For the life of me, I am unable to identify any attacks that result from
>> replacing certificates other than denial of service.
>>
>> For example, suppose I sign and send a message and someone replaces my
>> certificate with one they dynamically generate that contains "do not
>> trust this certificate", the recipient will surely not trust my message.
>> I, the sender, will still be able to resend my original message via
>> other means.
>>
>> No one has identified an attack that warrants changing the existing
>> standard to not allow multiple certificates per public key (which is
>> most probably not enforcable anyway).
>>
>> Unless someone can identify an attack that warrants changing the
>> standard, the standard should not be changed.
>
>
>I don't think anyone has proposed modifying any standard to prohibit
>multiple certification.  We're just pointing out security considerations
>that should lead to the Generally Accepted Practice of not doing it.

AWA comment:  I agree with what Mark Shuttleworth, Steve Kent, and a
couple of others have said:

        - certifying the same key in multiple certificates is a matter of
individual CA policy.  There are valid reasons for doing it.

        - it should not be deprecated in the PKIX documents, although it
wouldn't hurt to mention some of the dangers associated with it.

I would also point out the unwritten assumption here:  we're talking
about signature keys, only.  There are plenty of good reasons for
putting the same key-exchange/key-agreement key in multiple
certificates, and few if any of the authenticity problems that arise
with signature keys.

                Al Arsenault

-- speaking only for myself.  My views do not necessarily represent
those of my employer.

Approved-By:  Paul Koning <[email-masked]>
Date:         Fri, 6 Mar 1998 16:10: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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

 >> What is the foundation or context for this discussion: WHAT
 >> ATTACKS ARE WE CONCERNED ABOUT?

 David> Key compromise.

 David> If some other person gets a copy of my private key, that is a
 David> key compromise.  If I have a keypair certified for one
 David> purpose, and I take that private key and request that it be
 David> certified for a different purpose, that is a key compromise
 David> from one of my schizophrenic personalities to another :-).

I don't see the issue.

If your private key is compromised, your private key is compromised,
and the validity of all signatures made by that key is thrown in
doubt.  Whether the corresponding public key is attested by one or by
a million certificates makes no difference.

 David> More realistically, if one CA's Certification Practices
 David> Statement says that subscribers will be required to keep their
 David> private keys in a FIPS-140 rated module, and another CA allows
 David> subscribers to keep them in unencrypted hard disk files, then
 David> if I happen to request certification of two keys which happen
 David> to have the same bit pattern from the two CAs, one of the CA's
 David> policies may have been violated.

That doesn't follow at all.  You only get into trouble if the
intersection of the requirements of the various CAs is null.

In the example you quoted, all that's needed is that the private key
has to be in a rated module, since one of the CAs requires that.  So
long as the other CA doesn't have a policy *forbidding* the use of a
rated module, you're all set.

---
It seems to me that, given that many people view certificates as
things that describe authority (roles) and not identity, you're going
to have a pile of them.  And if you do, there are good reasons to want
to minimize the number of private keys.

To apply one of the standard analogies again: while I have one
identity, I have a lot of different authorizations (roles), and lots
of different pieces of plastic and paper attesting to these.  But my
signature on all of them is the same scribble.

Using certificates to describe authorization means of course that I
won't just check whether there exists a certificate that validates a
signature -- I'd also check that the certificate is one that grants
the kind of authorization I'm interested in.  For example, to
validate, say, a dialup access attempt, I might look for a certificate
issued by my company.

        paul

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 6 Mar 1998 15:20: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

I have permission from the author to post the following private message:

> From: "Balluffi, Frank" <[email-masked]>
>
> David,
>
> It seems to me that this whole multiple certificates per public key
> dicussion is moving in the direction of technology for technology's
> sake.

Funny, that's what I think about proposals to have multiple certificates
with a single key :-).  Existing technology (Netscape or MSIE pointed
at VeriSign) results in a new key for every cert requested, except in
the case of cross-certification, as pointed out previously.  You
have to go out of your way to make up cert requests with a shared
key.

> What is the foundation or context for this discussion: WHAT ATTACKS ARE
> WE CONCERNED ABOUT?

Key compromise.

If some other person gets a copy of my private key, that is a key compromise.
If I have a keypair certified for one purpose, and I take that private key
and request that it be certified for a different purpose, that is a key
compromise from one of my schizophrenic personalities to another :-).

More realistically, if one CA's Certification Practices Statement says
that subscribers will be required to keep their private keys in a
FIPS-140 rated module, and another CA allows subscribers to keep them
in unencrypted hard disk files, then if I happen to request certification
of two keys which happen to have the same bit pattern from the two CAs,
one of the CA's policies may have been violated.

That is an extreme example, but it applies anytime there are differences
in the purposes for which a certificate is issued. To be less extreme,
say the FPKI profile says that certs shall not contain keyUsage bits
set which allow both signature and encryption.  If the same key is certified
twice, once for each purpose, then both certs are compliant with the
policy but the end result is not.

It is impossible to analyze the interactions of all possible combinations
of certification practices and certificate attributes to determine whether
any two pairs result in unintended consequences.  Therefore, the safe
thing to do is to not multiply-certify a single key unless you have
analyzed and understand the results.

> For the life of me, I am unable to identify any attacks that result from
> replacing certificates other than denial of service.
>
> For example, suppose I sign and send a message and someone replaces my
> certificate with one they dynamically generate that contains "do not
> trust this certificate", the recipient will surely not trust my message.
> I, the sender, will still be able to resend my original message via
> other means.
>
> No one has identified an attack that warrants changing the existing
> standard to not allow multiple certificates per public key (which is
> most probably not enforcable anyway).
>
> Unless someone can identify an attack that warrants changing the
> standard, the standard should not be changed.

I don't think anyone has proposed modifying any standard to prohibit
multiple certification.  We're just pointing out security considerations
that should lead to the Generally Accepted Practice of not doing it.

Approved-By:  "Pawluk, Jean" <[email-masked]>
Date:         Fri, 6 Mar 1998 14:07:32 -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: "Pawluk, Jean" <[email-masked]>
Subject:      [IETF-PKIX] Recall: [IETF-PKIX] Deletes 3/6
To: [email-masked]

Pawluk, Jean would like to recall the message, "[IETF-PKIX] Deletes
3/6".

Approved-By:  "Pawluk, Jean" <[email-masked]>
Date:         Fri, 6 Mar 1998 12:02:33 -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: "Pawluk, Jean" <[email-masked]>
Subject:      [IETF-PKIX] Deletes 3/6
To: [email-masked]

delete IETF-PKIX [email-masked]
delete IETF-PKIX [email-masked]
delete IETF-PKIX [email-masked]
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  FNS/FNS054A1/tanakamnb IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX

Approved-By:  Stephen Kent <[email-masked]>
Date:         Fri, 6 Mar 1998 12:07:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Dan,

>Let's get this straight -- the key is the identity,
>your name is a handle.  If liberty means anything, you
>can call yourself what you want hence identity-to-handle
>mapping will be many to many.  The tradeoff is your
>complexity eval of managing O(10**2) keys versus your
>exposure eval of published cross correlation of the key
>sharing amongst certs.

Wrong mailing list.  What you said above is the SPKI notion, but it's not
the PKIX notion, of the semantics of the subject name field in a
certificate.

Steve

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 5 Mar 1998 22:50:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      [IETF-PKIX] Cryptographic binding of certificates to signatures
To: [email-masked]

(My apologies if a copy of this message with a different
subject is received. Our e-mail, and apparently that of
some other people, has been acting very strangely recently.
I don't know what is going on, but some incoming
messages are showing up a week late, and some
messages on other lists apparently aren't getting through at all.)

David,

If we were able to somehow add cryptographic binding of
the digital signature to the specific certificate that is s
supposed to be used to validate it, virtually all of my objections
to issuing more than one certificate per key would disappear,
and we would be left with some of the positive virtues of that
approach that others have mentioned.

However, I do NOT think that we should insist that each and
every protocol reinvent the wheel. Some will do it wrong (as per
your examples), and some just won't do it at all.

Unfortunately, the SIGNED macro doesn't include a version
indicator (will we _never_ learn?), so we can't do the version 3
trick that we pulled when we found that the X.509 certificate
wasn't adequate for our new extended purpose.

However, I think there is a way out, although from a purist
architectural standpoint it is an ugly hack. But hey, MISSI did
it, and what's good enough for the US Government ought to be
good enough for the rest of us, right?

What I'm proposing is that we define a new series of digital signature
algorithm OIDs, which would include the additional information that
is needed as part of the COMPONENTS.

We can debate the precise information that we might like to include later,
along with the optimum syntax, but this is the approach that as I
recall MISSI took to include clearance information and other parameters
that they had no place to put in the old V1 certificate format. Like I said,
an ugly, but noble hack.

One potential problem is that although currently in-vogue RSA and
DSA key lengths (1024 and 2048 bits) would probably be long enough
to directly include most of what we might like, the 512 bit lengths allowed
by US export (and some import) regulations might be pretty tight, and
would be extremely tight for elliptic curves.

One approach to solving this problem would be to use two message digests,
one for the ToBeSigned, and the other for the ancillary signature data (someone
has to think of a snappy attribute name ¯ I refuse to be blamed for "ancillarySignatureData"), and then include both message digests
within the signature.  This would work for algorithms of up to 320 bits
in length, which might still be tight for some elliptic curve algorithms.

The other approach, which could be extended to arbitrarily long
information, would be to effectively append the existing ToBeSigned
information (normally a message digest) to the ancillary information, and
then compute a super message digest over the entire collection. That
super message digest, plus any additional randomized padding (we
ought to fix that problem while we are at it) would then be the input
to the actual signing operation. This would support signature algorithms
and key lengths which only allow as little as 160 bits of input (or even
128 bits, for MD5)).

The second approach is obviously superior to the first, assuming
that the time for a second hash is considered negligible. But can
anyone think of an even better method?

The benefit of this scheme is that by simply implementing one
or more new enhanced signature algorithms (e.g., "RSA with
SHA-1 and ancillary data") within the underlying toolkits,
virtually all applications would benefit, with virtually no effort at all.

And if we do it right, we might even be able to achieve some degree of
backward compatibility by some sort of slight of hand involving
mapping the algorithm OIDs to existing algorithms
in such a way as to ignore the added information if the code doesn't yet
support it. Maybe some ASN.1 genius can think of a slick trick.

Let me let this sink in before I start talking about all of the stuff I
would like to see included. Hopefully this time we would do it right,
probably by defining the information to be included in ASN.1 with
strong typing, so that we additional information is proposed to be
added it will be simple to do. But that is tomorrow's homework
assignment.

At a minimum, however, it would have to include some form of
unique identification of the certificate to be used to validate the
signature, either issuerName and serial, authorityKeyId, or at
the very least a hash of the certificate contents (although that
wold cause some problems of circular definition if used within
the certificate itself.)  Certainly a URL or some other kind of hint
as to where to actually find the certificate would be a nice touch,
but we can discuss that independently of the primary issue.

Whaddaya think about the basic concept?

Bob

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

--------

>>> "David P. Kemp" <[email-masked]> 3/5/98 13:03:16 >>>
> From: Bob Jueneman <[email-masked]>
>
> The problem, to the extent that there is one, is that the X.509
> definition of the "sign" macro does not provide any means of defining
> precisely which certificate in particular should be used to validate a
> particular signature, and thereby associate a particular set of
> name/rights attributes with that signature.
>
> (That's what often happens when a standard that was intended for one
> purpose is appropriated for another, entirely different purpose. We,
> the digital signature community, probably should have rethought that
> particular issue before adopting the X.509 definition of signature.
> Some other information, such as the date/time and signing and the
> identity of the platform ("location") on which the signature took place
> would have been handy, also.)

Bob,

The X.509 "SIGNED" macro might not have been designed with the intent
of supporting this purpose, and so may be excused for not including
a method of binding a certificate to the signed data.

However, the IETF CMS specification (aka PKCS#7) was designed for
precisely this purpose (providing non-repudiation grade signatures over
generic content), yet it still does not provide a clean method of
binding the signer's certificate to the content.

The CMS definition of SignedData includes {content, certs, crls,
signerInfos}, and some other fields.  There may be multiple signatures
applied to the content, each represented by a SignerInfo.  Each
SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
Because the issuerAndSerialNumber field, which uniquely identifies the
certificate used by the signer, is not covered by the signature, it is
not bound to the content.  I'm not sure why PKCS#7 was designed that
way, but it was, and so is CMS.

It would have been preferable to define an issuerAndSerialNumber
attribute, which could have been included either in
authenticateAttributes to bind it with the signature, or in
unauthenticatedAttributes if the current semantics of not binding the
signer's cert to the signed content is desired.

Perhaps defining a redundant copy of issuerAndSerialNumber, to be
included in authenticatedAttributes, could address the requirement
without breaking backward compatibility.  (It only covers the signer's
cert, not the full path, but it's a start.)
The uglier alternative is  is to double-sign everything, encapsulating a
signedData within another signedData for each parallel signature.

Since CMS is intended to be a generic security encapsulation mechanism,
not just an S/MIME-specific structure, those who feel that this
requirement is important (to address either multiple certification of
keys or proof-of-possession) should discuss it in the S/MIME working
group.  (A SigningTime attribute is already defined in CMS, but a
"location" attribute is not.)

Dave Kemp

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 5 Mar 1998 22:16:12 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

David,

If we were able to somehow add cryptographic binding of
the digital signature to the specific certificate that is s
supposed to be used to validate it, virtually all of my objections
to issuing more than one certificate per key would disappear,
and we would be left with some of the positive virtues of that
approach that others have mentioned.

However, I do NOT think that we should insist that each and
every protocol reinvent the wheel. Some will do it wrong (as per
your examples), and some just won't do it at all.

Unfortunately, the SIGNED macro doesn't include a version
indicator (will we _never_ learn?), so we can't do the version 3
trick that we pulled when we found that the X.509 certificate
wasn't adequate for our new extended purpose.

However, I think there is a way out, although from a purist
architectural standpoint it is an ugly hack. But hey, MISSI did
it, and what's good enough for the US Government ought to be
good enough for the rest of us, right?

What I'm proposing is that we define a new series of digital signature
algorithm OIDs, which would include the additional information that
is needed as part of the COMPONENTS.

We can debate the precise information that we might like to include later,
along with the optimum syntax, but this is the approach that as I
recall MISSI took to include clearance information and other parameters
that they had no place to put in the old V1 certificate format. Like I said,
an ugly, but noble hack.

One potential problem is that although currently in-vogue RSA and
DSA key lengths (1024 and 2048 bits) would probably be long enough
to directly include most of what we might like, the 512 bit lengths allowed
by US export (and some import) regulations might be pretty tight, and
would be extremely tight for elliptic curves.

One approach to solving this problem would be to use two message digests,
one for the ToBeSigned, and the other for the ancillary signature data (someone
has to think of a snappy attribute name ¯ I refuse to be blamed for "ancillarySignatureData"), and then include both message digests
within the signature.  This would work for algorithms of up to 320 bits
in length, which might still be tight for some elliptic curve algorithms.

The other approach, which could be extended to arbitrarily long
information, would be to effectively append the existing ToBeSigned
information (normally a message digest) to the ancillary information, and
then compute a super message digest over the entire collection. That
super message digest, plus any additional randomized padding (we
ought to fix that problem while we are at it) would then be the input
to the actual signing operation. This would support signature algorithms
and key lengths which only allow as little as 160 bits of input (or even
128 bits, for MD5)).

The second approach is obviously superior to the first, assuming
that the time for a second hash is considered negligible. But can
anyone think of an even better method?

The benefit of this scheme is that by simply implementing one
or more new enhanced signature algorithms (e.g., "RSA with
SHA-1 and ancillary data") within the underlying toolkits,
virtually all applications would benefit, with virtually no effort at all.

And if we do it right, we might even be able to achieve some degree of
backward compatibility by some sort of slight of hand involving
mapping the algorithm OIDs to existing algorithms
in such a way as to ignore the added information if the code doesn't yet
support it. Maybe some ASN.1 genius can think of a slick trick.

Let me let this sink in before I start talking about all of the stuff I
would like to see included. Hopefully this time we would do it right,
probably by defining the information to be included in ASN.1 with
strong typing, so that we additional information is proposed to be
added it will be simple to do. But that is tomorrow's homework
assignment.

At a minimum, however, it would have to include some form of
unique identification of the certificate to be used to validate the
signature, either issuerName and serial, authorityKeyId, or at
the very least a hash of the certificate contents (although that
wold cause some problems of circular definition if used within
the certificate itself.)  Certainly a URL or some other kind of hint
as to where to actually find the certificate would be a nice touch,
but we can discuss that independently of the primary issue.

Whaddaya think about the basic concept?

Bob

----

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

>>> "David P. Kemp" <[email-masked]> 3/5/98 13:03:16 >>>
> From: Bob Jueneman <[email-masked]>
>
> The problem, to the extent that there is one, is that the X.509
> definition of the "sign" macro does not provide any means of defining
> precisely which certificate in particular should be used to validate a
> particular signature, and thereby associate a particular set of
> name/rights attributes with that signature.
>
> (That's what often happens when a standard that was intended for one
> purpose is appropriated for another, entirely different purpose. We,
> the digital signature community, probably should have rethought that
> particular issue before adopting the X.509 definition of signature.
> Some other information, such as the date/time and signing and the
> identity of the platform ("location") on which the signature took place
> would have been handy, also.)

Bob,

The X.509 "SIGNED" macro might not have been designed with the intent
of supporting this purpose, and so may be excused for not including
a method of binding a certificate to the signed data.

However, the IETF CMS specification (aka PKCS#7) was designed for
precisely this purpose (providing non-repudiation grade signatures over
generic content), yet it still does not provide a clean method of
binding the signer's certificate to the content.

The CMS definition of SignedData includes {content, certs, crls,
signerInfos}, and some other fields.  There may be multiple signatures
applied to the content, each represented by a SignerInfo.  Each
SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
Because the issuerAndSerialNumber field, which uniquely identifies the
certificate used by the signer, is not covered by the signature, it is
not bound to the content.  I'm not sure why PKCS#7 was designed that
way, but it was, and so is CMS.

It would have been preferable to define an issuerAndSerialNumber
attribute, which could have been included either in
authenticateAttributes to bind it with the signature, or in
unauthenticatedAttributes if the current semantics of not binding the
signer's cert to the signed content is desired.

Perhaps defining a redundant copy of issuerAndSerialNumber, to be
included in authenticatedAttributes, could address the requirement
without breaking backward compatibility.  (It only covers the signer's
cert, not the full path, but it's a start.)
The uglier alternative is  is to double-sign everything, encapsulating a
signedData within another signedData for each parallel signature.

Since CMS is intended to be a generic security encapsulation mechanism,
not just an S/MIME-specific structure, those who feel that this
requirement is important (to address either multiple certification of
keys or proof-of-possession) should discuss it in the S/MIME working
group.  (A SigningTime attribute is already defined in CMS, but a
"location" attribute is not.)

Dave Kemp

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 5 Mar 1998 16:31:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> From: Bill Burr <[email-masked]>
>
> I can leave my certificates stored on a directory somewhere and access them
> over the net when I want them.  I can have my file of certificates on the
> disk of my machine at work, on my machine at home, on my laptop, carry it
> around on a floppy disk, paste them on the wall, put them on my web site,
> and so on. I can have 100 copies and leave them anywhere I want.
>
> But, the key or keys I must protect.  I may want to carry them around on a
> chip card in my wallet.  It may be more important to use that silicon to do
> digital signatures and key agreement on the chip, so that the private key
> never leaves the chip, than to store a large number of certificates and
> separate keys.

Certainly certificates don't need to be carried in protected storage,
and keys do.  But the question is: does your token carry one private
key, period, or one private key per role.

The number of roles you want to manage is probably limited by
ergonomics; if all your certs are stored on floppies or directories, or
web servers, you still have to pick the cert to use for a particular
transaction.  I have trouble leafing through the 20 cards in my wallet
(drivers lic, MasterCard, AMEX, library, Red Cross, health insurance,
warehouse club memberships, etc).  In an electronic transaction,
selecting from 20 or 50 bookmarked URLs, desktop icons, address-book
entries, etc. to pull the cert to use may be practical; selecting from
1000 certs probably is not.

So if a token has the storage capacity for 20 or 50 or 100 private keys,
it probably meets the needs and organizational capabilities of most
human users.  100 private keys (12.8 KBytes) is not an outrageous number
to expect a token to support.  How much cheaper is a 128 byte token than
a 16 KB token?

And if you have application software that can handle pulling public
certificates from a directory/web server/floppy while pulling private
keys from a token, then it is unrealistic to expect that the software
would not be capable of correlating private keys with certs. Managing
100 certs with 100 keys is no more difficult for the user than managing
100 certs with 1 key.

> I don't accept that the pin on my token is analogous to a handwritten
> signature.  The AMEX card is analogous to the certificate, and my selecting
> a particular certificate for use in a protocol, is apanages to picking my
> AMEX rather than my VISA.  But, when I sign my transaction slip, I don't
> sign differently for Amex than for Visa.  It's the same signature.

The actions that the user must perform are analogous: open your wallet,
pick a card, sign a transaction slip.  Unlock your token with a PIN,
pick a personality (cert), click on the Go button.  The user authentication
happens at step 3 in the physical process and step 1 in the electronic
process, but so what?  (If you really want to emulate the physical
world, the app could wait until step 3 before asking for the PIN or
database password).

Why are you concerned whether the signature computed as a result of
clicking the Go button comes from the same private key or different
private keys for different certs?  Even if you always use the same
private key, the signature will be totally different every time if
you're using DSS.  And even if you use the same private key and a
deterministic signature algorithm (RSA), every signature will be
different if the content being signed is different.  It's not the same
signature, regardless of whether you have 1 private key or 100.

That's the danger of reasoning by analogy - you can't look too deep
or things fall apart.

Regards,
Dave Kemp

Approved-By: [email-masked]
Date:         Thu, 5 Mar 1998 10:27: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: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

At 03:20 PM 3/4/98 -0700, you wrote:
>Bill, I've already done my mea culpa's for the "signed by a certificate"
>imprecise usage. Rather than reiterate the argument yet again, I
>would be interested in your reaction to my recent reply to
>Tony Bartoletti.
>
>Havin' fun stirring up the hornets,
>
>Bob
>
>
>>>> Bill Burr <[email-masked]> 03/04 2:27 PM >>>
>Bob,
>
>But do we sign with a certificate, or with a key?  I don't think that key
>and certificate are synonymous.  If the context of the certificate matters
>to the signature, then I should include the certificate in the signed
>message.
> [snip]
>
>

Bob,

Sorry that I hadn't read your response to Tony.  The moderation of this
list seems to induce some delay in the loop.

I think that you may be right to suggest that a signature should be
cryptographically bound to a particular certificate.  But I don't see how a
one certificate per key rule does that, because there isn't any strong way
to enforce that rule.

It seems to me that, if it's important when I sign a message, that I'm
signing as Bill Burr, of NIST, as opposed to Bill Burr, a member of the
garden club, that my message had probably better make that clear, possibly
by including the certificate in the signed part of the message.

If I don't do that, and I have many certificates for a key, then I probably
must accept that a relying party can reasonably choose any of those
certificates, with whatever consequences that brings.

Moreover NIST might well choose to insist that I not use a key it
certified, in any other certificate.

The most serious problem that multiple certificates per key brings, it
seems to me, is revocation, for the particular case of key compromise.
But, at the moment, I'm not sure that today we have an accepted general
answer to revocation.  I think that one model, which would more or less
work today, is for a CA to issue certificates with short validity periods
(hours or a few days), and dispense entirely with CRLs, OCSP, etc.  The CA
could, for example, sign a new certificate every day, with, say, a two day
validity period.  If I, or a relying party need my cert. today, we go get
it from the repository, perhaps for a small charge. I think that this means
more than one certificate per key.

This doesn't solve the key compromise problem, if I have a lot of different
certificates for that key, but it may be a reasonable way to avoid the
problems of CRLs or on-line status protocols, with their baggage.

I'm just reluctant to embrace the one key, one certificate principle, until
we have a little more experience with what actually works.
Regards,

Bill Burr

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 5 Mar 1998 15:03: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> From: Bob Jueneman <[email-masked]>
>
> The problem, to the extent that there is one, is that the X.509
> definition of the "sign" macro does not provide any means of defining
> precisely which certificate in particular should be used to validate a
> particular signature, and thereby associate a particular set of
> name/rights attributes with that signature.
>
> (That's what often happens when a standard that was intended for one
> purpose is appropriated for another, entirely different purpose. We,
> the digital signature community, probably should have rethought that
> particular issue before adopting the X.509 definition of signature.
> Some other information, such as the date/time and signing and the
> identity of the platform ("location") on which the signature took place
> would have been handy, also.)

Bob,

The X.509 "SIGNED" macro might not have been designed with the intent
of supporting this purpose, and so may be excused for not including
a method of binding a certificate to the signed data.

However, the IETF CMS specification (aka PKCS#7) was designed for
precisely this purpose (providing non-repudiation grade signatures over
generic content), yet it still does not provide a clean method of
binding the signer's certificate to the content.

The CMS definition of SignedData includes {content, certs, crls,
signerInfos}, and some other fields.  There may be multiple signatures
applied to the content, each represented by a SignerInfo.  Each
SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
Because the issuerAndSerialNumber field, which uniquely identifies the
certificate used by the signer, is not covered by the signature, it is
not bound to the content.  I'm not sure why PKCS#7 was designed that
way, but it was, and so is CMS.

It would have been preferable to define an issuerAndSerialNumber
attribute, which could have been included either in
authenticateAttributes to bind it with the signature, or in
unauthenticatedAttributes if the current semantics of not binding the
signer's cert to the signed content is desired.

Perhaps defining a redundant copy of issuerAndSerialNumber, to be
included in authenticatedAttributes, could address the requirement
without breaking backward compatibility.  (It only covers the signer's
cert, not the full path, but it's a start.)
The uglier alternative is  is to double-sign everything, encapsulating a
signedData within another signedData for each parallel signature.

Since CMS is intended to be a generic security encapsulation mechanism,
not just an S/MIME-specific structure, those who feel that this
requirement is important (to address either multiple certification of
keys or proof-of-possession) should discuss it in the S/MIME working
group.  (A SigningTime attribute is already defined in CMS, but a
"location" attribute is not.)

Dave Kemp

Approved-By: [email-masked]
Date:         Thu, 5 Mar 1998 09:59: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: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

At 04:45 PM 3/4/98 -0500, you wrote:
>> From: Bill Burr <[email-masked]>
>>
>> If I have 50 or 100 certificates, each with some particular attributes
>> bound with my keys, one for the auto club, one for the New York Times
>> on-line, one for every pay site I subscribe to, etc., and I want to carry
>> them around on my token and use them at home and at work, etc., maybe I've
>> got a problem.
>>
>> Is does seem to me to simplify my life to use one key to sign everything;
>> after all, I don't sign my name differently when I use my AMEX card than
>> when I use my Visa.   This makes sense if we separate attributes from
>> identity and use X9 style attribute certificates, that don't contain a key.
>>  I'm far from convinced that such attribute certificates are practical.
>
>I believe the analogy is flawed.  When you use your AMEX card, the
>information extracted from the magstripe is different than the
>information on your Visa magstripe.  You use the same handwritten
>signature to authorize both cards, just as you use the same PIN to
>activate your token.
>
>I always cringe when people use the word "certificate" to mean both a
>public key certificate and the associated private data, but from an
>ergonomic point of view, there isn't much difference.  When you select
>an X.509 certificate in your web browser to sign a message, the browser
>automatically uses the private key associated with that certificate.
>If you have 50 or 100 certificates to choose from, you have to choose
>once, but you don't have to choose again to get the proper private key;
>that part is automatic.
>
>And if a token can store n certificates of 1K-2K bytes each, adding an
>additional 128-256 bytes of private key for each certificate doesn't
>significantly change the number of certs that can be carried on
>the token.
>
>Dave Kemp
>
>

I can leave my certificates stored on a directory somewhere and access them
over the net when I want them.  I can have my file of certificates on the
disk of my machine at work, on my machine at home, on my laptop, carry it
around on a floppy disk, paste them on the wall, put them on my web site,
and so on. I can have 100 copies and leave them anywhere I want.

But, the key or keys I must protect.  I may want to carry them around on a
chip card in my wallet.  It may be more important to use that silicon to do
digital signatures and key agreement on the chip, so that the private key
never leaves the chip, than to store a large number of certificates and
separate keys.

I don't accept that the pin on my token is analogous to a handwritten
signature.  The AMEX card is analogous to the certificate, and my selecting
a particular certificate for use in a protocol, is apanages to picking my
AMEX rather than my VISA.  But, when I sign my transaction slip, I don't
sign differently for Amex than for Visa.  It's the same signature.

There may be, as bob Juneman suggests, a flaw in the definition of a
signature, which perhaps should be cryptographically bound to a particular
certificate.  But trying to do that by making an unenforceable rule of a
different key per certificate seems to me the wrong way to fix the problem.
Regards,

Bill Burr

Approved-By: [email-masked]
Date:         Thu, 5 Mar 1998 18:32:24 +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: Mark Shuttleworth <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> Let's get this straight -- the key is the identity,
> your name is a handle.  If liberty means anything, you
> can call yourself what you want hence identity-to-handle
> mapping will be many to many.  The tradeoff is your
> complexity eval of managing O(10**2) keys versus your
> exposure eval of published cross correlation of the key
> sharing amongst certs.

Gotta disagree.  The name is your identity (and potentially your
authority).  The key is merely a way to tie an action (signature) to that
identity.  The problem is tht one-key-many-certs can mean that an action
is tied to multiple identities.  It's not a huge problem.

--
Mark Shuttleworth
Thawte Consulting

Approved-By: [email-masked]
Date:         Thu, 5 Mar 1998 11:01:32 +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: Mark Shuttleworth <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> The problem, to the extent that there is one, is that the X.509 definition of the
> "sign" macro does not provide any means of defining precisely which
> certificate in particular should be used to validate a particular signature,
> and thereby associate a particular set of name/rights attributes with that
> signature.

Fortunately, the authorityKeyIdentifier extension let's us do just that ;)

--
Mark Shuttleworth
Thawte Consulting

Approved-By: [email-masked]
Date:         Thu, 5 Mar 1998 11:04: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: [email-masked]
Subject:      [IETF-PKIX] OCSP draft 2
To: [email-masked]

another area that i'm really interested in is the possibility of extending
ocsp into online digital signature status ... (in contrast to
online certificate status). This relates to account authority
digital signature model ... where the relying party on the digital
signature isn't the account authority ... but still needs indication
regarding the validity of the digital signature.

in aads, certificates were removed from financial transactions ... in part
to provide end-to-end digital signature integrity for financial
transactions that had to transit legacy financial networks.  It turned
out that the removal of certificates from the operation also eliminated
systemic risks to the financial infrastructure (that are associated
with common CA infrastructures).

The embodiment of aads is in ANSI X9.59 electronic retail payment
protocol ... which has also been presented as electronic payment
convergenece (also has an acronym GUPI ... grand unified payment
initiative) ... and is targeted for international ISO fast-tracking.

The opportunity in AADS is to leverage a likely robust and pervasive
digital signature infrastructure for operations other than end-to-end,
high integrity financial transactions.

The no-brainer is for an AADS to also issue certificates. However,
the certificates and the account authority financial transactions then
operate at almost the opposite ends of the high-integrity spectrum.
The opportunity is to then to provide higher-integrity PKI that
is closer to the financial transaction end of the spectrum ... but
doesn't happen to be real financial transactions.

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Thu, 5 Mar 1998 10:17:28 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: "Charles W. Gardiner" <[email-masked]>
To: [email-masked]

At 10:16 AM 3/5/98 -0500, Charles W. Gardiner wrote:
>    Surely the document you signed as Purchasing Manager of BigCorp contained
>the name of BigCorp and your title.  The relying party should, therefore,
have
>looked up that certificate, not your chess club certificate.  You probably
>sent the classy cert. when you first placed a purchase order with XYX Corp.
>That's much the way the world works pre-digitally.  Digital signatures
will very
>likely follow in the same groove, well established by custom.
>
>Charlie Gardiner

I would hope so.  However, the comments in this thread imply otherwise.
You assume, I believe, that a human will be in the loop to read the purchase
order, and use this information to look up a certificate manually.  Perhaps
my purchase order example was not the best.  Please consider the comments of
Bob Jueneman, which I include (indented) below:

  The problem, to the extent that there is one, is that the X.509 definition
  of the "sign" macro does not provide any means of defining precisely which
  certificate in particular should be used to validate a particular signature,
  and thereby associate a particular set of name/rights attributes with that
  signature.

  (That's what often happens when a standard that was intended for one
purpose
  is appropriated for another, entirely different purpose. We, the digital
  signature community, probably should have rethought that particular issue
  before adopting the X.509 definition of signature. Some other information,
  such as the date/time and signing and the identity of the platform
  ("location") on which the signature took place would have been handy, also.)

  But that's water over the dam by now, and so all of the various
applications
  which might ever want to use a digital signature have to solve the problem
  themselves.

  Unfortunately, several of those applications further compounded the original
  error by not incorporating an unambiguous reference to the certificate
which
  is to be used to validate the signature within the signed document itself,
  but rather appended the reference to the certificate, or the certificate
  itself, to the document in an insecure manner. One way around that problem
  would be to recite the contents of the certificate itself, but that is both
  awkward, and not likely to be easily machine processable, since no
particular
  convention has been established for such a process.

  Since the certificate reference is not securely bound to the document in
  question, another certificate could easily be substituted. If it were not
for
  the private key proof-of-possession requirement, this would even allow some
  other person to claim authorship of the document, which might be quite
useful
  in some circumstances.  And it certainly allows an individual who possesses
  the key but is wearing different hats (roles) to play some games if it would
  be to his advantage.

(Thanks again Bob, for the explanation.)  Although I read most of the postings
to the PKI mailing lists, I find there is rarely a presentation, high
level, of
what each automated protocol needs or expects in order to perform its
function.
Not long ago, there was debate about whether the relying party was responsible
for gathering the chain of certs to validate a transaction, ot whether it was
the duty of the supplicant (transaction submitter) to supply these, or at
least
their links, to the relying party.

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Dan Geer <[email-masked]>
Date:         Thu, 5 Mar 1998 11:07:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dan Geer <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Let's get this straight -- the key is the identity,
your name is a handle.  If liberty means anything, you
can call yourself what you want hence identity-to-handle
mapping will be many to many.  The tradeoff is your
complexity eval of managing O(10**2) keys versus your
exposure eval of published cross correlation of the key
sharing amongst certs.

--dan

Approved-By:  "Charles W. Gardiner" <[email-masked]>
Date:         Thu, 5 Mar 1998 10:16: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: "Charles W. Gardiner" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

    Surely the document you signed as Purchasing Manager of BigCorp contained
the name of BigCorp and your title.  The relying party should, therefore, have
looked up that certificate, not your chess club certificate.  You probably
sent the classy cert. when you first placed a purchase order with XYX Corp.
That's much the way the world works pre-digitally.  Digital signatures will very
likely follow in the same groove, well established by custom.

Charlie Gardiner

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 3 Mar 1998 19:54:59 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]

Peter,

PKIX Part 1 identifies one means of identifying the validation point using
the AuthorityInfoAccess extension.  Beyond that I would expect it to be a
matter of local configuration similar to identifying one's nameserver.

Mike

-----Original Message-----
From: Peter Sylvester <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, March 03, 1998 11:14 AM
Subject: Re: [IETF-PKIX] OCSP Current Status

>I am not whether the following has been discussed or not for OCSP:
>
>Question: Is the protocol just intended to specify the communication
between
>a client and the well-known validation point, or is there something
>to about how to find that point.
>
>I image a possible response from the server saying, no, don't do this
>here, go elsewhere, here's the 'connection info' (URL or whatever).
>
>Peter Sylvester
>EdelWeb
>

Approved-By:  Michael Myers <[email-masked]>
Date:         Wed, 4 Mar 1998 05:33:32 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP draft 2
To: [email-masked]

Marc,

A very thorough review and much appreciated.

Mike

-----Original Message-----
From: Marc Branchaud <[email-masked]>
>
>(1) There's very little "online" about this protocol.  It's basically a
>mechanism for server-based CRL processing, with specific reference to the
>validation logic in PKIX1.
>
>There's nothing wrong with that.  It allows for thin clients that don't
have
>to bother with CRLs, which I think is great.  But because of this I don't
>think that words such as "timely" belong in the draft, because there's
>nothing that ensures the timeliness of a response any more than if CRLs
were
>used directly.  Indeed, calling it "OCSP" at all goes against my (probably
>skewed) pre-conceived notions of what an online status protocol should do,
>which is get status information as straight from the CA's mouth as
possible.

I'm having trouble understanding this line of reasoning.  OCSP exists
specifically to address timelineness issues.  True, the specification
enables one to take advantage of caching, but it doesn't mandate that you do
so.  If you have customers who need a real-time production of a
certificate's status, this is what OCSP is for.  I know I do.  One the other
hand, that same mechanism can be relaxed for CA key pairs that represent
customers with less stringent timeliness needs.

>The current proposal does no such thing.  In fact it's "caching" mechanism
>isn't really about a cache of responses from other OCSP servers or CAs, but
>is instead a way to preserve the results of certificate chain processing
>(incurred when the certificate's status is first determined).  For these
>reasons I propose that the draft be renamed "Server Based CRL Processing"
or
>some such thing.  On the other hand, Carlisle's right that there's nothing
>here that can't be done within the Notary Protocol draft.

As I said, the specification does not require one to implement caching.  You
can certainly take advantage of it if meets the needs of your customers or
market.  One way I've heard proposed is to acquire a certificate's status
through an LDAP directory.

I'm beginning to wonder though if the value-added variations of the proposed
Notary Protocol may have less to do with PKI (or PKIX) than with other fora
where such contexts are well defined.  Where, for example, is the boundary
between PKI and electronic rights management?  A bank's management of its
customer's accounts?  The validity of an electronic stock trade request?
The up-to-the minute validity of pre-established IPSEC Security
Associations?  How does the notary protocol help me revoke a signed object
distributed throughout an enterprise?

I first need a simple, workable, imlementable, deployable alternative to
CRLs.  This is OCSP.

>
>(2) There's been some call for the protocol to use ASN.1.  I agree with
those
>comments, and I would even attempt to propose some actual ASN.1 to get
things
>started were it not for some confusion I have about various parts of the
>draft (I'll get to those below).

I believe we've fairly well resolved this issue.  ASN.1 for ASN.1's sake is
an endless debate.

>
>(3) Let me restate my opinion that this protocol should not be tied to
HTTP.
>Although HTTP, particularly 1.1, may be well suited for the protocol, it
also
>makes sense to allow it to be implemented using CMP or SMTP or whatever
other
>P people might fancy.  Note, too, that the richness of HTTP 1.1's cache
>control is hardly needed with this protocol's notion of "caching" anyway.

Early readers of the OCSP drafts will recall that it was cast into a
transport-independant framework, which was subsequently judged to be
overkill for the scope of the problem.

If you or someone else wishes to produce an I-D that details transport of
OCSP request and response in, say, SMTP, then we would have the basis to
consider a multi-draft approach to the specification.  Until then, there
needs to be at least one transport to ensure interoperability among those
who choose to implement OCSP.

I would however debate the validity of the claim that CMP is a transport
mechanism in the same sense that HTTP, SMTP, FTP or LDAP are transports.

>
>(4) The draft says that definitive response messages SHALL be digitally
>signed.  This is good for providing some degree of non-repudiation, but I
>would suggest that signed responses be optional (or be "SHOULD" at most) to
>allow for SSL-authenticated connections when non-repudiation isn't a
>requirement.  Granted, for individual requests there isn't much benefit as
>the crypto would get done somewhere anyway, but a single SSL connection
could
>support several requests, which would make things a lot faster.

This is a good point that's been brought up earlier.  It would be useful to
detail out how SSL would be used in this context.  May I ask that you
provide some text that I could drop into the draft?

>
>(5) In the middle of page 6 there's mention of the "value '2' for the
>version field" but there is no definition of a "version" field.

I should have deleted that sentence in view of the simplification
of the top-level specification of a request which reads:

OCSP-request     =      url "/ocsp/ver/1/" target [extensions]

I would hope that the presence of "/ver/1" requires no further explanation.

>
>(6) On page 7 it says that the requester's signature is computed over { url
>request target extensions sig-fields } but "request" isn't defined
anywhere.

Good catch.  The syntactic definition of "request" was absorbed into the
definition of "OCSP-request".

Given the specification of:

OCSP-request     =      url "/ocsp/ver/1/" target [extensions]
[signature] [extensions]

The signature should be calculated over the first four elements.

>
>(7) Just below that, it says that the responder "verifies the signature,
>using the public key identified by key-id and the requester certificate
>extension defined below."  Shouldn't that "and" be an "or" since extensions
>are optional?

Yes.  I'll amend the text to reflect the optional inclusion of extensions in
this context.

>
>(8) Section 4.3 describes the cryptographic algorithm requirements of
>clients, but makes no mention of responders.

Yes, responders would be required to implement according to these
requirements as well.

>
>(9) The Requester Certificate extension (section 4.4.2) specifies the use
of
>MD5 for producing the reqid.  Shouldn't SHA1 be used here as it is
everywhere
>else?

Yes, this has been brought to my attention by others.  It should be SHA1
throughout.

>Also, a note in this section suggests that several certificates may
>need to be passed to the OCSP responder.  Wouldn't this be better served by
>POSTing them?  Taking that idea further, it seems to me that these extended
>request strings are getting awfully long and that the whole protocol would
be
>better served by using POST exclusively instead of GET.

>
>(10) The "/ocsp/ver/1/" defined in section 4.1 doesn't match the "/status/
>check/ver/1/" used in the examples from section 4.6.

Done.

>While we're on it,
>what's the advantage of using "/ver/1/" instead of "/ver1/" or just "/v1/"?

The latter point is intended to align the more general syntatic concept
of {name, value} so that in implementation the code structure would
be more uniform.

>
>(11) Finally, the distinction between minimal and definitive error
responses,
>and between error and definitive responses, is fairly muddled and needs to
be
>made more explicit earlier in the draft.

OK.

>
>
>To sum up, I think the basic idea behind this draft -- to offload CRL
>processing from client applications -- is good.  But I also think that the
>draft's title is misleading.  What's more, it could be specified as a
profile
>of the Notary protocol, but I don't mind it remaining a stand-alone
document.
>Either way, it needs substantial changes before going to last call.

Appreciate the review.  It will help in tightening it up and moving OCSP
forward.

As for the larger issue of just how far we can legitimately extend
PKIX protocols into what might arguably be considered non-PKI realms,
I'll leave that debate to the list.

>
>                Marc

Approved-By: [email-masked]
Date:         Wed, 4 Mar 1998 16:27:04 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

Bob,

But do we sign with a certificate, or with a key?  I don't think that key
and certificate are synonymous.  If the context of the certificate matters
to the signature, then I should include the certificate in the signed
message.

I would argue that a relying party needs to decide which one certificate it
is that he relying on, and check the status of that certificate before
relying on the signature.  Why do other certificates, whatever their key,
and whatever their status, matter?  And, if the Relying party is trying to
hold a CA or a signer responsible for damages, then why does he need to
worry about any other certificate than the one he relied upon?  If there
are other certificates for that key, and if some of them have been revoked,
why should it mater?

Of course, A CA might decide that it is prudent to contractually require
that a user not use a key that the CA certifies in other certificates.

I also hope that we're not creating some theory that says that I, as a
keyholder, can disclaim responsibility for my signature, because I used a
key it certified in a way that violated the CP under which a certificate
for that key was issued.

Has anyone observed in this discussion, that CAs themselves will probably
have dozens of certificates for the same key, if they cross-certify
broadly?  Surely someone must have.  Why is it OK for CAs but not
end-entities?

At 01:16 PM 3/4/98 -0700, you wrote:
>Hi, Blake,
>
>The original discussion included the more general question of issuing two
certificates containing the same key but including different attributes --
different DN, etc. Given the difficulty of distinguishing between two
certificates if they both contain the same key and therefore either could have
>been used to sign a document, I believe there may very well be subtle
legal issues that need to be considered, as I indicated.
>
>In addition to the risk management issue from the perspective of the
subscriber or the CA, there is also the question of the relying party's
risk with respect to CRLs, which is why I believe the subject needs to be
addressed within the CPS and perhaps the CA Accreditation Guidelines.
>
>But I probably play pretend-lawyer too much, so I'll defer to the real
experts.
>
>Bob
>
>>>> Blake Greenlee <[email-masked]> 03/04 12:14 PM >>>
>Dear Bob et al:
>
>To re-issue a public key in a new certificate or not is a risk management
issue, not a legal issue. Doing this shouldn't be any more constrained than
to point out that fact.
>
>It is probably not much more of a risk to re-issue a public key in a new
certificate than to send out new CA public keys in a message signed by the
old CA private key. (That is, given algorithms of appropriate key lengths).
>
>Blake
>
>
>
>-----Original Message-----
>From:  Bob Jueneman [SMTP:[email-masked]]
>Sent:  Wednesday, March 04, 1998 2:00 PM
>To:    [email-masked]
>Cc:    [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; Michael Baum;
[email-masked]
>Subject:       Fwd: Re: [IETF-PKIX] Multiple certificates for same key?
>
>There has been some discussion recently on the IETF-PKIX list
>regarding the wisdom of a CA reissuing a new certificate containing an old
public
>key -- in other words, issuing two certificates which contain the same key.
>
>I believe that this significantly complicates issues of certificate
revocation and
>nonrepudiation, and might have other legal consequences involving choice
of law issues
>and other considerations that are far from being immediately obvious.
>
>The subject arose originally in a discussion of the German digital
signature legislation.
>Although I haven't checked it, it might contain language that would
prohibit this
>practice -- I don't know.
>
>In any case, I think the issue is worth addressing from a legal and
legislative
>standpoint. In addition, as I said in the attached message to Steve Kent,
>I believe that the matter needs to be addressed in a CA's Certification
Practice
>Statement in order to provide a warning to a relying party, and it
probably ought
>to be addressed in the CA Accreditation Guidelines that are being
developed within
>the ABA Information Security Committee.
>
>Warwick Ford and Santosh Chokani, as the authors of the CPS Framework, and
the
>Federal PKI working group might also want to weigh in on this issue.
>
>I would be quite interested in any comments or feedback.
>
>Bob
>
>
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.
>Network Products Group
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>[email-masked]
>
>"If you are trying to get to the moon, climbing a tree,
>although a step in the right direction, will not prove
>to be very helpful."
>
>"The most dangerous strategy is to cross a chasm in two jumps."
>
> << Message: Re: [IETF-PKIX] Multiple certificates for same key? >>  <<
Message: Re: [IETF-PKIX] Multiple certificates for same key? >>
>
>
Regards,

Bill Burr

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 15:56:09 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Tony,

As you can imagine, I have had difficulty reading and responding to all
of the hornets at once, as well, so some of our mail has crossed.
I too hope the bandwidth expended has been worth it.

I think the point that I have been trying to make is that although
hashing the public key and saying "yes, SOME certificate exists and is valid
that matches that key" would establish the fact that the possessor of the
private key signed a document, there are inevitably, I argue, various
roles or other kinds of at least implied attributes that may have to be taken into
consideration, especially by the relying party.

The root problem is that the specific certificate which is intended to be used
to validate a digital signature is not crypotographically bound to the digitally
signed text, making it cryptographically ambiguous which certificate cum attributes
was intended to be validated.  In a sense, that is a fundamental flaw in the ASN.1
definition of a digital signature. It could be fixed, of course, and probably much
more easily repairing all of the various protocols that will ever use the Signed
macro, but I suspect that even though we are still at the dawn of this new era
and could fix it rather easily, we won't do that. "You can pay me now, or you
can pay me later." Sigh.

Anyway, thanks (blame?) to Stephan Kelm for raising this thread.
Every so often, we need to revisit our original assumptions and make sure
they are still valid.

Bob

>>> Tony Bartoletti <[email-masked]> 03/04 2:53 PM >>>
Bob,

Thanks for considering my comments.  I didn't see them until after sending
_yet_another_ diatribe on the issue.

While I am concerned about privacy issues, the real thrust of my exploration
was to ferret out, by way of implication, what cert-chain mechanisms folks
expect to exist.  The comments of some lead me to believe that an OSCP-type
responder could simply be submitted a public key (or its hash) and then it
would respond, boolean-wise, with "Yes, there IS a valid cert of some form for
that public key" or not.  That is, as if there would be no provision for the
(e.g., OCSP) user to specify a cert, or a set of attributes that must be
present to indicate the key is suitable for their purposes. Such a system
could only work if there were exactly one cert-per-key, so *the one* cert
(hence *the one* key) is either valid or not.

I hope all of this is of value to someone;)

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 15:39:57 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Paul, although I generally hate to respond point by point, I both
agree and disagree with you, so I guess I have to:>
>
>>>> Paul Koning <[email-masked]> 03/04 2:33 PM >>>
>I'll skip quoting previous messages because it's hard to tell anymore
>who said what....
>
>One analogy presented was that several certificates for the same key
>is similar to having several credit cards in your wallet.
>
>It occurs to me that some of what's going on in this discussion is the
>age-old problem of mixing up authentication with authorization.  As in
>"am I dealing with G. Paul Koning, that guy with the bushy beard,
>passport number foo...?" vs. "given that I believe I'm dealing with
>G. Paul Koning, is he entitled to charge $N to account number bar?"
>
>It seems pretty clear that a pile of certificates all attesting to the
>same key are certifying the same identity, i.e., authenticate the same
>entity.  But because they have different attributes, they may be
>driving different authorization decisions.

Quite correct.  If the identity is "you", you signed it, and "you" are liable.
But there is quite a difference between signing something in your
personal capacity vs. singing something as an authorized agent for
someone else, even though it is "you" who signed it in both cases.

Ask your corporate attorney what it means for your CEO to order
car and sign it "Bill Smith" vs. William A. Smith, President, XYZ Corp.
In the second case it is XYZ who is liable, not Bill personally.

>
>In other words, it looks like the question is: are certificates
>supposed to be authentication tools, or also authorization tools?

My point is that whether explicitly or implicitly, attributes other than the user's
common name imply, or at least tend to imply, some degree of authorization,
willy nilly.

>
>If only authentication tools, then that seems to leave only the case
>of recertifying an existing key as a meaningful scenario for multiple
>certificates.

And even that raises potential issues about CRLs.
>
>If also authentication tools, then clearly there can be many
>certificates since any individual is allowed to do many things, and
>those permissions are granted by many independent organizations.
>
>In the latter case, while it may be possible to have many different
>key pairs for those many authorizing certificates, I agree with Bill
>Burr that this is a bad idea.  The more bits of secret I have, the
>harder it is to protect those bits.

This is where I would take exactly the opposite view. if you cannot
tell which certificate is supposed to be used for what purpose, then
you don't know whether a particular authorization was valid or not.

(BTW, from an information theory standpoint, and particularly
from a covert channel analysis, the more bits of a secret
you have, the EASIER it is to protect it.  If you wrap up all of
your secretsin one short crypto key, it becomes extrarodinarily
difficult to protect it from a covert channel attack. but that's a
different issue. Of course covert channels, like Tempest attacks,
are not considered feasible, said the ostrich with his
head firmly in the sand.)

>
>Another point: if certificates are authorizing tools, you aren't
>actually going through the two step process of first authenticating
>then authorizing.  So it isn't functionally necessary to be able to
>prove that each of my authorizing certificates "belongs to" the same
>identity.  On the other hand, it seems to be very useful to be able to
>do this -- which is what you get by having them all tied to the same
>key.
>
>Finally, a thought that may not work... if there are many certificates
>sharing a key, it would make sense for revocation to revoke the key,
>not each certificate one by one.

Well, of course Carl Ellison and the SPKI crowd would agree with such
a key-centric view, but that would tend to further compound the problem of
blurring attributes associated with a particular key.
>
>        paul

Bob

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 4 Mar 1998 14:27:26 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

At 04:33 PM 3/4/98 -0500, Paul Koning wrote, in part:

>If only authentication tools, then that seems to leave only the case
>of recertifying an existing key as a meaningful scenario for multiple
>certificates.

As Bob Jueneman pointed out, in the absence of globally unique names,
how is such authentication to work?  Here at LLNL, there are several
Dave Browns and Bob Smiths, so even an additional company qualifier
fails to disambiguate.

Where the identity is unambiguous, then the "multiple certs" should
really be for authorizations, as you point out.  Multiple "identity"
certs may still differ in "class" or the degree of assurance given
to the binding by the CA.  So the RP application may need to know
which certificate, not to ascertain "role or attribute of holder" but
to determine assurance level appropriate to usage.

You make a very good point in alluding to a protocol that would state
"public key Z is revoked" rather than "cert Z is evoked" in the case
of revocation due to key compromise.  The difficulty:  In the latter
case, it is the cert issuer that governs a revocation status.  Who
would want the job of independently announcing the revocation status
of a key (perhaps wrongly) that has been certified by disparate parties?

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 15:20: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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Bill, I've already done my mea culpa's for the "signed by a certificate"
imprecise usage. Rather than reiterate the argument yet again, I
would be interested in your reaction to my recent reply to
Tony Bartoletti.

Havin' fun stirring up the hornets,

Bob

>>> Bill Burr <[email-masked]> 03/04 2:27 PM >>>
Bob,

But do we sign with a certificate, or with a key?  I don't think that key
and certificate are synonymous.  If the context of the certificate matters
to the signature, then I should include the certificate in the signed
message.
 [snip]

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 15:13:16 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Tony, I didn't go back to check, but I may have been guilty of the less
than precise usage implied by "which certificate was used to sign".
Obviously you are correct -- private keys sign documents, not certificates,
so the more correct usage would be "which certificate should be used to
validate a document that was signed by a private key which is mathematically
bound to a public key, which is in turn bound to some collection of attributes
and/or names in the certificate by the Certification Authority, based on
representations made by the subscriber and verified (more or less, as
spelled out in the CPS) by the CA." Sorry if I skipped a few steps in the terminology.

(What is the ASN.1 for "do what I mean, not what I say"?)

The problem, to the extent that there is one, is that the X.509 definition of the
"sign" macro does not provide any means of defining precisely which
certificate in particular should be used to validate a particular signature,
and thereby associate a particular set of name/rights attributes with that
signature.

(That's what often happens when a standard that was intended for one purpose
is appropriated for another, entirely different purpose. We, the digital signature
community, probably should have rethought that particular issue before adopting
the X.509 definition of signature. Some other information, such as the date/time and
signing and the identity of the platform ("location") on which the signature took
place would have been handy, also.)

But that's water over the dam by now, and so all of the various applications
which might ever want to use a digital signature have to solve the problem themselves.

Unfortunately, several of those applications further compounded the
original error by not incorporating an unambiguous reference to the certificate which
is to be used to validate the signature within the signed document itself, but rather
appended the reference to the certificate, or the certificate itself, to the document
in an insecure manner. One way around that problem would be to recite the
contents of the certificate itself, but that is both awkward, and not likely to be easily
machine processable, since no particular convention has been established for such a
process.

Since the certificate reference is not securely bound to the document in question,
another certificate could easily be substituted. If it were not for the private key
proof-of-possession requirement, this would even allow some other person to
claim authorship of the document, which might be quite useful in some circumstances.
And it certainly allows an individual who possesses the key but is wearing different
hats (roles) to play some games if it would be to his advantage.

To address your concerns, therefore, I submit that it matters a great deal to the
relying party whether the certificate that is used to validate a digitally signed document is
the Classy Certificate which identifies you as the purchasing agent for your company,
vs. the one which identifies you as the secretary of your bowling team, vs. the one for
you in your private citizen capacity, all of which had a common public key.

Although from a legal standpoint, it is "you" that signed the document in each case,
and hence "you" may be personally liable if your signature was not duly authorized
for that type of transaction, from the standpoint of the relying party "you" in your
private capacity may not have sufficient funds to pay for the nuclear reactor that
you just ordered in your capacity as an agent of Lawrence Livermore.

To put a different spin on it, suppose that you work for Unscrupulous Employer, Inc.
as an officer, director, or agent. You order 1 million blue widgets in the name of
your company in good faith. Unfortunately, by the time they arrive, the bottom
has dropped out of the blue widget market, and now everyone wants red ones.
Your employer is facing bankruptcy if they have to pay for the blue widgets, so some
way or another they manage to remove the company certificate from the signed
document and substitute your own personal certificate which contains the same key,
leaving you twisting slowly in the wind. Since widgets cost $10 apiece, the widget
manufacturer sues you for $10 million. He won't collect more than a few hundred
thousand after he sells your house, so both of you will be pretty upset.

You will both argue that it wasn't your private capacity certificate that was intended to
be referenced, but rather the company's Classy Certificate, and offer "proof" in the form of
the original document as received, but the Unscrupulous Employer can argue that you
change the document after it arrived, and that his copy was the correct one. At least
from a cryptographic standpoint it is indeterminate whose certificate was supposed
to have been used to validate the signature.

I suppose that once this problem is adequately recognized attorneys will advise the
clients not to rely solely on the certificate to establish authorship, but to include
a claim of authorship in the document itself, and to insist on such a reference
being in any signed transaction that is to be accepted, but as a technologist
I would prefer a technical solution.

Bob
>
>
>
>>>> Tony Bartoletti <[email-masked]> 03/04 1:18 PM >>>
>Pardon, please, my pedantic revisitation of this topic, but some of the
>comments that have been made imply (to me) a peculiar stance on the
>relationship between keys, certificates, end-entities (EE) and relying
>parties (RP).
>
>More than once, I have seen expressed "which certificate was used to sign"
>a document or transaction.  I thought that a "private key" was used, and is
>not a component of any certificate directly.  I think of a private key as
>having (potentially) a life of its own, possibly independent of any
>certificate (albeit not of great use where not certified in some capacity.)
>
>Where does the following example "fall down"? :
>
>In my hypothetical role as Purchase Officer for BigCorp, I obtain a classy,
>expensive certificate for a key, attesting to my identity and role, and
>obligating me to protect such key to the level of assurance indicated by
>the certificate.  I also have this key certified by Certs-R-Us as belonging
>to me in the capacity "member of chess club in good standing" (with a very
>low degree of assurance provided, and so a low cost.)
>
>I sign a purchase order on behalf of BigCorp.  The relying party must verify
>this signature, and so must obtain a some certificate by some means.  Simply
>verifying that some arbitrary public key verifies the signature is not
>enough.  It must be a *suitably certified* key.  If I point the RP to my
>"chess club" cert, the signature may verify, but the transaction should not
>proceed.  How could it?
>
>Also, how could my act of obtaining a "cheap cert" on the same key weaken
>in any way the relationship this key has to me in my BigCorp role, or my
>obligations to protect said key in accord with the provisions indicated in
>the classy, expensive certificate?
>
>Finally, I say all of this, not to advocate multiple certification of a key,
>(keys will NOT be a scarce commodity) but to understand the "liability issues"
>alluded to by some in this discussion.  I even wonder if there is a fear that
>"cheap CAs" might leverage the strong (pre-existing) certification on a key
>to issue additional certifications, attesting to whatever the owner-in-common
>would like, in essense conditioning the validity of their new binding on the
>continued validity of the "classy certificate."
>
>___TONY___
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 4 Mar 1998 13:53:22 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

Bob,

Thanks for considering my comments.  I didn't see them until after sending
_yet_another_ diatribe on the issue.

While I am concerned about privacy issues, the real thrust of my exploration
was to ferret out, by way of implication, what cert-chain mechanisms folks
expect to exist.  The comments of some lead me to believe that an OSCP-type
responder could simply be submitted a public key (or its hash) and then it
would respond, boolean-wise, with "Yes, there IS a valid cert of some form for
that public key" or not.  That is, as if there would be no provision for the
(e.g., OCSP) user to specify a cert, or a set of attributes that must be
present to indicate the key is suitable for their purposes. Such a system
could only work if there were exactly one cert-per-key, so *the one* cert
(hence *the one* key) is either valid or not.

I hope all of this is of value to someone;)

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 4 Mar 1998 16:45:54 -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] Multiple certificates for same key?
To: [email-masked]

> From: Bill Burr <[email-masked]>
>
> If I have 50 or 100 certificates, each with some particular attributes
> bound with my keys, one for the auto club, one for the New York Times
> on-line, one for every pay site I subscribe to, etc., and I want to carry
> them around on my token and use them at home and at work, etc., maybe I've
> got a problem.
>
> Is does seem to me to simplify my life to use one key to sign everything;
> after all, I don't sign my name differently when I use my AMEX card than
> when I use my Visa.   This makes sense if we separate attributes from
> identity and use X9 style attribute certificates, that don't contain a key.
>  I'm far from convinced that such attribute certificates are practical.

I believe the analogy is flawed.  When you use your AMEX card, the
information extracted from the magstripe is different than the
information on your Visa magstripe.  You use the same handwritten
signature to authorize both cards, just as you use the same PIN to
activate your token.

I always cringe when people use the word "certificate" to mean both a
public key certificate and the associated private data, but from an
ergonomic point of view, there isn't much difference.  When you select
an X.509 certificate in your web browser to sign a message, the browser
automatically uses the private key associated with that certificate.
If you have 50 or 100 certificates to choose from, you have to choose
once, but you don't have to choose again to get the proper private key;
that part is automatic.

And if a token can store n certificates of 1K-2K bytes each, adding an
additional 128-256 bytes of private key for each certificate doesn't
significantly change the number of certs that can be carried on
the token.

Dave Kemp

Approved-By:  Paul Koning <[email-masked]>
Date:         Wed, 4 Mar 1998 16:33:00 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

I'll skip quoting previous messages because it's hard to tell anymore
who said what....

One analogy presented was that several certificates for the same key
is similar to having several credit cards in your wallet.

It occurs to me that some of what's going on in this discussion is the
age-old problem of mixing up authentication with authorization.  As in
"am I dealing with G. Paul Koning, that guy with the bushy beard,
passport number foo...?" vs. "given that I believe I'm dealing with
G. Paul Koning, is he entitled to charge $N to account number bar?"

It seems pretty clear that a pile of certificates all attesting to the
same key are certifying the same identity, i.e., authenticate the same
entity.  But because they have different attributes, they may be
driving different authorization decisions.

In other words, it looks like the question is: are certificates
supposed to be authentication tools, or also authorization tools?

If only authentication tools, then that seems to leave only the case
of recertifying an existing key as a meaningful scenario for multiple
certificates.

If also authentication tools, then clearly there can be many
certificates since any individual is allowed to do many things, and
those permissions are granted by many independent organizations.

In the latter case, while it may be possible to have many different
key pairs for those many authorizing certificates, I agree with Bill
Burr that this is a bad idea.  The more bits of secret I have, the
harder it is to protect those bits.

Another point: if certificates are authorizing tools, you aren't
actually going through the two step process of first authenticating
then authorizing.  So it isn't functionally necessary to be able to
prove that each of my authorizing certificates "belongs to" the same
identity.  On the other hand, it seems to be very useful to be able to
do this -- which is what you get by having them all tied to the same
key.

Finally, a thought that may not work... if there are many certificates
sharing a key, it would make sense for revocation to revoke the key,
not each certificate one by one.

        paul

Approved-By:  "Balluffi, Frank" <[email-masked]>
Date:         Wed, 4 Mar 1998 16:23:51 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Balluffi, Frank" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

        I agree with Mark Shuttleworth:

>   2. If the signed package does not include the certs, or references
> to
>      the certs (like the issuer+serial form of authorityKeyIdentifier)
>      then the validating technology should examine each of the options
>      to see if an appropriate chain of authority can be found before
>      crying foul.  This is really the case where the reference is of
> the
>      "hash of key" form, which could in theory point to multiple certs
>      all containning the same key.
>
> What I'm trying to say is, we should come up with rules that the
> software
> should follow that allow for multiple certs containing the same key,
> rather than saying "hardly ever do this".  The market will determine
> how
> often we do it, and the implementation should support the market,
> rather
> than dictate.  Whew, better get off this pedestal before people start
> throwing fruit ;)
>
        I think the word "rules" is a bit strong. Perhaps the potential
problems associated with multiple certificates per public key should be
identified and accompanied by some suggestions. For example:

*       applications (and protocols) may uniquely identify a certificate
by issuer and serialNumber
*       policy qualifiers may be embedded into certificates

        It's hard to imagine an SSL client being confused by a
certificate containing the policy qualifier "only for use by protocol
number 9".

        As a consumer, I would like to be able to purchase an
inexpensive cryptographic token capable of storing one key pair and hold
multiple certificates, one for each application (or protocol).

        Frank Balluffi
        CertCo LLC
        [email-masked]

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 4 Mar 1998 12:18:27 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Pardon, please, my pedantic revisitation of this topic, but some of the
comments that have been made imply (to me) a peculiar stance on the
relationship between keys, certificates, end-entities (EE) and relying
parties (RP).

More than once, I have seen expressed "which certificate was used to sign"
a document or transaction.  I thought that a "private key" was used, and is
not a component of any certificate directly.  I think of a private key as
having (potentially) a life of its own, possibly independent of any
certificate (albeit not of great use where not certified in some capacity.)

Where does the following example "fall down"? :

In my hypothetical role as Purchase Officer for BigCorp, I obtain a classy,
expensive certificate for a key, attesting to my identity and role, and
obligating me to protect such key to the level of assurance indicated by
the certificate.  I also have this key certified by Certs-R-Us as belonging
to me in the capacity "member of chess club in good standing" (with a very
low degree of assurance provided, and so a low cost.)

I sign a purchase order on behalf of BigCorp.  The relying party must verify
this signature, and so must obtain a some certificate by some means.  Simply
verifying that some arbitrary public key verifies the signature is not
enough.  It must be a *suitably certified* key.  If I point the RP to my
"chess club" cert, the signature may verify, but the transaction should not
proceed.  How could it?

Also, how could my act of obtaining a "cheap cert" on the same key weaken
in any way the relationship this key has to me in my BigCorp role, or my
obligations to protect said key in accord with the provisions indicated in
the classy, expensive certificate?

Finally, I say all of this, not to advocate multiple certification of a key,
(keys will NOT be a scarce commodity) but to understand the "liability issues"
alluded to by some in this discussion.  I even wonder if there is a fear that
"cheap CAs" might leverage the strong (pre-existing) certification on a key
to issue additional certifications, attesting to whatever the owner-in-common
would like, in essense conditioning the validity of their new binding on the
continued validity of the "classy certificate."

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By: [email-masked]
Date:         Wed, 4 Mar 1998 11:37:33 +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: Mark Shuttleworth <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Hiya

I think that saying "OK, but only rarely" is dangerous, because it leads
to implementations which break when they see a signle key in multiple
certs.

How about this:

  1. Most "signing" technologies like S/MIME and PKCS#7 include the
     signing certificate along with the signed data.  So parsing
     applications only have to validate the presented or attached certs.

  2. If the signed package does not include the certs, or references to
     the certs (like the issuer+serial form of authorityKeyIdentifier)
     then the validating technology should examine each of the options
     to see if an appropriate chain of authority can be found before
     crying foul.  This is really the case where the reference is of the
     "hash of key" form, which could in theory point to multiple certs
     all containning the same key.

What I'm trying to say is, we should come up with rules that the software
should follow that allow for multiple certs containing the same key,
rather than saying "hardly ever do this".  The market will determine how
often we do it, and the implementation should support the market, rather
than dictate.  Whew, better get off this pedestal before people start
throwing fruit ;)

--
Mark Shuttleworth
Thawte Consulting

Approved-By: [email-masked]
Date:         Wed, 4 Mar 1998 12:50:04 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

At 09:42 AM 3/4/98 -0500, you wrote:
>> From: Tony Bartoletti <[email-masked]>
>>
>> The arguments put forth in deprecating multiple (independent) certification
>> of a single keypair are reasonable, but I point out that they belie the
>> purported nature of X.509 certificates as "identity certificates" (that is,
>> to bind the key simply to a warm body able to appear court.)
>
>I don't think X.509 certificates were ever purported to be "identity
>certificates" with the meaning you suggest.  That is an interpretation
>formulated by proponents of an alternative certificate format :-).
>
>The original purpose of X.509 was to provide strong (as opposed to
>password-based) authentication to X.500 directory servers.  Although
>X.509 v1 did bind just an "identity" to a key, the meaning of "identity"
>was concerned more with the privileges possessed by a warm body than
>by the warm body itself.  If Joe Smith @ foo.com had a certificate and
>the matching private key, he could get access to the directory if he
>was on the access list.  It doesn't really matter if Joe got his job
>under an assumed name to avoid child support, or how many Joe Smiths
>there are in the world, it only matters that there is one person with
>that userid at that company, and that that person is entitled to access.
>
>MISSI expanded the use of X.509v1 certificates by cleverly stuffing
>additional attributes (privileges, clearances, etc) into the
>subjectPublicKeyInfo field, since there was nowhere else to put them.
>Now that X.509v3 has extensions, privilege attributes can be included
>in a more proper location.  But the role of X.509 certificates is still
>the binding of privileges to keys, not the binding of warm bodies to keys.
>
>For the purpose of electronic filing of tax returns, or getting access
>to social security records, it would be convenient to have a "name"
>(i.e. SSN) that attempted to be uniquely tied to a particular warm body.
>But privacy advocates don't like that idea, so the binding between
>identities and warm bodies is deliberately left vague.  That is a
>political limitation, not a technical one.
>
>
>
>> Allowing independent certifications on a single key can be compared to the
>> use of both a "Diner's Club" card, and an "Auto Club" card.  If stranded
>> in a broken car, the tow truck operator will be uninterested in my Diner's
>> Club card, whether valid or not.  They want my Auto Club card, and want to
>> be assured that it is considered to be in effect at the time of
transaction.
>
>This presumes that keypairs are somehow a scarce commodity.  What
>possible benefit is there to having your Diners Club and Auto Club
>certificates share the same key?  They're just bits; billions and
>billions of combinations of them (apologies to the late A******
>Astronomer :-).  Just use a new keypair for each distinct purpose
>unless, as Bob Jueneman points out, there's a Very Good Reason not to.
>
>
Dave,

Keypairs may not exactly be a scarce commodity, but perhaps the protected
storage for private keys is.  If you think that you should keep your
private keys in a hardware token, you may not be able to have dozens of
private keys.

If I have 50 or 100 certificates, each with some particular attributes
bound with my keys, one for the auto club, one for the New York Times
on-line, one for every pay site I subscribe to, etc., and I want to carry
them around on my token and use them at home and at work, etc., maybe I've
got a problem.

Is does seem to me to simplify my life to use one key to sign everything;
after all, I don't sign my name differently when I use my AMEX card than
when I use my Visa.   This makes sense if we separate attributes from
identity and use X9 style attribute certificates, that don't contain a key.
 I'm far from convinced that such attribute certificates are practical.

But if, as you -I think correctly- suggest, we're actually binding a lot of
attributes into X.509 certificates, then I suspect that we're each
individually going wind up with a lot of x.509 public key certificates.  If
each of them has a different private key, then we've got a lot of private
keys to store, manage and protect.  I think that the fewer private keys I
have to manage, store and protect, the better.
Regards,

Bill Burr

Approved-By: [email-masked]
Date:         Wed, 4 Mar 1998 13:06:38 +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: Michael Warner <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Are you trying to solve too large a problem here ?   It seems as though you
are trying to have a fully automated equivalent of the entire legal system,
by trying to tightly link roles and responsibilities to the certificates.
It almost sounds like SPKI....

Surely the purpose of the certificate is to bind the public key with an
identity (or set of attributes) of a physical person.   The fact that I have
multiple names (or roles or other attributes) doesn't mean I'm actually
multiple people, or that I change my (handwritten) signature.

It is the application space which will be concerned about my various
attributes (including my name).   The fact that I have other attributes
(including my name) in one application space should not impact my attributes
in a second.   If the attributes have meaning in multiple application spaces
then they should not conflict.   If they do, it means they have been
incorrectly defined, assigned or interpreted.

If a signed message in one application space is so ambiguous in nature as to
have meaning in a different application space there would seem to be a
problem with the definition of the message structures of the applications -
not the certificates.

Cheers,

Michael

-----Original Message-----
From: Bob Jueneman <[email-masked]>

>The issue, of course, is that if there are two certificates which both
contain the same public key, then  the binding from the private key (which
signed the document) to the public key to the identity and other attributes
which are associated with the public/private key become indeterminate.
>
>It might be argued that if it is indeed the same entity, the no harm no
foul rule should apply. But I would argue that unless the ENTIRE contents of
the two certificates are precisely identical (in which case why bother),
then different is not the same.

>
>To go further would require an extensive analysis of exactly what the
differences were, and whether they might matter, even in some obscure
context that would be difficult to envision.  For example, a difference in
validity period might have some difference down the line in terms of
nonrepudiation, especially if one certificate was revoked because of a
compromise and the other was not.
>
>In the case of differences in the common name, address, etc., even though
it is the same person using either her married or personal name (Mrs. John
Smith vs. Lucy Smith), there might be some obscure legal difference due to
community property laws or whatnot -- who knows.
>
>Likewise, two different certificates -- one listing my primary residence
and the other my summer cabin -- might have slightly different connotations
in a legal context, since there might be differences in the laws of the two
different jurisdictions, and in the absence of any other indication of the
locus of the transaction, the locality of the user as expressed in the
certificate might govern.
>
>At one time I took the hard and fast position that said that the same
public key should NEVER be used in two different certificates, but someone
convinced me that sometimes corporations change their name (Esso to Exxon,
United States Steel to USX, etc.), other times they are acquired by another
company. forcing a drastic change of all of the subordinate names might
screw up name subordination and other mechanisms, and shouldn't be done
hastily, even if the organization whose name is changing is a CA.  So I
guess I can't say that public keys should _never_ be reused.
>
>How about HARDLY EVER, ALMOST NEVER, ONLY IF THE SUN DOESN'T RISE, AND THEN
ONLY IF YOU STOP AND THINK REAL HARD?
>
>On the other hand, having multiple certificates, all with the same entity
information but with different keys, whether because of different key
usages, algorithms, or just your whim, is perfectly acceptable. Maybe you
can get the CA to give you a volume discount.  (Seriously, why not, since
most of what they are doing is the due diligence of confirming who you are?)
>
>Bob
>
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.
>Network Products Group
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>[email-masked]
>
>"If you are trying to get to the moon, climbing a tree,
>although a step in the right direction, will not prove
>to be very helpful."
>
>"The most dangerous strategy is to cross a chasm in two jumps."
>
>
>>>> Tony Bartoletti <[email-masked]> 03/02 3:35 PM >>>
>Stefan,
>
>At 06:34 PM 3/2/98 +0100, you wrote:
>>Folks,
>>
>>I haven't had the time to browse through all the different latest drafts,
I'm
>>afraid. Having had some discussions concerning the German digital
signature
>>law, however, a question occured to me: Is a CA allowed to issue two (or
>>more) certificates for a single end-entity's public key? If yes, this
could
>>lead to big problems, especially in terms of liability of the CA. If
>>not, shouldn't this be specified somewhere?
>
>Could you expand on the liability issues you mention regarding the issuance
of
>differing certificates for the same public key?  From a layman's point of
>view,
>of course a CA could get into trouble issuing arbitrary certificates on a
>given
>end-user's public key.  But, for the sake of argument, if I want the same
key
>to be certified by a CA in two distinct certificates, both of which contain
>data that identifies me (in different ways, for different reasons,) then it
>seems to be up to the relying party to check if there is a valid
certificate
>for that key, suitable for their purposes of identification.  (Apologies
for
>naive view and tortured sentence structure.)
>
>Here is a related question (and perhaps more likely desired) : Can I ask a
CA
>to certify 10 keys, in 10 certificates, all of which attest to identical
info?
>(modulo certificate id, or course.)  My thought is, I want to use my keys
very
>sparingly, cycling through them so to thwart marketeers attempting to trace
my
>habits.  This presupposes that I, the cert-owner, control the cert that I
>point
>the relying party to use.
>
>Thoughts?
>
>
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: [email-masked]   phone: 510-422-3881             LLLLLLLL
>

Approved-By: [email-masked]
Date:         Wed, 4 Mar 1998 10:36:53 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      Re: [IETF-PKIX] Re patent 5699431 & PKIX
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msA259957B314729DBF867807C
Content-Type: multipart/mixed; boundary="------------749BDBCE2BA6267C9E2CAD72"

This is a multi-part message in MIME format.
--------------749BDBCE2BA6267C9E2CAD72
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul,
I think that David is right but there may be a larger issue at hand here...

It is my understanding that  since a company or private entity could file for a
patent against a technology up to  one year after public disclosure, that it
would be possible to enact a standard in the IETF/IESG and then patent it if you
could complete the standardization process in less than the obligatory year.
With this in mind perhaps a revision of the IETF charter text with regard to
patent issues is in order.

By the way - The actual text of the Intellectual property's notice (as taken
from the bottom of http://www.ietf.org.ipr.htm) reads something like:

(C) Where the IESG knows of rights, or claimed rights under (A), the IETF
Executive Director shall attempt to obtain from the claimant of such rights, a
written assurance that upon approval by the IESG of the relevant Internet
standards track specification(s), any party will be able to obtain the right to
implement, use and distribute the technology or works when implementing, using
or distributing technology based upon the specific specification(s) under openly
specified, reasonable, non-discriminatory terms. The Working Group proposing the
use of the technology with respect to which the proprietary rights are claimed
may assist the IETF Executive Director in this effort. The results of this
procedure shall not affect advancement of a specification along the standards
track, except that the IESG may defer approval where a delay may facilitate the
obtaining of such assurances. The results will, however, be recorded by the IETF
Executive Director, and made available. The IESG may also direct that a summary
of the results be included in any RFC published containing
the specification.

for further clarification of patented technologies in Internet Standards, see
section 4.1.2  and section 10.3.2 of RFC2026 - The Internet Standards Process
v3.

In my mind there is a bigger question as to whether the IETF should set a
standards requirements that makes its standardized technologies free of patent
encumbrance. Personally I think that since the US people are still funding the
bunt of the Internet and its operations that the technologies that we as IETF
members standardize on MUST be freely available to all.

With that in mind, from my viewpoint there are two time based issues with the
patent issues

    1) the text of the existing charter is specific to "patented" technologies,
but doesn't address the timeliness of the disclosure and with the amount of time
it takes to get a submission worked through the US PTMO, sometimes as much as
two (2) years or longer if the claims of a given patent are opened to
prosecution or the like, it seems reasonable that the text of the IETF/IESG
charter could be amended to refer to "technologies or specific implementations
of technologies" that are under way or will be filed for patent protection
within the 1 year filing deadline for US based disclosure. (whew!, sorry bout
the long sentence there!)

With this type of patent-specific text in place, any technologies that are
enacted as standards would not be patentable UNLESS they, the patents
themselves, were put into the public trust or maybe as an alternative "licensed
freely" as though they were in the public trust... Somewhat like the Spread
Spectrum Radio Patents done in the 40's.

I apologize for ranting, but this is an issue that I am particularly sensitive
to!.

Todd

David P. Kemp wrote:

> > From: Paul Hoffman / IMC <[email-masked]>
> > Date:         Thu, 15 Jan 1998 17:55:15 -0800
> >
> > Section 10.3.2 specifies what kind of patent information must be made
> > available before something can move onto standards track. If a company is
> > known to have an applicable patent but has not come up with a patent
> > statement, that company can hold up the process of getting the document on
> > standards track (nudge, nudge).
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
>
> draft-ietf-pkix-ipki3cmp-07.txt does not contain a patent statement, sigh.
> Will we need to wait for draft -08 before going to the IESG?
> (nudge, nudge, nudge).

 No - Lets get this one into IESG for review and action.

--
--------
--  Regards,
--  Todd Glassey

Todd's Latest Rant --
---------------------
"...Plan?, There ain't no plan, I though' you had the plan..."
      The Pig Killer - Mad Max: Beyond Thunderdome

--------------749BDBCE2BA6267C9E2CAD72
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Todd S. Glassey
n:              Glassey;Todd S.
org:            Coastek, Inc.
adr:            5550 Scotts Valley Drive;;Suite 700;Scotts Valley;Ca;95066;USA
email;internet: [email-masked]
title:          Chief Scientist and Principal Founder
tel;work:       408.440.0180
tel;fax:        408.438.2979
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------749BDBCE2BA6267C9E2CAD72--

--------------msA259957B314729DBF867807C
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msA259957B314729DBF867807C--

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Wed, 4 Mar 1998 11:53:05 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      [IETF-PKIX] Examples from PKIX part 1
To: [email-masked]

David Kemp has prepared binary examples of the three certs and the CRL that
are
shown in the back of the PKIX part 1 draft. They are now available at the
S/MIME WG's page at
<<http://www.imc.org/ietf-smime/>http://www.imc.org/ietf-smime/>, near the
bottom of the page.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 12:42:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Tony,

You've raised some good issues, and the question of a pure "identity"
certificate vs. one which contains additional attributes has been hotly
debated, especially on the SPKI list.

Since a common name is not sufficient to identify an individual in a globally
unambiguous way (something that is at least thought to be desirable in order to
facilitate global electronic commerce), some form of additional name
qualification is required.

Whether that involves the use of an organization name or a residential address,
I would argue that there are at least subtle implications of "rights" that may be
involved, whether we in the technical community intended that or not.

For example, although it might not be reasonable to assume that someone who
is issued a certificate containing the name of corporation XYZ is an agent (e.g.,
a purchasing agent) for that company, at least in the US there is a doctrine of
implied agency. That is, if it walks like a duck, quacks like a duck, and is ordering
duck food, it probably is a purchasing agent -- or at least the relying party may be
entitled to believe so. Obviously if someone has a certificate issued by XYZ Corp.
and is requesting a dozen pencils to be shipped to XYZ, they are more likely to be
believe than if the pencils were to be shipped to ABC Corp.

Likewise, there are subtle implications that may be associated with someone's
residential address. For example, if I am going to send out (spam) invitations to
visit my off-shore or Indian reservation gambling casino, I might not want to send
it to residents of states which ban such gambling. And likewise, if I were inclined
to make available for downloading from my web site in SanFrancisco certain
pictures that shall we say might be in questionable taste, I probably wouldn't
want to allow residents of states such as Utah and Tennessee to access such
images, for people have been convicted for violating those state's local standards
as to what constitutes pornography or indecent material.

Without getting metaphysical about it, the point is that the only available "attributes"
that can reasonably be used to differentiate between two individuals with the
same name also have other societal implications that may be both inescapable
and difficult to predict in advance, as it may in fact depend on the whim of some local
legislatures, rather than any bright-line legal principles.

In other words, as a bumper sticker on a water treatment truck I saw recently
said, "E coli happens."

Bob

>
>>>> Tony Bartoletti <[email-masked]> 03/03 8:10 PM >>>
>I am not a lawyer, and I don't claim to appreciate fully the legal issues
>surrounding a CA and their obligations, in either general or specific cases.
>
>The arguments put forth in deprecating multiple (independent) certification
>of a single keypair are reasonable, but I point out that they belie the
>purported nature of X.509 certificates as "identity certificates" (that is,
>to bind the key simply to a warm body able to appear court.)  Rather, they
>become attribute certificates, attesting to (say) primary residence, not so
>much for distinguishing among similarly named individuals but now assuming
>a free standing legal significance.  The certificate no longer attests only
>that a given document was signed by me, it can now be used as evidence that
>I reside at location X, *independent* of my use of the key at all.  While I
>can appreciate the utility of such usage, I question where the boundaries lie.
>
>Allowing independent certifications on a single key can be compared to the
>use of both a "Diner's Club" card, and an "Auto Club" card.  If stranded
>in a broken car, the tow truck operator will be uninterested in my Diner's
>Club card, whether valid or not.  They want my Auto Club card, and want to
>be assured that it is considered to be in effect at the time of transaction.
>
>True, a key compromise on one should affect all certificates over that key.
>If one certificate is not revoked, but should have been, it could just as
>easily be the certificate appropriate to the transaction as the one not.
>
>I wonder if the central issue is primarily one of protocol.  The RP must
>(somehow) obtain not just *any* certificate validating my ownership of the
>key in question, but the certificate indicating I satisfy the role that the
>relying party expects for a signatory to the given transaction.  (In pure
>"Identity Cert" principle, any such cert should just identify "me" to a
>given degree of assurance, and then the relying party should use that fact
>to determine if, within their own domain, this "me" has the required role.)
>
>Again, I am not really advocating such usage, but I wonder if the restriction
>is simply one of cert retrieval complexity, or if such usage would really
>"break X.509".  Has the structure so embedded these legal implications?
>
>___TONY___
>
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 11:41:37 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Steve,

I already agreed that I was not going to fall on my sword over the issue
of never, ever allowing two certificates to be issued for the same key,
at least in part because I don't know any possible mechanism for enforcing
such a rule if the user goes to two different CAs for the two certificates,
perhaps under two slightly different names or name forms. I suppose that
once we have established the principle, as the saying goes, all that
remains to be argued about is the price,

On the other hand, I am somewhat troubled by your example of deliberately
using a short validity interval to minimize the CRL problem, and re-certifing
the old key with a new certificate.  You may have minimized the CA's storage
space problem, and also minimized the bandwidth required to transmit the CRLs,
and in your new position as CTO for GTE CyberTrust (congratulations/ condolences :-)
I can understand that point of view, but rather than having eased the CRL management
problem I think you have compounded it, at least from the user's standpoint.

As Andreas Berger correctly pointed out, and I certainly should have, unless the
certificate is actually incoporated within the document which is being signed, it is not
deterministic which certificate was actually intended. Certainly in S/MIME (and PEM)
the certificate was carried in an unsigned attachment, and could therefore be
substituted or deleted, if indeed it was transmitted at all. it was this very possibility
that lead us to require proof of possision of the private key, so that someone
couldn't extract someone else's public key and include it in his own certificate,
and thereby claim authoriship for a signed document.

Certainly in the case of software-stored keys, there is no shortage of bits, and
there is very little reason I can think of to use such a re-certification mechanism
instead of a key update/replacement scheme.  Granted, in the case of a
centrally managed hardware token it may be slightly more difficult to
regenerate keys, especially in view of the power requirements for good hardware
key generation that was recently discussed on the cert-talk list in connection with a
Smart Disk, but I am not entirely convinced about that either.

I guess my recommendation would be for PKIX to officially deprecate recertification of a key
as generally undesirable without, as David Kemp says, A Very Good Reason, but not
to prohibit it entirely. Within that overall guidance, CAs and users (and relying parties!)
can make up their own mind what do to.

If as a CA you want a user's and potential relying party's point of view, I personally
wouldn't put a lot of faith in any CA who would countenance such actions, and I
would certainly want to see notice provided in a CA's CPS that would warn me of that
possibility. If a given CA issues multiple certificate for the same key _without_ informing
relying parties, I would be inclined to say that they were being derelict in their duty.

I'm going to bring this issue to the attention of the group within the ABA Information Security Committee that is drafting CA Accreditation Guidelines, so they can consider it further.

Bob

>>>> Stephen Kent <[email-masked]> 03/04 7:21 AM >>>
>Bob,
>
>Ignoring issues of non-repudiation (for which only some certs may be
>employed), it may be reasonable for two certs to hold the same public key.
>For example, A CA may choose to have a short validity interval to ease CRL
>management, but not require users to generate and transmit new key pairs to
>match the interval.  In that case, the CA can merely re-certify the old key
>and reissue a cert with a new serial number and the same name, and probably
>all the other attributes would be the same as well.
>
>Steve

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Wed, 4 Mar 1998 10:37:31 -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: Trevor Freeman <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

It is impossible for CA to establish whether a public key has been used in a
certificate elsewhere.
The public key bind the user to the certificate, but the it is the
certificate which hold the CA policy on the use of the certificate which is
equally important part of the process.
It is impossible to resolve this issue within the PKI alone. We should
recommend that when generating a signature for non-repudiation purposes
applications must ensure that the identity of the certificate used to sign
is part of the data protected by the signature.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 4 Mar 1998 11:56:32 -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] Re patent 5699431 & PKIX
To: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> Date:         Thu, 15 Jan 1998 17:55:15 -0800
>
> Section 10.3.2 specifies what kind of patent information must be made
> available before something can move onto standards track. If a company is
> known to have an applicable patent but has not come up with a patent
> statement, that company can hold up the process of getting the document on
> standards track (nudge, nudge).
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

draft-ietf-pkix-ipki3cmp-07.txt does not contain a patent statement, sigh.
Will we need to wait for draft -08 before going to the IESG?
(nudge, nudge, nudge).

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Wed, 4 Mar 1998 08:34:43 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

>If we agree that this comment data ought not be verified, then the argument
>is really over the inclusion of non-verified data in certs, which is a long
>standing debate in this community.  Deliverability is not the issue here,
>but rather the opportunity for users to be mislead.

Quite right. I agree with the "allow non-verified data" camp as long as we
put lots of words in the document about what things we know can't be
verified, then let CAs decide what to do with it. It seems like
over-regulation to say "we know better what you shouldn't put into a cert,
so we're going to prohibit it even though you might have done it well." The
comment in RFC 822 names is a very good example of this.

Since the mailing list archive has a huge hole in it, I don't know if this
debate was ever resolved for PKIX.

>Not sure where "DirectoryString" enters into our discussion.  It seems that
>there is a catch 22 here:  you seem to be saying that it's OK to not verify
>this data as a CA, but then suggest that it is important to include because
>of it's user friendliness.

Right.

>  This suggests that the latter quality is

>important for user comsumption, but that user consumption of unverified
>data from what purports to be a secure form of identiofication is OK in
>this context.  That's hard for me to accept.

It isn't for me. How do you know how well the CA verified the 822 address?
Did they send mail to it and get it back? Did they just do a VRFY on it?
Did they ever check it again? At what intervals? Did they check with the
Postmaster at the site to make sure the address was known to her/him and
not a hacker who got a temporary account by fraud? All of these things are
determined by reading the CA's policy before trusting them. Whether or not
they verified the comment part of the name is just one more thing on the
list of things that the CA tells you they verified.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Koning <[email-masked]>
Date:         Wed, 4 Mar 1998 10:23:18 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

...
 David> For the purpose of electronic filing of tax returns, or
 David> getting access to social security records, it would be
 David> convenient to have a "name" (i.e. SSN) that attempted to be
 David> uniquely tied to a particular warm body. ...

Digression alert...  identity to SSN binding is not actually unique,
in two ways: a person can have more than one SSN, and on a few
occasions apparently the same SSN has been issued more than once.

        paul

Approved-By:  "Balluffi, Frank" <[email-masked]>
Date:         Wed, 4 Mar 1998 10:13: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: "Balluffi, Frank" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

There are many reasons to issue multiple certificates per public key
(see example below).

There are also many reasons to only issue one certificate per public
key. For example, suppose a corporation provides a cryptographic token
capable of holding one key pair to each employee and institutes a policy
of only allowing the token to be used for corporate business. One method
of enforcing this policy might be to only permit one certificate to be
issued per public key. This method would disallow the public key to be
bound to the employee's corporate name (e.g., C=US, O=XYZ, CN=John
Smith) and personal name (e.g., C=US, ST=IL, L=Chicago, CN=John Smith).

It seems to me that the question of how many certificates per public key
is a policy question, not a technical question.

Frank Balluffi
CertCo LLC
[email-masked]

> -----Original Message-----
> From: Stephen Kent [SMTP:[email-masked]]
> Sent: Wednesday, March 04, 1998 9:22 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
>
> Bob,
>
> Ignoring issues of non-repudiation (for which only some certs may be
> employed), it may be reasonable for two certs to hold the same public
> key.
> For example, A CA may choose to have a short validity interval to ease
> CRL
> management, but not require users to generate and transmit new key
> pairs to
> match the interval.  In that case, the CA can merely re-certify the
> old key
> and reissue a cert with a new serial number and the same name, and
> probably
> all the other attributes would be the same as well.
>
> Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 4 Mar 1998 09:59:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Andreas,

>> I haven't had the time to browse through all the different latest
>>drafts, I'm
>> afraid. Having had some discussions concerning the German digital signature
>> law, however, a question occured to me: Is a CA allowed to issue two (or
>> more) certificates for a single end-entity's public key? If yes, this could
>> lead to big problems, especially in terms of liability of the CA. If
>> not, shouldn't this be specified somewhere?
>>From a technical point of view, there is no reason why it should be
>defined whether issuing several certificates for a single public key.
>The problem simply is that if you have two certificates with the same
>key available you cannot distinguish which one was used to produce the
>signature. To accomplish that you would have to name the certificate
>inside the document that was signed. This way, you can make sure that
>the signer chose the correct context (certificate) to sign the document.
>
>This whole scheme fails once the secret key is retrieved. Then anybody
>can use any of the two certificates. And what do you do if only one of
>the certificates is revoked, the other is not? Then it is important, why
>the certificate was revoked (a formal reason or a key compromise).
>
You are right that using the same key in two or more certs implies a need
to revoke all of them in the case of a compromise.  You and others are also
right that certain instances of reusing a key have significant adverse
effects, especially with regard to non-repudiation.  However, not all uses
of certs are for NR and there are legitimate circumstances for reuse, thus
I would not expect PKIX to preclude such reuse, though inclusion of a
suitable warning is not unreasonable.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 4 Mar 1998 09:48:23 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Paul,

>>I'd like to suggest that we not allow all of these representations of RFC
>>822 names, despite your obeservation that they are all syntactically
>>allowed under RFC 822.  My reasoning is that we ought to not confuse the
>>bounds of what is being certified.  As a CA, I can readily validate a pure
>>user_name@FQDN syntax, but when someone includes a parenthetical comment,
>>it makes the verification harder and subject to errors.
>
>I completely disagree. The RFC 822 syntax is absolutely clear that the
>other stuff is a comment with no relation to the deliverability of the
>address. It doesn't make "the verification harder and subject to errors":
>it is *never verified* because it can't be.

If we agree that this comment data ought not be verified, then the argument
is really over the inclusion of non-verified data in certs, which is a long
standing debate in this community.  Deliverability is not the issue here,
but rather the opportunity for users to be mislead.

>>  A user seeing such
>>a name is likely to pay more attention to a more human-readable part of the
>>name, which may not be verified, while software is almost certain to pay
>>attention to the more tightly constrained synatx that actually supports
>>addressing of the message.
>
>Possibly true. However, a user might also believe that the bare email
>address is valid because the cert is value, when in fact the address was
>only valid for the five minutes in which the CA checked it. Or the user
>might believe that "[email-masked]" means Joe is associated with IBM, even
>though he is no longer. And so on and so on. This is a user interface
>issue, not a reliability issue. And you'll have the same issue with many
>kinds of otherNames, uniformResourceIdentifiers, and iPAddresses (for IPv6).

This is a user interface issue, but it is also a security issue and this is
a security standard.  The user ID in a cert is of greatest concern to me
because of its likely extensive use in secure e-mail, where user's will
often make value judgements, vs. IP addresses and DNS names being processed
by software in IPsec.

>>  Thus a mismatch may occur if a secure e-mail
>>package or IPsec implementation validates based on the more restricted
>>syntax, but the user thinks in terms of the comment part of the name.
>
>Well, they shouldn't do that, should they? A comment in the draft would fix
>that.

We cannot standardize user behavior, but we can avoid obvious pitfalls that
users might encounter.

>You are making the field less friendly for fear of confusing people, but
>there are lots of room for other confusions in DirectoryString. I'd say
>leave it as it is and put a note in the text saying "nothing other than
>the address portion of the name can be verified based on the definition in
>RFC 822" and leave it at that.

Not sure where "DirectoryString" enters into our discussion.  It seems that
there is a catch 22 here:  you seem to be saying that it's OK to not verify
this data as a CA, but then suggest that it is important to include because
of it's user friendliness.  This suggests that the latter quality is
important for user comsumption, but that user consumption of unverified
data from what purports to be a secure form of identiofication is OK in
this context.  That's hard for me to accept.

Steve

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 4 Mar 1998 09:42: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> From: Tony Bartoletti <[email-masked]>
>
> The arguments put forth in deprecating multiple (independent) certification
> of a single keypair are reasonable, but I point out that they belie the
> purported nature of X.509 certificates as "identity certificates" (that is,
> to bind the key simply to a warm body able to appear court.)

I don't think X.509 certificates were ever purported to be "identity
certificates" with the meaning you suggest.  That is an interpretation
formulated by proponents of an alternative certificate format :-).

The original purpose of X.509 was to provide strong (as opposed to
password-based) authentication to X.500 directory servers.  Although
X.509 v1 did bind just an "identity" to a key, the meaning of "identity"
was concerned more with the privileges possessed by a warm body than
by the warm body itself.  If Joe Smith @ foo.com had a certificate and
the matching private key, he could get access to the directory if he
was on the access list.  It doesn't really matter if Joe got his job
under an assumed name to avoid child support, or how many Joe Smiths
there are in the world, it only matters that there is one person with
that userid at that company, and that that person is entitled to access.

MISSI expanded the use of X.509v1 certificates by cleverly stuffing
additional attributes (privileges, clearances, etc) into the
subjectPublicKeyInfo field, since there was nowhere else to put them.
Now that X.509v3 has extensions, privilege attributes can be included
in a more proper location.  But the role of X.509 certificates is still
the binding of privileges to keys, not the binding of warm bodies to keys.

For the purpose of electronic filing of tax returns, or getting access
to social security records, it would be convenient to have a "name"
(i.e. SSN) that attempted to be uniquely tied to a particular warm body.
But privacy advocates don't like that idea, so the binding between
identities and warm bodies is deliberately left vague.  That is a
political limitation, not a technical one.

> Allowing independent certifications on a single key can be compared to the
> use of both a "Diner's Club" card, and an "Auto Club" card.  If stranded
> in a broken car, the tow truck operator will be uninterested in my Diner's
> Club card, whether valid or not.  They want my Auto Club card, and want to
> be assured that it is considered to be in effect at the time of transaction.

This presumes that keypairs are somehow a scarce commodity.  What
possible benefit is there to having your Diners Club and Auto Club
certificates share the same key?  They're just bits; billions and
billions of combinations of them (apologies to the late A******
Astronomer :-).  Just use a new keypair for each distinct purpose
unless, as Bob Jueneman points out, there's a Very Good Reason not to.

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 4 Mar 1998 09:21: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Bob,

Ignoring issues of non-repudiation (for which only some certs may be
employed), it may be reasonable for two certs to hold the same public key.
For example, A CA may choose to have a short validity interval to ease CRL
management, but not require users to generate and transmit new key pairs to
match the interval.  In that case, the CA can merely re-certify the old key
and reissue a cert with a new serial number and the same name, and probably
all the other attributes would be the same as well.

Steve

Approved-By:  Peter Lipp <[email-masked]>
Date:         Wed, 4 Mar 1998 11:15:55 +0100
Reply-To: Peter Lipp <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Lipp <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0061_01BD475E.E6B01800
Content-Type: multipart/mixed;
        boundary="----=_NextPart_000_005F_01BD475E.E6A9FD80"

------=_NextPart_000_005F_01BD475E.E6A9FD80
Content-Type: text/plain;
        charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

>Does it make things slightly harder to process, or does it actually =
break
>X.509?

>Consider the scenario of a person who wishes to manage different
>"certificate profiles" but not have to worry about different keys.  For
>example, he may want to sign messages as one person within the company,
>using a cert with his Org, OrgUnit and Title, but outside the company =
he
>wants to use a simpler cert that just has his name and email address in
>it.  Why should both of those certs be forced to use different keys?

My image of these processes is a keycentric one.=20

If you get a signature, accepting the signature involves a) the =
cryptographic correctness of the signature and b) my policy accepting =
the certificate given. If one has 2 certificates for one key, the =
decision will not depend on the key only, but also on the certificate =
given. I consider this to be not ok. I would like to be able to use =
protocols that do not need to provide me with a suitable certificate - I =
could have a local cache or so. Carrying certificates around is not so =
great, considering the space such things use to take. Assuming a working =
infrastructure, I could ask some CA-service to deliver a cert if I don't =
have it in my cache. If there would be more than one, leading to =
different trust decisions, this would be a drawback.=20

Peter

------=_NextPart_000_005F_01BD475E.E6A9FD80
Content-Type: text/x-vcard;
        name="Peter Lipp.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
        filename="Peter Lipp.vcf"

BEGIN:VCARD
VERSION:2.1
N:Lipp;Peter;;
FN:Peter Lipp
ORG:Styria;
TITLE:
TEL;WORK;VOICE:+43 316 873 5513
TEL;HOME;VOICE:
TEL;VOICE:Graz
TEL;WORK;FAX:A-8042
ADR;WORK:;;;;;;
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:=0D=0A,  =0D=0A
EMAIL;PREF;INTERNET:[email-masked]
REV:19980304T101555Z
END:VCARD

------=_NextPart_000_005F_01BD475E.E6A9FD80--

------=_NextPart_000_0061_01BD475E.E6B01800
Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="smime.p7s"

------=_NextPart_000_0061_01BD475E.E6B01800--

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Tue, 3 Mar 1998 21:23:25 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

>I'd like to suggest that we not allow all of these representations of RFC
>822 names, despite your obeservation that they are all syntactically
>allowed under RFC 822.  My reasoning is that we ought to not confuse the
>bounds of what is being certified.  As a CA, I can readily validate a pure
>user_name@FQDN syntax, but when someone includes a parenthetical comment,
>it makes the verification harder and subject to errors.

I completely disagree. The RFC 822 syntax is absolutely clear that the
other stuff is a comment with no relation to the deliverability of the
address. It doesn't make "the verification harder and subject to errors":
it is *never verified* because it can't be.

>  A user seeing such
>a name is likely to pay more attention to a more human-readable part of the
>name, which may not be verified, while software is almost certain to pay
>attention to the more tightly constrained synatx that actually supports
>addressing of the message.

Possibly true. However, a user might also believe that the bare email
address is valid because the cert is value, when in fact the address was
only valid for the five minutes in which the CA checked it. Or the user
might believe that "[email-masked]" means Joe is associated with IBM, even
though he is no longer. And so on and so on. This is a user interface
issue, not a reliability issue. And you'll have the same issue with many
kinds of otherNames, uniformResourceIdentifiers, and iPAddresses (for IPv6).

>  Thus a mismatch may occur if a secure e-mail
>package or IPsec implementation validates based on the more restricted
>syntax, but the user thinks in terms of the comment part of the name.

Well, they shouldn't do that, should they? A comment in the draft would fix
that.

You are making the field less friendly for fear of confusing people, but
there are lots of room for other confusions in DirectoryString. I'd say
leave it as it is and put a note in the text saying "nothing other than
the address portion of the name can be verified based on the definition in
RFC 822" and leave it at that.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Tue, 3 Mar 1998 19:10:49 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

I am not a lawyer, and I don't claim to appreciate fully the legal issues
surrounding a CA and their obligations, in either general or specific cases.

The arguments put forth in deprecating multiple (independent) certification
of a single keypair are reasonable, but I point out that they belie the
purported nature of X.509 certificates as "identity certificates" (that is,
to bind the key simply to a warm body able to appear court.)  Rather, they
become attribute certificates, attesting to (say) primary residence, not so
much for distinguishing among similarly named individuals but now assuming
a free standing legal significance.  The certificate no longer attests only
that a given document was signed by me, it can now be used as evidence that
I reside at location X, *independent* of my use of the key at all.  While I
can appreciate the utility of such usage, I question where the boundaries lie.

Allowing independent certifications on a single key can be compared to the
use of both a "Diner's Club" card, and an "Auto Club" card.  If stranded
in a broken car, the tow truck operator will be uninterested in my Diner's
Club card, whether valid or not.  They want my Auto Club card, and want to
be assured that it is considered to be in effect at the time of transaction.

True, a key compromise on one should affect all certificates over that key.
If one certificate is not revoked, but should have been, it could just as
easily be the certificate appropriate to the transaction as the one not.

I wonder if the central issue is primarily one of protocol.  The RP must
(somehow) obtain not just *any* certificate validating my ownership of the
key in question, but the certificate indicating I satisfy the role that the
relying party expects for a signatory to the given transaction.  (In pure
"Identity Cert" principle, any such cert should just identify "me" to a
given degree of assurance, and then the relying party should use that fact
to determine if, within their own domain, this "me" has the required role.)

Again, I am not really advocating such usage, but I wonder if the restriction
is simply one of cert retrieval complexity, or if such usage would really
"break X.509".  Has the structure so embedded these legal implications?

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 3 Mar 1998 13:20: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other   extensions
Comments: To: [email-masked]
To: [email-masked]

Hoyt,

We agree exactly on the comment part of an RFC 822 name.  Now if nobody
disagrees, we can kill this part!

Sorry I can't make Snomass; our only skiing so far this year has been 3
days at Killington, but it was nice.  The CTO job is keeping me very busy,
and I get to keep my other jobs too ...

Steve

Approved-By:  Peter Sylvester <[email-masked]>
Date:         Tue, 3 Mar 1998 18:56:09 +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: Peter Sylvester <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]

I am not whether the following has been discussed or not for OCSP:

Question: Is the protocol just intended to specify the communication between
a client and the well-known validation point, or is there something
to about how to find that point.

I image a possible response from the server saying, no, don't do this
here, go elsewhere, here's the 'connection info' (URL or whatever).

Peter Sylvester
EdelWeb

Approved-By:  Peter Lipp <[email-masked]>
Date:         Tue, 3 Mar 1998 17:44:53 +0100
Reply-To: Peter Lipp <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Lipp <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00D0_01BD46CC.139B75F0
Content-Type: multipart/mixed;
        boundary="----=_NextPart_000_00CE_01BD46CC.13709560"

------=_NextPart_000_00CE_01BD46CC.13709560
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>What do others think?

I agree. One exception might be argueable: if the string in CN is =
<exactly> the same as the one between the <> or () pairs, then I =
wouldn't see any problem.

Peter

Dr. Peter Lipp
Institute for Applied Information Processing and Communications
Graz, University of Technology

------=_NextPart_000_00CE_01BD46CC.13709560
Content-Type: text/x-vcard;
        name="Peter Lipp.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
        filename="Peter Lipp.vcf"

BEGIN:VCARD
VERSION:2.1
N:Lipp;Peter;;
FN:Peter Lipp
ORG:Styria;
TITLE:
TEL;WORK;VOICE:+43 316 873 5513
TEL;HOME;VOICE:
TEL;VOICE:Graz
TEL;WORK;FAX:A-8042
ADR;WORK:;;;;;;
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:=0D=0A,  =0D=0A
EMAIL;PREF;INTERNET:[email-masked]
REV:19980303T164452Z
END:VCARD

------=_NextPart_000_00CE_01BD46CC.13709560--

------=_NextPart_000_00D0_01BD46CC.139B75F0
Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="smime.p7s"

------=_NextPart_000_00D0_01BD46CC.139B75F0--

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 3 Mar 1998 10:59:03 -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] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Paul,

I'd like to suggest that we not allow all of these representations of RFC
822 names, despite your obeservation that they are all syntactically
allowed under RFC 822.  My reasoning is that we ought to not confuse the
bounds of what is being certified.  As a CA, I can readily validate a pure
user_name@FQDN syntax, but when someone includes a parenthetical comment,
it makes the verification harder and subject to errors.  A user seeing such
a name is likely to pay more attention to a more human-readable part of the
name, which may not be verified, while software is almost certain to pay
attention to the more tightly constrained synatx that actually supports
addressing of the message.  Thus a mismatch may occur if a secure e-mail
package or IPsec implementation validates based on the more restricted
syntax, but the user thinks in terms of the comment part of the name.  I'd
like to urge more of a WISWYG approach here, even though it means
restricting the syntax to a subset of what can be expressed in 822.

What do others think?

Steve

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Tue, 3 Mar 1998 14: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: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] CMP question.
To: [email-masked]

'Certificate Management Protocols' feb. '98, says that

    'Certification may only be requested for one locally
    generated public key (for more, use separate PKIMessages)'

But the body structure

CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {
    certReq   CertRequest,
    ... }

CertRequest ::= SEQUENCE {
   ...
    certTemplate  CertTemplate,
   ... }

CertTemplate ::= SEQUENCE {
  ...
    publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
  ...}

seems to allow multiple requests for key certifications in the same
PKIMessage.

Could someone explain this to me?

- Jakob

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Tue, 3 Mar 1998 11:04:45 +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: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] caPubs-field in CertRepMessage
To: [email-masked]

to the list,

Can anyone tell me, what the intention of the field 'caPubs'
in CertRepMessage is?

  CertRepMessage ::= SEQUENCE {
      caPubs          [1] SEQUENCE SIZE (1..MAX) OF Certificate
OPTIONAL,
      response            SEQUENCE OF CertResponse
  }

- Jakob

Approved-By:  Peter Lipp <[email-masked]>
Date:         Tue, 3 Mar 1998 10:08:42 +0100
Reply-To: Peter Lipp <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Lipp <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0065_01BD468C.587C9F90
Content-Type: multipart/mixed;
        boundary="----=_NextPart_000_0063_01BD468C.586742D0"

------=_NextPart_000_0063_01BD468C.586742D0
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>Can I ask a CA to certify 10 keys, in 10 certificates, all of which =
attest=20
>to identical info? (modulo certificate id, or course.) =20

Any commercial CA would be more than happy to have you as a customer :-)

>Thoughts?

If no other privacy measures are available, this is a legitmate option.=20

Peter

------=_NextPart_000_0063_01BD468C.586742D0
Content-Type: text/x-vcard;
        name="Peter Lipp.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
        filename="Peter Lipp.vcf"

BEGIN:VCARD
VERSION:2.1
N:Lipp;Peter;;
FN:Peter Lipp
ORG:Styria;
TITLE:
TEL;WORK;VOICE:+43 316 873 5513
TEL;HOME;VOICE:
TEL;VOICE:Graz
TEL;WORK;FAX:A-8042
ADR;WORK:;;;;;;
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:=0D=0A,  =0D=0A
EMAIL;PREF;INTERNET:[email-masked]
REV:19980303T090841Z
END:VCARD

------=_NextPart_000_0063_01BD468C.586742D0--

------=_NextPart_000_0065_01BD468C.587C9F90
Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="smime.p7s"

------=_NextPart_000_0065_01BD468C.587C9F90--

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Tue, 3 Mar 1998 10:02:24 +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: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] CMP, feb, 1998
To: [email-masked]

To the list,

Having obtained 'Certificate Management Protocols' for february 1998
I find the following ASN.1 comment strange (a value of -1 to be ...):

CertResponse ::= SEQUENCE {
      certReqId           INTEGER,
      -- to match this response with corresponding request (a value
      -- of -1 is to be used if certReqId is not specified in the
      -- corresponding request)

well, the corresponding request has ASN.1 structure:

CertRequest ::= SEQUENCE {
    certReqId     INTEGER,
    certTemplate  CertTemplate,
    controls      Controls OPTIONAL }

where certReqId is NOT optional. Did I miss something?

- Jakob

Approved-By:  David Hemsath <[email-masked]>
Date:         Mon, 2 Mar 1998 18:19: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: David Hemsath <[email-masked]>
Subject:      [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki3cmp-07.txt
To: [email-masked]

                   Status Distribution March 02, 1998 14:46:48

The message regarding "[IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki3cmp-07.txt" sent on March 02, 1998 14:46:48 was sent by

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

Recipients

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

Status          769
Explanation     Invalid recipient

X.400 Status    769
Explanation     Error transferring to D01HUBM1/01/H/IBM mail.box; Server error: File does not exist

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Mon, 2 Mar 1998 14:35:50 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: Stefan Kelm <[email-masked]>
To: [email-masked]

Stefan,

At 06:34 PM 3/2/98 +0100, you wrote:
>Folks,
>
>I haven't had the time to browse through all the different latest drafts, I'm
>afraid. Having had some discussions concerning the German digital signature
>law, however, a question occured to me: Is a CA allowed to issue two (or
>more) certificates for a single end-entity's public key? If yes, this could
>lead to big problems, especially in terms of liability of the CA. If
>not, shouldn't this be specified somewhere?

Could you expand on the liability issues you mention regarding the issuance of
differing certificates for the same public key?  From a layman's point of
view,
of course a CA could get into trouble issuing arbitrary certificates on a
given
end-user's public key.  But, for the sake of argument, if I want the same key
to be certified by a CA in two distinct certificates, both of which contain
data that identifies me (in different ways, for different reasons,) then it
seems to be up to the relying party to check if there is a valid certificate
for that key, suitable for their purposes of identification.  (Apologies for
naive view and tortured sentence structure.)

Here is a related question (and perhaps more likely desired) : Can I ask a CA
to certify 10 keys, in 10 certificates, all of which attest to identical info?
(modulo certificate id, or course.)  My thought is, I want to use my keys very
sparingly, cycling through them so to thwart marketeers attempting to trace my
habits.  This presupposes that I, the cert-owner, control the cert that I
point
the relying party to use.

Thoughts?

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Stephen Kent <[email-masked]>
Date:         Mon, 2 Mar 1998 16:25: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Stefan,

I don't think we have any prohibitions against issuing multiple certs
against the same public key.  In fact, if the certs represent renewal
certs, I'm sure we would not preclude such actions.  Since two certs can
differ in terms of extensions, validity intervals, etc., not just in terms
of subject names, this would seem an unduly restrictive prohibition in the
general case.  Thus I suscept this is more of a policy matter for a given
CA context.

Steve

Approved-By:  Russ Housley <[email-masked]>
Date:         Sat, 28 Feb 1998 13:42:11 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

I also think OCSP should be defined in a transport independent fashion.  I
do not think it will be hard to remove the http dependencies.

Russ

At 11:50 AM 2/24/98 +0100, Peter Sylvester wrote:
>A little nit-picking:
>
>- There is a need for an 'pretty online' service to find out the
>  status of certificates. One might consider to define this service
>  without referencing to http, and then selecting http
>  as 'use of lower layers'.
>  In the actual text these things seems to be tied together.
>
>- The mentioned keyword/value pairs might be given as such
>  (using whatever textual means to describe it) but not in
>  the rather implicit way through its encoding in an http request.
>
>- The text should be written in ASCII or ISO-latin-1 (not with
>  quotes coming from some well known word-processing-$ware.)
>
>- In the description of a request, there is a definition of
>  'time' which is not used anywhere?
>
>Peter Sylvester -- EdelWeb France
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 2 Mar 1998 15:23:51 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] CMP Progression
To: [email-masked]

> From: Warwick Ford <[email-masked]>
>
> These documents will now be submitted back to the IESG with a
> recommendation for publication as RFCs specifying Proposed Standards.
>
> Congratulations to the editors for their relentless efforts to resolve the
> issues surrounding these documents!

As a member of the team that produced one of the documents, let me say
that no one is as pleased as we are to see them moving forward.

I am aware of only one remaining open issue with the CRMF document.
The registration info field defines two methods for carrying certificate
content between a Registration Agent and the CA; call them methods A and B.
CRMF currently contains no conformance requirements, thus support for
both A and B is optional.

The IESG may insist, as they have in other working groups, on minimum
conformance requirements which ensure interoperability between
PKIX-conformant clients and servers.  In the case of CRMF, such
requirements would designate either A or B (or both) as
mandatory-to-implement.

This Working Group may wish to consider whether conformance requirements
should be included in the CRMF specification, included in some other
IETF specification, or left up to community-specific profiles.  I expect
that the question will be raised by the IESG; if we wish to progress the
specification, we should have an answer ready.

Approved-By: [email-masked]
Date:         Mon, 2 Mar 1998 12:51:26 -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-07.txt
Comments: To: [email-masked]
To: [email-masked]

--NextPart

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 X.509 Public Key Infrastructure
                          Certificate Management Protocols
        Author(s)       : C. Adams, S. Farrell
        Filename        : draft-ietf-pkix-ipki3cmp-07.txt
        Pages           : 67
        Date            : 26-Feb-98

This document describes 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-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-07.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-07.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID:     <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-07.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ipki3cmp-07.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--OtherAccess--

--NextPart--

Approved-By: [email-masked]
Date:         Mon, 2 Mar 1998 18:34:22 +0100
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stefan Kelm <[email-masked]>
Subject:      [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Folks,

I haven't had the time to browse through all the different latest drafts, I'm
afraid. Having had some discussions concerning the German digital signature
law, however, a question occured to me: Is a CA allowed to issue two (or
more) certificates for a single end-entity's public key? If yes, this could
lead to big problems, especially in terms of liability of the CA. If
not, shouldn't this be specified somewhere?

Sorry if this topic already has been discussed.

Cheers,

        Stefan.

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

Approved-By:  Russ Housley <[email-masked]>
Date:         Sat, 28 Feb 1998 13:42:11 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]

I also think OCSP should be defined in a transport independent fashion.  I
do not think it will be hard to remove the http dependencies.

Russ

At 11:50 AM 2/24/98 +0100, Peter Sylvester wrote:
>A little nit-picking:
>
>- There is a need for an 'pretty online' service to find out the
>  status of certificates. One might consider to define this service
>  without referencing to http, and then selecting http
>  as 'use of lower layers'.
>  In the actual text these things seems to be tied together.
>
>- The mentioned keyword/value pairs might be given as such
>  (using whatever textual means to describe it) but not in
>  the rather implicit way through its encoding in an http request.
>
>- The text should be written in ASCII or ISO-latin-1 (not with
>  quotes coming from some well known word-processing-$ware.)
>
>- In the description of a request, there is a definition of
>  'time' which is not used anywhere?
>
>Peter Sylvester -- EdelWeb France
>

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Sun, 1 Mar 1998 11:28:11 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

At 09:16 PM 2/28/98 -0800, you wrote:
>> When an RFC822 name is encoded in SubjectAltName (or one of its
>> equivalents), is a display name allowed as well as the base address?
>> So can I encode "Jim Schaad [[email-masked]]", or can I just
>> encode [email-masked]?

Note that your example should be:
     Jim Schaad <[email-masked]>
With <> instead of [].

Since the rfc822Namein SubjectAltName is expressed as an IA5String, I would
hope that any mailbox syntax that used only the IA5String character set
would be acceptable. And, since all valid 822 addresses must be in the
ASCII character set, this should include all three acceptable formats:
     [email-masked]
     Jim Schaad <[email-masked]>
     [email-masked] (Jim Schaad)

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By: [email-masked]
Date:         Sat, 28 Feb 1998 21:16:56 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

> A question was recently asked of me which I though I knew the answer
> for but cannot find any backup on this information.
>
> When an RFC822 name is encoded in SubjectAltName (or one of its
> equivalents), is a display name allowed as well as the base address?
> So can I encode "Jim Schaad [[email-masked]]", or can I just
> encode [email-masked]?   I have always assumed until I was asked
> that only the latter was permitted.
>
> jim schaad
>
>

Approved-By:  Moshe Litvin <[email-masked]>
Date:         Wed, 1 Apr 1998 10:14:26 +0300
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: Moshe Litvin <[email-masked]>
Subject:      Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
Comments: To: [email-masked]
To: [email-masked]

Peter Gutmann wrote:
>
> Moshe Litvin <[email-masked]> writes:
> >Peter Gutmann wrote:
> >>Since including certain extensions like
> >>basicConstraints, keyUsage, certificatePolicies, and a few others is
> >>pointless unless they're marked critical, I'm thinking of recommending that
> >>if used, these extensions must be marked critical.  What do people think
> >>about this?
>
> >I think that this prove the point, marking an extension as critical will
> >render it useless for a lot of software, you don't want to do it unless you
> >have a VERY good reason to do so.
>
> But if an extension isn't marked critical then by implication it's marked
> useless, because an implementation is free to ignore it.  For example:

Critical does not necessary mean important. The critical flag was meant
to be a backward compatibility flag - a way to add information to a
certificate without breaking existing applications.

Unless explicitly specified an application must process any extension it
understands regardless of the criticality flag. The criticality flag is
meant only for application that does not understand the specific
extension.

>
> >I suggest the we will should say that the the basicConstraints shouldn't be
> >marked critical on a CA's certificate.
>
> will make it possible for anyone to ignore the basicConstraints.  The whole
> point of having the constraints (basic, path, policy, etc) is to place some
> limits on what can be done with a certificate, but by making these extensions
> non-critical they also become non-constraints.

Consider a basicConstraint extension with ca=TRUE and no
pathLenConstraint. This extension means no constraints at all.
The ONLY effect of marking it as critical is to stop applications that
don't recognize that extension from processing the certificate, and
since that particular extension represent no constraint - why on earth
would you want that ??

>
> PKIX part 1 requires that compliant implementations handle a number of
> important constraint extensions, so there shouldn't be any problem in
> requiring that various constraints are marked critical.  At the moment the
> handling of constraints is very haphazard, because you can just ignore
> anything you don't like (basicConstraint = non-CA, keyUsage = keyEncipherment
> only, but you can ignore that and treat it as a CA cert for keyCertSigning if
> you want because the constraint extensions aren't critical).

No, No, No. A PKIX part 1 compliant application must support the
basicConstraint extension and therefore for a compliant application
there e is no difference weather the extension is marked critical or
not. It MUST process it any way.

The whole debate is how we tell non PKIX compliant applications that
don't support it if they can use the certificate or not.

> An alternative to this is to have a cert.policy which requires that all
> constraint extensions be processed and enforced, whether they're marked
> critical or not.

This IS the situation.

Moshe
--
-----------------------------------------------------------------------
Moshe Litvin                    Check Point Software Technologies Ltd.

[email-masked]            Tel:   +972-3-753-4601 (972-3-753-4555)
                                Fax:   +972-3-575-9256
-----------------------------------------------------------------------

Approved-By: [email-masked]
Date:         Tue, 31 Mar 1998 09:42:25 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
To: [email-masked]

--simple boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Description: "cc:Mail Note Part"

Moshe Litvin <[email-masked]> writes:
>Peter Gutmann wrote:
>>Since including certain extensions like
>>basicConstraints, keyUsage, certificatePolicies, and a few others is
>>pointless unless they're marked critical, I'm thinking of recommending that
>>if used, these extensions must be marked critical.  What do people think
>>about this?

>I think that this prove the point, marking an extension as critical will
>render it useless for a lot of software, you don't want to do it unless you
>have a VERY good reason to do so.

But if an extension isn't marked critical then by implication it's marked
useless, because an implementation is free to ignore it.  For example:

>I suggest the we will should say that the the basicConstraints shouldn't be
>marked critical on a CA's certificate.

will make it possible for anyone to ignore the basicConstraints.  The whole
point of having the constraints (basic, path, policy, etc) is to place some
limits on what can be done with a certificate, but by making these extensions
non-critical they also become non-constraints.  It's a bit like the
recommended 130kmh speed limit on autobahns (which are treated like
non-critical extensions), the theoretical limit is 130, you're sitting there
doing 180, and you're getting overtaken by Porsches and whatnot doing about
250.  It's not until you actually get police enforcing things (about 100m past
the Austrian border) that everyone slows down, and you get the effect of a
critical extension where you obey the rules or else.

PKIX part 1 requires that compliant implementations handle a number of
important constraint extensions, so there shouldn't be any problem in
requiring that various constraints are marked critical.  At the moment the
handling of constraints is very haphazard, because you can just ignore
anything you don't like (basicConstraint = non-CA, keyUsage = keyEncipherment
only, but you can ignore that and treat it as a CA cert for keyCertSigning if
you want because the constraint extensions aren't critical).  What would be
better is a requirement like:

  If the cert is a v3 cert then it must contain at least a basicConstraints
  extension, and if it contains <any certificate constraint extensions> then
  these must be marked critical.

or something similar.  Since an implementation must be able to handle these
extensions to comply with the standard, there shouldn't be any problems with
marking them critical.

An alternative to this is to have a cert.policy which requires that all
constraint extensions be processed and enforced, whether they're marked
critical or not.  Unfortunately in order to avoid allowing implementations to
ignore it if they feel so inclined, you need to mark it critical...

Peter.

--simple boundary--

Approved-By: [email-masked]
Date:         Tue, 31 Mar 1998 09:42:25 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Gutmann <[email-masked]>
Subject:      Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
Comments: To: [email-masked]
To: [email-masked]

Moshe Litvin <[email-masked]> writes:
>Peter Gutmann wrote:
>>Since including certain extensions like
>>basicConstraints, keyUsage, certificatePolicies, and a few others is
>>pointless unless they're marked critical, I'm thinking of recommending that
>>if used, these extensions must be marked critical.  What do people think
>>about this?

>I think that this prove the point, marking an extension as critical will
>render it useless for a lot of software, you don't want to do it unless you
>have a VERY good reason to do so.

But if an extension isn't marked critical then by implication it's marked
useless, because an implementation is free to ignore it.  For example:

>I suggest the we will should say that the the basicConstraints shouldn't be
>marked critical on a CA's certificate.

will make it possible for anyone to ignore the basicConstraints.  The whole
point of having the constraints (basic, path, policy, etc) is to place some
limits on what can be done with a certificate, but by making these extensions
non-critical they also become non-constraints.  It's a bit like the
recommended 130kmh speed limit on autobahns (which are treated like
non-critical extensions), the theoretical limit is 130, you're sitting there
doing 180, and you're getting overtaken by Porsches and whatnot doing about
250.  It's not until you actually get police enforcing things (about 100m past
the Austrian border) that everyone slows down, and you get the effect of a
critical extension where you obey the rules or else.

PKIX part 1 requires that compliant implementations handle a number of
important constraint extensions, so there shouldn't be any problem in
requiring that various constraints are marked critical.  At the moment the
handling of constraints is very haphazard, because you can just ignore
anything you don't like (basicConstraint = non-CA, keyUsage = keyEncipherment
only, but you can ignore that and treat it as a CA cert for keyCertSigning if
you want because the constraint extensions aren't critical).  What would be
better is a requirement like:

  If the cert is a v3 cert then it must contain at least a basicConstraints
  extension, and if it contains <any certificate constraint extensions> then
  these must be marked critical.

or something similar.  Since an implementation must be able to handle these
extensions to comply with the standard, there shouldn't be any problems with
marking them critical.

An alternative to this is to have a cert.policy which requires that all
constraint extensions be processed and enforced, whether they're marked
critical or not.  Unfortunately in order to avoid allowing implementations to
ignore it if they feel so inclined, you need to mark it critical...

Peter.

Approved-By: [email-masked]
Date:         Mon, 30 Mar 1998 09:52:17 +0100
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Francisco Jordan <[email-masked]>
Organization: UPC
Subject:      [IETF-PKIX] Error in draft-ietf-pkix-crmf-00.txt
To: [email-masked]

Martin,

the problem is due to the "draft-ietf-pkix-crmf-00.txt" document
in "Appendix C. ASN.1 Structures and OIDs" has an incorrect
specification for POPOSigningKey type, namely:

        POPOSigningKey ::= SEQUENCE {
                poposkInput           POPOSigningKeyInput OPTIONAL,
                algorithmIdentifier   AlgorithmIdentifier,
                signature             BIT STRING }

which conveys an ambiguity in "poposkInput" field.

Note that the same document in "5.4 Proof of Possession Syntax"
specifies a correct syntax, namely:

        POPOSigningKey ::= SEQUENCE {
                poposkInput         [0] POPOSigningKeyInput OPTIONAL,
                algorithmIdentifier     AlgorithmIdentifier,
                signature               BIT STRING }

Please fix yourself the bug and I will send you the new version
including the other stuff asap.

Best Regards,
Francisco Jordan

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 30 Mar 1998 10:14: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:      Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
Comments: To: [email-masked]
To: [email-masked]

This is somewhat tangential, but we have a case where we would like to go to an external CA to replace a certificate which was previously issued by our CA toolkit for internal use.

In other words, our PKIS CA toolkit will allow a user to set up his installation for internal use, generate certificates for servers, etc. However, the toolkit doesn't really know what the customer's organization name is, so there is no due diligence.  If and when the organization wishes to make his facilities available to the outside world, they don't want to have to reissue all of the subordinate certificates, but instead wants to have a public CA (one whose root is widely known) issue a replacement certificate.

We can issue a certificate signing request containing the public key and all of the other attributes, but we would also like to include the serial number, so that upwards references (Subject to Issuer) will be correct.  Assuming that we guarantee a machine-unique serial number, is there anything wrong with including the Serial in the attributes field in PKCS 10?

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Peter Gutmann <[email-masked]> 03/29 11:55 AM >>>
While making some long-overdue updates to the X.509 style guide, I saw that the
section on PKCS #10 use might need some corrections.  This currently says:

  According to the PKCS #10 spec, the attributes field is mandatory, so if it's
  empty it's encoded as a zero-length field.  The example however assumes that
  if there are no attributes, the field shouldn't be present, treating it like
  an OPTIONAL field.  A number of vendors conform to the example rather than
  the specification, but just to confuse the issue RSADSI, who produced PKCS
  #10, regard things the other way around, with the spec being right and the
  example being wrong.  The most obvious effect of this is that TIPEM (which
  was the only available toolkit for PKCS#10 for a long time) follows the spec
  and does it "wrong (sense #2)", whereas more recent independant
  implementations follow the example and do it "wrong (sense #1)".

  PKCS #10 also dates from the days of X.509v1 and includes references to
  obsolete and deprecated objects and data formats.  PKCS #6 extended
  certificates are a workaround for the abscence of certificate extensions in
  X.509v1 and shouldn't be used at all, and it's probably a good idea to avoid
  the use of PKCS #9 extended attributes as well (some certification request
  protocols bypass the use of PKCS #9 by wrapping extra protocol layers
  containing PKCS #9 elements around the outside of PKCS #10).  Unfortunately
  since PKCS #10 doesn't mention X.509v3 at all, there's no clear indication of
  what is and isn't valid as an attribute for X.509v3 (for example a
  GeneralName should be treated as a valid attribute, a BasicConstraint may or
  may not be treated as valid depending on the CA's certification policy, and
  an AuthorityKeyIdentifier would definitely be an invalid attribute).

  To add to the confusion, the S/MIME certificate request draft states that
  X.509v3 extensions used as attributes in a certification request should be
  encoded as a SEQUENCE OF extensions wrapped up in a PKCS #9 attribute
  identified by the OID { pkcs-9 14 }.

Unfortunately I haven't been able to find anything which clears up the
confusion over either the encoding of the attributes field, or the use of
X.509v3 extensions.  Is anyone aware of implementations which still encode the
attributes as if they were declared 'Attributes OPTIONAL'?  Everything I've
seen recently always encodes the attributes as a zero-length field, however
being outside the US I can't check what most of the commonly-available
implementations do.  Should I recommend that they always be encoded as per the
spec and drop the section on encoding as per the example entirely?  (NB: I know
what the official position on this is, what I'd like to know is what it's like
in practice).

The other area of confusion is what's in the attributes.  PKCS #10 still refers
to the deprecated PKCS #6 extended certificates, as well as PKCS #9 extended
attributes, but not X.509v3 attributes/extensions which would probably be more
useful.  If I could get some indication of usage of X.509v3 attributes in a
certification request I'd like to add some comments on it to the guide -
because PKCS #10 predates the various v3 attributes you often have to resort to
guesswork to find out what is and isn't acceptable.  Are the comments in the
text above appropriate?  How should X.509v3 attributes be specified, as per the
S/MIME draft or directly as attributes (without the PKCS #9 wrapping)?  What
attributes are valid?  What ones are used in practice?

On the subject of extensions, the guide currently makes some rather vague
comments about handling extensions.  Looking through the X.509v3, S/MIME, and
PKIX cert-related drafts, I've noticed that the recommendations in there about
handling the critical flag are even more vague, since if the critical flag
isn't set most of the extensions are meant to be of an advisory nature only.
This means that an implementation could conceivably handle them with:

 1. If extension is critical and unrecognised, cert = invalid.
 2. If extension is noncritical, ignore it.

which relegates all noncritical extensions to communicating the message "I'm
only including this to bloat up the cert" (very few of the certs I've got have
their extensions marked as critical, in playing with MSIE and Netscape I've
found that doing this renders some certs unusable by both browsers).  For
instance consider the <anonymous CA> root cert, which is marked, via a keyUsage
extension, as being for cert and CRL signing only.  Since it's non-critical,
I'm free to ignore this and use it for key exchange, encryption, and whatever
else I please.

The problem lies in the nature of the critical flag (and I know this has been
debated before, but it was never really resolved).  At the moment it's used as:

 Critical = you must process this extension
 Non-critical = you don't have to process this extension

However "you don't have to process this extension" leaves implementors free to
either process it anyway or ignore it.  What complicates this issue is that
various standards leave the question of criticality up to implementors ("it
would be cool if you made this critical, but don't like, feel any pressure to
do so", or words to that effect).  Since including certain extensions like
basicConstraints, keyUsage, certificatePolicies, and a few others is pointless
unless they're marked critical, I'm thinking of recommending that if used,
these extensions must be marked critical.  What do people think about this?

Peter.

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 30 Mar 1998 09:56: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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] [CERT-TALK] Subject line tag
To: [email-masked]

I strongly agree.  I've been nailed a couple of times, on this list and
elsewhere. So have others on this list. It's embarrassing, to say the least.

And while were at it, could they PLEASE stop modifying the text type from
quoted-printable to 8-bit? There is no justification for doing so, and
it forces me to manually insert carriage returns in every line.

Bob

>Far worse, for me, is the substitution of the list in the Reply-to field,
>which causes extra manual effort to reply to the sender of a message, and
>has tricked numerous people into sending to the list when they meant to
>reply to the sender privately, since before it was reconfigured you could
>simply reply-to-sender or reply-to-all depending on whether or not you
>wanted the list involved.
>
>I took this up privately with the list administrators, but they disagreed.
>Since no one else seemed to have a problem, I let it drop, but maybe there's
>some interest in this also...
>
>brian
>
>Brian Thomas, CISSP - Distributed Systems Architect  [email-masked]
>Southwestern Bell                                    [email-masked]
>One Bell Center,  Room 34G3                          Tel: 314 235 3141
>St. Louis, MO 63101                                  Fax: 314 235 0162
>
>
>
>> I agree with Michael, and wonder if the configuration of the PKIX list
>> server could be modified to stop putting this annoying chaff in it's
>> subject lines.
>>
>> The response time of the new list server is great, but it's munging of
>> email header fields is annoying.  Can we keep the horsepower and ditch
>> the twiddling?

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  Moshe Litvin <[email-masked]>
Date:         Mon, 30 Mar 1998 09:46:23 +0300
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: Moshe Litvin <[email-masked]>
Subject:      Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
To: [email-masked]

Peter Gutmann wrote:

> Since including certain extensions like
> basicConstraints, keyUsage, certificatePolicies, and a few others is pointless
> unless they're marked critical, I'm thinking of recommending that if used,
> these extensions must be marked critical.  What do people think about this?

In the same message he also wrote:

>  (very few of the certs I've got have
> their extensions marked as critical, in playing with MSIE and Netscape I've
> found that doing this renders some certs unusable by both browsers).

I think that this prove the point, marking an extension as critical will
render it useless for a lot of software, you don't want to do it unless
you have a VERY good reason to do so.

About the basicConstraints extension (from pkix-ipki-part1-07)

  This profile requires the use of this extension, and it shall always
  be critical for CA certificates.

Suppose we have an application that does not understand that extension,
therefore he must assume that every certificate can act as a CA
certificate and validate other certificate. It now gets a certificate
with a basicConstraints extension with cA=TRUE and no pathLenConstraint,
which means that it is a CA certificate with no limit on the number of
CA certificate that can follows. It exactly what the application assumed
about the certificate but it can't use it because the extension was
marked critical.

We really want to stop an application from using a non-CA certificate as
a CA certificate, but to do that we must put the critical extension on
the end entity extension.

I suggest the we will should say that the the basicConstraints shouldn't
be marked critical on a CA's certificate.

Moshe
--
-----------------------------------------------------------------------
Moshe Litvin                    Check Point Software Technologies Ltd.

[email-masked]            Tel:   +972-3-753-4601 (972-3-753-4555)
                                Fax:   +972-3-575-9256
-----------------------------------------------------------------------

Approved-By:  "Pawluk, Jean" <[email-masked]>
Date:         Sun, 29 Mar 1998 17:03:32 -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: "Pawluk, Jean" <[email-masked]>
Subject:      [IETF-PKIX] PLEASE FIX
To: [email-masked]

Would whoever is sending mail to :

  [email-masked]

  [email-masked]

  fou                      at novell.com
  allen long           at novell.com

  [email-masked]

PLEASE remove these people from your email lists or forwarders since
they are not on the IETF-PKIX mailing list.  Thier address are invalid
and are returning numerous mail errors to the PKIX mailbox.

 Thanks in advance,

 Jean

Some of  details extracted from the mail error messages
----------------------------------------------------------------------
--> Error description:
Error-For:  [email-masked]
Error-Code: 0
Error-Text: 550 User unknown

----------------------------------------------------------------------
     ----- The following addresses had permanent fatal errors -----
<[email-masked]>
    (expanded from: <[email-masked]>)
----------------------------------------------------------------------
The mail you sent could not be delivered to:

fou

The user/address is either incorrect or no longer valid in Novell's mail
system.  Please check the address and resend.
----------------------------------------------------------------------
The mail you sent could not be delivered to:

allen_long

The user/address is either incorrect or no longer valid in Novell's mail
system.  Please check the address and resend.
----------------------------------------------------------------------
   ----- The following addresses had permanent fatal errors -----
<[email-masked]>
    (expanded from: <[email-masked]>)

Approved-By: [email-masked]
Date:         Sun, 29 Mar 1998 10:55:23 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Gutmann <[email-masked]>
Subject:      [IETF-PKIX] Questions about PKCS #10 and cert extensions
To: [email-masked]

While making some long-overdue updates to the X.509 style guide, I saw that the
section on PKCS #10 use might need some corrections.  This currently says:

  According to the PKCS #10 spec, the attributes field is mandatory, so if it's
  empty it's encoded as a zero-length field.  The example however assumes that
  if there are no attributes, the field shouldn't be present, treating it like
  an OPTIONAL field.  A number of vendors conform to the example rather than
  the specification, but just to confuse the issue RSADSI, who produced PKCS
  #10, regard things the other way around, with the spec being right and the
  example being wrong.  The most obvious effect of this is that TIPEM (which
  was the only available toolkit for PKCS#10 for a long time) follows the spec
  and does it "wrong (sense #2)", whereas more recent independant
  implementations follow the example and do it "wrong (sense #1)".

  PKCS #10 also dates from the days of X.509v1 and includes references to
  obsolete and deprecated objects and data formats.  PKCS #6 extended
  certificates are a workaround for the abscence of certificate extensions in
  X.509v1 and shouldn't be used at all, and it's probably a good idea to avoid
  the use of PKCS #9 extended attributes as well (some certification request
  protocols bypass the use of PKCS #9 by wrapping extra protocol layers
  containing PKCS #9 elements around the outside of PKCS #10).  Unfortunately
  since PKCS #10 doesn't mention X.509v3 at all, there's no clear indication of
  what is and isn't valid as an attribute for X.509v3 (for example a
  GeneralName should be treated as a valid attribute, a BasicConstraint may or
  may not be treated as valid depending on the CA's certification policy, and
  an AuthorityKeyIdentifier would definitely be an invalid attribute).

  To add to the confusion, the S/MIME certificate request draft states that
  X.509v3 extensions used as attributes in a certification request should be
  encoded as a SEQUENCE OF extensions wrapped up in a PKCS #9 attribute
  identified by the OID { pkcs-9 14 }.

Unfortunately I haven't been able to find anything which clears up the
confusion over either the encoding of the attributes field, or the use of
X.509v3 extensions.  Is anyone aware of implementations which still encode the
attributes as if they were declared 'Attributes OPTIONAL'?  Everything I've
seen recently always encodes the attributes as a zero-length field, however
being outside the US I can't check what most of the commonly-available
implementations do.  Should I recommend that they always be encoded as per the
spec and drop the section on encoding as per the example entirely?  (NB: I know
what the official position on this is, what I'd like to know is what it's like
in practice).

The other area of confusion is what's in the attributes.  PKCS #10 still refers
to the deprecated PKCS #6 extended certificates, as well as PKCS #9 extended
attributes, but not X.509v3 attributes/extensions which would probably be more
useful.  If I could get some indication of usage of X.509v3 attributes in a
certification request I'd like to add some comments on it to the guide -
because PKCS #10 predates the various v3 attributes you often have to resort to
guesswork to find out what is and isn't acceptable.  Are the comments in the
text above appropriate?  How should X.509v3 attributes be specified, as per the
S/MIME draft or directly as attributes (without the PKCS #9 wrapping)?  What
attributes are valid?  What ones are used in practice?

On the subject of extensions, the guide currently makes some rather vague
comments about handling extensions.  Looking through the X.509v3, S/MIME, and
PKIX cert-related drafts, I've noticed that the recommendations in there about
handling the critical flag are even more vague, since if the critical flag
isn't set most of the extensions are meant to be of an advisory nature only.
This means that an implementation could conceivably handle them with:

 1. If extension is critical and unrecognised, cert = invalid.
 2. If extension is noncritical, ignore it.

which relegates all noncritical extensions to communicating the message "I'm
only including this to bloat up the cert" (very few of the certs I've got have
their extensions marked as critical, in playing with MSIE and Netscape I've
found that doing this renders some certs unusable by both browsers).  For
instance consider the <anonymous CA> root cert, which is marked, via a keyUsage
extension, as being for cert and CRL signing only.  Since it's non-critical,
I'm free to ignore this and use it for key exchange, encryption, and whatever
else I please.

The problem lies in the nature of the critical flag (and I know this has been
debated before, but it was never really resolved).  At the moment it's used as:

 Critical = you must process this extension
 Non-critical = you don't have to process this extension

However "you don't have to process this extension" leaves implementors free to
either process it anyway or ignore it.  What complicates this issue is that
various standards leave the question of criticality up to implementors ("it
would be cool if you made this critical, but don't like, feel any pressure to
do so", or words to that effect).  Since including certain extensions like
basicConstraints, keyUsage, certificatePolicies, and a few others is pointless
unless they're marked critical, I'm thinking of recommending that if used,
these extensions must be marked critical.  What do people think about this?

Peter.

Approved-By:  Andy Nourse <[email-masked]>
Date:         Fri, 27 Mar 1998 17:21: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: Andy Nourse <[email-masked]>
Subject:      [IETF-PKIX] Archives?
To: [email-masked]

Where is this list archived?
The location in the homepage isn't it.

Andy Nourse - Cisco Systems

Approved-By:  Paul Koning <[email-masked]>
Date:         Fri, 27 Mar 1998 17:17: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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] [CERT-TALK] Subject line tag
To: [email-masked]

>>>>> "Brian" == Brian M Thomas <[email-masked]> writes:

 Brian> Far worse, for me, is the substitution of the list in the
 Brian> Reply-to field, which causes extra manual effort to reply to
 Brian> the sender of a message, and has tricked numerous people into
 Brian> sending to the list when they meant to reply to the sender
 Brian> privately, since before it was reconfigured you could simply
 Brian> reply-to-sender or reply-to-all depending on whether or not
 Brian> you wanted the list involved.

 Brian> I took this up privately with the list administrators, but
 Brian> they disagreed.  Since no one else seemed to have a problem, I
 Brian> let it drop, but maybe there's some interest in this also...

YES!

This is the only mailer I've ever seen that does this and it's really
annoying.

        paul

Approved-By:  "Brian M. Thomas" <[email-masked]>
Date:         Fri, 27 Mar 1998 15:44: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] [CERT-TALK] Subject line tag
To: [email-masked]

Far worse, for me, is the substitution of the list in the Reply-to field,
which causes extra manual effort to reply to the sender of a message, and
has tricked numerous people into sending to the list when they meant to
reply to the sender privately, since before it was reconfigured you could
simply reply-to-sender or reply-to-all depending on whether or not you
wanted the list involved.

I took this up privately with the list administrators, but they disagreed.
Since no one else seemed to have a problem, I let it drop, but maybe there's
some interest in this also...

brian

Brian Thomas, CISSP - Distributed Systems Architect  [email-masked]
Southwestern Bell                                    [email-masked]
One Bell Center,  Room 34G3                          Tel: 314 235 3141
St. Louis, MO 63101                                  Fax: 314 235 0162

> I agree with Michael, and wonder if the configuration of the PKIX list
> server could be modified to stop putting this annoying chaff in it's
> subject lines.
>
> The response time of the new list server is great, but it's munging of
> email header fields is annoying.  Can we keep the horsepower and ditch
> the twiddling?
>
>
>
> ----- Begin Included Message -----
>
> To: [email-masked]
> Subject: Re: [CERT-TALK] Subject line tag
> Date: Fri, 27 Mar 1998 08:31:26 -0800
> From: Michael Helm <[email-masked]>
>
> > > I wonder if Cert Talk subscribers, like the E-CARM list, could tag their
> > > subject lines (as above) to help us all manage our in-boxes?
>
> Please, NO!  Don't fill the most significant bits of the
> subject line with chaff (unless you have a secret message
> in there you want me to look for).  If you need something
> to sort on, you _can_ use the information you already have; I suggest
> the first line:
>
>   From [email-masked] ...
> but the to: & cc: lines may work.
>
> There's nothing sillier than a folder of mail like this:
>
> ssh:fionn% scan +ECARM | tail
>  268  03/25 Ben Wright         [E-CARM] Making PKI signatues legal<<The US Gene
>  269  03/26 Ed Gerck           Re: [E-CARM] Making PKI signatues legal<<On Wed,
>  270  03/27*Self <Single-user  Re: [E-CARM] Making PKI signatues legal<<Date se
>  271  03/25 Judie Mulholland   [E-CARM] What's New in The 2BGuide<<fyi/j <snip>
>  272  03/26 pj ponder          [E-CARM] Incorrect attribution here in one of my
>  273  03/26 "William H. Geige  [E-CARM] Failed signature<<- -----BEGIN PGP SIGN
>  274  03/26 Judie Mulholland   Re: [E-CARM] Failed signature<<there is somethin
>  275  03/26 matthew@nablewest  Re: [E-CARM] Failed signature<<Dear Sirs- I too
>  276  03/26 listmanager@orang  [E-CARM] Call for Founders: Digital Bearer Settl
>  277  03/27 Judie Mulholland   [E-CARM] TKR-NEWSLETTER<<fyi/j - ---------- Forw
>
> It's a petty annoyance, but it's an annoyance; in a busy list
> I don't want to be scanning that useless tag all the time when
> making the decision about whether or not this message is something
> I should read.
>
> ----- End Included Message -----
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 27 Mar 1998 14:00:24 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] [CERT-TALK] Subject line tag
To: [email-masked]

I agree with Michael, and wonder if the configuration of the PKIX list
server could be modified to stop putting this annoying chaff in it's
subject lines.

The response time of the new list server is great, but it's munging of
email header fields is annoying.  Can we keep the horsepower and ditch
the twiddling?

----- Begin Included Message -----

To: [email-masked]
Subject: Re: [CERT-TALK] Subject line tag
Date: Fri, 27 Mar 1998 08:31:26 -0800
From: Michael Helm <[email-masked]>

> > I wonder if Cert Talk subscribers, like the E-CARM list, could tag their
> > subject lines (as above) to help us all manage our in-boxes?

Please, NO!  Don't fill the most significant bits of the
subject line with chaff (unless you have a secret message
in there you want me to look for).  If you need something
to sort on, you _can_ use the information you already have; I suggest
the first line:

  From [email-masked] ...
but the to: & cc: lines may work.

There's nothing sillier than a folder of mail like this:

ssh:fionn% scan +ECARM | tail
 268  03/25 Ben Wright         [E-CARM] Making PKI signatues legal<<The US Gene
 269  03/26 Ed Gerck           Re: [E-CARM] Making PKI signatues legal<<On Wed,
 270  03/27*Self <Single-user  Re: [E-CARM] Making PKI signatues legal<<Date se
 271  03/25 Judie Mulholland   [E-CARM] What's New in The 2BGuide<<fyi/j <snip>
 272  03/26 pj ponder          [E-CARM] Incorrect attribution here in one of my
 273  03/26 "William H. Geige  [E-CARM] Failed signature<<- -----BEGIN PGP SIGN
 274  03/26 Judie Mulholland   Re: [E-CARM] Failed signature<<there is somethin
 275  03/26 matthew@nablewest  Re: [E-CARM] Failed signature<<Dear Sirs- I too
 276  03/26 listmanager@orang  [E-CARM] Call for Founders: Digital Bearer Settl
 277  03/27 Judie Mulholland   [E-CARM] TKR-NEWSLETTER<<fyi/j - ---------- Forw

It's a petty annoyance, but it's an annoyance; in a busy list
I don't want to be scanning that useless tag all the time when
making the decision about whether or not this message is something
I should read.

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

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Fri, 27 Mar 1998 09:32:59 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
Subject:      Re: [IETF-PKIX] Patent 5699431
To: [email-masked]

"David P. Kemp" writes:
> > From: "Perry E. Metzger" <[email-masked]>
> >
> > I'd say it is. The document is supposed to be self contained to some
> > extent. If you print it and get on an airplane to read, is it too much
> > to ask that a paragraph be there telling you why you would care about
> > this mysterious patent number?
>
>
> I apologize for the flip response.  Of course it would be helpful to
> include a sentence referring to the subject matter of the patent,
> something like "partitioning of revocation information".   But
> bibliographic references in general do not include abstracts, just
> sufficient information for the reader to fetch the information being
> referenced.

Actually, bibliographic references DO contain a micro-abstract: the
name of the paper in question, which is usually suggestive. A patent
number is *not* suggestive, however, and contains far less information
than the name of a paper would.

Perry

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 27 Mar 1998 08:51:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      [IETF-PKIX] Patent 5699431
To: [email-masked]

> From: "Perry E. Metzger" <[email-masked]>
>
> I'd say it is. The document is supposed to be self contained to some
> extent. If you print it and get on an airplane to read, is it too much
> to ask that a paragraph be there telling you why you would care about
> this mysterious patent number?

I apologize for the flip response.  Of course it would be helpful to
include a sentence referring to the subject matter of the patent,
something like "partitioning of revocation information".   But
bibliographic references in general do not include abstracts, just
sufficient information for the reader to fetch the information being
referenced.

I suspect that the lack of explanation is due to the fact that
including the patent abstract verbatim in the RFC might be viewed as
too wordy, and attempting to condense or paraphrase it might have legal
implications, or stir up debate over whether the proposed text is an
accurate summary of the claims.

Approved-By: [email-masked]
Date:         Thu, 26 Mar 1998 22:01:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA4OjIxOjE3UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBbSUVURi1QS0lYXSBNZXNzYWdlIFVuZGVsaXZl
cmFibGUgdG8gY2M6TWFpbA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLQ0K

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogUG9zdG1hc3RlciBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA3OjE0OjM2UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBbSUVURi1QS0lYXSBNZXNzYWdlIFVuZGVsaXZl
cmFibGUgdG8gY2M6TWFpbA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLQ0K

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authoriz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authoriz"

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogUG9zdG1hc3RlciBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_de~1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_de~1"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA2OjIzOjQ0UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBSZTogW0lFVEYtUEtJWF0gQ29tbWVudHMgb24g
RHJhZnQgQ01DLTAwDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tDQo=

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Author~1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Author~1"

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogbW15ZXJzQHZlcmlzaWduLmNvbV9hdF9J
TlRFUk5FVCBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov

Jim,

Thanks for taking the time to thoroughly review these drafts.  They help
considerably in moving the work products forward.  Some responses to your
comments:

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of Jim Schaad (Exchange)
> Sent: Wednesday, March 25, 1998 12:33 PM
> To: [email-masked]
> Subject: [IETF-PKIX] Comments on Draft CMC-00
>
>
> This is my first cut at comments about the CMC draft.  I think this still
> needs some work to make it usable in a general case solution.  I have many
> fewer comments on this draft at this point because a large point of it
> depends on getting clarifications for CRMF and CMMF first.

Agree.

>
> 1.  Section 3 - I don't think it is correct to call this a new CMS content
> type.  You are not defining this in the CMS specifiction.  Please use the
> sentence "This document defines a new content type PKIDATA.  This content
> type is used as an encapulsated content within the CMS security
> framework."

OK.

>
> 2.  Section 3.1, paragraph 2 -- I think you should really refer to this as
> "the familiar CMS (formerly PKCS7) degerate".

OK.

>
> 3.  Section 3.1 -- Please re-define id-pkiData in this section rather than
> puttin in the reference to PKIXCERT.

OK.

>
> 4.  Section 4.1, paragraph 3 -- The use of MailListKeyIdentifier in this
> draft should be strongly discuraged.  This is for sending
> encrypted messages
> to a DL and MUST NOT be used for PKI work.

Mailing lists could be used to broadcast revocation information and CA key
updates.

>
> 5.  Section 4.2 - Since we are using CMS as the basis of the
> Crypto in this
> document.  Please change the reference of how signatures and key
> exchange is
> to be done from the PKIXCERT documents to the CMS document.  I
> don't want to
> have to have a CMS implemention with two different types of
> algorithms just
> because the two documents are not in 100% agreement.

This makes sense.  However we should make certain that both works are
aligned since it affects interoperability in the more general case.

>
> 6.  Section 4.4, paragraph 2 - The procedure in the second paragraph not
> very clear. I see nothing in section 4.3 about enveloping as an
> id-pKIData.
> It discusses EnvelopedData and SignedData but not PKIdata -- did
> you mean a
> different section?

The phrase " . . . as defined in section 4.3 . . ." should be deleted.  The
third paragraph in this section speaks to the requirements directly.

>
> 7.  Section 4.4, paragraph 3 - Change the section reference from
> 5.3 to 4.3

OK.

>
> 8.  Section 4.4 in the Encryption Option 1:  (I may have mislead
> you on this
> one)  It should be as follows:
>         signedData.AuthencatedAttributes.contentType  <- id-envelopedData
>         signedData.AuthencatedAttributes.contentHint   <- id-pkiData

OK.

>
> 9. Section 4.5, paragraph 2, bullet 1:  This should be refering to the
> content-hint attribute not the content-type attribute.  This is
> the correct
> property to say what the innermost content is.  Signature validation will
> fail if you change the content-type attribute.

OK.

>
> 10.  Section 4.8.1 paragraph 2 - In the last sentence I am not sure if you
> really mean that the subject name should be encoded as an empty
> sequence or
> as a missing property.  Which do you mean?

Empty sequence.  The subject Name is not OPTIONAL in a PKCS10:

CertificationRequestInfo ::= SEQUENCE {
  version Version,
  subject Name,
  subjectPublicKeyInfo SubjectPublicKeyInfo,
  attributes [0] IMPLICIT Attributes }

>
> 11.  Section 4.8.5 - Should GetCert have a mode which returns the chain of
> certificates rather than just a single certificate.

Sending back a chain is implied by specification of CertRep as a response
which does accomodate sending back the chain.  CMC currently reads " . . . a
SignedData response containing the requested certificate . . .".  I'll add
"As noted in CMMF, this response MUST contain a single certificate and
SHOULD include other certificates which link the issuer to higher level
certification authorities."

>
> 12. Section 4.8.7 - I don't care if the mesage format for a RevReq is not
> covered by CMS -- can we still state something good here about how it is
> sent to the server and the server recognizes this?  The concept of local
> implementation does not help the world with internet access, just small
> conclaves.

In re-reading this, I agree that the sentence "The structure of an unsigned
. . . RevReq . . . is a matter of local implementation." is too loose to
ensure interoperability.  It's probably best to clarify this text by cases:

1.  The use of CMS in the case of RA-authenticated revocation request is
clear cut.

2.  For the case of a end-user initiated revocation request in instances
when the end-entity's private key is reliable and available, CMS is equally
useful to authenticate the request.

3.  It is the case where either the end-entity's private key is either
unreliable (e.g. compromise) or not available (e.g. token broke, forgot
password, etc.).  As a strawman I would propose specification of an
unencapsulated CertRep that SHALL contain the passphrase.

>
> 13.  General Comment:  I would like to see an additional content type
> defined which would address one of the needs that I can see.  I want to be
> able to return more than one CMMF body in a single message.  Thus
> I propose
> that we add a new message type of XX (to be assigned).  The body of this
> message type will be:
>
>         MultipleResponse ::= SEQUENCE OF ContentInfo
>
> Where one or more signed items each containing a different response may be
> included.  This will allow me to return both a CertRepContent,
> KeyRecRepContent and some additional messages as the same time in a single
> transaction.

A useful requirement, but the MultiResponse syntax should include
messageType, or are we thinking of two different encapsulation models?

>
> jim
>

Mike

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_ms~1"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_ms~1"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351b16c3.im52637j.hqrtmta1.doe.gov--

Approved-By: [email-masked]
Date:         Thu, 26 Mar 1998 20:21: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: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA3OjE0OjM2UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBbSUVURi1QS0lYXSBNZXNzYWdlIFVuZGVsaXZl
cmFibGUgdG8gY2M6TWFpbA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLQ0K

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogUG9zdG1hc3RlciBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA2OjIzOjQ0UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBSZTogW0lFVEYtUEtJWF0gQ29tbWVudHMgb24g
RHJhZnQgQ01DLTAwDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tDQo=

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authoriz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authoriz"

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogbW15ZXJzQHZlcmlzaWduLmNvbV9hdF9J
TlRFUk5FVCBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov

Jim,

Thanks for taking the time to thoroughly review these drafts.  They help
considerably in moving the work products forward.  Some responses to your
comments:

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of Jim Schaad (Exchange)
> Sent: Wednesday, March 25, 1998 12:33 PM
> To: [email-masked]
> Subject: [IETF-PKIX] Comments on Draft CMC-00
>
>
> This is my first cut at comments about the CMC draft.  I think this still
> needs some work to make it usable in a general case solution.  I have many
> fewer comments on this draft at this point because a large point of it
> depends on getting clarifications for CRMF and CMMF first.

Agree.

>
> 1.  Section 3 - I don't think it is correct to call this a new CMS content
> type.  You are not defining this in the CMS specifiction.  Please use the
> sentence "This document defines a new content type PKIDATA.  This content
> type is used as an encapulsated content within the CMS security
> framework."

OK.

>
> 2.  Section 3.1, paragraph 2 -- I think you should really refer to this as
> "the familiar CMS (formerly PKCS7) degerate".

OK.

>
> 3.  Section 3.1 -- Please re-define id-pkiData in this section rather than
> puttin in the reference to PKIXCERT.

OK.

>
> 4.  Section 4.1, paragraph 3 -- The use of MailListKeyIdentifier in this
> draft should be strongly discuraged.  This is for sending
> encrypted messages
> to a DL and MUST NOT be used for PKI work.

Mailing lists could be used to broadcast revocation information and CA key
updates.

>
> 5.  Section 4.2 - Since we are using CMS as the basis of the
> Crypto in this
> document.  Please change the reference of how signatures and key
> exchange is
> to be done from the PKIXCERT documents to the CMS document.  I
> don't want to
> have to have a CMS implemention with two different types of
> algorithms just
> because the two documents are not in 100% agreement.

This makes sense.  However we should make certain that both works are
aligned since it affects interoperability in the more general case.

>
> 6.  Section 4.4, paragraph 2 - The procedure in the second paragraph not
> very clear. I see nothing in section 4.3 about enveloping as an
> id-pKIData.
> It discusses EnvelopedData and SignedData but not PKIdata -- did
> you mean a
> different section?

The phrase " . . . as defined in section 4.3 . . ." should be deleted.  The
third paragraph in this section speaks to the requirements directly.

>
> 7.  Section 4.4, paragraph 3 - Change the section reference from
> 5.3 to 4.3

OK.

>
> 8.  Section 4.4 in the Encryption Option 1:  (I may have mislead
> you on this
> one)  It should be as follows:
>         signedData.AuthencatedAttributes.contentType  <- id-envelopedData
>         signedData.AuthencatedAttributes.contentHint   <- id-pkiData

OK.

>
> 9. Section 4.5, paragraph 2, bullet 1:  This should be refering to the
> content-hint attribute not the content-type attribute.  This is
> the correct
> property to say what the innermost content is.  Signature validation will
> fail if you change the content-type attribute.

OK.

>
> 10.  Section 4.8.1 paragraph 2 - In the last sentence I am not sure if you
> really mean that the subject name should be encoded as an empty
> sequence or
> as a missing property.  Which do you mean?

Empty sequence.  The subject Name is not OPTIONAL in a PKCS10:

CertificationRequestInfo ::= SEQUENCE {
  version Version,
  subject Name,
  subjectPublicKeyInfo SubjectPublicKeyInfo,
  attributes [0] IMPLICIT Attributes }

>
> 11.  Section 4.8.5 - Should GetCert have a mode which returns the chain of
> certificates rather than just a single certificate.

Sending back a chain is implied by specification of CertRep as a response
which does accomodate sending back the chain.  CMC currently reads " . . . a
SignedData response containing the requested certificate . . .".  I'll add
"As noted in CMMF, this response MUST contain a single certificate and
SHOULD include other certificates which link the issuer to higher level
certification authorities."

>
> 12. Section 4.8.7 - I don't care if the mesage format for a RevReq is not
> covered by CMS -- can we still state something good here about how it is
> sent to the server and the server recognizes this?  The concept of local
> implementation does not help the world with internet access, just small
> conclaves.

In re-reading this, I agree that the sentence "The structure of an unsigned
. . . RevReq . . . is a matter of local implementation." is too loose to
ensure interoperability.  It's probably best to clarify this text by cases:

1.  The use of CMS in the case of RA-authenticated revocation request is
clear cut.

2.  For the case of a end-user initiated revocation request in instances
when the end-entity's private key is reliable and available, CMS is equally
useful to authenticate the request.

3.  It is the case where either the end-entity's private key is either
unreliable (e.g. compromise) or not available (e.g. token broke, forgot
password, etc.).  As a strawman I would propose specification of an
unencapsulated CertRep that SHALL contain the passphrase.

>
> 13.  General Comment:  I would like to see an additional content type
> defined which would address one of the needs that I can see.  I want to be
> able to return more than one CMMF body in a single message.  Thus
> I propose
> that we add a new message type of XX (to be assigned).  The body of this
> message type will be:
>
>         MultipleResponse ::= SEQUENCE OF ContentInfo
>
> Where one or more signed items each containing a different response may be
> included.  This will allow me to return both a CertRepContent,
> KeyRecRepContent and some additional messages as the same time in a single
> transaction.

A useful requirement, but the MultiResponse syntax should include
messageType, or are we thinking of two different encapsulation models?

>
> jim
>

Mike

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351aff3e.im52465s.hqrtmta1.doe.gov--

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Thu, 26 Mar 1998 16:47:05 -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: Tony Bartoletti <[email-masked]>
Comments: To: [email-masked]
To: [email-masked]

At 06:59 PM 3/26/98 -0500, you wrote:
>"David P. Kemp" writes:
>> > > >Note: Implementors of this protocol should consider the
applicability of
> the
>> > > following patent(s): US patent no. 5,699,431
>> >
>> > Would there be something wrong with including enough text from the
>> > patent that someone would know WHY they would want to examine it?
>>
>>
>> I guess it's too much to expect that everyone knows to get patent
>> information from http://www.patents.ibm.com/details?patent_number=5699431,
>
>I'd say it is. The document is supposed to be self contained to some
>extent. If you print it and get on an airplane to read, is it too much
>to ask that a paragraph be there telling you why you would care about
>this mysterious patent number?
>
>And what if IBM stops providing this free service?
>
>Perry

I concur.  After reading through the "20 claims" and several references,
I would still need to hire a patent lawyer to give me any clue at all.

Just what is so "innovative" here that I should move with caution in
developing, deploying (or commercializing) something.

Why do I feel like patenting the method of Pythagorus' Theorem, citing
existing patents for addition, subtraction, squares and roots used in
this novel method for determining distances?

"Note:  Implementors of mathematical functions should consider the
 applicability of the following patents:  ..."

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By: [email-masked]
Date:         Thu, 26 Mar 1998 19:14: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: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]

------ =_0_MIME_Boundary_27088.351aef82.im52390m.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDMvMjYvMTk5OCA2OjIzOjQ0UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBSZTogW0lFVEYtUEtJWF0gQ29tbWVudHMgb24g
RHJhZnQgQ01DLTAwDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tDQo=

------ =_0_MIME_Boundary_27088.351aef82.im52390m.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogbW15ZXJzQHZlcmlzaWduLmNvbV9hdF9J
TlRFUk5FVCBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_27088.351aef82.im52390m.hqrtmta1.doe.gov

Jim,

Thanks for taking the time to thoroughly review these drafts.  They help
considerably in moving the work products forward.  Some responses to your
comments:

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of Jim Schaad (Exchange)
> Sent: Wednesday, March 25, 1998 12:33 PM
> To: [email-masked]
> Subject: [IETF-PKIX] Comments on Draft CMC-00
>
>
> This is my first cut at comments about the CMC draft.  I think this still
> needs some work to make it usable in a general case solution.  I have many
> fewer comments on this draft at this point because a large point of it
> depends on getting clarifications for CRMF and CMMF first.

Agree.

>
> 1.  Section 3 - I don't think it is correct to call this a new CMS content
> type.  You are not defining this in the CMS specifiction.  Please use the
> sentence "This document defines a new content type PKIDATA.  This content
> type is used as an encapulsated content within the CMS security
> framework."

OK.

>
> 2.  Section 3.1, paragraph 2 -- I think you should really refer to this as
> "the familiar CMS (formerly PKCS7) degerate".

OK.

>
> 3.  Section 3.1 -- Please re-define id-pkiData in this section rather than
> puttin in the reference to PKIXCERT.

OK.

>
> 4.  Section 4.1, paragraph 3 -- The use of MailListKeyIdentifier in this
> draft should be strongly discuraged.  This is for sending
> encrypted messages
> to a DL and MUST NOT be used for PKI work.

Mailing lists could be used to broadcast revocation information and CA key
updates.

>
> 5.  Section 4.2 - Since we are using CMS as the basis of the
> Crypto in this
> document.  Please change the reference of how signatures and key
> exchange is
> to be done from the PKIXCERT documents to the CMS document.  I
> don't want to
> have to have a CMS implemention with two different types of
> algorithms just
> because the two documents are not in 100% agreement.

This makes sense.  However we should make certain that both works are
aligned since it affects interoperability in the more general case.

>
> 6.  Section 4.4, paragraph 2 - The procedure in the second paragraph not
> very clear. I see nothing in section 4.3 about enveloping as an
> id-pKIData.
> It discusses EnvelopedData and SignedData but not PKIdata -- did
> you mean a
> different section?

The phrase " . . . as defined in section 4.3 . . ." should be deleted.  The
third paragraph in this section speaks to the requirements directly.

>
> 7.  Section 4.4, paragraph 3 - Change the section reference from
> 5.3 to 4.3

OK.

>
> 8.  Section 4.4 in the Encryption Option 1:  (I may have mislead
> you on this
> one)  It should be as follows:
>         signedData.AuthencatedAttributes.contentType  <- id-envelopedData
>         signedData.AuthencatedAttributes.contentHint   <- id-pkiData

OK.

>
> 9. Section 4.5, paragraph 2, bullet 1:  This should be refering to the
> content-hint attribute not the content-type attribute.  This is
> the correct
> property to say what the innermost content is.  Signature validation will
> fail if you change the content-type attribute.

OK.

>
> 10.  Section 4.8.1 paragraph 2 - In the last sentence I am not sure if you
> really mean that the subject name should be encoded as an empty
> sequence or
> as a missing property.  Which do you mean?

Empty sequence.  The subject Name is not OPTIONAL in a PKCS10:

CertificationRequestInfo ::= SEQUENCE {
  version Version,
  subject Name,
  subjectPublicKeyInfo SubjectPublicKeyInfo,
  attributes [0] IMPLICIT Attributes }

>
> 11.  Section 4.8.5 - Should GetCert have a mode which returns the chain of
> certificates rather than just a single certificate.

Sending back a chain is implied by specification of CertRep as a response
which does accomodate sending back the chain.  CMC currently reads " . . . a
SignedData response containing the requested certificate . . .".  I'll add
"As noted in CMMF, this response MUST contain a single certificate and
SHOULD include other certificates which link the issuer to higher level
certification authorities."

>
> 12. Section 4.8.7 - I don't care if the mesage format for a RevReq is not
> covered by CMS -- can we still state something good here about how it is
> sent to the server and the server recognizes this?  The concept of local
> implementation does not help the world with internet access, just small
> conclaves.

In re-reading this, I agree that the sentence "The structure of an unsigned
. . . RevReq . . . is a matter of local implementation." is too loose to
ensure interoperability.  It's probably best to clarify this text by cases:

1.  The use of CMS in the case of RA-authenticated revocation request is
clear cut.

2.  For the case of a end-user initiated revocation request in instances
when the end-entity's private key is reliable and available, CMS is equally
useful to authenticate the request.

3.  It is the case where either the end-entity's private key is either
unreliable (e.g. compromise) or not available (e.g. token broke, forgot
password, etc.).  As a strawman I would propose specification of an
unencapsulated CertRep that SHALL contain the passphrase.

>
> 13.  General Comment:  I would like to see an additional content type
> defined which would address one of the needs that I can see.  I want to be
> able to return more than one CMMF body in a single message.  Thus
> I propose
> that we add a new message type of XX (to be assigned).  The body of this
> message type will be:
>
>         MultipleResponse ::= SEQUENCE OF ContentInfo
>
> Where one or more signed items each containing a different response may be
> included.  This will allow me to return both a CertRepContent,
> KeyRecRepContent and some additional messages as the same time in a single
> transaction.

A useful requirement, but the MultiResponse syntax should include
messageType, or are we thinking of two different encapsulation models?

>
> jim
>

Mike

------ =_0_MIME_Boundary_27088.351aef82.im52390m.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_27088.351aef82.im52390m.hqrtmta1.doe.gov--

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Thu, 26 Mar 1998 18:59:44 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
To: [email-masked]

"David P. Kemp" writes:
> > > >Note: Implementors of this protocol should consider the applicability of
 the
> > > following patent(s): US patent no. 5,699,431
> >
> > Would there be something wrong with including enough text from the
> > patent that someone would know WHY they would want to examine it?
>
>
> I guess it's too much to expect that everyone knows to get patent
> information from http://www.patents.ibm.com/details?patent_number=5699431,

I'd say it is. The document is supposed to be self contained to some
extent. If you print it and get on an airplane to read, is it too much
to ask that a paragraph be there telling you why you would care about
this mysterious patent number?

And what if IBM stops providing this free service?

Perry

Importance: Normal
Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 26 Mar 1998 15:23:51 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Draft CMC-00
To: [email-masked]

Jim,

Thanks for taking the time to thoroughly review these drafts.  They help
considerably in moving the work products forward.  Some responses to your
comments:

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of Jim Schaad (Exchange)
> Sent: Wednesday, March 25, 1998 12:33 PM
> To: [email-masked]
> Subject: [IETF-PKIX] Comments on Draft CMC-00
>
>
> This is my first cut at comments about the CMC draft.  I think this still
> needs some work to make it usable in a general case solution.  I have many
> fewer comments on this draft at this point because a large point of it
> depends on getting clarifications for CRMF and CMMF first.

Agree.

>
> 1.  Section 3 - I don't think it is correct to call this a new CMS content
> type.  You are not defining this in the CMS specifiction.  Please use the
> sentence "This document defines a new content type PKIDATA.  This content
> type is used as an encapulsated content within the CMS security
> framework."

OK.

>
> 2.  Section 3.1, paragraph 2 -- I think you should really refer to this as
> "the familiar CMS (formerly PKCS7) degerate".

OK.

>
> 3.  Section 3.1 -- Please re-define id-pkiData in this section rather than
> puttin in the reference to PKIXCERT.

OK.

>
> 4.  Section 4.1, paragraph 3 -- The use of MailListKeyIdentifier in this
> draft should be strongly discuraged.  This is for sending
> encrypted messages
> to a DL and MUST NOT be used for PKI work.

Mailing lists could be used to broadcast revocation information and CA key
updates.

>
> 5.  Section 4.2 - Since we are using CMS as the basis of the
> Crypto in this
> document.  Please change the reference of how signatures and key
> exchange is
> to be done from the PKIXCERT documents to the CMS document.  I
> don't want to
> have to have a CMS implemention with two different types of
> algorithms just
> because the two documents are not in 100% agreement.

This makes sense.  However we should make certain that both works are
aligned since it affects interoperability in the more general case.

>
> 6.  Section 4.4, paragraph 2 - The procedure in the second paragraph not
> very clear. I see nothing in section 4.3 about enveloping as an
> id-pKIData.
> It discusses EnvelopedData and SignedData but not PKIdata -- did
> you mean a
> different section?

The phrase " . . . as defined in section 4.3 . . ." should be deleted.  The
third paragraph in this section speaks to the requirements directly.

>
> 7.  Section 4.4, paragraph 3 - Change the section reference from
> 5.3 to 4.3

OK.

>
> 8.  Section 4.4 in the Encryption Option 1:  (I may have mislead
> you on this
> one)  It should be as follows:
>         signedData.AuthencatedAttributes.contentType  <- id-envelopedData
>         signedData.AuthencatedAttributes.contentHint   <- id-pkiData

OK.

>
> 9. Section 4.5, paragraph 2, bullet 1:  This should be refering to the
> content-hint attribute not the content-type attribute.  This is
> the correct
> property to say what the innermost content is.  Signature validation will
> fail if you change the content-type attribute.

OK.

>
> 10.  Section 4.8.1 paragraph 2 - In the last sentence I am not sure if you
> really mean that the subject name should be encoded as an empty
> sequence or
> as a missing property.  Which do you mean?

Empty sequence.  The subject Name is not OPTIONAL in a PKCS10:

CertificationRequestInfo ::= SEQUENCE {
  version Version,
  subject Name,
  subjectPublicKeyInfo SubjectPublicKeyInfo,
  attributes [0] IMPLICIT Attributes }

>
> 11.  Section 4.8.5 - Should GetCert have a mode which returns the chain of
> certificates rather than just a single certificate.

Sending back a chain is implied by specification of CertRep as a response
which does accomodate sending back the chain.  CMC currently reads " . . . a
SignedData response containing the requested certificate . . .".  I'll add
"As noted in CMMF, this response MUST contain a single certificate and
SHOULD include other certificates which link the issuer to higher level
certification authorities."

>
> 12. Section 4.8.7 - I don't care if the mesage format for a RevReq is not
> covered by CMS -- can we still state something good here about how it is
> sent to the server and the server recognizes this?  The concept of local
> implementation does not help the world with internet access, just small
> conclaves.

In re-reading this, I agree that the sentence "The structure of an unsigned
. . . RevReq . . . is a matter of local implementation." is too loose to
ensure interoperability.  It's probably best to clarify this text by cases:

1.  The use of CMS in the case of RA-authenticated revocation request is
clear cut.

2.  For the case of a end-user initiated revocation request in instances
when the end-entity's private key is reliable and available, CMS is equally
useful to authenticate the request.

3.  It is the case where either the end-entity's private key is either
unreliable (e.g. compromise) or not available (e.g. token broke, forgot
password, etc.).  As a strawman I would propose specification of an
unencapsulated CertRep that SHALL contain the passphrase.

>
> 13.  General Comment:  I would like to see an additional content type
> defined which would address one of the needs that I can see.  I want to be
> able to return more than one CMMF body in a single message.  Thus
> I propose
> that we add a new message type of XX (to be assigned).  The body of this
> message type will be:
>
>         MultipleResponse ::= SEQUENCE OF ContentInfo
>
> Where one or more signed items each containing a different response may be
> included.  This will allow me to return both a CertRepContent,
> KeyRecRepContent and some additional messages as the same time in a single
> transaction.

A useful requirement, but the MultiResponse syntax should include
messageType, or are we thinking of two different encapsulation models?

>
> jim
>

Mike

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 26 Mar 1998 18:20: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]>
To: [email-masked]

> From: "Perry E. Metzger" <[email-masked]>
>
> Stephen Samson writes:
> > >We recommend the inclusion of a note in the following internet drafts:
> >
> > >draft-ietf-pkix-cmc-00.txt
> > >draft-ietf-pkix-opp-ftp-http-02.txt; and
> > >draft-ietf-pkix-ocsp-03.txt.
> > >
> > >The text of the note should be as follows:
> > >
> > >Note: Implementors of this protocol should consider the applicability of the
> > following patent(s): US patent no. 5,699,431
>
> Would there be something wrong with including enough text from the
> patent that someone would know WHY they would want to examine it?
>
> Perry

I guess it's too much to expect that everyone knows to get patent
information from http://www.patents.ibm.com/details?patent_number=5699431,
just as it was negligent to not include a full reference for the documents.

For reference, they are:
  ftp://ietf.org/internet-drafts/draft-ietf-pkix-cmc-00.txt
  ftp://ietf.org/internet-drafts/draft-ietf-pkix-opp-ftp-http-02.txt
  ftp://ietf.org/internet-drafts/draft-ietf-pkix-ocsp-03.txt

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Thu, 26 Mar 1998 17:09:27 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
To: [email-masked]

Stephen Samson writes:
> >We recommend the inclusion of a note in the following internet drafts:
>
> >draft-ietf-pkix-cmc-00.txt
> >draft-ietf-pkix-opp-ftp-http-02.txt; and
> >draft-ietf-pkix-ocsp-03.txt.
> >
> >The text of the note should be as follows:
> >
> >Note: Implementors of this protocol should consider the applicability of the
> following patent(s): US patent no. 5,699,431

Would there be something wrong with including enough text from the
patent that someone would know WHY they would want to examine it?

Perry

Approved-By:  Warwick Ford <[email-masked]>
Date:         Thu, 26 Mar 1998 16:09:21 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] agenda for next weeks meetings
To: [email-masked]

Here is a tentative agenda for next week.  Apologies if I have missed
anything that anyone has asked for.  Please advise omissions or requested
additions.

Warwick

IETF PKIX AGENDA - LOS ANGELES
Meeting times: Wed 4/1, 3:30-5:30; Thur 4/2, 9:00-11:30

- Certificate and CRL Profile
- LDAP Profile and Schema
- OCSP (and RCSP)
- CRMF and CMP
- CMMF
- CMC
- Time Stamping Protocol
- Notary Protocol
- PKIX Implementation Notes (B. LaMacchia)
- IPSEC and S/MIME support

At 02:21 AM 3/25/98 -0800, Jeff Weinstein wrote:
>Is someone going to post an agenda for next weeks meetings in LA?

******** PLEASE NOTE NEW CONTACT DETAILS ********
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Approved-By: [email-masked]
Date:         Thu, 26 Mar 1998 11:19:29 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Samson <[email-masked]>
To: [email-masked]

>We recommend the inclusion of a note in the following internet drafts:

>draft-ietf-pkix-cmc-00.txt
>draft-ietf-pkix-opp-ftp-http-02.txt; and
>draft-ietf-pkix-ocsp-03.txt.
>
>The text of the note should be as follows:
>
>Note: Implementors of this protocol should consider the applicability of the
following patent(s): US patent no. 5,699,431

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Thu, 26 Mar 1998 16:18:16 -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] New OCSP Requirements (and new straw poll...)
Comments: To: Stephen Kent <[email-masked]>
To: [email-masked]

Steve,

> We have an extension in PKIX that points to where a CRL can be found.  Do
> we need to extend this to allow for an explicit pointer to where an OCSP
> query should be directed? That would provide an unambiguous way to address
> this problem.
>
> >The problem is that the pointer only gives a *hint* on the place where
> >we can fetch the information. We have not defined a chain of trust which
> >allows to *make sure* that the information we get is really coming from
> >the right source.
>
> The pointer is put into the cert by the CA, so I consider it to be more
> than a "hint."  The CA shoukd be the definitive source for the location of
> its own cert and the CRL on which the subject cert would be listed, etc.
> If we define an explicit pointer for OCSP purposes, I would expect it to be
> just as definitive.  However, as you suggest in the next paragraph, there
> is the question of how we validate a response as being from an authorized
> source of validity info realtive to the CA in question. So, I think the
> real issue is not that the pointer here is just a hint, but that it is just
> a pointer, not a public key!  However, we could fix that, couldn't we?

I said :" We have not defined a chain of trust". The question is :
should we leave this open (and thus recognize that the problem has to be
solve one way or another) or should we tell how to build such a chain ?
I wanted to say that we have no story at this time. Since we are close
to the meeting, we could have chat on this topic in LA.

> >There is one exception: if the key used by the OCSP is the same private
> >key as the key of the CA (which might not be the best situation). For
> >the other cases, and in particular the delegation case, we currently
> >have no story.

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Stephen Kent <[email-masked]>
Date:         Thu, 26 Mar 1998 10:05: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
Comments: To: [email-masked]
To: [email-masked]

Denis,

>> We have an extension in PKIX that points to where a CRL can be found.  Do
>> we need to extend this to allow for an explicit pointer to where an OCSP
>> query should be directed? That would provide an unambiguous way to address
>> this problem.
>
>The problem is that the pointer only gives a *hint* on the place where
>we can fetch the information. We have not defined a chain of trust which
>allows to *make sure* that the information we get is really coming from
>the right source.

The pointer is put into the cert by the CA, so I consider it to be more
than a "hint."  The CA shoukd be the definitive source for the location of
its own cert and the CRL on which the subject cert would be listed, etc.
If we define an explicit pointer for OCSP purposes, I would expect it to be
just as definitive.  However, as you suggest in the next paragraph, there
is the question of how we validate a response as being from an authorized
source of validity info realtive to the CA in question. So, I think the
real issue is not that the pointer here is just a hint, but that it is just
a pointer, not a public key!  However, we could fix that, couldn't we?

>There is one exception: if the key used by the OCSP is the same private
>key as the key of the CA (which might not be the best situation). For
>the other cases, and in particular the delegation case, we currently
>have no story.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 25 Mar 1998 18:16: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
Comments: To: [email-masked]
To: [email-masked]

Denis,

>> We have an extension in PKIX that points to where a CRL can be found.  Do
>> we need to extend this to allow for an explicit pointer to where an OCSP
>> query should be directed? That would provide an unambiguous way to address
>> this problem.
>
>The problem is that the pointer only gives a *hint* on the place where
>we can fetch the information. We have not defined a chain of trust which
>allows to *make sure* that the information we get is really coming from
>the right source.

The pointer is put into the cert by the CA, so I consider it to be more
than a "hint."  The CA shoukd be the definitive source for the location of
its own cert and the CRL on which the subject cert would be listed, etc.
If we define an explicit pointer for OCSP purposes, I would expect it to be
just as definitive. However, as your next paragraph notes, the real issues
here is how to verify the authorization of an OCSP responder associated
with the pointer we can provide.  That's a valid question.

>There is one exception: if the key used by the OCSP is the same private
>key as the key of the CA (which might not be the best situation). For
>the other cases, and in particular the delegation case, we currently
>have no story.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 25 Mar 1998 12:50:24 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
To: [email-masked]

Mike,

>
>Is this not AuthorityInfoAccess extension as defined in PKIX Part 1?

yes.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 25 Mar 1998 18:15: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Using PKIX
To: [email-masked]

Fredrick,

>1)  Yes, I am also a European guy addicted to Hardware Tokens.  My question
>is about how to make a distinction between a Hardware Key and a Software
>one.  Suppose you have a Certification Authority which supports centralised
>key generation, both in software and on hardware tokens (suppose one of the
>Internet CA's would like to do this),
>        1) How can an EE tell the CA where to store the Certificate and the
>secret key?

One might encode this piece of info in the cert policy extension.

Steve

Approved-By:  Valentin Oprean <[email-masked]>
Date:         Thu, 26 Mar 1998 15:54:25 +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: Valentin Oprean <[email-masked]>
Subject:      [IETF-PKIX] data to/from X.509
To: [email-masked]

Hi!

I am a student and i try to learn some basic stuff about X.509 since i have
to use X.509 together with Oracles Data Cartridge. I am interested in
finding information regarding how data must look like before going in the
X.509 and how it looks leaving the X.509 or what kind of data do I have to
use to/from X.509.

If anybody knows any places where i could find the information please let
me know.

Thanks in advance,

Valentin ([email-masked])

Approved-By: [email-masked]
Date:         Wed, 25 Mar 1998 12:32:44 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Comments on Draft CMC-00
To: [email-masked]

This is my first cut at comments about the CMC draft.  I think this still
needs some work to make it usable in a general case solution.  I have many
fewer comments on this draft at this point because a large point of it
depends on getting clarifications for CRMF and CMMF first.

1.  Section 3 - I don't think it is correct to call this a new CMS content
type.  You are not defining this in the CMS specifiction.  Please use the
sentence "This document defines a new content type PKIDATA.  This content
type is used as an encapulsated content within the CMS security framework."

2.  Section 3.1, paragraph 2 -- I think you should really refer to this as
"the familiar CMS (formerly PKCS7) degerate".

3.  Section 3.1 -- Please re-define id-pkiData in this section rather than
puttin in the reference to PKIXCERT.

4.  Section 4.1, paragraph 3 -- The use of MailListKeyIdentifier in this
draft should be strongly discuraged.  This is for sending encrypted messages
to a DL and MUST NOT be used for PKI work.

5.  Section 4.2 - Since we are using CMS as the basis of the Crypto in this
document.  Please change the reference of how signatures and key exchange is
to be done from the PKIXCERT documents to the CMS document.  I don't want to
have to have a CMS implemention with two different types of algorithms just
because the two documents are not in 100% agreement.

6.  Section 4.4, paragraph 2 - The procedure in the second paragraph not
very clear. I see nothing in section 4.3 about enveloping as an id-pKIData.
It discusses EnvelopedData and SignedData but not PKIdata -- did you mean a
different section?

7.  Section 4.4, paragraph 3 - Change the section reference from 5.3 to 4.3

8.  Section 4.4 in the Encryption Option 1:  (I may have mislead you on this
one)  It should be as follows:
        signedData.AuthencatedAttributes.contentType  <- id-envelopedData
        signedData.AuthencatedAttributes.contentHint   <- id-pkiData

9. Section 4.5, paragraph 2, bullet 1:  This should be refering to the
content-hint attribute not the content-type attribute.  This is the correct
property to say what the innermost content is.  Signature validation will
fail if you change the content-type attribute.

10.  Section 4.8.1 paragraph 2 - In the last sentence I am not sure if you
really mean that the subject name should be encoded as an empty sequence or
as a missing property.  Which do you mean?

11.  Section 4.8.5 - Should GetCert have a mode which returns the chain of
certificates rather than just a single certificate.

12. Section 4.8.7 - I don't care if the mesage format for a RevReq is not
covered by CMS -- can we still state something good here about how it is
sent to the server and the server recognizes this?  The concept of local
implementation does not help the world with internet access, just small
conclaves.

13.  General Comment:  I would like to see an additional content type
defined which would address one of the needs that I can see.  I want to be
able to return more than one CMMF body in a single message.  Thus I propose
that we add a new message type of XX (to be assigned).  The body of this
message type will be:

        MultipleResponse ::= SEQUENCE OF ContentInfo

Where one or more signed items each containing a different response may be
included.  This will allow me to return both a CertRepContent,
KeyRecRepContent and some additional messages as the same time in a single
transaction.

jim

Approved-By:  Tim Polk <[email-masked]>
Date:         Wed, 25 Mar 1998 15:03: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: Tim Polk <[email-masked]>
Subject:      [IETF-PKIX] new draft of certificate profile
To: [email-masked]

The much anticipated (or is that maligned?) seventh draft of the
certificate profile is now available via http.  (In the immortal words of
Maxwell Smart, "I missed the I-D submission deadline by *this much*.")  The
URL is

        http://csrc.nist.gov/pki/draft-ietf-pkix-ipki-part1-07.txt

You must use the whole URL; there are no links from the PKI welcome page. I
will submit draft 7 formally on Monday.

This draft satisfies all Last Call requirements.  This draft has several
minor enhancements.

Most importantly, the document incorporates UTF-8 in several key areas.
This was done to conform with RFC 2277, "IETF Policy on Character Sets and
Languages" and should satisfy most of those concerns. The one controversial
point - we are now *leading* ISO's definition of DirectoryString by
including UTF8String as a choice.  That won't be official for several months.

Next most important (on my list anyway) is the updated path validation text
(section 7.) We were out of synch with ISO's most recent work there.

Wilcarding has been excised from the subject alternative name.  The
applications that wanted this feature have discovered better ways to
achieve their goals.  There were simply too many opportunities for
misinterpretation, usually resulting in serious security problems.

The conformance requirements have been clarified somewhat...  Acording to
RFC 2119, "Key Words for Use in RFCs to Indicate Requirement Levels," any
of the key words {MUST, SHALL, REQUIRE, SHOULD, RECOMMEND, MAY, OPTIONAL}
were good key words for stating conformance requirements.  I did not
attempt to standardize on any particular subset (MUST and SHALL appear
interchangeably), but I did try to remove all inappropriate occurences of
the word "will", since it didn't make the list.

I also added a Table of Contents, updated the References, and added a
patent statement from Entrust.

Please let me know if you have any difficulty downloading the document!

Hope to see you in LA!

Tim Polk

P.S.  I downloaded the text file on another machine, just to double check.
I *believe* the formatting is intact.  If I'm wrong, please let me know
ASAP and I'll correct it.

Approved-By: [email-masked]
Date:         Wed, 25 Mar 1998 11:15:44 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Biddle, Bradford" <[email-masked]>
Subject:      Re: [IETF-PKIX] [E-CARM] PKI, CAs, TTPs &c.
Comments: To: George Capehart <[email-masked]>, [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: [email-masked]

I'll toss out some thoughts on this topic, to all of the lists which
George added (although I share his discomfort with the breadth of the
cross-posting -- my vote would be for E-CARM as the forum for any
further discussion).

Below I've pasted in, first, an adapted version of some brief points I
made in connection with some written comments submitted to the Commerce
Department when they were looking at PKI issues last summer. Second,
I've pasted in the introduction to a paper I wrote called "Legislating
Market Winners" which appeared in the Summer 1997 issue of the World
Wide Web Journal (an expanded version is forthcoming in the San Diego
Law Review), along with a cite to the current URL. Both the Commerce
Dept. comments and the paper address the business-model issues raised in
this thread, although the focus of both is largely on the issue of the
need or desirability of PKI-related legislation.

Both of the items below are increasingly a bit dated. I've grown
uncomfortable with the "open PKI/closed PKI" nomenclature which I use
below.  In general, as used below, "open PKI" refers to the ABA Digital
Signature Guidelines/Utah Digital Signature Act/VeriSign-style "public"
CA model, whereby CAs issue generic "identity" certificates to
"subscribers" for use in a wide variety of transactions. "Closed PKI"
refers not to a closed or proprietary system, but rather to a PKI model
whereby limited -purpose certificates are used in a closed or bounded
context.

Here's an adapted version of the five points submitted to the Commerce
Dept., which I also posted to several lists last summer:

1.   The conventional wisdom about how certification authorities will
function is wrong. The "open PKI" model envisioned by the ABA Guidelines
is an economically inefficient model that would not survive under
marketplace discipline. Generic, all-purpose identity certificates
issued by freestanding third-party CAs are simply not what the
marketplace is demanding. The marketplace has developed, and continues
to develop, more economically efficient, useful, and imaginative
business models.

2.   CAs practicing the open PKI business model envisioned by the ABA
Guidelines can and should compete in the marketplace without special
legislation.  CAs practicing this model can overcome the "contractual
privity problem" which is used to justify ABA Guidelines-style
legislation.

3.   Legislation which endorses the open PKI model will harm the
development of the electronic commerce marketplace. Even legislation
which implements an  "optional" state-endorsed authentication scheme
risks drawing capital and resources away from more efficient and
innovative enterprises, and risks creating economic harms which are
externalized on to innocent parties.

4.   Licensing efforts focused on the open PKI model risk being either
irrelevant or harmful. Licensing is an intrusive form of market
intervention that should be  reserved for situations where demonstrated
market flaws cannot be addressed by other, less intrusive means.
Mandatory licensing of CAs would be harmful; optional licensing of CAs
is simply unnecessary.

5.   The ABA Guidelines-inspired legislation enacted to date poses
serious risks to the development of a robust global electronic commerce
infrastructure. CAs, which could conceivably be global businesses, are
faced with the specter of conforming to dramatically inconsistent local
regulatory schemes.  Such legislation is unwise and unnecessary.

Here's the introduction to the "Legislating Market Winners" article:

[full article at <http://www.acusd.edu/~biddle/LMW.htm>]

"Legislating Market Winners: Digital Signature Laws and the
Electronic Commerce Marketplace"

The argument goes something like this: Internet commerce is
hampered by the authentication problem. There is no reliable
way to ensure that the sender of an electronic transmission is
in fact who they purport to be. Digital signatures, supported by
a "public key infrastructure" of certification authorities (CAs)
and certificate databases, can solve this authentication
problem. CAs will not emerge under the current legal regime,
however, because they face uncertain and potentially
immense liability exposure. Additionally, the legal status of
digitally signed documents is unclear. Therefore, legislation is
needed which defines and limits CA liability and which
establishes the legality of digitally signed documents.

This argument has captured an influential segment of the legal
community, and has led to the enactment of "digital signature
legislation" in several U.S. states and foreign nations.
Unfortunately, the argument is built on fundamentally flawed
assumptions, and the legislation enacted based upon it is
correspondingly flawed. Much (but not all) of the digital
signature legislation enacted to date presumes a vision of
electronic commerce that simply is not tenable, and which
would not "naturally" evolve in the marketplace. This
legislation poses the risk of profoundly distorting an infant
market and locking in business models which are harmful to
consumers and to the future development of electronic
commerce.

The type of public key infrastructure (PKI) envisioned by many
of the existing digital signature laws is not viable. The problem
is liability. Digital signature legislation drafters have assumed
that the potential liability exposure faced by CAs is somehow a
flaw of the existing legal regime. This is an erroneous
assumption: the liability exposure faced by CAs under the
"open PKI" model envisioned by legislation drafters is a
product of a business model that cannot internalize the costs
associated with its implementation. Moreover, in attempting to
limit the liability exposure of CAs, current digital signature laws
shift an immense liability burden onto consumers who use the
infrastructure envisioned by these laws. Putting this type of
liability burden on consumers violates long-held tenets of
public policy, and is a result which consumers would reject in
any truly "bargained for" transaction.

Digital signatures will undoubtedly play a significant role in
electronic commerce. However, rather than being
implemented in the "open PKI" model envisioned by various
digital signature laws, digital signatures are more likely to be
utilized under a "closed PKI" system. Under a closed PKI
system, the liability problems associated with digital
signatures become much more manageable. This article
describes the differences between open and closed PKI, and
suggests that, in the absence of legislative displacement,
certain marketplace trends indicate that closed PKI is indeed
the likely market winner.

The open PKI model can and should compete against closed
PKI and other authentication technologies, and should not be
accorded special legal status via legislation. Such legislation is
unnecessary: the "contractual privity problem" which is used
to justify open PKI legislation is a red herring. Commercial CAs
utilizing the open PKI model can compete in the marketplace
without special PKI legislation. These CAs are unlikely to
succeed, not because of flaws with the legal system, but
because the open PKI model is not a winning business model.

Despite raising the very peculiar specter of regulating an
essentially nonexistent industry (CAs), and despite increased
recognition of the problems associated with the very specific
vision of electronic commerce embodied in these digital
signature laws, laws based on the open PKI model continue to
be proposed and implemented. This article suggests that one
of several factors behind the continued momentum of this
legislation, particularly at the federal and international levels, is
its synergy with cryptographic "key escrow" proposals. While
digital signature legislation ostensibly addresses the use of
cryptography only for the purposes of authentication, and not
for confidentiality, the infrastructure created by these laws is
ideal for implementing a key escrow scheme.

Ultimately this article argues that digital signature laws which
impose a particular view of electronic commerce should be
abandoned. Laws which remove specific, well-defined barriers
to electronic commerce -- such as unnecessary "writing" or
handwritten signature requirements -- and which allow the
electronic commerce marketplace to evolve unfettered should
be encouraged.

 - - - - - - -

I look forward to further discussion on this topic!

Regards,
Brad

Brad Biddle <[email-masked]>
Cooley Godward LLP <http://www.cooley.com>
4365 Executive Dr. Ste. 1100 San Diego, CA 92121
voice: (619) 550-6301  fax: (619) 453-3555

> -----Original Message-----
> From: George Capehart [SMTP:[email-masked]]
> Sent: Wednesday, March 25, 1998 4:00 AM
> To:   [email-masked]
> Cc:   [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject:      Re: [E-CARM] PKI, CAs, TTPs &c.
>
> First, *MAJOR* apologies for cross-posting like this, but I have been
> having the same questions as those posed below.  I know that there
> have
> been various threads in the different groups that have touched on
> them,
> but most have taken tangents at some point or another or simply
> weren't
> appropriate for the list.  I, for one, would like to attack this whole
> area.  I changed jobs and ISPs a while back and have had a *really*
> hard
> time getting caught back up.  I have a feeling this would be a forum
> that would allow the thoughts and work being done by the different
> groups to converge.  I'd like to see discussion of these topics
> progress, whether on this list, in private or <shudder> on a new list
> if
> need be . . .
>
> pj ponder wrote:
> >
> > Is this a good time to discuss the practicality of certificate and
> > CA based public key infrastructure?  Is there any interest in
> discussing
> > whether truly open PKI is viable? Trusted third parties?  Cross
> > certification?  If you are interested in this, or have an opinion on
> the
> > trust or business models represented by open PKI and public CAs, we
> can
> > either discuss it here, or in private email.  I'm hearing a general
> > rumbling that indicates it just won't work - not from a technical
> > viewpoint, we know the math works - but from a practical perspective
> of
> > how it might be implemented.
>
> rgds,
> --
> /*  George Capehart    [email-masked]      +1 704.866.9151
> *
>  *
> *
>  *  "If you push something hard enough, it will fall over."
> *
>  *                          Fudd's First Law of Opposition
> */
> ======================================================================
> =====
> Help with Majordomo commands plus list archives and information is
> available through the E-Carm web page at www.kc-inc.net/e-carm/.
> Sponsored by The Knowledge Connection.
> ======================================================================
> =====

Approved-By:  George Capehart <[email-masked]>
Date:         Wed, 25 Mar 1998 06:59:44 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: George Capehart <[email-masked]>
Subject:      Re: [IETF-PKIX] [E-CARM] PKI, CAs, TTPs &c.
Comments: To: pj ponder <[email-masked]>
Comments: cc: [email-masked], CERT-TALK <[email-masked]>, IETF-SPKI <[email-masked]>, MCG-TALK <[email-masked]>
To: [email-masked]

First, *MAJOR* apologies for cross-posting like this, but I have been
having the same questions as those posed below.  I know that there have
been various threads in the different groups that have touched on them,
but most have taken tangents at some point or another or simply weren't
appropriate for the list.  I, for one, would like to attack this whole
area.  I changed jobs and ISPs a while back and have had a *really* hard
time getting caught back up.  I have a feeling this would be a forum
that would allow the thoughts and work being done by the different
groups to converge.  I'd like to see discussion of these topics
progress, whether on this list, in private or <shudder> on a new list if
need be . . .

pj ponder wrote:
>
> Is this a good time to discuss the practicality of certificate and
> CA based public key infrastructure?  Is there any interest in discussing
> whether truly open PKI is viable? Trusted third parties?  Cross
> certification?  If you are interested in this, or have an opinion on the
> trust or business models represented by open PKI and public CAs, we can
> either discuss it here, or in private email.  I'm hearing a general
> rumbling that indicates it just won't work - not from a technical
> viewpoint, we know the math works - but from a practical perspective of
> how it might be implemented.

rgds,
--
/*  George Capehart    [email-masked]      +1 704.866.9151  *
 *                                                                    *
 *  "If you push something hard enough, it will fall over."           *
 *                          Fudd's First Law of Opposition            */

Approved-By:  Jeff Weinstein <[email-masked]>
Date:         Wed, 25 Mar 1998 02:21:14 -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: Jeff Weinstein <[email-masked]>
Subject:      [IETF-PKIX] agenda for next weeks meetings
To: [email-masked]

Is someone going to post an agenda for next weeks meetings in LA?

        --Jeff

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Wed, 25 Mar 1998 10:53:59 -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] New OCSP Requirements (and new straw poll...)
Comments: To: Stephen Kent <[email-masked]>
To: [email-masked]

Steve,

Thank you for handling the topic through short messages. I will do the
same.

> Denis,
>
> We have an extension in PKIX that points to where a CRL can be found.  Do
> we need to extend this to allow for an explicit pointer to where an OCSP
> query should be directed? That would provide an unambiguous way to address
> this problem.

The problem is that the pointer only gives a *hint* on the place where
we can fetch the information. We have not defined a chain of trust which
allows to *make sure* that the information we get is really coming from
the right source.

There is one exception: if the key used by the OCSP is the same private
key as the key of the CA (which might not be the best situation). For
the other cases, and in particular the delegation case, we currently
have no story.

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 24 Mar 1998 17:44:35 -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] Comments on CRMF-00
To: [email-masked]

Hi Jim,

One quick comment:

>----------
>From:  Jim Schaad (Exchange)[SMTP:[email-masked]]
>Sent:  Tuesday, March 24, 1998 12:45 PM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Comments on CRMF-00
>
(...stuff deleted...)

>17. Given that we have a CMMF document now, and both CMP and CMC refer that
>that document as well as this one. Is there any reason not to combine CRMF
>and CMMF into a single document? I believe that the original reasons for
>seperating them are no longer applicable.

Note that CMP does not point to CMMF (CMMF was still a thought, not yet
a draft, when the final version of CMP was being submitted so CMP had
nothing to point to).  CMP does, however, point to CRMF.

This, perhaps, is as good a reason as any to keep them as separate
documents for the time being.

Carlisle.

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 24 Mar 1998 15:46:41 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
To: [email-masked]

Steve,

Is this not AuthorityInfoAccess extension as defined in PKIX Part 1?

Mike

-----Original Message-----
From: Stephen Kent <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, March 24, 1998 2:20 PM
Subject: Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)

>Denis,
>
>We have an extension in PKIX that points to where a CRL can be found.  Do
>we need to extend this to allow for an explicit pointer to where an OCSP
>query should be directed? That would provide an unambiguous way to address
>this problem.
>
>Steve
>

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Tue, 24 Mar 1998 14:33:31 -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: Tony Bartoletti <[email-masked]>
Subject:      [IETF-PKIX] Belated Post Response
Comments: To: "David P. Kemp" <[email-masked]>
To: [email-masked]

David, on March 10, you wrote:

> The PKIX list server seems to be back up, but this message from Monday
> hasn't popped out yet, so we'll try again.
>
>   dpk
>
>
> ----- Begin Included Message -----
>
> > From: Tony Bartoletti <[email-masked]>
> >
> > > From: [email-masked]
> > >

It looks like it just did, two weeks later!  Ain't computers wunnerful?

____TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 24 Mar 1998 17:31: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on CRMF-00
To: [email-masked]

> From: "David P. Kemp" <[email-masked]>
>
> Appendix C. ASN.1 Structures and OIDs

One other change we might consider:  importing IssuerSerial from
X.509, and defining:

   OldCertId ::= IssuerSerial

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 24 Mar 1998 17:19:29 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on CRMF-00
To: [email-masked]

> From: "Jim Schaad (Exchange)" <[email-masked]>
>
> 14. id-pkip definition should be "::=" not "::"
> 15. Several instances of regCtrl exist which should be id-regCtrl
> 16. The following elements are not defined in the module and need to be:
> AttributeTypeAndValue, EnvelopedData, GeneralName, Name,
> AlgorithmIdentifier, Version, Extensions, UniqueIdentifier,
> SubjectPublicKeyInfo

Thanks to Jim and to Phil Griffin, who also spotted these (and a few
other) errors and reported them to the authors.  The following ASN.1
module from March 2 corrects all the errors I am aware of at this point,
and should be included in the next CRMF draft.

Dave Kemp

Appendix C. ASN.1 Structures and OIDs

CRMF DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS
    Version, AlgorithmIdentifier, Name, Time, SubjectPublicKeyInfo,
    Extensions
        FROM AuthenticationFramework {joint-iso-ccitt ds(5) module(1)
        authenticationFramework(7) 3}

    selectedAttributeTypes
        FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1)
        usefulDefinitions(0) 3}

    UniqueIdentifier
        FROM SelectedAttributeTypes selectedAttributeTypes

    GeneralName
        FROM CertificateExtensions {joint-iso-ccitt ds(5) module(1)
        certificateExtensions(26) 0}

    EnvelopedData
        FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840)
        rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) };

CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {
    certReq   CertRequest,
    pop       ProofOfPossession  OPTIONAL,
    -- content depends upon key type
    regInfo   SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }

CertRequest ::= SEQUENCE {
    certReqId     INTEGER,          -- ID for matching request and reply
    certTemplate  CertTemplate,  -- Selected fields of cert to be issued
    controls      Controls OPTIONAL }   -- Attributes affecting issuance

CertTemplate ::= SEQUENCE {
    version      [0] Version               OPTIONAL,
    serialNumber [1] INTEGER               OPTIONAL,
    signingAlg   [2] AlgorithmIdentifier   OPTIONAL,
    issuer       [3] Name                  OPTIONAL,
    validity     [4] OptionalValidity      OPTIONAL,
    subject      [5] Name                  OPTIONAL,
    publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
    issuerUID    [7] UniqueIdentifier      OPTIONAL,
    subjectUID   [8] UniqueIdentifier      OPTIONAL,
    extensions   [9] Extensions            OPTIONAL }

  OptionalValidity ::= SEQUENCE {
      notBefore  [0] Time OPTIONAL,
      notAfter   [1] Time OPTIONAL } --at least one must be present

Controls  ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
    type         OBJECT IDENTIFIER,
    value        ANY DEFINED BY type }

ProofOfPossession ::= CHOICE {
    raVerified        [0] NULL,
    -- used if the RA has already verified that the requester is in
    -- possession of the private key
    signature         [1] POPOSigningKey,
    keyEncipherment   [2] POPOPrivKey,
    keyAgreement      [3] POPOPrivKey }

POPOSigningKey ::= SEQUENCE {
    poposkInput           [0] POPOSigningKeyInput OPTIONAL,
    algorithmIdentifier   AlgorithmIdentifier,
    signature             BIT STRING }
    -- The signature (using "algorithmIdentifier") is on the
    -- DER-encoded value of poposkInput.  NOTE: If the CertReqMsg
    -- certReq CertTemplate contains the subject and publicKey values,
    -- then poposkInput MUST be omitted and the signature MUST be
    -- computed on the DER-encoded value of CertReqMsg certReq.  If
    -- the CertReqMsg certReq CertTemplate does not contain the public
    -- key and subject values, then poposkInput MUST be present and
    -- MUST be signed.  This strategy ensures that the public key is
    -- not present in both the poposkInput and CertReqMsg certReq
    -- CertTemplate fields.

POPOSigningKeyInput ::= SEQUENCE {
    authInfo            CHOICE {
        sender              [0] GeneralName,
        -- used only if an authenticated identity has been
        -- established for the sender (e.g., a DN from a
        -- previously-issued and currently-valid certificate
        publicKeyMAC        [1] BIT STRING },
        -- used if no authenticated GeneralName currently exists for
        -- the sender; publicKeyMAC contains a password-based MAC
        -- on the DER-encoded value of publicKey
    publicKey           SubjectPublicKeyInfo }  -- from CertTemplate

POPOPrivKey ::= CHOICE {
    thisMessage       [0] BIT STRING,
    -- posession is proven in this message (which contains the private
    -- key itself (encrypted for the CA))
    subsequentMessage [1] SubsequentMessage,
    -- possession will be proven in a subsequent message
    dhMAC             [2] BIT STRING }
    -- for keyAgreement (only), possession is proven in this message
    -- (which contains a MAC (over the DER-encoded value of the
    -- certReq parameter in CertReqMsg, which must include both subject
    -- and publicKey) based on a key derived from the end entity's
    -- private DH key and the CA's public DH key);
    -- the dhMAC value MUST be calculated as per the directions given
    -- in Appendix A.

SubsequentMessage ::= INTEGER {
    encrCert (0),
    -- requests that resulting certificate be encrypted for the
    -- end entity (following which, POP will be proven in a
    -- confirmation message)
    challengeResp (1) }
    -- requests that CA engage in challenge-response exchange with
    -- end entity in order to prove private key possession

-- Object identifier assignments --

id-pkix  OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 }

-- arc for Internet X.509 PKI protocols and their components
id-pkip  OBJECT IDENTIFIER ::= { id-pkix 5 }

-- Registration Controls in CRMF
id-regCtrl        OBJECT IDENTIFIER ::= { id-pkip 1 }

id-regCtrl-regToken          OBJECT IDENTIFIER ::= { id-regCtrl 1 }
--with syntax:
RegToken ::= OCTET STRING

id-regCtrl-authenticator      OBJECT IDENTIFIER ::= { id-regCtrl 2 }
--with syntax:
Authenticator ::= OCTET STRING

id-regCtrl-pkiPublicationInfo    OBJECT IDENTIFIER ::= { id-regCtrl 3 }
--with syntax:
PKIPublicationInfo ::= SEQUENCE {
   action     INTEGER {
                dontPublish (0),
                pleasePublish (1) },
   pubInfos  SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
     -- pubInfos MUST NOT be present if action is "dontPublish"
     -- (if action is "pleasePublish" and pubInfos is omitted,
     -- "dontCare" is assumed)

SinglePubInfo ::= SEQUENCE {
    pubMethod    INTEGER {
        dontCare    (0),
        x500        (1),
        web         (2),
        ldap        (3) },
    pubLocation  GeneralName OPTIONAL }

id-regCtrl-pkiArchiveOptions     OBJECT IDENTIFIER ::= { id-regCtrl 4 }
--with syntax:
PKIArchiveOptions ::= CHOICE {
    encryptedPrivKey     [0] EncryptedKey,
    -- the actual value of the private key
    keyGenParameters     [1] KeyGenParameters,
    -- parameters which allow the private key to be re-generated
    archiveRemGenPrivKey [2] BOOLEAN }
    -- set to TRUE if sender wishes receiver to archive the private
    -- key of a key pair which the receiver generates in response to
    -- this request; set to FALSE if no archival is desired.

EncryptedKey ::= CHOICE {
    encryptedValue        EncryptedValue,
    envelopedData     [0] EnvelopedData }
    --import from [CMS], where the inner content of the
    --EnvelopedData is id-envelopedData and the data content is a
    --BIT STRING encoding of the private key

EncryptedValue ::= SEQUENCE {
    encValue          BIT STRING,
    -- the encrypted value itself
    intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
    -- the intended algorithm for which the value will be used
    symmAlg       [1] AlgorithmIdentifier  OPTIONAL,
    -- the symmetric algorithm used to encrypt the value
    encSymmKey    [2] BIT STRING           OPTIONAL,
    -- the (encrypted) symmetric key used to encrypt the value
    keyAlg        [3] AlgorithmIdentifier  OPTIONAL,
    -- algorithm used to encrypt the symmetric key
    valueHint     [4] OCTET STRING         OPTIONAL }
    -- a brief description or identifier of the encValue content
    -- (may be meaningful only to the sending entity, and used only
    -- if EncryptedValue might be re-examined by the sending entity
    -- in the future)

KeyGenParameters ::= OCTET STRING

id-regCtrl-oldCertID          OBJECT IDENTIFIER ::= { id-regCtrl 5 }
--with syntax:
OldCertId ::= CertId

CertId ::= SEQUENCE {
    issuer           GeneralName,
    serialNumber     INTEGER }

id-regCtrl-protocolEncrKey    OBJECT IDENTIFIER ::= { id-regCtrl 6 }
--with syntax:
ProtocolEncrKey ::= SubjectPublicKeyInfo

-- Registration Info in CRMF
id-regInfo      OBJECT IDENTIFIER ::= { id-pkip 2 }
id-regInfo-asciiPairs    OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
AsciiPairs ::= OCTET STRING
id-regInfo-certReq       OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest

END

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 24 Mar 1998 12:07:40 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: Scott Guthery <[email-masked]>
To: [email-masked]

Scott,

...

>Digital certificates are not about identity.  They are about risk.

I disagree with this broad statement.  Sometimes certs are about risk.
Certs used in many financial systems are not about identity, but about
ensuring that a merchant gets paid.  Sometimes, howeverm certs are about
identity, e.g., as input to an access control decision or for identofying
the sender of an e-mail message.  If the issuer of a cert is also the only
consumer of the cert (in an access control system), I don't think "risk"
captures the essence of certs used here.  Similarly, when I receive signed
e-mail, I want to know the identity of the sender, period.  I may not be
taking some overt action as a result of receipt of the message, and so risk
does not seem to appropriate here either.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 24 Mar 1998 13:46: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] New OCSP Requirements (and new straw poll...)
Comments: To: [email-masked]
To: [email-masked]

Denis,

We have an extension in PKIX that points to where a CRL can be found.  Do
we need to extend this to allow for an explicit pointer to where an OCSP
query should be directed? That would provide an unambiguous way to address
this problem.

Steve

Approved-By: [email-masked]
Date:         Tue, 24 Mar 1998 09:45:41 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Comments on CRMF-00
To: [email-masked]

The following represents my best guess on how to implement enrollment
protocols based on the CRMF specification (I do realize that only the
enrollment message itself is in this document).
1. Section 3, bullet item d: Please add the following sentence to the end.
"(Details of this are covered in other drafts.)"
2. publicKeyMAC -- Only one hash alg allowed?
3. Section 5.4 POPOSigningKeyInput: I don't understand the use of the
authInfo/sender field. Under what circumstances would this be used? Why
would the sender name not be put into the CertTemplate field instead?
4. Section 6. Since you have stated that transaction processing is out of
the scope of this specfication, please change "transaction identifier" to
"request identifier".
5. Section 7.1 -- I have a problem with Registration Token Controls, I can
see it is an octet string, but I cannot determine how I should fill in this
field. Is this just a copy of the token issued by the CA or will this be
different from CA to CA and therefore not standardized in any way? I would
suggest that we define a specific way to do this for this draft. If other
CAs want to use a different way, they should define both the OID and the new
structure for this information.
6. Section 7.3, last paragraph. This states that it is where the EE would
like to find the certificate. What restrictions does this really place on
the CA about publishing? For example is it legal for a CA to publish in a
location or way which is not requested by the PKIPublicationInfo control.
7. Section 7.4 -- Can we turn around the parameters to EncryptedValue?
People who are hand coding will appreciate the fact that we give the
parameters needed to do the decryption prior to giving the value to be
decrypted.
8. Section 7.4 -- I don't know if you can "legally" used EnvelopedData at
this point. Only ContentInfo is actually exported from the CMS module.
9. Section 7.4 -- I see no benefit in requiring that the contentType field
in the EnvelopedData object must be id-data. In a number of cases inclusion
of ASN data directly without another wrapping makes sense and this should be
done using the correct OID.
10. Section 7.6 -- This is incompatable with some of the POP methods. This
needs to be stated in the text for this section.
11. Appendix A. -- Which (or what) subjectName and issuerName are we using?
I assume but it is not stated that we are using the issuer and subject names
for the CA certificate. I make this assumption because I don't necessarily
have the fields in the request (in fact I don't have the subject name by
definition).
Please state this explicity.
12. If you are doing Name-Value pairs, I strongly sugguest you add an
id-regInfo-utf8 for non-ascii situations.
13. Appendix B.1 -- Please put in information in this section about how to
do quoting in the event that either ? or % is part of the value field.
14. id-pkip definition should be "::=" not "::"
15. Several instances of regCtrl exist which should be id-regCtrl
16. The following elements are not defined in the module and need to be:
AttributeTypeAndValue, EnvelopedData, GeneralName, Name,
AlgorithmIdentifier, Version, Extensions, UniqueIdentifier,
SubjectPublicKeyInfo
17. Given that we have a CMMF document now, and both CMP and CMC refer that
that document as well as this one. Is there any reason not to combine CRMF
and CMMF into a single document? I believe that the original reasons for
seperating them are no longer applicable.
jim

Approved-By: [email-masked]
Date:         Wed, 25 Mar 1998 03:53:20 +1200
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 Gutmann <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
Comments: To: [email-masked]
To: [email-masked]

Bob Jueneman <[email-masked]> wrote:

>One question regarding the "least general encoding" rule.  Is it sufficient
>for a given application to trust the code page that is typically used in
>order to decide the string type, or is it necssary to examine each individual
>character in the string in order to determine what the absolutely minimal
>directoryString type should be?

You should use the current code page/locale/whatever (this can get rather
complex, for example under Win32 each individual thread can have its own
locale, although I doubt anyone really takes advantage of this functionality).

Hal Lockhart <[email-masked]> asked:

>Could you add a short comment clarifying the differences between
>printableString, IA5String and visibleString?

Printable = alphanumerics plus a very limited amount of punctuation.
IA5String = (effectively) ASCII, including all the control codes.
VisibleString (aka ISO646String) = ASCII without the control codes.

The only really sensible/useful one there is VisibleString.  For most of the
others it would have been a lot more logical to constrain VisibleString than
to invent lots of new string types with strange restrictions placed on them
(there are several more string types alongside the ones above).  For example
you can't encode an email address in a PrintableString because it doesn't
include an '@', and you're not allowed a VisibleString, so you have to go all
the way up to T61String just to specify your email address.

Assuming that it's too late to change the DirectoryString definition, one
change in usage which would go a long way towards fixing the current mess is
to require the following:

  PrintableString - Use this if possible.
  T61String - Can only contain 8859-1, no escape sequences or anything else.
  BMPString - Use this if it's not 8859-1.
  UniversalString - Don't use this at all.

as well as requiring strict compliance to the "least general" encoding rule
(this isn't done at the moment, I know of at least one widely-used
implementation which seems to randomly use T61String in place of
PrintableString).

Currently, since T61String allows escape sequences, you can move from the
default 8859-1 to pretty much anything, including gratuitous changing of
codesets simply to foil direct comparisons of characters.  Restricting it to
8859-1 only would fix this problem.

Given that it's unlikely that any implementations to date use T61String for
much other than 8859-1 (apart from ones which stuff anything into a T61String,
which are broken anyway), it should be possible to make the change without
breaking things too much.  It would also be really nice to drop in
VisibleString in place of that &*#$ PrintableString, but I guess that would
break too many implementations.

Peter.

Approved-By: [email-masked]
Date:         Tue, 24 Mar 1998 19:38:22 +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: Bengtsson Jim <[email-masked]>
Subject:      [IETF-PKIX] Cross certification question
To: [email-masked]

Hi,

I have a question on cross-certification described in "Certificate
Management Protocols", chapter 4.6(revision 7).

It is stated:
"The requester CA writes the requester certificate to the Repository".
Shouldn´t it be stated "The requester CA writes the received
cross-certificate to the Repository"?

It isn't stated that the responder CA should distribute the
cross-certificate to its repository(along  the rest of the certificates
it issued, and a regulary updated CRL); then why is the statement I
asked about stated present?

Regards,
Jim Bengtsson

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 9 Mar 1998 10:43: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> From: Tony Bartoletti <[email-masked]>
>
> > From: [email-masked]
> >
> >Wrong mailing list.  What you said above is the SPKI notion, but it's not
> >the PKIX notion, of the semantics of the subject name field in a
> >certificate.
> >
> >Steve
>
> I agree with your characterization of subject name SPKI vis-a-vis PKIX.
>
> Dan makes a secondary point, in that the cost of carrying different keys
> for every usage (identification or authorization, I suppose) be weighed
> against the potential privacy concern of having one key (especially in
> the case of an identity role) employed so widely that tracking usage on
> the one key produces a virtual dossier on the owner.

Tony's characterization is eloquent enough that it cannot be improved
upon, but merely restated.  By following the "wallet and paper signature"
model and having a single public key which announces "This Is Me!", users
would be voluntarily adopting the very thing they refuse to have
imposed upon them externally: a national ID.

My primary objection to multiple certification is the lack of handling
flexibility, not usage tracking.  If certificates are analogous to the
contents of a wallet, then I would like to be able to dynamically decide
what to carry in my wallet depending on where I'm going.  Normally I'd
carry everything, for convenience.  But if I'm going on a trip, I'd
remove the cards I'm not expecting to need so that if the wallet is
lost or stolen, I don't have to cancel everything.

In a token or key database, if every certificate's copy of the
private key has the same value (or in Paul Koning's model, which I
haven't heard of being supported in commercially available tokens or
applications, every certificate refers to the same storage location for
the private key), then the assignment of certificates to storage
modules is done once at issuance.  But if every certificate uses a
different private key, then those keys can be moved in and out of the
storage module as needed to accommodate where the module will be used.
I might normally want to keep my "AMEX Platinum" key on my smartcard,
but if I were going to plug that smartcard into a mall kiosk or an IETF
terminal room machine, I'd rather take the AMEX key off and leave just
an S/MIME email key on the card.

The third objection to multiple certification is that it leads
inexorably to a permanent key that cannot be updated.  Although it is
impossible for a single CA to verify that a key has not been certified
somewhere else, it is certainly possible and often desirable for that
CA to ensure that the key is changed at renewal.  But if a single key
is used for all certificates, and the validity dates for all CAs are
not synchronized, then it is impossible for any CA to rekey it's own
subjects' certificates, much less establish rekey periods that are
appropriate for the purpose of the certificates.

In summary, the disadvantages of a shared key across certificates include:

* inability of the user to change the contents of a storage module
* inability for any CA to establish a policy of rekeying on reissuance
* enables usage tracking
* not supported by current applications (counterexamples welcome)

The advantages include:

* might save memory (if each cert doesn't keep it's own copy of the
  private key).

With regard to comments that a standard requiring users not to share
keys is "unenforceable":  so is any standard recommending behavior that
is in the user's interest.  No one is going to jail for failing
to eat their Recommended Daily Allowance of Vitamin A.  But it is
nonetheless useful to publish RDA numbers ("standards") for vitamins
and minerals to allow consumers to make educated decisions based on
information published by nutrition experts and food producers.

PKIX is an information resource, not just a technical interoperability
specification.  Let's write security considerations that provide some
useful guidance on choosing a key sharing policy.

Dave Kemp

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 24 Mar 1998 11:08:00 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

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

Content-Type: text/plain; charset=us-ascii

Michael Myers <[email-masked]> scrawled:
>
> You raise some very good points about the details implied by caching.
> Transport independance further complicates this subject.  We should expect
> that some environments can and will inject client-transparent cache
> management mechanisms.  What's your opinion of  companion draft approach,
> where the OCSP spec defines the basic point-to-point interface while a
> companion draft addresses requirements, assumptions and recommendations
> regarding caching?

Capital idea!  I'll even volunteer to write it.

                Marc

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

Approved-By:  Russ Housley <[email-masked]>
Date:         Tue, 24 Mar 1998 13:25: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: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Using PKIX
To: [email-masked]

At 07:46 AM 3/24/98 -0500, Frederik Loeckx wrote:
>1)  Yes, I am also a European guy addicted to Hardware Tokens.  My question
>is about how to make a distinction between a Hardware Key and a Software
>one.  Suppose you have a Certification Authority which supports centralised
>key generation, both in software and on hardware tokens (suppose one of the
>Internet CA's would like to do this),
>        1) How can an EE tell the CA where to store the Certificate and the
>secret key?

Is this really necessary?  If the CA sends the centrally generated keying
material to the EE, the EE will store it in the appropriate place.  When a
hardware token is used, I would hope that the keying material to revover
the private key is available only on that token.  In this case, the private
key cannot be used until it is put on the token and recovered.

>        2) Is there a way to transmit all the stuff to use the smartcard
>(unblocking PIN, access PIN, ..) along with the message in a secured way?

This is a good question.  PKIX has never looked at the issues associated
with distributing token specific information.  It might be useful to define
extensions to the protocols (once they are stable) for this information.
All of the protocols have extension mechanisms.

Russ

Approved-By:  Russ Housley <[email-masked]>
Date:         Tue, 24 Mar 1998 13:56: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: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

PKIX Part 1 says:

   Conforming CAs are not required to issue CRLs if other revocation or
   status mechanisms are provided.  Conforming CAs that issue CRLs are
   required to issue version 2 CRLs, and must include the date by which
   the next CRL will be issued in the nextUpdate field (Section
   5.1.2.5).  Conforming applications are required to process version 1
   and 2 CRLs.

Therefore, it seems to me that nextUpdate should be required.

Russ

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 24 Mar 1998 11:22:07 -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] Using PKIX
To: [email-masked]

Hi Frederik,

>----------
>From:  Frederik Loeckx[SMTP:[email-masked]]
>Sent:  Tuesday, March 24, 1998 7:46 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Using PKIX
>
>Hello everybody,
>
>I am trying to fit the PKIX messages onto some global Public Key
>Infrastructures I can think off.
>
>This exercise was pretty usefull and most of the cases are fully covered by
>PKIX.  There are however two situations in which I don't know what to do.
>Perhaps the list can help me finding a way out.

The situations you describe are not explicitly covered by the CMP/CRMF
documents.  However, these documents specify a framework within which
you can certainly accommodate what you need.

>1)  Yes, I am also a European guy addicted to Hardware Tokens.  My question
>is about how to make a distinction between a Hardware Key and a Software
>one.  Suppose you have a Certification Authority which supports centralised
>key generation, both in software and on hardware tokens (suppose one of the
>Internet CA's would like to do this),
>        1) How can an EE tell the CA where to store the Certificate and the
>secret key?

There are a couple of options here.  I think the preferred route is to
define another choice for the PKIArchiveOptions control in CRMF
(something like "storeOnHardwareToken  [3]  BOOLEAN").  The second
possibility is to define a new Control for the request (again, something
like "StoreOnHardwareToken ::= BOOLEAN").  Note that in either case, the
CMP CertResponse message would have a status of "granted" but would omit
the optional certifiedKeyPair.

>        2) Is there a way to transmit all the stuff to use the smartcard
>(unblocking PIN, access PIN, ..) along with the message in a secured way?

Yes.  Since this is not specific to each certificate in the CMP
CertReqMessages or CertRepMessage (assuming there are multiple), but is
instead related to the message as a whole, this is a good example of a
use for the generalInfo field of the CMP PKIHeader.  An InfoTypeAndValue
can be defined to carry this data (perhaps with syntax EncryptedValue
from CRMF).  Note that if this data is generated by the CA and sent to
the EE (e.g., for cases in which the CA initializes the hardware token
itself) then the EE should send a protocolEncryptionKey control in the
CertRequest so that the data can be protected for confidentiality.

>2) I have a problem with the CertTemplate where the whole
>SubjectPublicKeyInfo is treated as one big entity.  Suppose (in the same
>case of centralised keygen), I want to be able to request a 1024 bit RSA
>key (and not an 512 bit one).  This means I need to transmit the modulus
>length somewhere in the message.  The only possibility I have found, is to
>include some dummy modulus and exponent in the SubjectPublicKeyInfo field.
>But now the CA thinks I am asking him to certify my public key instead of
>generating a new keypair for me.  Am I missing something?

There are three possibilities here.  I think the preferred route is to
send nothing in the SubjectPublicKeyInfo but to send a
protocolEncryptionKey control (the size of the modulus in the protocol
encryption key dictates the size to use for the modulus of the
centrally-generated key pair).  Another alternative is the one you
suggest in which a modulus and exponent are transmitted but are clearly
not intended as the public key (e.g., a modulus of 2**1023 and an
exponent of 0).  Thirdly, a new control can be defined for the request
(something like "SizeOfReqModulus ::= INTEGER").

Again, the situations you describe can be handled in the existing
CMP/CRMF framework.  Furthermore, one or more of the proposals presented
above can be standardized if there is sufficient interest in doing so.

Thanks for your interest!

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

Approved-By:  Frederik Loeckx <[email-masked]>
Date:         Tue, 24 Mar 1998 07:46: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: Frederik Loeckx <[email-masked]>
Subject:      [IETF-PKIX] Using PKIX
To: [email-masked]

Hello everybody,

I am trying to fit the PKIX messages onto some global Public Key
Infrastructures I can think off.

This exercise was pretty usefull and most of the cases are fully covered by
PKIX.  There are however two situations in which I don't know what to do.
Perhaps the list can help me finding a way out.

1)  Yes, I am also a European guy addicted to Hardware Tokens.  My question
is about how to make a distinction between a Hardware Key and a Software
one.  Suppose you have a Certification Authority which supports centralised
key generation, both in software and on hardware tokens (suppose one of the
Internet CA's would like to do this),
        1) How can an EE tell the CA where to store the Certificate and the
secret key?
        2) Is there a way to transmit all the stuff to use the smartcard
(unblocking PIN, access PIN, ..) along with the message in a secured way?

2) I have a problem with the CertTemplate where the whole
SubjectPublicKeyInfo is treated as one big entity.  Suppose (in the same
case of centralised keygen), I want to be able to request a 1024 bit RSA
key (and not an 512 bit one).  This means I need to transmit the modulus
length somewhere in the message.  The only possibility I have found, is to
include some dummy modulus and exponent in the SubjectPublicKeyInfo field.
But now the CA thinks I am asking him to certify my public key instead of
generating a new keypair for me.  Am I missing something?

Regards,

Frederik Loeckx

Approved-By:  Nada Kapidzic Cicovic <[email-masked]>
Date:         Tue, 24 Mar 1998 12:30:14 +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: Nada Kapidzic Cicovic <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

At 12:23 3/20/98 -0500, Russ Housley wrote:
>At 05:13 PM 3/19/98 +1200, Peter Gutmann wrote:
>>4.2.1.2.
>>
>>This gives the subject key identifier as the hash of the
subjectPublicKeyInfo
>>*without* the tag and length.  Is this a mistake, or is it meant to be like
>>that?  Every other instance in which an ASN.1 object is hashed (eg
>>certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes the
>>entire object.  In fact the PKIX CMP draft uses a hash of the full
>>subjectPublicKeyInfo in the OOBCertHash, which would make it incompatible
>with
>>the value in the subject key identifier.  Requiring a well-defined standard
>>X.509 object to be broken up into pieces before processing it seems an
>>extremely peculiar move, so I'm guessing it's some sort of mistake in the
>spec.
>
>This was done prior to the CMP section.  To use the public key, you need to
>get the value out of the certificate without the associated ASN.1 stuff, so
>that was the reason we chose to hash just the key.

However, for RSA public keys you still have ASN.1 there, since the public
key consists of n and e, which are coded as ASN.1 sequence. Therefore, your
reasoning does not hold.

I suggest to use whole SubjectPublicKeyInfo for calculation of key ids, to
avoid confusion and have compatibility with CMP OOBCertHash.

....

>>7.3.2.
>>
>>This gives a redundant definition of the DH p and g values (the ASN.1
>>definition is followed immediately by text which says exactly the same
>thing -
>>actually the RSA definition does this too with n and e), but doesn't explain
>>the INTEGER which is the DH public key (what *is* this value?  The only
thing
>>I can think of is g^x mod p, but that shouldn't be a fixed value).  It also
>>goes to some lengths to explain the encoding of the INTEGER parameter as a
>BIT
>>STRING, which seems very odd.
>
>Whould you like to suggest improved text?
>
>Russ
>

I would like to suggest the following change in the text:

Instead of:

"The Diffie-Hellman public key (an INTEGER) is mapped to a
subjectPublicKey (a BIT STRING) as follows: the most significant bit
(MSB) of the INTEGER becomes the MSB of the BIT STRING; the least
significant bit (LSB) of the INTEGER becomes the LSB of the BIT
STRING."

to have:

"The DSA public key shall be ASN.1 encoded as an INTEGER; this
encoding shall be used as the contents (i.e., the value) of the
subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
data element.

        DHPublicKey ::= INTEGER -- public key y = g^x mod p"

This would be in accordance with DSA public key definition from 7.3.3.

Regards,

Nada

______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 23 Mar 1998 14:17:53 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

Paul,

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, March 23, 1998 9:52 AM
Subject: Re: [IETF-PKIX] OCSP Update

>>I agree that the semantics of nextUpdate need refinement.  I've placed a
>>note in the v.04 text (the one I posted) calling attention to this issue.
>>I would prefer that nextUpdate have exactly the same semantics as its
>>counterpart in X.509 CRLs, nothing more and nothing less.
>
>But the wording in the new OCSP is *much less* than what is in PKIX part 1.
In
>part 1, there is no disclaimer to the validity of the data between the two
>time, at least none that I could find.

The text on nextUpdate in the v-04 draft was largely drawn from the RCSP
contribution.  I placed a note in the text regarding these statement rather
than take a unilateral position in the update.  This view of nextUpdate
clearly  needs resolution against the commonly held view of nextUpdate in
CRLs, which OCSP is intended to replace for some environments.

If we conclude that { thisUpdate-nextUpdate} semantics are broken, then
they're broken for both OCSP and X.509 CRLs.   If not, then X.509 semantics
should apply.

>
>>The use of nextUpdate is not restricted to caches.  Caches accelerate
basic
>>functions; consider LDAP.  That said, we should not presume responses
can't
>>or won't be cached.  The exact mechanism may vary now by transport.
>
>If we suspect that there will be any caching, we have to add very strong
words
>about it and about cache time skew problems to the OCSP draft. The time
skew
>problems for HTTP caches were discussed in grotesque detail on the HTTP WG
>mailing list about two years ago, and they are amazingly complex and
>dangerous.

I'm confident that Phill can fill us in here when his travel plans enable
him to do so.

>
>If caching is allowed, I believe that we have to change nextUpdate to being
>required in every message, and we have to define it much more tightly than
we
>do now. For instance, what if a cache has a recent response that says
>"notRevoked", and then is too busy to cache a following response that says
>"revoked"? The user querying the cache would have no idea of the latter,
and
>without a nextUpdate that means something, would have no way to find out
the
>real value or to even know that they were getting a stale value.

I have no problem mandating nextUpdate.  There is  a modest bandwidth impact
but resulting reduction is options enhances interoperability.  Real time
responses would set both values equal.

>
>My preference is to say "no caching is allowed", but if others in the WG
want
>caching (and I fully agree that it could help relieve OCSP servers), we
>need to
>look at what that means to users of the cached data.

You raise some very good points about the details implied by caching.
Transport independance further complicates this subject.  We should expect
that some environments can and will inject client-transparent cache
management mechanisms.  What's your opinion of  companion draft approach,
where the OCSP spec defines the basic point-to-point interface while a
companion draft addresses requirements, assumptions and recommendations
regarding caching?

>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

Mike

Approved-By:  Stephen Kent <[email-masked]>
Date:         Mon, 23 Mar 1998 07:28: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Unique Identification of a Certificate
To: [email-masked]

Slava,

While the hash of a CA's key would likely be unique, it also is a terrible
search key in many instances. One has to be careful about the context in
which a pointer to a CA cert is being used. In a cert, having a CA "key ID"
that is based on the hash of the CA is fine, because we already have the CA
name, and maybe even a locator.  In other protocol context we should have a
similar level of naming for search purposes, and rely on something like a
key hash just for disambiguation among multiple possible keys associated
with the same CA.

Steve

Approved-By: [email-masked]
Date:         Mon, 23 Mar 1998 13:22: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: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Comments on draft CMMF-00
To: [email-masked]

Here are the first set of comments that I have on this draft:

1.  Lets combine this with CRMF to produce a single draft of all messages.
The reasons for breaking them into two drafts no longer exist to the best of
my knowledge.

2.  Formatting issue:  Should be some space before the start of section 4.

3. Section 4.2 - Need to put in a defintion for PKIFreeText into this draft.
Should not have to reference CMP for this, it is now a primitive.

4. Section 4.4 - I can see the use of having both encryptedValue and
cMSEnveloped in the EncryptedData type, however I see no use for the last
two types.  All they are doing is making the structures more difficult and
harder to interop with, more options mean more problems.  Additionally I
have heard of no current efforts to move the PKCS #8 and 12 into IETF
drafts.

5.  Section 4.4 - I don't understand the reasoning behind the fact that RSA
uses a symmetric key and D-H does not.  It seems reasonable to me to say
that you don't need to have the encrypted symmetric key in D-H, but allow it
anyway.  If you are going to put the text in this manner please change it to
working such as the following:

"For key agreement algorithms (such as Diffie-Hellman), the encSymmKey field
of EncryptedValue is not included.  For key exchange algorithms (such as
RSA), the encSymmKey is a symmetric key encrypted under the subscriber's
public key."

6.  Section 5.2.1 -- I need far more information about what the structure of
rspInfo should be?  If we don't define it then we can't possibly get a get
interopability.  There appears to be a vague reference to it being
name/value pairs, but this is not certian from the text.

7. Section 5.1 - Please add a certReqId to the PKCSReq type.  This allows
for a correct value to be placed in a CertRepContent in the event that
multiple PKCSReqs are sent to a CA.

8. Section 5.3 - Need to add a CertReqId to this message. If multiple
requests have been sent in then this would be needed to disabmiguate the
different requests.

9. Section 5.3 - Does this imply that you must put a subject and issuer into
the certificate request if you want to use this polling method?  Does this
imply that a CA cannot return PENDING as a code in the event that a subject
and issuer name have not been placed in the request? or just that the
certificates cannot be polled for?

10. Section 5.4 - How do I retrieve a CRL in the event that the CA has an
empty Issuer name?  Do I put the empty name in the issuerName field or do I
extract a portion of the IssuerAltName?

11. Section 5.5.1 - Should change PrintableString to UTF8string in the
RevRequest ASN.

12. Section 5.5.1 - Why is there not a SEQUENCE OF RevRequest defined?  The
text about certDetails in RevReqContent implies to me that the RevRequest
form would be perfered if you actually knew the issuer and serial number.  I
see nothing which would prevent the usage of the RevReqContent except for
the "I don't have access to my keys any more" case.

13. Section 5.6 - Please change the first sentence to: "The response to the
RevReqContent message."  I am making an assumption that this message would
not be generated in response to a RevRequest message since the first
sentence is currently singular rather than plural.  This may be a bad
assumption.

14. Section 5.7 - Please change FullCertTemplates in the comment for
POPODecKeyChallContent to CertReqMessages.

15. Section 5.7 - In order to make the association between the request and
the challenge clearer, I strongly suggest adding a CertReqId field to the
Challenge structure.  This means that we could remove the order association
in the comment on POPODecKeyChallContent if desired and still have correct
associations.

16. Section 5.7 - It would appear to be that something should definitely be
said about the suggested length of A being used in the challenge,  I also
see some potential problems about the total length of the integer and the
senders GeneralName.  What should be done if the encoding of Rand happens to
be larger than the longest value that is encryptable by the public key?  If
you are using a bulk algorithm for doing the key exchange/key agreement
versions, then you must specify the AlgorithmIdentifier of the bulk
encryption algorithm.

17. Section 5.7 - What would be the correct way to say that I failed to do
this?  THere is a success body content defined but not a failure body.  I
can see this as possibly being handled in the overlying protocal but that
potentically should be stated.

18. Section 5.7 - There is a reference to PKIHeader, but I can not find the
defintion of this in either CRMF or CMMF.  Please put in a defintion or
correct the reference.

19. Section 5.9 - The second sentence in this paragraph implies that I will
be generating a response to these announcement messages.  I cannot believe
that this is what was intended. I would suggest "These messages are
generally unsolicited and may be received by End Entities at random times."

20. Section 5.9.1 - I disagree that the old CA private key is no longer
required after sending out this message.  I think that you still need the
old CA private key to produce CRLs right up to the time that the old CA
certificate expires.  Here the the problem that I see with your statement.
Lets say that I am using my own private CA which is publishing CRLs via an
HTTP link.  I send you a signed message with my certificates and the current
(old) chain.  The CA then updates it key set and send me the information and
publishes out a CRL signed with its (new) private key.  You then attempt to
verify the message I sent you and pick up the CRL.  You are unable to verify
the signature on the CRL and thus the message I sent you.  If I now send you
a new message it will verify since I have the new chain of certificates to
send to you.  This is fine in a closed environment but not on the internet.

21.  Section 5.10 - From the fact that the CA is just anouncing this
information, am I correct in assuming that the request for this would come
from an Out-Of-Band request?  It makes no sense to me that this would just
randomly show up in my mailbox.  I would feel very srongly that this should
be an explicit request/reply message in the normal format rather than tan
anouncement message.

22. Section 5.10 - The structure includes a field for newSigCert, how and
where was the request for this certificate made if this is just a random
annoucement? (I use the words random from a client point of view.  I know
that the CA will only generate this message in response to some well defined
events, but the client does not see those events.)

23. Section 5.11 - There are a set of examples that are partially defined.
It would appear that atleast some of the items in the examples
(CAKeyUpdateInfo) are explicitly called out in the spec and therefore should
not appear here.

24. Section 5.11/5.12 -- I give up.  This is not defined enough for me to
even start to understand how to use these messages.

25. Section 6. There is a warning in this section about the unadvisablity of
doing arbitrary decryptions and sending them back to somebody.  It would
appear to me that this is very close to what is being done in the
challenge/response POP seqeuences.  I think a paragraph either here or in
the section on the POP messages would be in order about why I should not
consider this to be an explicitly documented version of this attack I am
suppose to ipmlement.

26. Need an appendix containing the ASN pulled out into a single module for
easy reference.

jim schaad

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 23 Mar 1998 15:24: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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

Hi David,

>----------
>From:  David P. Kemp[SMTP:[email-masked]]
>Sent:  Monday, March 23, 1998 2:43 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP Update
>
>> From: Paul Koning <[email-masked]>
>>
>>  IMC> My preference is to say "no caching is allowed", but if others
>>  IMC> in the WG want caching (and I fully agree that it could help
>>  IMC> relieve OCSP servers), we need to look at what that means to
>>  IMC> users of the cached data.
>>
>> I find it very hard to imagine that a "no caching allowed" rule will
>> turn out to be acceptable.  Yes, caching creates some new issues; I'd
>> say those issues need to be addressed.
>
>Original OCSP attempted to satisfy two radically different purposes:
>1) efficient distribution of timely certificate revocation status, and
>2) simplifying end-user systems by relieving them of the burden of
>   validating certification paths.

...

>My view of OCSP is that it serves purpose 2 only, and should thus be
>called "Online Certificate Validation Protocol".  A relying party
>could operate a "validation proxy server" to perform all path validation
>tasks (trust point maintenance, cert storage and retrieval, signature
>verification, validity period checking, revocation checking, processing
>certificatePolicies, etc.)  Applications would query the validation
>proxy using OCVP, conceptually using statically-configured keys to
>avoid the bootstrapping problem (they could be symmetric keys for
>performance), and all clients of a given validation proxy MUST be
>considered a single Relying Party.

I tend to disagree here.  It seems to me that "purpose 2" is falls
nicely within the scope and concept of the notary protocol, whereas
"purpose 1" is what may be covered by OCSP.

>The path validation engine, whether located in a proxy server or built
>into each application, needs to get timely revocation status from the
>CA.  But the CA-to-validation-engine protocol should be different from
>the validation-proxy-to-client protocol, because they do two different
>things.
>
>If we are designing an "Online Certificate (Revocation) Status
>Protocol", to satisfy purpose 1, then it must not cache responses
>received from the CA unless the response contains a CA-generated
>expiration time, in which case the response may be cached only until
>it expires.  I believe that the per-certificate nature of the current
>OCSP and RCSP drafts make them less suitable for distributed cache
>maintenance than a bulk-update protocol based on CertificateLists.

I agree with this.

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

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 23 Mar 1998 14:43: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

> From: Paul Koning <[email-masked]>
>
>  IMC> My preference is to say "no caching is allowed", but if others
>  IMC> in the WG want caching (and I fully agree that it could help
>  IMC> relieve OCSP servers), we need to look at what that means to
>  IMC> users of the cached data.
>
> I find it very hard to imagine that a "no caching allowed" rule will
> turn out to be acceptable.  Yes, caching creates some new issues; I'd
> say those issues need to be addressed.
>
>         paul

I agree with Paul Hoffman - my preference is "no caching allowed" for
certificate revocation status, not because it couldn't in principle
be made to work, but because if caching appears to be needed then CRLs
are a better mechanism for maintaining consistency between the CA and
caching servers than individual per-certificate transactions.

Original OCSP attempted to satisfy two radically different purposes:
1) efficient distribution of timely certificate revocation status, and
2) simplifying end-user systems by relieving them of the burden of
   validating certification paths.

Attempting to satisfy both requirements with a single protocol just
results in confusion between the two purposes.  Revocation status must
flow from the CA to the Relying Party and thus involves communication
efficiency / timeliness tradeoffs.  Path validation must be performed
by the Relying Party itself, but is a static function of its inputs.

My view of OCSP is that it serves purpose 2 only, and should thus be
called "Online Certificate Validation Protocol".  A relying party
could operate a "validation proxy server" to perform all path validation
tasks (trust point maintenance, cert storage and retrieval, signature
verification, validity period checking, revocation checking, processing
certificatePolicies, etc.)  Applications would query the validation
proxy using OCVP, conceptually using statically-configured keys to
avoid the bootstrapping problem (they could be symmetric keys for
performance), and all clients of a given validation proxy MUST be
considered a single Relying Party.

The path validation engine, whether located in a proxy server or built
into each application, needs to get timely revocation status from the
CA.  But the CA-to-validation-engine protocol should be different from
the validation-proxy-to-client protocol, because they do two different
things.

If we are designing an "Online Certificate (Revocation) Status
Protocol", to satisfy purpose 1, then it must not cache responses
received from the CA unless the response contains a CA-generated
expiration time, in which case the response may be cached only until
it expires.  I believe that the per-certificate nature of the current
OCSP and RCSP drafts make them less suitable for distributed cache
maintenance than a bulk-update protocol based on CertificateLists.

Approved-By:  Paul Koning <[email-masked]>
Date:         Mon, 23 Mar 1998 13:04:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Comments:     Hyperbole mail buttons accepted, v04.023.
From: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

>>>>> "IMC" == IMC  <Paul> writes:

>...
 IMC> My preference is to say "no caching is allowed", but if others
 IMC> in the WG want caching (and I fully agree that it could help
 IMC> relieve OCSP servers), we need to look at what that means to
 IMC> users of the cached data.

I find it very hard to imagine that a "no caching allowed" rule will
turn out to be acceptable.  Yes, caching creates some new issues; I'd
say those issues need to be addressed.

        paul

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Mon, 23 Mar 1998 12:47:01 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: Scott Guthery <[email-masked]>
To: [email-masked]

"Scott Guthery" writes:
> >In any real financial transaction system in use *today*, the
> >relationships are bilateral and there is no need for third party
> >identity verification, since the bilateral counterparties have
> >prearranged their relationship.
>
> Barter is the only one I can think of and even in this case there are
> consumer protection laws.  Cash is backed by social 'suasion or
> its issuer.

Not quite.

"Cash" used to mean "gold". Gold is not backed that way.

Banknotes, which you are refering to, used to be standard commercial
paper in the manner of any other commercial paper. As such, they were
not automatically accepted by a creditor -- and a creditor would often
demand endorsement of the banknote. (People might be interested in
finding out what the legal implications of endorsement are. I suppose
one could still demand endorsement of a $100 bill on the premise that
it might be counterfeit, but in practice no one does so.)

You are correct that since the creation of legal tender laws and the
Fed, we no longer have private issuance of banknotes, and thus federal
reserve notes are treated as though they were cash in our
system. However, for our purposes, $100 bills count as "gold
substitutes". To put it another way, both parties have a bilateral
arrangement with the Federal Government, implicitly via its imposition
of the legal tender laws.

> Checks are backed by a legal system and its incarceration powers.

True enough, but as merchants rarely get paid off on bounced checks
from strangers, what counts to a bank is whether they are going to get
paid off of the individual check they have been handed, and not
whether ultimately some criminal sanction might be brought. Thus, the
reluctance of many merchants to take non-certified checks, and a
series of bilateral arrangements at places that do take checks, like
Supermarkets that set up "courtesy check cashing cards" and other
schemes to limit risk.

By the way, I will point out that the check case is COMPLETELY
bilateral. There is no legal obligation on the part of the bank to the
merchant -- the bank is not liable if the check bounces, and the
merchant has no legal relationship with the merchant of any other
sort, either. The check is an order to the bank from its customer (who
happens to be the merchant's customer as well) ordering disbursment of
funds, but the check is NOT an instrument of the bank, and the bank in
no way guarantees payment. If there is a default, it is the customer
who owes money, not the bank. "Bilateral relationships".

> Credit and debit cards rest on contracts between the cardholder and
> the merchant with the bank or the bankcard association.

Bilateral arrangements, all.

> Giros, ATMs, ACH etc. all have active third party involvement.

Nope. They are all a series of bilateral arrangements.

Take an ATM, for example. You present a bank card to a NYCE
machine. The bank tells NYCE you are withdrawing money, NYCE tells
your bank, your bank tells NYCE "yes, I'll pay off that sum", and at
that point NYCE tells the bank card machine owner that it will
guarantee that you get paid. No third party arrangements -- all are
bilateral arrangements.

> The question is not if there will be a third party but who will it
> be.

ALL clearing and settlement rests ultimately on bilateral
arrangements. ALL of it.

You are inaccurately labeling intermediaries third parties, which they
are not -- they are engaged in intermediation, which is different.

> Being a third party to financial transactions is a very, very good
> business to be in

There are no "third parties" to financial transactions.

That is why the phrase is INTERMEDIATION. Financial institutions act
as INTERMEDIARIES to a pair of bilateral transactions -- not as third
parties in a multilateral transaction. The liability is all bilateral.

When I trade stock, I do not care if the counterparty fails to
deliver, because my *intermediaries* assume liability for that. If
there is a failure to deliver, the counterparty's broker has to
deliver. That is part of what they get paid for -- their
intermediation involves a guarantee to deliver.

Even seemingly "multiparty" transactions never are. Take cosignature
of a debt instrument. The cosigner is guaranteeing payment, and
assumes all risk in exchange for another arrangment with the
debtor. The lender disburses funds to the debtor, but it is the
cosigner that assumes all risk, not the debtor, which is why the
cosigner ends up being the entity that the lender credit checks. The
arrangement is effectively (again) bilateral.

Now, digital signature technology has dramatic potential for lowering
the costs of intermediation, and simpling intermediation by reducing
the number of intermediaries that have to be involved. However, as all
the counterparties to all the individual bilateral components of a
transaction continue know each other, there is no need for third party
identity verification.

Perry

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 23 Mar 1998 09:22:30 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

>I agree that the semantics of nextUpdate need refinement.  I've placed a
>note in the v.04 text (the one I posted) calling attention to this issue.
>I would prefer that nextUpdate have exactly the same semantics as its
>counterpart in X.509 CRLs, nothing more and nothing less.

But the wording in the new OCSP is *much less* than what is in PKIX part 1. In
part 1, there is no disclaimer to the validity of the data between the two
time, at least none that I could find.

>The use of nextUpdate is not restricted to caches.  Caches accelerate basic
>functions; consider LDAP.  That said, we should not presume responses can't
>or won't be cached.  The exact mechanism may vary now by transport.

If we suspect that there will be any caching, we have to add very strong words
about it and about cache time skew problems to the OCSP draft. The time skew
problems for HTTP caches were discussed in grotesque detail on the HTTP WG
mailing list about two years ago, and they are amazingly complex and
dangerous.

If caching is allowed, I believe that we have to change nextUpdate to being
required in every message, and we have to define it much more tightly than we
do now. For instance, what if a cache has a recent response that says
"notRevoked", and then is too busy to cache a following response that says
"revoked"? The user querying the cache would have no idea of the latter, and
without a nextUpdate that means something, would have no way to find out the
real value or to even know that they were getting a stale value.

My preference is to say "no caching is allowed", but if others in the WG want
caching (and I fully agree that it could help relieve OCSP servers), we
need to
look at what that means to users of the cached data.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 23 Mar 1998 08:46:14 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

Paul,

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
>Thank you for responding this quickly, Mike! I believe you are right, that
>this will help reduce the amount about OCSP the WG needs to talk about in
LA.
>
>A few notes:
>
>>Changed all occurrences of "producedAt" with "thisUpdate".
>
>Er, not all of them. You left producedAt in the ASN.1. :-)

Thanks for the catch.

>
>>QUESTION:  Meaning of thisUpdate (formerly producedAt) field.  Is it the
>>time at which the response was signed, or the time when the certificate
was
>>placed on a CRL (that is, the value of thisUpdate of a CRL that may be
used
>>to source OCSP responses)?
>
>I think it has to be the time the response was signed. How would a
>requester know the difference between:
>>2.  revoked responses not sourced by a CRL.
>>3.  revoked responses sourced by a CRL.
>Unless you add a field that says "this response was sourced by a CRL", a
>requestor won't know what date you are referring to.

I agree that the value for thisUpdate should be the time at which a response
was signed.  I'm waiting to hear what others might think.

>
>>QUESTION:  Should we accommodate the following extended error cases?
>>
>>PROPOSED RESOLUTION:  Yes, by adding appropriate INTEGER values to
>>OCSPResponseStatus.
>
>But those integer values better be different than the ones you listed,
>since they overlap with the current response statuses.

Yes.  I did not want to disturb that spectrum prematurely.

>
>At the end of section 2.4, there are multiple disclaimers for the meaning
>of nextUpdate. To me, they make nextUpdate useless. And, now that the HTTP
>carrying mechanism is a POST instead of a GET, meaning the response can't
>be cached, I think there is no more use for nextUpdate. Since it is not
>definitive, based on the disclaimers, I think it should just be taken out.
>If people want it left in, I think it has to mean "the CA assures the
>recipient that the certificate status is valid until the nextUpdate time",
>which is a pretty scary thing to assure.

I agree that the semantics of nextUpdate need refinement.  I've placed a
note in the v.04 text (the one I posted) calling attention to this issue.
I would prefer that nextUpdate have exactly the same semantics as its
counterpart in X.509 CRLs, nothing more and nothing less.

The use of nextUpdate is not restricted to caches.  Caches accelerate basic
functions; consider LDAP.  That said, we should not presume responses can't
or won't be cached.  The exact mechanism may vary now by transport.

>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

Mike

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 23 Mar 1998 11:13: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Unique Identification of a Certificate
To: [email-masked]

> From: Denis Pinkas <[email-masked]>
>
> > Specifically one can eliminate the CA name (both primary and
> > alternative) from certificate identification. Instead one can use (a
> > hash of?) CA public key/serial number combination to identify a
> > certificate. This approach attempts to use one of the fundamental
> > assumptions made by SPKI working group that PKI principals are
> > essentially signing keys and names are just some of the attributes bound
> > to the key by means of issuing a certificate.
>
> In order to identify/fetch a certificate, the only way *for PKIX* to
> identify/retrieve a certificate is to use a CA name first, associated
> with either a subject name or a certificate serial number.
>
> This message is sent to the wrong mailing list. It belongs to SPKI, not
> PKIX.

I disagree.  Although the SPKI key-is-principal principle is unsuited
for identifying entities, it is perfectly reasonable to use a public key
to identify a specific issuer certificate.  The X.509 standard
authorityKeyIdentifier extension, which "identifies the public key to
be used to verify the signature on this certificate or CRL", recognizes
that fact.

If every CA had subjectKeyIdentifier in it's own certificates and
authorityKeyIdentifier in every certificate it issued, then one could
could fetch issuer certificates by key identifier.  But since that
practice is not ubiquitous (and if you allow a CA to have more
than one cert with a given key), it's also necessary to include the
issuer/serialNumber in any scheme to uniquely identify a certificate.

> CertID                  ::=     SEQUENCE {
>          issuerKeyHash            Hash,
>          serialNumber                    CertificateSerialNumber,
> }
>
> where issuerKeyHash is a hash of subjectPublicKeyInfo field from the
> corresponding CA certificate,

This is a reasonable approach if you ignore the cert retrieval and
multiple-key issues, however you still need to specify the hash
algorithm since it's inappropriate to hard code a single algorithm
into the standard:

   CertID ::= SEQUENCE {
      issuerKeyID       KeyID,
      serialNumber      CertificateSerialNumber }

   KeyID  ::= CHOICE {
      publicKey         [0] SubjectPublicKeyInfo,
      sha1KeyHash       [1] OCTET STRING,     -- SHA1 of SubjectPublicKeyInfo
      ripemd160KeyHash  [2] OCTET STRING,
       ...       }

All in all, it gets pretty ugly if you want to make it work in all cases.
It may be easier just to use the existing authority and subject key
identifier extensions instead of trying to design something new.

BTW, the current definition of AuthorityKeyIdentifier is an offense to
the sensibilities!  It's as if someone sat around and thought "ASN.1
has a WITH COMPONENTS construct - it'd be a shame if we couldn't come
up with some excuse to use it." The current extension should be
deprecated and replaced with:

   AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier   KeyIdentifier OPTIONAL,
      authorityCert   IssuerSerial OPTIONAL }

where IssuerSerial is as defined in X.509 (GeneralNames, serial number,
and optional UID).

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 23 Mar 1998 16:19:19 -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 Update
To: [email-masked]

Michael Myers wrote:

(...)

> NEW AND DEFERRED REQUIREMENTS
> -----------------------------
>
> Delegation
> ----------
> Deleted text addressing authority delegation requirements per recent list
> traffic on the subject.

Before addressing delegation, we need to solve the basic problem which
is to identify the right OCSP, when ambiguous CA names are being used.
This item should be moved in the "QUESTIONS FOR DISCUSSION" list.

(...)

> QUESTIONS FOR DISCUSSION
> ------------------------

(...)

> QUESTION:  Should we accommodate the following extended error cases?
>
> Standard values for reason-text SHALL include:
> "1   The root for this certificate is not trusted on this responder."

This item is no more relevant. We do not address validation, but
revocation status only.

> "2   Could not find CA’s public key."

This item is no more relevant. If it is the right OCSP, then it must
have the right information, otherwise it is a status like "service
temporary unavailable".

> "3   CA’s public key invalid."

I fear this also has to do with validation. Please explain ... or
delete.  :-)

> "4   CA’s public key revoked."
> "5   CA’s public key expired."

This status would only be sent if the CA certificate has not be renewed
in time; otherwise there should be a nice rollover between CA public
keys.

> "6   CA not authorized for Subject’s name."

This item is no more relevant. We do not address validation, but
revocation status only.

> "7   CA not authorized for Subject’s privileges."

This item is no more relevant. We do not address validation, but
revocation status only.

> "8   CA’s public key did not validate signature."

Please explain.

> "9   Could not find CA’s revocation information."
> "10  CA’s CRL out of date."

Fine.

(...)

I would like to add an additional topic to this list, since it seems
that we are re-inventing a new "year 2000" problem. Suppose that I
received a signed message on the monday but that the certificate has
expired during the week-end, I fear that I will get an expired status in
place of a "notRevoked" status.

Add the following question:

QUESTION: Is the "expired" status really needed/meaningful ?

Denis

P.S. There is a new version attached. I would like to mention that there
might be some good reason why the IETF does not agree to publish new
drafts after the deadline.

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 23 Mar 1998 15:38:54 -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] Unique Identification of a Certificate
Comments: To: Ambarish Malpani <[email-masked]>
Comments: cc: "Ietf-Smime (E-mail)" <[email-masked]>
To: [email-masked]

See an updated proposal for CertUID at the end of this E-mail.

Ambarish Malpani wrote:

> Hi Denis,
>     I joined the SMIME mailing list just recently, so I am not certain
> of the problem you guys are trying to solve. Let me explain the
> issues in RCSP and the reasoning for choosing the method I have
> for trying to uniquely identify a cert:

> In RCSP, a client is sending over one or more certificates to an
> RCSP responder, to check their revocation status.
> I think we all agree that issuer/serial is sufficient to uniquely
> identify a certificate.

I would disagree with this, unless "issuer" is a FDN in the X.521 sense.

> So the question is: how does one uniquely identify an issuer.

This is not the right question.   :-(

> I submit that the DN is not enough, because it is possible for
> the to be DN name clashes - either maliciously, or because two
> groups don't talk to each other before they choose their names.

DN can clash when they are RDNs (Relative Distinguished Names).

> There really is no way of enforcing uniqueness is issuer DNs all
> over the world.

Correct.

> However, public keys don't suffer from the problem of impersonation.
> If somebody else claims to have the same public/private key as me,
> it is easy to prove otherwise.

OK.

> Therefore, we have chosen to use the issuerDN, issuerPublicKey
> and CertificateSerialNumber to uniquely identify a cert. (I need
> to add the issuerAltName also, as you have).

The problem to consider is an empty DN and the use of an issuerAltName.
The issuerAltName and the CertificateSerialNumber do not necessarily
identify uniquely a certificate unless some additional assumptions are
made on the structure of the issuerAltName.

> As an optimization, to reduce the size of a request, we ask the
> requestor to hash the issuerDN and issuerPublicKey in the request
> rather than sending all the bytes.

Hold on a second. You suppose an upstream problem already solved !
If you get a signed message, you may need to identify who signed it and
with which certificate. The structure you propose below does not allows
this, unless by some magic you get an hint.

> Adding the certificateHash in the CertUID doesn't help us identify
> the cert at all, because as an RCSP responder, I don't have the
> cert itself - so I can't verify the CertHash against anything.

But it does help the requester  :-)

See also the response I sent today to Carlisle, where I raise the basic
question on the means to identify the right OCSP. If that question is
solved, then your problem is also solved. However, I do not claim that
the answer to that question is unique or easy. :-)

> As an aggregator of revocation data/CRLs from multiple CAs, we
> would like to be able to accept all CRLs - including ones where
> the DNs might clash.
>
> Is the SMIME problem different from this one? Does the recipient
> already have the certificate the sender is referring to?
>
> Regards,
> Ambarish
>
> P.S. For those who haven't been actively following these groups,
> my suggestion for cert identification is:
>
> CertID                  ::=     SEQUENCE {
>         issuerNameAndKeyHash            Hash,
>         serialNumber                    CertificateSerialNumber,
> }
>
> IssuerNameAndKey                ::=     SEQUENCE {
>         issuerDN                        Name,
>         issuerAltName                   IssuerAltName OPTIONAL,
>         issuerPublicKey                 SubjectPublicKeyInfo
> }
>
> i.e. you identify a cert by the hash of the IssuerNameAndKey
> and a serial number.
>
> The hash includes the public key of the issuer - this prevents the
> Banana Republic CA from impersonating our well beloved and well
> trusted US CA ;-).
>
> Ofcourse, if keeping the size of the request small is not important,
> or the recipient might not be able to figure out the issuer from
> the hash, it might make sense to send IssuerNameAndKey instead
> of its hash.
>
> Denis Pinkas wrote:
>
> > There is no final position yet, but it seems that we are going towards
> > the following structure:
> >
> > CertUID ::=     SEQUENCE {
> >      issuerDN           Name,
> >      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
> >      serial             CertificateSerialNumber,
> >      certificateHash    CertHash
> > }
> >
> > This allows the support of alternate names and the certificate hash
> > allows to make the difference between certificates that would be issued
> > by CAs having the same name.
> >
> > In any case, I would recommend that the pkix group and the smime group
> > adopt the same structure.
> >
> > Denis

There has been a proposal to make the certificateHash optional. If the
issuerDN is a FDN, then the certificateHash is not needed, so this is a
good reason. If the  issuerAltName has some form of hierarchy that
allows it to be unambiguous, in the same way the certificateHash is not
needed. In all the other cases, it is needed.

I would thus propose the following structure :

CertUID ::=     SEQUENCE {
      issuerDN           Name,
      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
      serial             CertificateSerialNumber,
      certificateHash    CertHash OPTIONAL
}

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 23 Mar 1998 14:18:30 -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] New OCSP Requirements (and new straw poll...)
To: [email-masked]

Carlisle,

I fear that you are opening a new topic of discussion. You wrote:

> > Certificate Identification  -  I think that CA DName with Serial
> > Number is sufficient.
>
> Denis and Ambarish both make valid points here:  we should try to align
> with the S/MIME group if at all possible, but the structure being
> discussed in that group is not sufficient if the OCSP responder does not
> have the certificate itself (e.g., if it only has the issuer's
> certificate and signed revocation information).  Perhaps a solution is
> to add "issuerCertHash" to the CertUID structure, but this is starting
> to look a bit unwieldy...

Another answer to the question would be to modify the format of the CRL
!
When the format of the CRL was designed, the name of the CA was a DN. So
there could be no ambiguity on the name of the CA. We now accept
Alternate names. This allows name collision between CAs.

If the CRLs were using the same structure (i.e. would add the
certificate hash in the CRL) then the OCSP responder could make the
check without the need to get the certificate. Also valid technically, I
do not think, it would be appropriate to make that change at this time,
if we can find another acceptable solution.

Another way is to suppose that the client may get the certificate and
find in the certificate enough information that allows him to make sure
that it talks to a right delegate of the CA.

We should address that issue in the "Security Considerations" section.

" For this service to be effective, requesters must connect to the
*right* certificate status service provider".

If we can correctly address that issue, then we can possibly solve the
problem of CA name homonyms.

I propose to add an item like "Right OCSP" to the list of issues to be
solved and identified by Mike.

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 23 Mar 1998 12:28:25 -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] Unique Identification of a Certificate
To: [email-masked]

Slava Galperin wrote:
>
> Ambarish Malpani wrote:
> >
> >
> > In RCSP, a client is sending over one or more certificates to an
> > RCSP responder, to check their revocation status.
> > I think we all agree that issuer/serial is sufficient to uniquely
> > identify a certificate.
> > So the question is: how does one uniquely identify an issuer.
> > I submit that the DN is not enough, because it is possible for
> > the to be DN name clashes - either maliciously, or because two
> > groups don't talk to each other before they choose their names.
> > There really is no way of enforcing uniqueness is issuer DNs all
> > over the world.
> > However, public keys don't suffer from the problem of impersonation.
> > If somebody else claims to have the same public/private key as me,
> > it is easy to prove otherwise.
> > Therefore, we have chosen to use the issuerDN, issuerPublicKey
> > and CertificateSerialNumber to uniquely identify a cert. (I need
> > to add the issuerAltName also, as you have).
> > As an optimization, to reduce the size of a request, we ask the
> > requestor to hash the issuerDN and issuerPublicKey in the request
> > rather than sending all the bytes.
>
> Actually if we do believe in the uniqueness of the CA signing key pair
> (which would better be true ! ;-) we can take even more extreme approach
> to identifying a cert.
>
> Specifically one can eliminate the CA name (both primary and
> alternative) from certificate identification. Instead one can use (a
> hash of?) CA public key/serial number combination to identify a
> certificate. This approach attempts to use one of the fundamental
> assumptions made by SPKI working group that PKI principals are
> essentially signing keys and names are just some of the attributes bound
> to the key by means of issuing a certificate.

In order to identify/fetch a certificate, the only way *for PKIX* to
identify/retrieve a certificate is to use a CA name first, associated
with either a subject name or a certificate serial number.

This message is sent to the wrong mailing list. It belongs to SPKI, not
PKIX.

> Although X.509 world heavily relies on combination of name/key
> identifier in certificate chaining I guess it would be a pretty safe
> assumption that most CA never use two CA certificates with different CA
> name and same key. Even if CA signing key pair is attached to many
> different names (possibly of different name forms), these names form
> equivalence class and are specified in a single CA certificate possibly
> using a combination of subject and subjectAlternativeName.
>
> Technically I am proposing to use either
>
> CertID                  ::=     SEQUENCE {
>          issuerKeyHash            Hash,
>          serialNumber                    CertificateSerialNumber,
> }
>
> where issuerKeyHash is a hash of subjectPublicKeyInfo field from the
> corresponding CA certificate, or
>
> CertID                  ::=     SEQUENCE {
>          issuerKey          SubjectPublicKeyInfo,
>          serialNumber                    CertificateSerialNumber,
> }
>
> in case we are afraid of the hash collisions and are willing to
> sacrifice some bandwidth for some peace of mind.
>
> Note however, that both in the original RCSP spec and in my proposed
> scheme above there is another interesting open problem of dealing with
> the CA
> key change-over, i.e. when various subsets of the set of all issued
> certificates (and CRLs !) are signed by different signing keys
>
> I would be very interested in group's comments.
> --
> Slava Galperin          Certified Certificate Certifier
> [email-masked]   tel: 650.937.6757
>
>  It doesn't matter so much whether you've won the war or lost it.
>  What matters is who you have lost it to.
>                             -- From the memoirs of a married man

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Scott Guthery <[email-masked]>
Date:         Mon, 23 Mar 1998 05:15:44 -0500
Reply-To: Scott Guthery <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Scott Guthery <[email-masked]>
Subject:      [IETF-PKIX] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0074_01BD561A.BB3E4280
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Perry Metzger notes ...

>In any real financial transaction system in use *today*, the
>relationships are bilateral and there is no need for third party
>identity verification, since the bilateral counterparties have
>prearranged their relationship.

Barter is the only one I can think of and even in this case there are
consumer protection laws.  Cash is backed by social 'suasion or
its issuer.  Checks are backed by a legal system and its
incarceration powers. Credit and debit cards rest on contracts
between the cardholder and the merchant with the bank or the
bankcard association.  Giros, ATMs, ACH etc. all have active
third party involvement.

The question is not if there will be a third party but who will it be.  That's
where the tectonic battle is today.

Being a third party to financial transactions is a very, very good
business to be in which is exactly why many governments give
themselves an exclusive license.  What is happening is that a new
competitor with a much lower cost structure has entered the market.
The new competitor is also offering to solve some anciallary
problems which has at least interested the monopolists who have
responsibility for these problems too.

1) The trick is extracting the transaction fee.  Sometimes it's only
    float, seigniorage or escheate. "Only" is used very loosely here.
   Seigniorage on US cash is worth roughly $25B/year and 1/4 of
   purchased French phone cards are never used.

2) All third parties will limit their risk and will seek to distribute what
     they can't eliminate.  Certificates are quanta of risk.  They have
     two useful properties as compared to existing risk packages: they
    encapsulate much small units of risk and their time unit is seconds
    rather than years.  Order of magnitude smaller risk for an order
    of magnitude less time all in a net-friendly format.  Hmmmmmm.

Digital certificates are not about identity.  They are about risk.

All IMHO, of course.

Cheers, Scott

------=_NextPart_000_0074_01BD561A.BB3E4280
Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="smime.p7s"

------=_NextPart_000_0074_01BD561A.BB3E4280--

Approved-By:  Stephen Kent <[email-masked]>
Date:         Sun, 22 Mar 1998 16:50:03 -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] New OCSP Requirements (and new straw poll...)
To: [email-masked]

Folks,

The ASN.1 change was clear enough to vote on.  Given the broader set of
proposed changes we are now discussing I think it worthwhile to purse this
in more detail at the WG meetings in LA. We can continue to explore these
issues on the mailing list in preparation for the meeting. However, I think
it premature to suggest that a solid vote for the use of ASN.1 necessarily
implies a need to shift from one document, to another as a basis for
further discussion.  Let's give the document authors an opportubity to work
in that issue over the next week.

steve

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Sun, 22 Mar 1998 13:29:09 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Update
To: [email-masked]

Thank you for responding this quickly, Mike! I believe you are right, that
this will help reduce the amount about OCSP the WG needs to talk about in LA.

A few notes:

>Changed all occurrences of "producedAt" with "thisUpdate".

Er, not all of them. You left producedAt in the ASN.1. :-)

>QUESTION:  Meaning of thisUpdate (formerly producedAt) field.  Is it the
>time at which the response was signed, or the time when the certificate was
>placed on a CRL (that is, the value of thisUpdate of a CRL that may be used
>to source OCSP responses)?

I think it has to be the time the response was signed. How would a
requester know the difference between:
>2.  revoked responses not sourced by a CRL.
>3.  revoked responses sourced by a CRL.
Unless you add a field that says "this response was sourced by a CRL", a
requestor won't know what date you are referring to.

>QUESTION:  Should we accommodate the following extended error cases?
>
>PROPOSED RESOLUTION:  Yes, by adding appropriate INTEGER values to
>OCSPResponseStatus.

But those integer values better be different than the ones you listed,
since they overlap with the current response statuses.

At the end of section 2.4, there are multiple disclaimers for the meaning
of nextUpdate. To me, they make nextUpdate useless. And, now that the HTTP
carrying mechanism is a POST instead of a GET, meaning the response can't
be cached, I think there is no more use for nextUpdate. Since it is not
definitive, based on the disclaimers, I think it should just be taken out.
If people want it left in, I think it has to mean "the CA assures the
recipient that the certificate status is valid until the nextUpdate time",
which is a pretty scary thing to assure.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Michael Myers <[email-masked]>
Date:         Sun, 22 Mar 1998 10:55:14 -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: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] OCSP Update
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01BD5580.FE31E6E0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

All,

I've attached an update to the current OCSP draft that incorporates the
recent ASN.1 poll and requirements comments as well as the contributions
put forward by Malpani and others.  As I noted earlier, my intent here is to
establish a single, harmonized draft that fairly represents the needs
of all who hold an opinion on the evolution of OCSP as a draft standard.

Resolving the comments and contributions revealed further detailed points of
dicussion which I've listed below.  These fall into two broad categories:
New and Deferred Requirements and Questions for Discussion.  Interested
parties are encouraged to review and comment in the spirit of our recent
ASN.1 and requirements poll.  With any luck at all, the OCSP agenda topic in
L.A. will be nothing more than a status report on our consensus regarding
these points.  If I've missed anyone's positions in the recent flurry of
exchanges regarding OCSP, please let me know so I can be sure to at least
get it into the L.A. agenda if not into the next rev of the draft.

Mike

NEW AND DEFERRED REQUIREMENTS
--------------------------------------------------------

Delegation
---------------
Deleted text addressing authority delegation requirements per recent list
traffic on the subject.

Requirement on Basic Response
----------------------------------------------
Added the following requirement to ensure a minimum level of
interoperability:

"OCSP responders SHALL be capable of recognizing and responding to the
id-pkix-ocsp-basic response type.  Correspondingly, OCSP clients SHALL be
capable of receiving and processing the id-pkix-ocsp-basic response type."

Acceptable Response Types
---------------------------------------
Added the following requirements to ensure a minimum level of
interoperability:

"As noted in Section 3.3, OCSP responders SHALL be capable of recognizing
and responding to the id-pkix-ocsp-basic response type.  Correspondingly,
OCSP clients SHALL be capable of receiving and processing the
id-pkix-ocsp-basic response type."

Use of thisUpdate
------------------------
Changed all occurrences of "producedAt" with "thisUpdate".

Interpretation of "time" in StatusWithTime
---------------------------------------------------------------------
Added the following note regarding StatusWithTime:  If the certStatusType is
revoked, onHold or expired, the "time" field of StatusWithTime is the time
of revocation, suspension or expiration respectively.  The date returned for
expiration should match the notAfter date of the certificate’s validity
interval.

Expired State
-----------------
Added an "expired" status value so that a definitive assertion can be made
when the certificate is in this state.  Applications shouldn't query in such
a circumstance, but it's forseeable that some will anyway.

notFound error state
---------------------------
Added a "notFound" error state and the following text:

A recipient of a request may not be able to resolve a reference to the
subject certificate; a value of notFound is returned in such a case.  This
value should not be taken as confirmation of the certificate's existence.

noCRL error state
-------------------------
Added a "noCRL" error state and the following text:

An extension is defined to enable delivery of CRLs with OCSP responses.
However, there is no requirement to list certificates on a CRL in order to
use OCSP to acquire revocation status on those certificates. The error value
noCRL is defined for this instance.

Version
----------
Added an explicit definition of v1:

Version  ::=  INTEGER  {  v1(0) }

QUESTIONS FOR DISCUSSION
-------------------------------------------

QUESTION:  Meaning of thisUpdate (formerly producedAt) field.  Is it the
time at which the response was signed, or the time when the certificate was
placed on a CRL (that is, the value of thisUpdate of a CRL that may be used
to source OCSP responses)?

Note:  There is no requirement to place a certificate on a CRL in order to
implement OCSP.

PROPOSED RESOLUTION:  We have three cases to consider:

1.  notRevoked responses.
2.  revoked responses not sourced by a CRL.
3.  revoked responses sourced by a CRL.

The dominant number of OCSP responses will be positive responses; that is,
indications of non-revocation.  In these cases it is clear that the time of
response production is the only relevant value.

Similarly,  revoked responses not sourced by a CRL should indicate the
response signing time in the value of thisUpdate of a BasicResponse.

Non-repudiation is enhanced when witnessing parties date their signatures.
Since the time field of StatusWithTime could be used to indicate the value
of thisUpdate in a CRL used to source OCSP responses, it seems most useful
to use signing time uniformly.

QUESTION:  Should we accommodate the following extended error cases?

Standard values for reason-text SHALL include:
"1   The root for this certificate is not trusted on this responder."
"2   Could not find CA’s public key."
"3   CA’s public key invalid."
"4   CA’s public key revoked."
"5   CA’s public key expired."
"6   CA not authorized for Subject’s name."
"7   CA not authorized for Subject’s privileges."
"8   CA’s public key did not validate signature."
"9   Could not find CA’s revocation information."
"10  CA’s CRL out of date."

PROPOSED RESOLUTION:  Yes, by adding appropriate INTEGER values to
OCSPResponseStatus.

QUESTION:  What about the text strings?

PROPOSED RESOLUTION:  Keep the text strings in the spec for guidance to
implementors.  Some implementations may wish to provide more user-friendly
dialogs.

QUESTION:  Delete Policy ID extension?

PROPOSED RESOLUTION:  Yes, pending a direct request for its re-inclusion.
It's unclear how this extension would be used in practice.

QUESTION:  Do we keep CERTIFICATE DATA REQUIRED?

PROPOSED RESOLUTION:  Comments anyone?   I left it in for now.

QUESTION:  How best to match a single response to a request?  Inclusion of
the certificates in the response wastes bandwidth, particularly since the
requestor is already in possession of the certificates.

PROPOSED RESOLUTION: Require clients to locally compute certID to match a
response to a request that contains multiple certificates.  Amend syntax of
SingleResponse to specify certID only.

QUESTION: OCSP defined a mandatory "Responder Key Id" field in the response
to provide clients a means to determine which public key to use to validate
the signature on the response.  The RCSP contribution appears to define two
other methods:

1.  specification of "certs" in BasicOCSPResponse; and
2.  "responderName" in ResponseData.

The "certs" field is optional while the responderName is not.  However, the
possibility exists that a given name may be simultaneously associated with
more than one valid signing key.  Clients need a mechanism to identify the
signing key needed to validate the signature on a response.

PROPOSED RESOLUTION:  Comments towards a consensus are welcome.  For a
strawman, consider deleting "certs" from BasicOCSPResponse.  While "certs"
is optional, past experience has shown that applications which implement
support for such optional syntax will more likely than not always send the
certs since there's no way to predict when the recipient doesn't need them.
Doing so would seriously impact the bandwidth efficiencies OCSP set out to
address.   Furthermore, OCSP is not a key distribution protocol.  These
requirements are being addressed by other PKIX work efforts.  To identify
the signing key, replace responderName field of ResponseData and its
associated Name syntax with responderKey and KeyIdentifier syntax, where
KeyIdentifier syntax is intended to align with SubjectKeyIdentifier
definition in PKIX Part 1.  That is, a SHA-1 hash of the key in question.

I amended the definition of ResponseData as follows, pending resolution of
this point:

ResponseData ::= SEQUENCE {
   version                            [0] EXPLICIT Version DEFAULT v1,
   reponderID                           ResponderID,
   responses                           SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName   [0] Name,
   byKey        [1] KeyID }

KeyID ::= KeyIdentifier –-as defined in PKIX Part.1 for SubjectKeyIdentifier

------=_NextPart_000_0013_01BD5580.FE31E6E0
Content-Type: text/plain;
        name="draft-ietf-pkix-ocsp-03.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
        filename="draft-ietf-pkix-ocsp-03.txt"

PKIX Working Group                               Michael Myers(VeriSign)
draft-ietf-pkix-ocsp-03.txt                         Rich Ankney (CertCo)
                                             Ambarish Malpani (Valicert)
                                               Slava Galperin (Netscape)
                                   Carlisle Adams (Entrust Technologies)

Expires in 6 months                                           March 1998

                   X.509 Internet Public Key Infrastructure
                  Online Certificate Status Protocol - OCSP
                        <draft-ietf-pkix-ocsp-03.txt>

Status of this Memo

This document is an Internet-Draft. Internet-Drafts  are  working=20
documents  of the Internet Engineering Task Force (IETF), its areas, and =

its working groups. Note that other groups may also distribute working=20
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum  of  six  months =

and  may be  updated,  replaced, or obsoleted by other documents at any=20
time. It is inappropriate to use Internet-Drafts as  reference  material =

or to cite them other than as "work in progress."

To learn the current status of  any  Internet-Draft,  please  check  the =

"1id-abstracts.txt"  listing  contained  in  the  Internet-Drafts Shadow =

Directories   on   ftp.is.co.za   (Africa),   nic.nordu.net    (Europe), =

munnari.oz.au   (Pacific  Rim),  ds.internic.net  (US  East  Coast),  or =

ftp.isi.edu (US West Coast).

1. Abstract

This document specifies a protocol useful in determining the
current status of a digital certificate without the use of CRLs.
Additional mechanisms addressing PKIX operational requirements are
specified in separate documents.

Section 2 provides an overview of the protocol. Section 3 goes=20
establishes functional requirements, while section 4 provides the=20
details of the protocol. In section 5 we cover security issues with the
protocol. Appendix A demonstrates OCSP over HTTP and appendix B=20
accumulates ASN.1 syntactic elements.

2. Protocol Overview

In lieu of or as a supplement to checking against a periodic CRL, it may
be necessary to obtain timely status regarding a  certificate=92s=20
revocation state (cf. PKIX Part 1, Section 3.3). Examples include high-
value funds transfer or the compromise of a highly sensitive key.

The Online Certificate Status Protocol (OCSP) enables applications
to determine the revocation state of an identified certificate. OCSP may =

Myers, Ankney, Malpani, Galperin, Adams                        [Page 1]
=0CINTERNET DRAFT                                                March =
1998

be used to satisfy some of the operational requirements of providing=20
more timely revocation information than is possible with CRLs.  An OCSP=20
client issues a status request to an OCSP responder and suspends=20
acceptance of the certificate in question until the responder
provides a response.

This protocol specifies the data that needs to be exchanged between an
application checking the revocation status of a certificate and the
server providing that status.

2.1 Request

An OCSP request contains the following data:

- protocol version
- service request
- target certificate identifier or a single end-entity certificate
- optional extensions which MAY be processed by the OCSP Responder

Upon receipt of a request, an OCSP Responder determines if: 1) the=20
message is well formed, 2) the responder is configured to provide the=20
requested service, and 3) the responder can perform the requested=20
service for the subject certificate.  If any one of the prior conditions =

are not met, the OCSP responder produces an error message; otherwise, it =

returns a definitive response.

2.2 Response

All definitive response messages SHALL be digitally signed.  The key=20
used to sign the response MUST belong to one of the following:

- the CA who issued the certificate in question
- a Trusted Responder whose public key is trusted by the requester

A definitive response message is composed of:

- response type identifier (to allow for different response types)
- version of the response
- name of the responder
- responses for each of the certificates in a request
- optional extensions
- signature algorithm OID
- signature computed across hash of the response

The response for each of the certificates in a request consists of

- target certificate identifier
- certificate status value
- response validity interval
- optional extensions

This specification defines the following definitive response indicators=20
for use in the certificate status value:

Myers, Ankney, Malpani, Galperin, Adams                        [Page 2]
=0CINTERNET DRAFT                                                March =
1998

- notRevoked
- revoked
- onHold
- expired

The notRevoked state indicates that the certificate is not revoked. It
does not necessarily mean that the certificate was ever issued. Nor
does it mean that the certificate is in its validity interval. A
notRevoked state by an OCSP responder DOES NOT absolve the application
of the responsibility of checking that the certificate is in its
validity period and has been correctly signed.

The revoked state indicates that the certificate has been revoked.

The onHold state corresponds to valid certificates that are=20
operationally suspended in accordance with PKIX Part 1.

A request that returns an expired state indicates that the validity of=20
the subject certificate has expired.  Applications SHOULD check the=20
validity interval of a certificate and not perform an OCSP request if=20
the certificate=92s validity has expired.

2.3 Exception Cases

In case of errors, the OCSP Responder may return an error message.
Errors can be of the following types:

- malformedRequest
- internalError
- tryLater
- notFound
- certRequired
- noCRL

A server produces the malformedRequest response if the request received=20
does not conform to the OCSP syntax.

The response internalError indicates that the OCSP responder reached
an inconsistent internal state. The query should be retried, potentially
with another responder.

In the event that the OCSP responder is operational, but unable to=20
return a status for the requested certificate, the tryLater response=20
can be used to indicate that the service exists, but is temporarily=20
unable to respond.

A recipient of a request may not be able to resolve a reference to the=20
subject certificate; a value of notFound is returned in such a case.=20
This value should not be taken as confirmation of the certificate's=20
existence.

The response certRequired is returned in cases where the server requires =

the client to supply the certificate data itself in order to construct a =

response.

Myers, Ankney, Malpani, Galperin, Adams                        [Page 3]
=0CINTERNET DRAFT                                                March =
1998

An extension is defined to enable delivery of CRLs with OCSP responses.  =

However, there is no requirement to list certificates on a CRL in order=20
to use OCSP to acquire revocation status on those certificates. The=20
error value noCRL is defined for this instance.

2.4 Response Pre-production

The response validity interval noted in the prior section is composed of =

a {thisUpdate, nextUpdate} pair of elements in the response syntax.=20
Section 4.2 provides details of the response syntax.

OCSP responders MAY pre-produce signed responses specifying the current=20
status of certificates at the time the response was produced.  The time=20
at which the response was produced SHALL be reflected in the thisUpdate=20
field of the response.

If responses are pre-produced, then for a given certificate, the=20
periodicity of this pre-production SHOULD match the response validity=20
interval of the most recently produced response.

[need to resolve the above statement with the following RCSP assertions, =

esp. with respect to positive responses.  Question put to the list.]

The time at which the response was known to be correct SHALL
be specified in the producedAt field of the response. This time is not
necessarily the same as the time at which the response was produced -
e.g. if the responder obtains a CRL from a CA and creates pre-produced
responses, the thisUpdate time should specify the thisUpdate time in
the CRL.

The producer of the response MAY include a value for nextUpdate.  The=20
exact interval between thisUpdate and nextUpdate for given response is=20
a matter of local security and operational policy.  If the nextUpdate=20
field is not present, the response is is known to be correct at the=20
thisUpdate time.  Equivalently, the nextUpdate field is considered to be =

the same as the thisUpdate field.

No assertions are being made about the current state of the certificate, =

nor are any recommendations being made as to when the requestor should=20
check again with the responder.  If the value of nextUpdate is set, it=20
is just a hint, not a guarantee, of when the responder expects to have=20
new information about that certificate's status.

3. Functional Requirements

3.1 Certificate Content

In order to convey to OCSP clients a well-known point of information=20
access, CAs SHALL provide the capability to include the=20
AuthorityInfoAccess extension (defined in PKIX Part 1, section 4.2.2.1)=20
in certificates that can be checked using OCSP.  Alternatively, the=20
accessLocation for the OCSP provider may be configured locally at the=20
OCSP client.

Myers, Ankney, Malpani, Galperin, Adams                        [Page 4]
=0CINTERNET DRAFT                                                March =
1998

CAs that support an OCSP service, either hosted locally or provided by
an Authorized Responder, MAY provide a value for a
uniformResourceIndicator (URI) accessLocation and the OID value
id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate
corresponds to the URL placed into an OCSP request.

3.3 Error Responses

Upon receipt of a request which fails to parse, the receiving OCSP=20
responder SHALL respond with an error message.  Error responses MAY be=20
signed.

3.5 Signed Response Acceptance Requirements

Prior to accepting a signed response as valid, OCSP clients SHALL=20
confirm that:

1.  The certificate identified in a received response corresponds to=20
    that which was identified in the corresponding request;
=20
2.  The signature on the response is valid;
=20
3.  The identity of the signer matches the intended recipient of the=20
    request.

4. Detailed Protocol

The ASN.1 syntax imports terms defined in the X.509 Certificate and CRL
Profile Internet Draft. For signature calculation, the data to be signed =

is encoded using the ASN.1 distinguished encoding rules (DER) [X.690].

ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.

The terms imported from elsewhere are: Version, Extensions,=20
CertificateSerialNumber, SubjectPublicKeyInfo, Name,=20
AlgorithmIdentifier, GeneralizedTime

4.1 Request Syntax

OCSPRequest     ::=3D  SEQUENCE {
   version             [0]  EXPLICIT Version DEFAULT v1,
   hashAlgorithm            AlgorithmIdentifier,
   requestList            SEQUENCE OF Request,
   requestExtensions   [1]  EXPLICIT Extensions OPTIONAL }

Version  ::=3D  INTEGER  {  v1(0) }

Request ::=3D CHOICE {
   certID              [0]  EXPLICIT CertID,
   cert                [1]  EXPLICIT Certificate }

Myers, Ankney, Malpani, Galperin, Adams                        [Page 5]
=0CINTERNET DRAFT                                                March =
1998

CertID ::=3D SEQUENCE {
   issuerNameAndKeyHash Hash,
   serialNumber         CertificateSerialNumber }

IssuerNameAndKey ::=3D SEQUENCE {
   issuer               Name,
   issuerPublicKey      SubjectPublicKeyInfo }

Hash                    ::=3D   OCTET STRING --hash of IssuerNameAndKey--

3.2 Response Syntax

This section specifies the ASN.1 specification for a confirmation
response. The actual formatting of the message could vary depending on
the transport mechanism used (http, smtp, ldap, etc.).

3.2.1 ASN.1 Specification of the OCSP Response

An OCSP response at a minimum consists of a responseStatus field=20
indicating the processing status of the prior request.  If the value of=20
responseStatus is one of the error conditions, responseBytes are not=20
set.

OCSPResponse ::=3D SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::=3D ENUMERATED {
    successful            (0),      --Response has valid confirmations
    malformedRequest      (1),      --Illegal confirmation request
    internalError         (2),      --Internal error in issuer
    tryLater              (3),      --Try again later
    notFound              (4),      --Certificate not on record
    certRequired          (5)       --Must supply certificate }

3.2.1.1 BasicResponse

The value for responseBytes consists of an OBJECT IDENTIFIER and a=20
response syntax identified by that OID encoded as an OCTET STRING:

ResponseBytes ::=3D     SEQUENCE {
    responseType   OBJECT IDENTIFIER,
    response       OCTET STRING }

For a basic OCSP responder, responseType will be id-pkix-ocsp-basic,
where:

id-pkix-ocsp           OBJECT IDENTIFIER ::=3D { id-ad-ocsp }
id-pkix-ocsp-basic     OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 1 }

OCSP responders SHALL be capable of recognizing and responding to the=20
id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be =

capable of receiving and processing the id-pkix-ocsp-basic response=20
type.

Myers, Ankney, Malpani, Galperin, Adams                        [Page 6]
=0CINTERNET DRAFT                                                March =
1998

The value for response SHALL be the DER encoding of BasicOCSPResponse:

BasicOCSPResponse       ::=3D SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs                [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

The value for signature SHALL be computed on the hash of the DER=20
encoding ResponseData.

3.2.1.2 ResponseData

ResponseData ::=3D SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   reponderID               ResponderID,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::=3D CHOICE {
   byName   [0] Name,
   byKey    [1] KeyHash }

KeyHash ::=3D KeyIdentifier =96-SHA-1 hash as defined in PKIX Part.1

3.2.1.3 SingleResponse

[note: question put to the list regarding bandwidth issues associated=20
with sending certificates back; could just use certID directly since=20
requester already has certificates in question.]

SingleResponse ::=3D SEQUENCE {
   request            Request,
   certStatus         CertStatus,
   producedAt         GeneralizedTime,
   nextUpdate         [0] EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions   [2] EXPLICIT Extensions OPTIONAL }

CertStatus ::=3D CHOICE {
    certStatusType    [0] EXPLICIT CertStatusType (notRevoked | onHold),
    statusWithTime    [1] EXPLICIT StatusWithTime }

StatusWithTime ::=3D SEQUENCE {
    certStatusType    CertStatusType (revoked),
    time              GeneralizedTime }

CertStatusType ::=3D ENUMERATED {
    notRevoked        (0),  --This serial number is not revoked
    revoked           (1),  --Serial number was revoked
    onHold            (2),  --Cert is on hold
    expired           (3)   -- certificate is expired }

Applications SHOULD determine by observation of the certificate=92s=20
validity interval that a certificate is expired.  The expired value of=20

Myers, Ankney, Malpani, Galperin, Adams                        [Page 7]
=0CINTERNET DRAFT                                                March =
1998

CertStatusType defines a value to return when a request is received for=20
a subject certificate in this state.

3.2.2 Notes on OCSP Responses

If the certStatusType is revoked, onHold or expired, the time field of=20
StatusWithTime is the time of revocation, suspension or expiration=20
respectively.  The date returned for expiration should match the=20
notAfter date of the certificate=92s validity interval.

The thisUpdate and nextUpdate fields define a recommended validity
interval. This interval corresponds to the {thisUpdate, nextUpdate}
interval in CRLs. Responses whose nextUpdate value is earlier
than the local system time value SHOULD be considered unreliable.
Responses whose thusUpdate time is earlier than the local system time
SHOULD be considered unreliable.  Responses where the nextUpdate value
is not set are equivalant to a CRL with no time for nextUpdate (see
section 2.3).

3.3 Mandatory and Optional Cryptographic Algorithms

Clients that request OCSP services SHALL be capable of processing=20
responses signed used DSA keys identified by the DSA sig-alg-oid=20
specified in section 7.2.2 of PKIX Part 1.  Clients SHOULD also be=20
capable of processing RSA signatures as specified in section 7.2.1 of=20
PKIX Part 1.  OCSP responders SHALL support the SHA1 hash algorithm.

3.4 Extensions

This section defines some standard extensions.  Support for all=20
extensions is OPTIONAL.  For each extension, the definition indicates=20
its syntax, processing performed by the OCSP Responder, and any=20
extensions which are included in the corresponding response.

3.4.1 Nonce

The nonce cryptographically binds a request and a response to prevent
replay attacks. The nonce is included as one of the requestExtensions
in requests, while in responses it would be included as one of the
responseExtensions.  In both the request and the response, the nonce
will be identified by the object identifier id-pkix-ocsp-nonce, while
the extnValue is the value of the nonce.

id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 2 }

3.4.2 Signed Requests

This extension allows the requester to sign a request. The requestor=20
includes an extension that has the signatureIdentifier, the actual bits=20
of the signature and a sequence of certificates to allow the OCSP=20
responder to verify the signature. The data to be signed is just the=20
basic request (none of the extensions). The OCSP Responder can verify=20
the signature, potentially using certificates that have been included=20

Myers, Ankney, Malpani, Galperin, Adams                        [Page 8]
=0CINTERNET DRAFT                                                March =
1998

with the extension. The signature on a request will be identified by id-
pkix-ocsp-signature, while the value will be SignatureData, where:

id-pkix-ocsp-signature OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 5 }

SignatureData ::=3D SEQUENCE {
   signatureAlgorithm       AlgorithmIdentifier,
   signature                BIT STRING,
   certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

3.4.3 CRL References

It may be desirable for the OCSP responder to indicate the CRL on which=20
a revoked or onHold certificate is found. This can be useful where OCSP=20
is used between repositories, and also as an auditing mechanism. The
CRL may be specified by a URL (the URL at which the CRL is available),
a number (CRL number) or a time (the time at which the relevant CRL
was created). These extensions will be specified as singleExtensions.
The identifier for this extension will be id-pkix-ocsp-crl, while the
value will be CrlID.

id-pkix-ocsp-crl       OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 4 }

CrlID ::=3D SEQUENCE {
   crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
   crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
   crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

For the choice crlUrl, the IA5String will specify the URL at which the
CRL is available. For crlNum, the INTEGER will specify the value of the
CRL number extension of the relevant CRL. For crlTime, the=20
GeneralizedTime will indicate the time at which the relevant CRL was=20
issued.

Note:  There is no requirement to list certificates on a CRL in order to =

use OCSP to acquire revocation status on those certificates.  Therefore=20
inclusion of this extension in a request may yield no CRL information. =20
The error value noCRL is defined for this instance.

3.4.4 Acceptable Response Types

An OCSP client MAY wish to specify the kinds of response types it
understands. To do so, it SHOULD use an extension with the OID
id-pkix-ocsp-response, and the value AcceptableResponses. The OIDs
included in AcceptableResponses are the OIDs of the various response
types this client can accept (e.g., id-pkix-ocsp-basic).

id-pkix-ocsp-response  OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 3 }

AcceptableResponses ::=3D       SEQUENCE OF { id OBJECT IDENTIFIER }

As noted in section 3.3, OCSP responders SHALL be capable of recognizing =

and responding to the id-pkix-ocsp-basic response type. Correspondingly, =

Myers, Ankney, Malpani, Galperin, Adams                        [Page 9]
=0CINTERNET DRAFT                                                March =
1998

OCSP clients SHALL be capable of receiving and processing the id-pkix-
ocsp-basic response type.

3.4.5 Other Extensions

CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are=20
also supported as singleExtensions.

4. Security Considerations

For this service to be effective, certificate using systems must connect =

to the certificate status service provider. In the event such a=20
connection cannot be obtained, certificate-using systems could implement =

CRL processing logic as a fall-back position.

A denial of service vulnerability is evident with respect to a flood of=20
queries constructed to produce error responses.  The production of a=20
cryptographic signature significantly affects response generation cycle=20
time, thereby exacerbating the situation.

Unsigned error responses can be produced more rapidly and thus reduce=20
the danger of this attack. However, unsigned error responses open up the =

protocol to another denial of service attack, where the attacker sends=20
false error responses.

The use of precomputed responses allows replay attacks in which an=20
old (notRevoked) response is replayed prior to its expiration date but=20
after the certificate has been revoked. Deployments of OCSP should=20
carefully evaluate the benefit of precomputed responses against the=20
probability of a replay attack and the costs associated its successful=20
execution.

5. References

[HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee,
       R. Fielding & H. Frystyk, RFC 1945, May 1996.=20

[ABNF] Augmented BNF for Syntax Specifications: ABNF.  D. Crocker,
P.  Overell, RFC 2234, November 1997.

[MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels,
 S. Bradner, RFC 2119, March 1997.

[URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter,
M.  McCahill, RFC 1738, December 1994.

7. Author=92s Address

Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019
[email-masked]
=20

Myers, Ankney, Malpani, Galperin, Adams                        [Page 10]
=0CINTERNET DRAFT                                                March =
1998

Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA  20151
[email-masked]

Ambarish Malpani
ValiCert, Inc.
3160 W. Bayshore Drive
Palo Alto, CA 94303
[email-masked]

Slava Galperin
Netscape Communications Corp.
MV-068
501 E. Middlefield Rd.
Mountain View, CA 94043
[email-masked]

Carlisle Adams
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario
K1V 1A7
Canada
[email-masked]

Appendix A

A.1 OCSP over HTTP

This section describes the formatting that will be done to the request
and response to support HTTP.

A.1.1 Request

An OCSP request is an HTTP 1.0 POST method. The Content-Type header
has the value "application/ocsp-request" while the body of the message
is the DER encoding of the OCSPRequest.

A.1.2 Response

An HTTP-based OCSP response is composed of the appropriate HTTP headers,
followed by the DER encoding of the OCSPResponse. The Content-Type
header has the value "application/ocsp-response". The Content-Length
header SHOULD specify the length of the response. Other HTTP headers
MAY be present and MAY be ignored if not understood by the requestor.

Myers, Ankney, Malpani, Galperin, Adams                        [Page 11]
=0CINTERNET DRAFT                                                March =
1998

Appendix B:  OCSP in ASN.1

OCSPRequest     ::=3D  SEQUENCE {
   version             [0]  EXPLICIT Version DEFAULT v1,
   hashAlgorithm            AlgorithmIdentifier,
   requestList            SEQUENCE OF Request,
   requestExtensions   [1]  EXPLICIT Extensions OPTIONAL }

Version  ::=3D  INTEGER  {  v1(0) }

Request ::=3D CHOICE {
   certID              [0]  EXPLICIT CertID,
   cert                [1]  EXPLICIT Certificate }

CertID ::=3D SEQUENCE {
   issuerNameAndKeyHash Hash,
   serialNumber         CertificateSerialNumber }

IssuerNameAndKey ::=3D SEQUENCE {
   issuer               Name,
   issuerPublicKey      SubjectPublicKeyInfo }

Hash                    ::=3D   OCTET STRING --hash of IssuerNameAndKey--

OCSPResponse ::=3D SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::=3D ENUMERATED {
    successful            (0),      --Response has valid confirmations
    malformedRequest      (1),      --Illegal confirmation request
    internalError         (2),      --Internal error in issuer
    tryLater              (3),      --Try again later
    notFound              (4),      --Certificate not on record
    certRequired          (5)       --Must supply certificate }

BasicOCSPResponse       ::=3D SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs                [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

ResponseData ::=3D SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   reponderID               ResponderID,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::=3D CHOICE {
   byName   [0] Name,
   byKey    [1] KeyHash }

KeyHash ::=3D KeyIdentifier =96-SHA-1 hash as defined in PKIX Part.1

Myers, Ankney, Malpani, Galperin, Adams                        [Page 12]
=0CINTERNET DRAFT                                                March =
1998

SingleResponse ::=3D SEQUENCE {
   request            Request,
   certStatus         CertStatus,
   producedAt         GeneralizedTime,
   nextUpdate         [0] EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions   [2] EXPLICIT Extensions OPTIONAL }

CertStatus ::=3D CHOICE {
    certStatusType    [0] EXPLICIT CertStatusType (notRevoked | onHold),
    statusWithTime    [1] EXPLICIT StatusWithTime }

StatusWithTime ::=3D SEQUENCE {
    certStatusType    CertStatusType (revoked),
    time              GeneralizedTime }

CertStatusType ::=3D ENUMERATED {
    notRevoked        (0),  --This serial number is not revoked
    revoked           (1),  --Serial number was revoked
    onHold            (2),  --Cert is on hold
    expired           (3)   -- certificate is expired }

--Extensions

SignatureData ::=3D SEQUENCE {
   signatureAlgorithm       AlgorithmIdentifier,
   signature                BIT STRING,
   certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

AcceptableResponses ::=3D       SEQUENCE OF { id OBJECT IDENTIFIER }

CrlID ::=3D SEQUENCE {
   crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
   crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
   crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

-- Object Identifiers

id-pkix-ocsp           OBJECT IDENTIFIER ::=3D { id-ad-ocsp }
id-pkix-ocsp-basic     OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 2 }
id-pkix-ocsp-response  OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 3 }
id-pkix-ocsp-crl       OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 4 }
id-pkix-ocsp-signature OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 5 }

Myers, Ankney, Malpani, Galperin, Adams                        [Page 13]

------=_NextPart_000_0013_01BD5580.FE31E6E0--

Priority: normal
Approved-By:  David Chadwick <[email-masked]>
Date:         Sun, 22 Mar 1998 00:06:39 +0000
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Comments:     Authenticated sender is <[email-masked]>
From: David Chadwick <[email-masked]>
Organization: University of Salford
Subject:      Re: [IETF-PKIX] New OCSP Requirements
Comments: To: [email-masked]
To: [email-masked]

> Date:          Sat, 21 Mar 1998 14:21:48 -0800
> Reply-to:      [email-masked]
> From:          Peter Gutmann <[email-masked]>
> Subject:       Re: [IETF-PKIX] New OCSP Requirements
> To:            [email-masked]

> After following the current debate on OCSP-related issues, I thought I'd
> provide my own contribution to online validity checking.  I think this should
> solve all the current problems.  Since it's very short, I've included it
> below.  It's pre-released by just over a week, but I thought it was
> appropriate to post it now while the issue is still under active debate.
>
> Peter.

Unfortunately, because you live in Australia, your draft will only
have a very short time span, insufficient to catch anyone out. This
is because April fool's day only officially lasts until midday, and
when you issue it, it will be March 31 in Europe, and when it expires
at midday in Australia, it will only just have turned midnight on
April 1 in Europe, so we wont have time to check out your extension
or get fooled by it.

Hope this is still intelligible to you down under.
Gooday to you all (or should I say goodnight?)
David

>
> -- Snip --
>
> XIKP Working Group                                              P. Gutmann
> Internet Draft                                      University of Auckland
> expires in six months                                         1 April 1998
>
>                    Internet X.509 Public Key Infrastructure
>             Operational Protocols: Certificate Validity Checking
>                          <draft-ietf-pkix-parp-01.txt>
>
> Abstract
>
>   This document describes an active online certificate revocation protocol
>   which bypasses some of the shortcomings of existing protocols.  The protocol
>   described in this document is Peter's Active Revocation Protocol (PARP),
>   which provides for online validity checking for certificates.
>
>   Please send comments on this document to the Usenet alt.flarf.parp newsgroup.
>
> 1. Protocol Description
>
>   The PARP protocol is very simple and involves an X.509v3 certificate
>   extension which provides a facility for online certificate validity checking.
>   The extension is as follows:
>
>     id-ce-parp OBJECT IDENTIFIER ::= { id-ce 99 }
>
>     PARPObject ::= CHOICE {
>         activeXControl  [0] OCTET STRING,
>         javaApplet      [1] OCTET STRING,
>         win95           [2] OCTET STRING
>         }
>
>   To check a certificates validity, the ActiveX control or Java applet is
>   extracted from the extension and executed.  Since the validity checking is
>   performed entirely by the code contained within the extension, there is no
>   need for tedious protocol specification and interoperability testing, as
>   anything which can run ActiveX or Java can verify a certificate.
>
>   The Win95 option is a special case which applies to older systems running DOS
>   or Windows 3.1 which don't provide support for ActiveX or Java.  This option
>   includes a complete Windows 95 installation in the extension which, when run,
>   installs Win95 on the machine, locates and downloads whatever support is
>   necessary for ActiveX and/or Java (typically a copy of MSIE), and then
>   performs a PARP verification as described above.  CA's which include the
>   Win95 option should be aware that this may lead to a small increase in
>   certificate size.
>
> Security Considerations
>
>   CA's which include the Win95 option may wish to operate from a different
>   country than the one in which their subjects are located, preferably one with
>   strong gun control legislation.
>
>
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 370 957 287
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
***************************************************

Approved-By: [email-masked]
Date:         Sat, 21 Mar 1998 14:21:48 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Gutmann <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

After following the current debate on OCSP-related issues, I thought I'd
provide my own contribution to online validity checking.  I think this should
solve all the current problems.  Since it's very short, I've included it
below.  It's pre-released by just over a week, but I thought it was
appropriate to post it now while the issue is still under active debate.

Peter.

-- Snip --

XIKP Working Group                                              P. Gutmann
Internet Draft                                      University of Auckland
expires in six months                                         1 April 1998

                   Internet X.509 Public Key Infrastructure
            Operational Protocols: Certificate Validity Checking
                         <draft-ietf-pkix-parp-01.txt>

Abstract

  This document describes an active online certificate revocation protocol
  which bypasses some of the shortcomings of existing protocols.  The protocol
  described in this document is Peter's Active Revocation Protocol (PARP),
  which provides for online validity checking for certificates.

  Please send comments on this document to the Usenet alt.flarf.parp newsgroup.

1. Protocol Description

  The PARP protocol is very simple and involves an X.509v3 certificate
  extension which provides a facility for online certificate validity checking.
  The extension is as follows:

    id-ce-parp OBJECT IDENTIFIER ::= { id-ce 99 }

    PARPObject ::= CHOICE {
        activeXControl  [0] OCTET STRING,
        javaApplet      [1] OCTET STRING,
        win95           [2] OCTET STRING
        }

  To check a certificates validity, the ActiveX control or Java applet is
  extracted from the extension and executed.  Since the validity checking is
  performed entirely by the code contained within the extension, there is no
  need for tedious protocol specification and interoperability testing, as
  anything which can run ActiveX or Java can verify a certificate.

  The Win95 option is a special case which applies to older systems running DOS
  or Windows 3.1 which don't provide support for ActiveX or Java.  This option
  includes a complete Windows 95 installation in the extension which, when run,
  installs Win95 on the machine, locates and downloads whatever support is
  necessary for ActiveX and/or Java (typically a copy of MSIE), and then
  performs a PARP verification as described above.  CA's which include the
  Win95 option should be aware that this may lead to a small increase in
  certificate size.

Security Considerations

  CA's which include the Win95 option may wish to operate from a different
  country than the one in which their subjects are located, preferably one with
  strong gun control legislation.

Approved-By:  Michael Myers <[email-masked]>
Date:         Sat, 21 Mar 1998 13:32:51 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
To: [email-masked]

Carlisle,

I don't see that a poll is necessary here.  In the end, we're all looking
for a single, harmonized draft.

The intent of my posting was to identify where the current OCSP work product
should be updated to reflect these recent contributions.  I'm prepared to
execute this editorial role to ensure that the OCSP effort fairly and openly
reflects IETF process and PKIX consensus.

Mike

-----Original Message-----
From: Carlisle Adams <[email-masked]>
. . .
>Where do we go from here?  Given that the primary purpose of RSCP was to
>do the editing work necessary to move the OCSP draft to ASN.1 and to
>transport independence, it seems to me that the RCSP draft is the
>logical basis for progression.  [If Mike is agreeable, his name can
>certainly be included again on the authors list; furthermore, the
>protocol name can go back to "OCSP" if people prefer this.]
>
>Is it time for another straw poll?  Should the PKIX WG move forward from
>the current OCSP or from the current RCSP?
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>

Approved-By:  Michael Myers <[email-masked]>
Date:         Sat, 21 Mar 1998 10:23:25 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] We voted, now what?
To: [email-masked]

Rich,

We'll have to address questions regarding specifics of the ASN.1 question
going into L.A.  Doubtless the Malpani et. al. contribution provides a
strawman regarding ASN.1.

One should expect bits on the wire to change as a consequence of this
decision.  In the very near term, there is nonetheless merit in proving the
concept using the -02 syntax, particularly since as your implementation has
shown the development investment is minor.  I would expect that the proof of
concept trials regarding OCSP that I'm aware of would inform the evolution
of the draft standard irregardless of the specific transfer syntax.

As to the socket protocol, this is just a placeholder for the moment until
we can determine if the request for this level of transport independance is
sufficiently broad-based to warrant treatment in the draft standard.  It is
my intent to keep the the number of options to a minimum in the interests of
interoperability.

Mike

-----Original Message-----
From: Rich Salz <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Friday, March 20, 1998 7:21 AM
Subject: [IETF-PKIX] We voted, now what?

>I'm confused by the results of the straw poll.
>
>I understand that the documentation used in the RFC is going to change.
>Instead of
>        ocsp-request = url version target [extensions] [signature]
[extensions]
>        extensions = *extension
>It's going to be
>        OCSP-REQUEST ::= { SIGNED { VERSION TARGET EXTENSIONS }
EXTENSIONS }
>        EXTENSIONS ::= SEQUENCE OF EXTENSION
>(I'm sure I have syntax errors in both notations. :)
>
>What's not at all clear to me is this:
>    -   Is the wire protocol also going to change?  I have seen messages
>        on this list that implied this, asked for this, and were also
>        silent on this matter.
>    -   If so, how?
>            -   A new reserved port# which sends/receives the PDU's
>                defined in the spec; and/or
>            -   For HTTP, a defined "well-known URL" which uses GET
>                and replies to transmit the PDU's as a defined MIME type
>    -   If not, how?
>            -   Define an ASN.1 to "netascii" mapping?
>
>Is it clear to everyone else?  Anyone else? :)
>        /r$
>

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 20 Mar 1998 19:53:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

Perry,

We seem to be at cross purposes. You keep talking about
financial systems, and I'm trying to address the issue of
Reliance Limits in NON-financial applications

I was involved in the early days of SET, I am reasonably
familiar with how the banking/credit card system works, and
quite agree that from a liability perspective, the
digital signature aspect of SET is a rather low priority. In fact
the original iKP proposal made by IBM assumed that the
banks wouldn't bother to implement the consumer digital signature.

Other than the increasinly stringent "know your customer" rules
being applied to combat money laundering, the banks and credit card
companies wouldn't care you are identity-wise, so long as you
pay your bill on time.  SET doesn't depend on your signature to
tell whether you have money in the bank to cover your pruchase,
they go ask the bank.

Duh.

What the signature does provide, if you were watching all the
flames on SET last year, is protiction to the MERCHANT against
repudiation of a purchase, especially of intangible goods, by
a customer who under the previously existing rules could simply
disavow the purchase, leaving the bank to roll over on the merchant,
who had no receipt to back up his claim. The system was patently
unfair in that case, and to their credit Visa fixed the problem. If the
purchase order is digially signed, the merchant can push back against
the bank's attempt to deny the charge, and let the merchant, the
bank, and the customer fight it out in court, if necessary.

>> I certainly understand the difficulties with using a Reliance Limit
>> in the absence of "Dynamic, signed attributes retrieved securely by
>> authenticated real-time access to an on-line repository". That is
>> the primary reason why I have been pushing hard for a notarization
>> model that includes the ability to indicate to the repository, CA,
>> or other mediator what the estimated value of a particular message
>> is to the relying party, in case either the subscriber or the CA
>> would like to keep track of the aggregate value and cut off further
>> approvals by revoking the certificate if things look like they are
>> getting out of hand.
>
>I would again ask you what your model is for how these certificates
>will be used.

Fair enough.
>
>In any real financial transaction system in use *today*, the
>relationships are bilateral and there is no need for third party
>identity verification, since the bilateral counterparties have
>prearranged their relationship.

OK. Once more, the transaction are NOT necessarily financial
in nature, and in particular they are NOT taking place over any kind
of a pre-established transaction system, financial or otherwise.
and they do NOT necessarily involve preestablished knowledge of
parties, much less a re-arranged contractual agreement.
So I am not even going to discuss EDI, much less credit cards
or routine banking, although the EDI folks would very much like to get
away from the model of having to neotiate individual contracts
between all of the trading partners.

But do you imagine that I just discarded all possible uses of a
digital signature?  Of course not.

Take purchase orders, for example.  Many, many businesses
place orders every day to merchants they may have never dealt
with before, and they simply ask to be billed.  After the invoiced
items arrive and the bill comes in, they pay it, in many cases
using the USPS to deliver a physical check.

Would they like to be able to send orders in electronically? Yes.
Would the merchant like to have just a little better evidence as
to who this company is than a rpeprinted form or letterhead?
Yes.  Could a digitally signed document, backed up by a
certificate issued by a CA who had done at least some minimal
due diligence, such as confimring the company's Dun and Bradstreet
listing, provide that additional level of assurance. Yes.  Is the
additional speed transaction speed provided by the Internet, as
compared to sending that hard-copy letterhead evidence, worth
a great deal. Yes.  (This is the whole rationale behind an open PKI--
it is intended to facilitate a very wide variety of transactions between
relative strangers wh cannot be face to face, or pay cash.)

Could the company get screwed if the CA issued a certificate to the
wrong person? Yes, absolutely.  Even without some kind of velocity
controls, would the company like to take some modest precautions
against the possibility that some very large ticket items could somehow
be ordered erroneously, apparently signed by them, and leading to
a major battle? Yes.  Is some kind of a reliance limit at least a reasonable
and prudent inimum precaution against such a possibility, just like the
requirement for two signatures on a check over a certain amount?
Yes, yes, yes.
>
>> If I want to check that the latest series of messages really and
>> truly came from Perry, Andrew, or Dwight, perhaps because I want to
>> buy or sell short some CA's stock, depending on how I value the
>> message, then I may want to be reasonably sure that the message came
>> from them.
>
>> And in the good old fashioned American tradition, if something goes wrong,
>> I don't want to take the blame for a stupid decision on my part, I want to
>> sue someone to get well! :-)
>
>> Perry, however, may not enjoy the thought of my suing him for a gigabuck
>> because his rant led me to do something dumb, and especially if he didn't
>> even send the message but his evil twin Skippy did -- even if he is confident
>> that he will prevail in court --  he doesn't even want to get involved in
>> such silliness
>
>> So he might very well want to negotiate some kind of a limit of
>> liability with his CA, to be put into his certificate as at least an
>> approximate indicator o f what both he and the CA think might be a
>> reasonable upper limit for a "commercially reasonable" reliance.
>
>You will pardon me for noting that this is a highly, highly convoluted
>example. I can't think of anyone reasonable spending time thinking of
>how to rig the world's electronic mail system to make lawsuits most
>feasible (although I'm certain that various unreasonable people
>working for law firms spend time fantasizing about it.)

I'm not trying to make them more feasible, I'm trying to defend AGAINST
that possibility, by setting out limits where the possibility that an
errant transaction would be accepted as commercially reasonable
can be reasonably well tolerated.

If you don't want to take any financial risk at all, perhaps because you
realize that you really don't have adequate controls over your keys,
then you are free to specify a Relianace Limit of ZERO.  What's wrong
with that?
>
>Let me produce a much more straightforward example of how one uses
>identity information: credit card based payments. In a credit card
>based payment system, the "identity" of the person signing the credit
>card payment slip is utterly uninteresting. "So what if you are Bob
>Jueneman", says the Merchant. "How do I know you have credit left your
>card account?  How do I know you have an account at this bank? How do
>I know the bank exists?"

Agreed, as previously stipulated.
>
>None of those are answers that verifying your handy-dandy shiny
>Versign Certificate will give. All it will say is "This is indeed
>someone named Bob Jueneman."
>
>Well, the dirty little secret is that the merchant doesn't give a
>flying damn what your name is, except so he can send you catalogs at
>Christmas, and even then he doesn't care if you used your real
>name. All he wants is his money.

Not quite, as I discussed above.  He also needs a receipt
for the goods, or at least a signed order,  to back up his claim
that you were in fact the customer who ordered and receive
the merchandise.
>
>Now, the way that your merchant finds out that his money is coming to
>him is by talking to his bank, which says "yup, you're getting your
>money". He trusts his bank -- whether foolishly or correctly matters
>to no one but him. He doesn't have to care about your "Verisign
>Certificate" which he won't care about. The merchant's bank trusts the
>clearing system which trusts the issuing bank which in the end cares
>who you are, because you, "Bob Jueneman", have a bilateral
>relationship with the bank.
>
>In a 21st Century equivalent of this transaction, we can add massive
>security simply by providing a digital signature that gets verified by
>the issuing bank. The banks have all the liability, not the merchant,
>who doesn't care and needn't care. For the issuing bank's safety, it
>may wish to make sure that a digital signature on the request for
>payment matches the on-file public key of the person to whom the card
>has been issued. Does the issuing bank care about what Verisign thinks
>your name is? No. It doesn't give a damn. It has your key in its
>database, and can trust that information. (If it has trouble with the
>security on that database it has far worse problems on its hands, like
>people faking how much is in various accounts.)
>
>For real future credit transactions, I can't see what use certificates
>will be except as a convenient format for conveying public keys, and
>I'm very skeptical about the use of third party CAs ever becoming
>important in real financial transaction systems.

Well, Visa, MasterCard, American Express, et al, may in fact be wrong,
but they certainly see a role, if not the primary role. As you say, the
certificate doesn't tell anyone how much money you have in the bank.

>> Does that mean that because we can't be perfect, we shouldn't even
>> try to be prudent? I don't think so.  Even if it is like chicken soup for
>> a cold, it presumably won't hurt, and might actually do some good.
>
>I'm asking a far more fundamental question.
>
>In the financial transactions case -- the case where the concept of a
>"Reliance Limit" is the most relevant -- are there any real instances
>in which anyone needs certificates at all?

Well, if not, then this discussion is cetainly moot, and not worth wasting
either of our time!  I obviously disagree that Reliance Limits are
only of use in such well structured environments, where I basically
agree with your asessment. But that wasn't my point.
>
>If no one should care about the use of certificates from third party
>CAs in financial transactions -- if the only certificates that get
>issued are by the bank for the use of its customers in dealing only
>with the bank itself -- then why should we care about "Reliance
>Limits" at all?
>
>Perry

I think we have probably beat this one to death.  If you suddenly
have an epiphany and change your mind  by all means post it to the
list, but otherwise we can probably just continue this in private, or let
it drop and agree to disagee.

Regards,

Bob

Approved-By:  Warwick Ford <[email-masked]>
Date:         Fri, 20 Mar 1998 21:12:00 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
To: [email-masked]

I agree that concensus is emerging.  However, I suggest we concentrate on
resolving all the issues to everyone's satisfaction first, leaving the
editorial logistics aside for a moment.  In any case, I don't feel a straw
poll is either necessary or appropriate for that purpose.  If we can agree
on one protocol, then the best way to proceed is to ask all of the
substantive contributors to work together to produce the resultant
document.  I think that is best handled in person at the LA meeting.

Warwick

At 05:44 PM 3/20/98 -0500, Carlisle Adams wrote:
>All,
>
>As a concrete (and succinct) example, I include Russ' latest posting,
>but I think that "rough consensus" is building on almost all these
>issues.
>
>>----------
>>From:  Russ Housley[SMTP:[email-masked]]
>>Sent:  Thursday, March 19, 1998 12:16 PM
>>To:    [email-masked]
>>Subject:       Re: [IETF-PKIX] New OCSP Requirements
>>
>>Mike:
>>
>>Here are my responses:
>>
>>ASN.1  -  I support moving from ABNF to ASN.1.
>
>Definite rough consensus.  Issue closed (as far as I can tell).
>
>>Multiple Certs In Request  -  I think that this is desirable, but not
>>mandatory.
>
>Rough consensus (although I think the S/MIME example moves this to
>"mandatory").
>
>>Transport Independance  -  In my opinion, binding to HTTP is a mistake.
>>Independence to the transport is highly desirable.
>
>Rough consensus.
>
>>Multiple Response Types  -  I think that revocation information is
>>sufficient.
>
>It may be too early to judge rough consensus, but there does seem to be
>agreement that multiple response types would be easy to do syntactically
>(particularly in ASN.1) and would provide desirable generality for
>future evolution of the protocol without adding undue complexity.
>
>>Ceritificate Identification  -  I think that CA DName with Serial Number is
>>sufficient.
>
>Denis and Ambarish both make valid points here:  we should try to align
>with the S/MIME group if at all possible, but the structure being
>discussed in that group is not sufficient if the OCSP responder does not
>have the certificate itself (e.g., if it only has the issuer's
>certificate and signed revocation information).  Perhaps a solution is
>to add "issuerCertHash" to the CertUID structure, but this is starting
>to look a bit unwieldy...
>
>>Delegation of Authority  -  I think we should consider an enhancement at a
>>later time in conjunction with other attribute certificate work.  However,
>>you might want to include a certificate type in the protocol as a place
>>holder.
>
>It may be too early to judge rough consensus here as well, but there
>does seem to be agreement that this work should be done in a broader
>context.
>
>
>
>
>Where do we go from here?  Given that the primary purpose of RSCP was to
>do the editing work necessary to move the OCSP draft to ASN.1 and to
>transport independence, it seems to me that the RCSP draft is the
>logical basis for progression.  [If Mike is agreeable, his name can
>certainly be included again on the authors list; furthermore, the
>protocol name can go back to "OCSP" if people prefer this.]
>
>Is it time for another straw poll?  Should the PKIX WG move forward from
>the current OCSP or from the current RCSP?
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>
******** PLEASE NOTE NEW CONTACT DETAILS ********
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Fri, 20 Mar 1998 19:32:41 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

Bob Jueneman writes:
> I have to mildly disagree.

As someone highly involved in the world of certificates for the last
decade, I would be shocked if you didn't.

> I don't want to get all wrapped up in a general purpose discussion
> of trust, nor of the various pros and cons of possible transaction systems.

I wasn't discussing the question of "Trust" at all. I was discussing
whether financial transaction systems actually need CAs.

> I certainly understand the difficulties with using a Reliance Limit
> in the absence of "Dynamic, signed attributes retrieved securely by
> authenticated real-time access to an on-line repository". That is
> the primary reason why I have been pushing hard for a notarization
> model that includes the ability to indicate to the repository, CA,
> or other mediator what the estimated value of a particular message
> is to the relying party, in case either the subscriber or the CA
> would like to keep track of the aggregate value and cut off further
> approvals by revoking the certificate if things look like they are
> getting out of hand.

I would again ask you what your model is for how these certificates
will be used.

In any real financial transaction system in use *today*, the
relationships are bilateral and there is no need for third party
identity verification, since the bilateral counterparties have
prearranged their relationship.

> If I want to check that the latest series of messages really and
> truly came from Perry, Andrew, or Dwight, perhaps because I want to
> buy or sell short some CA's stock, depending on how I value the
> message, then I may want to be reasonably sure that the message came
> from them.

> And in the good old fashioned American tradition, if something goes wrong,
> I don't want to take the blame for a stupid decision on my part, I want to
> sue someone to get well! :-)

> Perry, however, may not enjoy the thought of my suing him for a gigabuck
> because his rant led me to do something dumb, and especially if he didn't
> even send the message but his evil twin Skippy did -- even if he is confident
> that he will prevail in court --  he doesn't even want to get involved in
> such silliness

> So he might very well want to negotiate some kind of a limit of
> liability with his CA, to be put into his certificate as at least an
> approximate indicator o f what both he and the CA think might be a
> reasonable upper limit for a "commercially reasonable" reliance.

You will pardon me for noting that this is a highly, highly convoluted
example. I can't think of anyone reasonable spending time thinking of
how to rig the world's electronic mail system to make lawsuits most
feasible (although I'm certain that various unreasonable people
working for law firms spend time fantasizing about it.)

Let me produce a much more straightforward example of how one uses
identity information: credit card based payments. In a credit card
based payment system, the "identity" of the person signing the credit
card payment slip is utterly uninteresting. "So what if you are Bob
Jueneman", says the Merchant. "How do I know you have credit left your
card account?  How do I know you have an account at this bank? How do
I know the bank exists?"

None of those are answers that verifying your handy-dandy shiny
Versign Certificate will give. All it will say is "This is indeed
someone named Bob Jueneman."

Well, the dirty little secret is that the merchant doesn't give a
flying damn what your name is, except so he can send you catalogs at
Christmas, and even then he doesn't care if you used your real
name. All he wants is his money.

Now, the way that your merchant finds out that his money is coming to
him is by talking to his bank, which says "yup, you're getting your
money". He trusts his bank -- whether foolishly or correctly matters
to no one but him. He doesn't have to care about your "Verisign
Certificate" which he won't care about. The merchant's bank trusts the
clearing system which trusts the issuing bank which in the end cares
who you are, because you, "Bob Jueneman", have a bilateral
relationship with the bank.

In a 21st Century equivalent of this transaction, we can add massive
security simply by providing a digital signature that gets verified by
the issuing bank. The banks have all the liability, not the merchant,
who doesn't care and needn't care. For the issuing bank's safety, it
may wish to make sure that a digital signature on the request for
payment matches the on-file public key of the person to whom the card
has been issued. Does the issuing bank care about what Verisign thinks
your name is? No. It doesn't give a damn. It has your key in its
database, and can trust that information. (If it has trouble with the
security on that database it has far worse problems on its hands, like
people faking how much is in various accounts.)

For real future credit transactions, I can't see what use certificates
will be except as a convenient format for conveying public keys, and
I'm very skeptical about the use of third party CAs ever becoming
important in real financial transaction systems.

> Does that mean that because we can't be perfect, we shouldn't even
> try to be prudent? I don't think so.  Even if it is like chicken soup for
> a cold, it presumably won't hurt, and might actually do some good.

I'm asking a far more fundamental question.

In the financial transactions case -- the case where the concept of a
"Reliance Limit" is the most relevant -- are there any real instances
in which anyone needs certificates at all?

If no one should care about the use of certificates from third party
CAs in financial transactions -- if the only certificates that get
issued are by the bank for the use of its customers in dealing only
with the bank itself -- then why should we care about "Reliance
Limits" at all?

Perry

Approved-By:  Slava Galperin <[email-masked]>
Date:         Fri, 20 Mar 1998 14:43:32 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Slava Galperin <[email-masked]>
Organization: Netscape Communications Corp
Subject:      Re: [IETF-PKIX] Unique Identification of a Certificate
To: [email-masked]

Ambarish Malpani wrote:
>
>
> In RCSP, a client is sending over one or more certificates to an
> RCSP responder, to check their revocation status.
> I think we all agree that issuer/serial is sufficient to uniquely
> identify a certificate.
> So the question is: how does one uniquely identify an issuer.
> I submit that the DN is not enough, because it is possible for
> the to be DN name clashes - either maliciously, or because two
> groups don't talk to each other before they choose their names.
> There really is no way of enforcing uniqueness is issuer DNs all
> over the world.
> However, public keys don't suffer from the problem of impersonation.
> If somebody else claims to have the same public/private key as me,
> it is easy to prove otherwise.
> Therefore, we have chosen to use the issuerDN, issuerPublicKey
> and CertificateSerialNumber to uniquely identify a cert. (I need
> to add the issuerAltName also, as you have).
> As an optimization, to reduce the size of a request, we ask the
> requestor to hash the issuerDN and issuerPublicKey in the request
> rather than sending all the bytes.

Actually if we do believe in the uniqueness of the CA signing key pair
(which would better be true ! ;-) we can take even more extreme approach
to identifying a cert.

Specifically one can eliminate the CA name (both primary and
alternative) from certificate identification. Instead one can use (a
hash of?) CA public key/serial number combination to identify a
certificate. This approach attempts to use one of the fundamental
assumptions made by SPKI working group that PKI principals are
essentially signing keys and names are just some of the attributes bound
to the key by means of issuing a certificate.

Although X.509 world heavily relies on combination of name/key
identifier in certificate chaining I guess it would be a pretty safe
assumption that most CA never use two CA certificates with different CA
name and same key. Even if CA signing key pair is attached to many
different names (possibly of different name forms), these names form
equivalence class and are specified in a single CA certificate possibly
using a combination of subject and subjectAlternativeName.

Technically I am proposing to use either

CertID                  ::=     SEQUENCE {
         issuerKeyHash            Hash,
         serialNumber                    CertificateSerialNumber,
}

where issuerKeyHash is a hash of subjectPublicKeyInfo field from the
corresponding CA certificate, or

CertID                  ::=     SEQUENCE {
         issuerKey          SubjectPublicKeyInfo,
         serialNumber                    CertificateSerialNumber,
}

in case we are afraid of the hash collisions and are willing to
sacrifice some bandwidth for some peace of mind.

Note however, that both in the original RCSP spec and in my proposed
scheme above there is another interesting open problem of dealing with
the CA
key change-over, i.e. when various subsets of the set of all issued
certificates (and CRLs !) are signed by different signing keys

I would be very interested in group's comments.
--
Slava Galperin          Certified Certificate Certifier
[email-masked]   tel: 650.937.6757

 It doesn't matter so much whether you've won the war or lost it.
 What matters is who you have lost it to.
                            -- From the memoirs of a married man

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Fri, 20 Mar 1998 17:44:48 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements (and new straw poll...)
To: [email-masked]

All,

As a concrete (and succinct) example, I include Russ' latest posting,
but I think that "rough consensus" is building on almost all these
issues.

>----------
>From:  Russ Housley[SMTP:[email-masked]]
>Sent:  Thursday, March 19, 1998 12:16 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] New OCSP Requirements
>
>Mike:
>
>Here are my responses:
>
>ASN.1  -  I support moving from ABNF to ASN.1.

Definite rough consensus.  Issue closed (as far as I can tell).

>Multiple Certs In Request  -  I think that this is desirable, but not
>mandatory.

Rough consensus (although I think the S/MIME example moves this to
"mandatory").

>Transport Independance  -  In my opinion, binding to HTTP is a mistake.
>Independence to the transport is highly desirable.

Rough consensus.

>Multiple Response Types  -  I think that revocation information is
>sufficient.

It may be too early to judge rough consensus, but there does seem to be
agreement that multiple response types would be easy to do syntactically
(particularly in ASN.1) and would provide desirable generality for
future evolution of the protocol without adding undue complexity.

>Ceritificate Identification  -  I think that CA DName with Serial Number is
>sufficient.

Denis and Ambarish both make valid points here:  we should try to align
with the S/MIME group if at all possible, but the structure being
discussed in that group is not sufficient if the OCSP responder does not
have the certificate itself (e.g., if it only has the issuer's
certificate and signed revocation information).  Perhaps a solution is
to add "issuerCertHash" to the CertUID structure, but this is starting
to look a bit unwieldy...

>Delegation of Authority  -  I think we should consider an enhancement at a
>later time in conjunction with other attribute certificate work.  However,
>you might want to include a certificate type in the protocol as a place
>holder.

It may be too early to judge rough consensus here as well, but there
does seem to be agreement that this work should be done in a broader
context.

Where do we go from here?  Given that the primary purpose of RSCP was to
do the editing work necessary to move the OCSP draft to ASN.1 and to
transport independence, it seems to me that the RCSP draft is the
logical basis for progression.  [If Mike is agreeable, his name can
certainly be included again on the authors list; furthermore, the
protocol name can go back to "OCSP" if people prefer this.]

Is it time for another straw poll?  Should the PKIX WG move forward from
the current OCSP or from the current RCSP?

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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 20 Mar 1998 14:43:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

Perry, Andrew, and Dwight,

I have to mildly disagree.

I don't want to get all wrapped up in a general purpose discussion
of trust, nor of the various pros and cons of possible transaction systems.
This isn't the place for that -- I'll leave the philosophy to Ed Gerck.

I certainly understand the difficulties with using a Reliance Limit in the
absence of "Dynamic, signed attributes retrieved securely by authenticated
real-time access to an on-line repository". That is the primary reason why
I have been pushing hard for a notarization model that includes the ability
to indicate to the repository, CA, or other mediator what the estimated value
of a particular message is to the relying party, in case either the subscriber
or the CA would like to keep track of the aggregate value and cut off further
approvals by revoking the certificate if things look like they are getting
out of hand.

This does NOT mean that all such messages are expected to be financial
transactions, at all. If I want to check that the latest series of messages
really and truly came from Perry, Andrew, or Dwight, perhaps because I
want to buy or sell short some CA's stock, depending on how I value the
message, then I may want to be reasonably sure that the message came
from them.

And in the good old fashioned American tradition, if something goes wrong,
I don't want to take the blame for a stupid decision on my part, I want to
sue someone to get well! :-)

Perry, however, may not enjoy the thought of my suing him for a gigabuck
because his rant led me to do something dumb, and especially if he didn't
even send the message but his evil twin Skippy did -- even if he is confident
that he will prevail in court --  he doesn't even want to get involved in
such silliness

So he might very well want to negotiate some kind of a limit of liability with
his CA, to be put into his certificate as at least an approximate indicator of
what both he and the CA think might be a reasonable upper limit for a
"commercially reasonable" reliance.  If I as the relyin gparty ignore that limit,
fuzzy though it might be, then I am taking the risk on my own head.

So yes, I agree. Without a closed loop validation, the CA doesn't know
how many times the subscriber will actually use his key to sign something, nor
the value of the "transaction"; and even the signer doesn't necessarily
know how many different people will validate his signature, and how many
times. (Consider a code-signing function applied to Windows 95.)

So from that perspective, if either the CA or the subscriber screwed up,
they could be facing infinity squared liability, even if the Reliance Limit
were a penny.

Yup, that's true.  So what?

Does that mean that because we can't be perfect, we shouldn't even
try to be prudent? I don't think so.  Even if it is like chicken soup for
a cold, it presumably won't hurt, and might actually do some good.

Surely you wouldn't completely dismiss the difference in due diligence
offered by the various classes of Verisign certificate, would you? In a sense,
they have a Relaince Limit -- it's just in their CPS instead of in their certificate.

Although we as technologists often think that we know a lot more about
the law, commerce, technology, etc. than the legislators do (and on some
favorite hot-button topics of mine, I'm certainly convinced that I do), we
didn't choose to run for office, and certainly weren't elected.  So the laws
are what they are, and we can perhaps lobby to change them if we
disagree with them, but we probably shouldn't ignore them.

As a result, we plan to provide for an optional Reliance Limit extension in
the certificates which our customers can produce using our  CA tools,
and the only issue I have is whether to include a Reliance Limit per
transaction, or per certificate (which is effectively what VeriSign does
in their CPS), or both.  At the moment I intend to provide both options.

The other issue is how to denominate the currency, but ISO 4317
solves that problem, and even allows me to specify the currency in gold.
(Whether grams, troy ounces, or pounds isn't clear).  So far, I can't
encode a Reliance Limit in terms of pound of flesh, but I'm working on it. :-)

I just didn't want to miss some particularly funky feature that some jurisdiction
thought would be neat, out of ignorance.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Andrew Csinger <[email-masked]> 03/20 12:13 PM >>>
>At 13:15 3/20/98 -0500, Perry E. Metzger wrote:
>>Sorry for ranting. I normally remain silent here, but the whole
>>concept of using third party signature guarantees in transactions is
>>so absurd -- and flys so far in the face of almost 1000 years of
>>merchant law and practice -- that I just had to say something. Its
>>utterly ridiculous.
>>Perry
>
>That's OK.  I've been saying it for years and it still gives me pleasure.
>I'll say it again:
>
>The signature on the certificate is not by itself the basis for trust.
>
>Andrew
>
>PS: Dynamic, signed attributes retrieved securely by authenticated real-
>    time access to an on-line repository, now, that's a different matter ;)

Approved-By:  Paul Koning <[email-masked]>
Date:         Fri, 20 Mar 1998 16:44:04 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

Question on Peter Gutmann's discussion on character string encoding:

It strikes me that part of the problem comes from the fact that ASN.1,
for historical reasons, includes a number of oddball string encodings
that are way out of mainstream.  Teletext is one example; I don't
remember exactly what T61String stands for but that sounds like
another.

Would it be possible to restrict encodings used to be selected only
from major mainstream standards?  Specifically: ISO 8859-1 (Latin-1)
and Unicode?

This has the advantage that most strings will in fact come across as
Latin-1; much of the time you can get away with thinking of that as
"ASCII".  It also has the advantage of supporting the national
characters of much of western Europe.  And, if memory serves, it's the
closest standard set to what Windows uses for its character set.

        paul

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 20 Mar 1998 13:52:59 -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] New CertUID (was: Re: [IETF-PKIX] New OCSPRequirements)
Comments: To: [email-masked]
To: [email-masked]

Isnt't the use of both serial and certificateHash redundant?

Perhaps CHOICE of two OPTIONAL attributes?

And I think we probably ought to spell out the desired semantics of the Issuer DN and/or issuerAltName.

There has been some extensive discussion of the cert-talk list about the requirement for multiple subjectAltNames to support multilingual countries. Some of these names may be "official", and some may be unofficial trnaslations or transliterations.

But merely defining the syntax isn't sufficinet. If I include my company's JPEG logo in subjectAltName, does that mean that would be a useful issuerAltName?  Probably not.

What are we assuming about these names, then.  Should they be locations I can retrieve a certificate from?  Probably. Using what kind of access method-- LDAP, http, mental telepathy? Any of the above?

Pardon me for barging in, since I just joined this list to discuss the multiple certificate per key issue.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Marc Branchaud <[email-masked]> 03/20 10:08 AM >>>
-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii

Denis Pinkas <[email-masked]> scrawled:
>
> This topic is being debated on the smime mailing list when talking about
> the CMS specification. There is no final position yet, but it seems that
> we are going towards the following structure:
>
> CertUID ::=     SEQUENCE {
>      issuerDN           Name,
>      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
>      serial             CertificateSerialNumber,
>      certificateHash    CertHash
> }
>
> This allows the support of alternate names and the certificate hash
> allows to make the difference between certificates that would be issued
> by CAs having the same name.
>
> In any case, I would recommend that the pkix group and the smime group
> adopt the same structure.
>

I'm completely for using this construct as the "official" certificate ID of
fine PKI implementations everywhere.

If I might make one small suggestion, it would be to make the
certificateHash OPTIONAL.  This would mean that the basic ID form is the
most efficient DN-and-serial, and it would only need to be expanded if that
were insufficient.

I did not follow the smime thread that lead / is leading to this structure,
so if there's a good reason for making certificateHash mandatory, please post
it.

                Marc

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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 20 Mar 1998 13:17: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:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
Comments: To: [email-masked], [email-masked]
To: [email-masked]

Peter, your comments and comparisons are extraordinarily useful, if sufficiently depressing to warrant taking a whole bottle of Prozac.

One question regarding the "least general encoding" rule.  Is it sufficient for a given application to trust the code page that is typically used in order to decide the string type, or is it necssary to examine each individual character in the string in order to determine what the absolutely minimal directoryString type should be?

Bob

>>> Peter Gutmann <[email-masked]> 03/19 11:52 PM >>>
Included below is the section from the X.509 style guide
(http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt) which covers
character set and string encoding issues, both the existing text on character
sets and the new bit on comparing strings.  I'd be interested in any comments
people have on this, in particular whether anyone has seriously looked at
implementing proper string handling on multiple platforms.  I have code which
implements this stuff if anyone wants it, the only condition for use is that
you have to send me a copy of any changes so I can keep things updated and
consistent.  I'd also like to get it tested by people in locales which use
DBCS's and other non-ASCII, non-8859-1 character sets.

Peter.

-- Snip --

Character Sets
--------------

Character strings are used in various places (most notably in DN's), and are
encumbered by the fact that ASN.1 defines a whole series of odd subsets of
ASCII/ISO 646 as character string types, but only provides a few peculiar and
strange oddball character encodings for anything outside this limited character
range.
                    The protruding upper halves of the letters now appear to
                    read, in the local language, "Go stick your head in a pig",
                    and are no longer illuminated, except at times of special
                    celebration.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

To use the example of DN's, the allowed string types are:

DirectoryString ::= CHOICE {
    teletexString           TeletexString (SIZE (1..maxSize)),
    printableString         PrintableString (SIZE (1..maxSize)),
    bmpString               BMPString (SIZE (1..maxSize)),
    universalString         UniversalString (SIZE (1..maxSize))
    }

The easiest one to use, if you can get away with it, is IA5String, which is
basically 7-bit ASCII, but with the dollar sign potentially replaced with a
"currency symbol".  In the DirectoryString case, you have to make do with
PrintableString, which is one of the odd ASCII/ISO 646 subsets (for example you
can't encode an '@', which makes it rather challenging to encode email
addresses).

Beyond that there is the T.61/TeletexString, which can select different
character sets using escape codes (this is one of the aforementioned "peculiar
and strange oddball encodings").  The character sets are Japanese Kanji (JIS C
6226-1983, set No. 87), Chinese (GB 2312-80, set No. 58), and Greek, using
shifting codes specified in T.61 or the international version, ISO 6937.  Some
of the characters have a variable-length encoding (ie it takes 2 bytes to
encode a character, with the interpretation being done in a context-specific
manner).  The reason I'm mentioning all this detail is to justify ending this
paragraph with the comment "Avoid this one".  Anyway: Avoid this one.

                    There are those who will say Danforth and I were utterly
                    mad not to flee for our lives after that; since our
                    conclusions were now completely fixed, and of a nature I
                    need not even mention to those who have read my account so
                    far.
                        - H.P.Lovecraft, "At the Mountains of Madness".

Next are the BMPString and UniversalString, with BMPString having 16-bit
characters and UniversalString having 32-bit characters, both encoded in
big-endian format.  BMPString is a subset of UniversalString, being the 16-bit
character range in the 0/0 plane (ie the UniversalString characters in which
the 16 high bits are 0, or UCS-2), corresponding to straight ISO 10646/Unicode
characters.  UniversalString apparently comes with its own set of complex
encoding issues involving mucking around with code tables and shift functions
and escape sequences and variable-length character encodings and God knows what
other horrors (another part of the standard however says that "Control
functions and signatures shall not be used").  In addition the ASN.1 standard
says that it should only be used if the encoding possibilities are constrained,
it's better to avoid it entirely and only use BMPString/ISO 10646/Unicode.

                    I might as well be frank in stating what we saw; though at
                    the time we felt that it was not to be admitted even to
                    each other.  The words reaching the reader can never even
                    suggest the awfulness of the sight itself.
                        - H.P.Lovecraft, "At the Mountains of Madness".

However, there is a problem with this: at the moment few implementors know how
to handle or encode BMPStrings, and people have made all sorts of guesses as to
how Unicode strings should be encoded: with or without Unicode byte order marks
(BOMs), possibly with a fixed endianness, and with or without the terminating
null character.

The correct format for BMPStrings is: big-endian 16-bit characters, no Unicode
byte order marks (BOMs), and no terminating null character (ISO 8825-1 section
8.20).

An exception to this is PFX/PKCS #12, where the passwords are converted to a
Unicode BMPString before being hashed.  However both Netscape and Microsoft's
early implementations treated the terminating null characters as being part of
the string, so the PKCS #12 standard was retroengineered to specify that the
null characters be included in the string.

Because of these problems, the SET designers produced their own alternative,
SETString, for places were DN's weren't required for compatibility purposes.
The design goals for the SETString were to both provide the best coverage of
ASCII and national-language character sets, and also to minimise implementation
pain.  The SETString type is defined as:

SETString ::= CHOICE {
    visibleString           VisibleString (SIZE (1..maxSIZE)),
    bmpString               BMPString (SIZE (1..maxSIZE))
    }

This provides complete ASCII/ISO 646 support using single byte characters, and
national language support through Unicode, which is in common use by industry.

In addition the SET designers decided to create their own version of the
DirectoryString which is a proper subset of the X.500 version.  The initial
version was just an X.500 DirectoryString with a number of constraints applied
to it, but just before publication this was changed to:

DirectoryString ::= CHOICE {
    printableString         PrintableString (SIZE(1..maxSIZE)),
    bmpString               BMPString (SIZE(1..maxSIZE))
    }

It was felt that this improved readablility and interoperability.  T61String
was never seriously considered in the design, and UniversalString with its
four-byte characters had no identifiable industry support and required too much
overhead.  If you want to produce certs which work for both generic X.509 and
SET, then using the SET version of the DirectoryString is a good idea.  It's
trivial to convert an ISO 8859-1 T61String to a BMPString and back (just
add/subtract a 0 byte every other byte).

A good rule of thumb when dealing with these character sets is to use the
"least inclusive" set when trying to determine which encoding to use.  This
means trying to encode as PrintableString first, then T61String, and finally
BMPString/UniversalString.  Microsoft goes from PrintableSting straight to
UniversalString encodings with the result that many cerficates have unnecessary
multibyte encodings, and can't be interpreted by any other software in
existence.  SET requires that either PrintableStrings or BMPStrings be used,
with TeletexStrings and UniversalStrings being forbidden.

>From this we can build the following set of recommendations:

- Use PrintableString if possible (or IA5String if this is allowed, because
  it's somewhat more versatile than PrintableString).
- If if won't go into a PrintableString, try for a BMPString.  However since
  noone's software really understands these, you may have to use a T61String
  instead.
- Only use a T61String if you really have to, and if you don't require SET
  compliance.  Avoid the use of anything involving shifting and escape codes at
  any cost - treat it as a pure ISO 8859-1 string.
- Avoid UniversalStrings.

Comparing DN's
--------------

This is an issue which is so problematic that it requires a section of its own
to cover it fully.  According to X.500, to compare a DN:

- The number of RDN's must match.
- RDN's must have the same number of AVA's.
- Corresponding AVA's must match for equality:
  - Leading and trailing spaces are ignored.
  - Multiple internal spaces are treated as a single internal space.
  - Characters (not code points, which are a particular encoding of a
    character) are matched in a case-insensitive manner.

As it turns out, this matching is virtually impossible to perform (more
specifically, it is virtually impossible to accurately compare two DN's for
equivalence).
                    This, many claim, is not merely impossible but clearly
                    insane, which is why the advertising executives of the star
                    system of Bastablon came up with this quote: 'If you've
                    done six impossible things this morning, why not round it
                    off with breakfast at Milliways, the Restaurant at the End
                    of the Universe?'.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

The reason for this is that, with the vast number of character sets, encodings,
and alternative encodings (code points) for the same character, and the often
very limited support for non-ASCII character sets available on many systems, it
isn't possible to accurately and portably compare any RDN's other than those
containing one of the basic ASCII string types.  The best you can probably do
is to use the strategy outlined below.

First, check whether the number of RDN's is equal.  If they match, break up the
DN's into RDN's and check that the RDN types match.  If they also match, you
need to compare the text in each RDN in turn.  This is where it gets tricky.

                    He walked across to the window and suddenly stumbled
                    because at that moment his Joo-Janta 200 Super-Chromatic
                    Peril Sensitive sunglasses had turned utterly black.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

First, take both strings and convert them to either ASCII (ISO646String) or
Unicode (BMPString) using the "least inclusive" rule.  This is quite a task in
itself, because several implementations aren't too picky about what they'll put
into a string, and will stuff T61String characters into a PrintableString, or
(more commonly) Unicode characters into a T61String or anything into a
BMPString.  Finding a T61String in a PrintableString or an 8-bit character set
string in a BMPString is relatively easy, but the best guess you can take at
detecting a Unicode string in a T61String is to check whether either the string
length is odd or all the characters are ASCII or ASCII with the high bit set.
If neither are true, it might be a Unicode string disguised as a T61String.

Once this is done, you need to canonicalise the strings into a format in which
a comparison can be done, either to compare strings of different types (eg
8-bit character set or DBCS string to BMPString) or strings with the same type
but different encodings (eg two T61Strings using alternative encodings).  To
convert ASCII-as-Unicode to ASCII, just drop the odd-numbered bytes. Converting
a T61String to Unicode is a bit more tricky.  Under Windows 95 and NT, you can
use MultiByteToWideChar(), although the conversion will depend on the current
code page in use.  On systems with widechar support, you can use mbstowcs()
directly if the widechar size is the same as the BMPString char size (which it
generally isn't), otherwise you need to first convert the string to a widechar
string with mbstowcs() and then back down again to a BMPString, taking the
machine endianness into account.  Again, the behaviour of mbstowcs() will
depend on the current locale in use.  If the system doesn't have widechar
support, the best you can do is a brute-force conversion to Unicode by hoping
it's ISO 8859-1 and adding a zero byte every other byte.

Now that you might have the strings in a format where they can be compared, you
can actually try and compare them.  Again, this often ends up as pure guesswork
if the system doesn't support the necessary character sets, or if the
characters use weird encodings which result in identical characters being
located at different code points.

First, check the converted character sets: If one is Unicode and the other
isn't, then the strings probably differ (depending on how well the
canonicalisation step went).  If the types are the same, strip leading,
trailing, and repeated internal spaces from the string, which isn't as easy as
it sounds since there are several possible code points allocated to a space.

Once you've had a go at stripping spaces, you can try to compare the strings.
If the string is a BMPString then under Windows NT (but not Windows 95) you can
use CompareString(), with the usual caveat that the comparison depends on the
current locale.  On systems which support towlower() you can extract the
characters from the string into widechars (taking machine endianness into
account) and compare the towlower() forms, with the usual caveat about locale
and the added problem that towlower() implementations vary from bare-bones
(8859-1 only under Solaris) to vague (Unicode under Win95, OSF/1).  If there's
no support for towlower(), the best you can do is use the normal tolower() if
the characters have a high byte of zero (some systems will support 8859-1 for
tolower(), the worst which can happen is that the characters will be returned
unchanged), and compare the code points directly if it isn't an 8-bit value.

                    Zaphods skin was crawling all over his body as if it was
                    trying to get off.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

Finally, if it's an ASCII string, you can just use a standard case-insensitive
string comparison function.

As you can see, there's almost no way to reliably compare two RDN elements. In
particular, no matter what you do:

- Some malicious users will deliberately pass DN checks with weird encodings.
- Some normal users will accidentally fail DN checks with weird encodings.

This becomes an issue when certain security checks depend on a comparison of
DN's (for example with excluded subtrees in the Name Constraints extension)
because it's possible to create multiple strings which are displayed
identically to the user (especially if you know which platform and/or software
to target) assuming they get displayed at all, but which compare as different
strings.  If you want to be absolutely certain about DN comparisons, you might
need to set a certificate policy of only allowing PrintableStrings in DN's,
because they're the only ones which can be reliably compared.

Approved-By: [email-masked]
Date:         Fri, 20 Mar 1998 14:26:22 -0500
Reply-To: John Horton <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: John Horton <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

And why I would contend that a distributed model vs. a hierarchial model be
designed & implemented.

JH

-----Original Message-----
From: Andrew Csinger <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Friday, March 20, 1998 2:16 PM
Subject: Re: [IETF-PKIX] Reliance limits in statutes

>At 13:15 3/20/98 -0500, Perry E. Metzger wrote:
>>Sorry for ranting. I normally remain silent here, but the whole
>>concept of using third party signature guarantees in transactions is
>>so absurd -- and flys so far in the face of almost 1000 years of
>>merchant law and practice -- that I just had to say something. Its
>>utterly ridiculous.
>>Perry
>
>That's OK.  I've been saying it for years and it still gives me pleasure.
>I'll say it again:
>
>The signature on the certificate is not by itself the basis for trust.
>
>Andrew
>
>PS: Dynamic, signed attributes retrieved securely by authenticated real-
>    time access to an on-line repository, now, that's a different matter ;)
>
>--------------------------------------------------------------
>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
>--------------------------------------------------------------
>

Approved-By:  Jeff Weinstein <[email-masked]>
Date:         Fri, 20 Mar 1998 11:59:59 -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: Jeff Weinstein <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

In case its not clear from my comments below, I say YES to asn.1.

David P. Kemp wrote:
> Your argument presupposes that Microsoft and Netscape will refuse to
> ship IETF-standard OCSP ironmongery in their products, as well as that
> independent developers are incapable of providing that support in the
> script/plugin/applet/dll aftermarket.  How likely is that?

  I just want to be clear here.  Netscape products include a fairly general
ASN.1/BER/DER encoder/decoder internally, which is used by our certificate
and S/MIME libraries.  It is not a burden to us at all to support ASN.1
for OCSP.  It is actually better for us if we don't have to construct a
new parser.

> > I think the vote should also clearly point out that there is a loss of
> > functionality in going to ASN.1.The responses are no longer
> > cachable as HTTP requests.
>
> Then how does KEYGEN work?

  I don't understand Phill's argument.  If OCSP was transport independent,
then we could specify a wrapping for it that would work in HTTP and
be cachable.

        --Jeff

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Fri, 20 Mar 1998 11:39:05 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] Unique Identification of a Certificate
Comments: To: [email-masked]
Comments: cc: "Jim Schaad (Exchange)" <[email-masked]>, Blake Ramsdell <[email-masked]>, "[email-masked]" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
To: [email-masked]

Hi Denis,
    I joined the SMIME mailing list just recently, so I am not certain
of the problem you guys are trying to solve. Let me explain the
issues in RCSP and the reasoning for choosing the method I have
for trying to uniquely identify a cert:

In RCSP, a client is sending over one or more certificates to an
RCSP responder, to check their revocation status.
I think we all agree that issuer/serial is sufficient to uniquely
identify a certificate.
So the question is: how does one uniquely identify an issuer.
I submit that the DN is not enough, because it is possible for
the to be DN name clashes - either maliciously, or because two
groups don't talk to each other before they choose their names.
There really is no way of enforcing uniqueness is issuer DNs all
over the world.
However, public keys don't suffer from the problem of impersonation.
If somebody else claims to have the same public/private key as me,
it is easy to prove otherwise.
Therefore, we have chosen to use the issuerDN, issuerPublicKey
and CertificateSerialNumber to uniquely identify a cert. (I need
to add the issuerAltName also, as you have).
As an optimization, to reduce the size of a request, we ask the
requestor to hash the issuerDN and issuerPublicKey in the request
rather than sending all the bytes.

Adding the certificateHash in the CertUID doesn't help us identify
the cert at all, because as an RCSP responder, I don't have the
cert itself - so I can't verify the CertHash against anything.

As an aggregator of revocation data/CRLs from multiple CAs, we
would like to be able to accept all CRLs - including ones where
the DNs might clash.

Is the SMIME problem different from this one? Does the recipient
already have the certificate the sender is referring to?

Regards,
Ambarish

P.S. For those who haven't been actively following these groups,
my suggestion for cert identification is:

CertID                  ::=     SEQUENCE {
        issuerNameAndKeyHash            Hash,
        serialNumber                    CertificateSerialNumber,
}

IssuerNameAndKey                ::=     SEQUENCE {
        issuerDN                        Name,
        issuerAltName                   IssuerAltName OPTIONAL,
        issuerPublicKey                 SubjectPublicKeyInfo
}

i.e. you identify a cert by the hash of the IssuerNameAndKey
and a serial number.

The hash includes the public key of the issuer - this prevents the
Banana Republic CA from impersonating our well beloved and well
trusted US CA ;-).

Ofcourse, if keeping the size of the request small is not important,
or the recipient might not be able to figure out the issuer from
the hash, it might make sense to send IssuerNameAndKey instead
of its hash.

Denis Pinkas wrote:
>
> There is no final position yet, but it seems that we are going towards
> the following structure:
>
> CertUID ::=     SEQUENCE {
>      issuerDN           Name,
>      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
>      serial             CertificateSerialNumber,
>      certificateHash    CertHash
> }
>
> This allows the support of alternate names and the certificate hash
> allows to make the difference between certificates that would be issued
> by CAs having the same name.
>
> In any case, I would recommend that the pkix group and the smime group
> adopt the same structure.
>
> Denis
>
> --
>       Denis Pinkas     Bull S.A.          mailto:[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

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Fri, 20 Mar 1998 14:30:30 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: Andrew Csinger <[email-masked]>
To: [email-masked]

[This really isn't PKIX material in a direct sense. Uninterested
people will want to hit <delete> now. Sorry for bringing this stuff up.]

Andrew Csinger writes:
> At 13:15 3/20/98 -0500, Perry E. Metzger wrote:
> >Sorry for ranting. I normally remain silent here, but the whole
> >concept of using third party signature guarantees in transactions is
> >so absurd -- and flys so far in the face of almost 1000 years of
> >merchant law and practice -- that I just had to say something. Its
> >utterly ridiculous.
> >Perry
>
> That's OK.  I've been saying it for years and it still gives me pleasure.
> I'll say it again:
>
> The signature on the certificate is not by itself the basis for trust.

"Trust" is not the issue. Certificates are designed to create
multilateral trust, but that sort of trust doesn't matter in most
payment scenarios, because the signature doesn't matter to the payee,
so the payee has no reason to check the signature.

It usually doesn't matter to the merchant if the signature is
legitimate, because that isn't what guarantees if he gets paid. It
matters to the bank, not the merchant -- and the bank's relationship
with the payor is bilateral, not multilateral, so there is no reason
for the bank to trust a third party since it has regular dealings with
the payor and can keep a copy of the payor's public key on file, in
precisely the manner of a signature card.

Of course, most people don't understand this, or ignore it. Sigh.

> PS: Dynamic, signed attributes retrieved securely by authenticated real-
>     time access to an on-line repository, now, that's a different matter ;)

I'm really curious how many people here who are off designing
interesting "Internet Commerce Protocols Of The Future" (TM) even
understand basic concepts of commercial paper, like what an
endorsement signature on a check actually means. My guess is "maybe
two or three of us reading this, at best."

Sigh.

Perry

Approved-By:  Andrew Csinger <[email-masked]>
Date:         Fri, 20 Mar 1998 11:13:21 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Andrew Csinger <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

At 13:15 3/20/98 -0500, Perry E. Metzger wrote:
>Sorry for ranting. I normally remain silent here, but the whole
>concept of using third party signature guarantees in transactions is
>so absurd -- and flys so far in the face of almost 1000 years of
>merchant law and practice -- that I just had to say something. Its
>utterly ridiculous.
>Perry

That's OK.  I've been saying it for years and it still gives me pleasure.
I'll say it again:

The signature on the certificate is not by itself the basis for trust.

Andrew

PS: Dynamic, signed attributes retrieved securely by authenticated real-
    time access to an on-line repository, now, that's a different matter ;)

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

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Fri, 20 Mar 1998 13:15:14 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Perry E. Metzger" <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

Dwight Arthur writes:
> Last I checked, NY and VT pending statutes included the "reliance limit"
> concept. On a personal note, this is one reason that I will work against
> the passage of either.

The entire "reliance limit" idea shows how twisted the whole notion of
using certificates in commerce is.

All real world transactions are bilateral, not multilateral. Digital
signatures are being asked to fulfill roles that real signatures do
not, and the systems to do so are being envisioned by people who've
never touched an actual clearing and settlement system in a real bank
or brokerage. This is very much an example of the engineers completely
misunderstanding how the thing they are trying to enhance operates. A
few months working in the cage at a brokerage or in a clearinghouse
would probably fix most misperceptions, but people of course aren't
perpared to do that.

This is, of course, why the payments systems people have been
developing for several years now have all sunk like lead balloons.

Sorry for ranting. I normally remain silent here, but the whole
concept of using third party signature guarantees in transactions is
so absurd -- and flys so far in the face of almost 1000 years of
merchant law and practice -- that I just had to say something. Its
utterly ridiculous.

Perry

Approved-By:  Russ Housley <[email-masked]>
Date:         Fri, 20 Mar 1998 12:23:30 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

At 05:13 PM 3/19/98 +1200, Peter Gutmann wrote:
>4.2.1.2.
>
>This gives the subject key identifier as the hash of the subjectPublicKeyInfo
>*without* the tag and length.  Is this a mistake, or is it meant to be like
>that?  Every other instance in which an ASN.1 object is hashed (eg
>certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes the
>entire object.  In fact the PKIX CMP draft uses a hash of the full
>subjectPublicKeyInfo in the OOBCertHash, which would make it incompatible
with
>the value in the subject key identifier.  Requiring a well-defined standard
>X.509 object to be broken up into pieces before processing it seems an
>extremely peculiar move, so I'm guessing it's some sort of mistake in the
spec.

This was done prior to the CMP section.  To use the public key, you need to
get the value out of the certificate without the associated ASN.1 stuff, so
that was the reason we chose to hash just the key.

>In addition I really don't like the idea of dumping a raw hash into the
>KeyIdentifier OCTET STRING, because it's not possible to distinguish it from
>whatever anyone else decides to put in there.  Much better would be to use
the
>PKCS #7 DigestInfo, which is well-defined and whose OID + data format
uniquely
>identifies the contents (that is, make the KeyIdentifier an OCTET STRING hole
>for a DigestInfo rather than an opaque blob).  Given that a KeyIdentifier
>could potentially contain anything, it's somewhat risky to put raw,
>unidentified data in there.

The hash the default way to make a key identifier.  Other schemes can be
used.  The idea is to identify the key, and the hash of the key is a simple
way to make an identifier for the key.

>4.2.1.3.
>
>The decipherOnly key usage indicates that the public key can only be used for
>deciphering data.  This would be quite a feat :-).  I assume this should say
>that the private key corresponding to the public key can only be used for
>deciphering data.

No.  The encipherOnly and decipherOnly apply only to key agreement.  These
bits are intended to place rescrictions on the key that results from key
agreement operations.

>Speaking of private vs public keys, it would be useful to have some standard
>unambiguous term defined to indicate the private key which is tied to the
>public key, eg "corresponding to" or "identified by" or "paired with" or
>something similar.  I've used "identified by" (eg "The end-user certificate
>should be signed by the private key identified by a CA certificate"), but I'm
>not sure if that sounds right.  The current draft seems to use different
terms
>in different places.

Different authors leads to different terms.  I suggest that Tim Polk (who
is now the senior editor) make it read like one person wrote it.  This
depends on the amount of time that he can spend on the task.  Are there any
places where this actually makes the text confusing?

>7.3.2.
>
>This gives a redundant definition of the DH p and g values (the ASN.1
>definition is followed immediately by text which says exactly the same
thing -
>actually the RSA definition does this too with n and e), but doesn't explain
>the INTEGER which is the DH public key (what *is* this value?  The only thing
>I can think of is g^x mod p, but that shouldn't be a fixed value).  It also
>goes to some lengths to explain the encoding of the INTEGER parameter as a
BIT
>STRING, which seems very odd.

Whould you like to suggest improved text?

Russ

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Fri, 20 Mar 1998 09:08:15 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      [IETF-PKIX] New CertUID (was: Re: [IETF-PKIX] New OCSP Requirements)
Comments: To: [email-masked]
To: [email-masked]

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

Content-Type: text/plain; charset=us-ascii

Denis Pinkas <[email-masked]> scrawled:
>
> This topic is being debated on the smime mailing list when talking about
> the CMS specification. There is no final position yet, but it seems that
> we are going towards the following structure:
>
> CertUID ::=     SEQUENCE {
>      issuerDN           Name,
>      issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
>      serial             CertificateSerialNumber,
>      certificateHash    CertHash
> }
>
> This allows the support of alternate names and the certificate hash
> allows to make the difference between certificates that would be issued
> by CAs having the same name.
>
> In any case, I would recommend that the pkix group and the smime group
> adopt the same structure.
>

I'm completely for using this construct as the "official" certificate ID of
fine PKI implementations everywhere.

If I might make one small suggestion, it would be to make the
certificateHash OPTIONAL.  This would mean that the basic ID form is the
most efficient DN-and-serial, and it would only need to be expanded if that
were insufficient.

I did not follow the smime thread that lead / is leading to this structure,
so if there's a good reason for making certificateHash mandatory, please post
it.

                Marc

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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Fri, 20 Mar 1998 17:07:09 -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] New OCSP Requirements
To: [email-masked]

Michael,

I agree with most of the comments sent on OCSP, the support of
revocation (for multiple certificates) instead of validation, etc... but
I would like to focus on Certificate Identification.

(...)

> To resolve this point, I would ask that participating members of PKIX
> provide their opinion on the matter.  As with the ASN.1 issue, OCSP can and
> will be adjusted to reflect that consensus.  Until then I would prefer to
> maintain the spec of certID as is since it is aligned with concepts defined
> in X.509.
>
> My concern here is alignment with other PKI-based security protocols, not
> the least of with is CMS.  Might I note that the SignerInfos syntax has as
> an element issuerAndSerialNumber which is defined as:
>
> IssuerAndSerialNumber ::= SEQUENCE {
>         issuer Name,
>         serialNumber SerialNumber }
>
> SerialNumber ::= INTEGER

This topic is being debated on the smime mailing list when talking about
the CMS specification. There is no final position yet, but it seems that
we are going towards the following structure:

CertUID ::=     SEQUENCE {
     issuerDN           Name,
     issuerAltName      IssuerAltName OPTIONAL,  -- As defined in PKIX
     serial             CertificateSerialNumber,
     certificateHash    CertHash
}

This allows the support of alternate names and the certificate hash
allows to make the difference between certificates that would be issued
by CAs having the same name.

In any case, I would recommend that the pkix group and the smime group
adopt the same structure.

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Rich Salz <[email-masked]>
Date:         Fri, 20 Mar 1998 10:00:32 -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 Salz <[email-masked]>
Subject:      [IETF-PKIX] We voted, now what?
To: [email-masked]

I'm confused by the results of the straw poll.

I understand that the documentation used in the RFC is going to change.
Instead of
        ocsp-request = url version target [extensions] [signature] [extensions]
        extensions = *extension
It's going to be
        OCSP-REQUEST ::= { SIGNED { VERSION TARGET EXTENSIONS } EXTENSIONS }
        EXTENSIONS ::= SEQUENCE OF EXTENSION
(I'm sure I have syntax errors in both notations. :)

What's not at all clear to me is this:
    -   Is the wire protocol also going to change?  I have seen messages
        on this list that implied this, asked for this, and were also
        silent on this matter.
    -   If so, how?
            -   A new reserved port# which sends/receives the PDU's
                defined in the spec; and/or
            -   For HTTP, a defined "well-known URL" which uses GET
                and replies to transmit the PDU's as a defined MIME type
    -   If not, how?
            -   Define an ASN.1 to "netascii" mapping?

Is it clear to everyone else?  Anyone else? :)
        /r$

Approved-By:  "Charles W. Gardiner" <[email-masked]>
Date:         Fri, 20 Mar 1998 10:04:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Charles W. Gardiner" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

    ASN.1 by all means.  It's so simple to use!

Charlie Gardiner

Approved-By:  Dwight Arthur <[email-masked]>
Date:         Thu, 19 Mar 1998 18:27: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: Dwight Arthur <[email-masked]>
Subject:      [IETF-PKIX] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

Bob,

Last I checked, NY and VT pending statutes included the "reliance limit"
concept. On a personal note, this is one reason that I will work against
the passage of either.

-Dwight

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 20 Mar 1998 09:09: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

> From: "Phillip M. Hallam-Baker" <[email-masked]>
>
> The arguments about ASN.1 parsers are completely bogus. Windows NT
> ships with PKCS#7 parsing ironmongery but it does not ship with a generic
> ASN.1 compiler. Similar arguments hold for other platforms.

Why is that an argument against the use of ASN.1 in OCSP?  PKCS#7 is
specified in ASN.1.  If PKCS#7 were specified in ABNF and Windows NT
supported it, then that example might support your position.  But can
you actually envision a world based on ABNF PKCS#7?  I shudder at the
thought :-).

Your argument presupposes that Microsoft and Netscape will refuse to
ship IETF-standard OCSP ironmongery in their products, as well as that
independent developers are incapable of providing that support in the
script/plugin/applet/dll aftermarket.  How likely is that?

> I think the vote should also clearly point out that there is a loss of
> functionality in going to ASN.1.The responses are no longer
> cachable as HTTP requests.

Then how does KEYGEN work?

> It is easy to make arguments about consistency, I am concerned about
> function.

As is everyone else.  Function argues in favor of ASN.1.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 20 Mar 1998 08:49: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

> From: "Matthew S. Hamrick" <[email-masked]>
>
> Yes, provided it specifies DER encoding.
>
> I believe that one's opinion of this topic is heavily influenced by how
> good your ASN.1 / BER / DER tools are. I have a toolset that that
> generates a remarkably good code footprint if you turn indefinite length
> encoding off.

If the toolset generates remarkably bad code with indefinite length
encoding (BER) enabled, it's a very strange toolset.  For the size of
messages envisioned for OCSP, there isn't any particular advantage to
using BER (for one-pass processing), but I don't see any reason to
restrict OCSP to DER either.  Indefinite length is marginally easier
for the encoder, definite length is marginally easier for the decoder.
Either way, as long as the OCSP message fits in memory, the difference
in coder footprint is minimal.

Approved-By:  Russ Housley <[email-masked]>
Date:         Thu, 19 Mar 1998 12:16: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: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

Mike:

Here are my responses:

ASN.1  -  I support moving from ABNF to ASN.1.

Multiple Certs In Request  -  I think that this is desirable, but not
mandatory.

Transport Independance  -  In my opinion, binding to HTTP is a mistake.
Independence to the transport is highly desirable.

Multiple Response Types  -  I think that revocation information is sufficient.

Ceritificate Identification  -  I think that CA DName with Serial Number is
sufficient.

Delegation of Authority  -  I think we should consider an enhancement at a
later time in conjunction with other attribute certificate work.  However,
you might want to include a certificate type in the protocol as a place
holder.

Russ

Approved-By:  Russ Housley <[email-masked]>
Date:         Thu, 19 Mar 1998 12:04:29 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

I would like to see the protocol move to ASN.1.

Russ

At 10:30 PM 3/18/98 -0800, Michael Myers wrote:
>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Fri, 20 Mar 1998 11:44:21 +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: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] Question about CMMF
To: [email-masked]

To the list,

The following is written in Certificate Management Message Formats
(CMMF)
february 1998, page 2:

... Using these message formats, a PKI client may:
           ...
- Request data of a PKI, including:
     - One’s own or others’ certificate

However, in the document I failed to find any ASN.1 structure supporting
the
situation, where an end entity requests for a certificate of another end
entity.

Can someone tell me, which structure/message should be used in this
situation?

- Jakob

Approved-By:  Nada Kapidzic Cicovic <[email-masked]>
Date:         Fri, 20 Mar 1998 11:20: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: Nada Kapidzic Cicovic <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

ASN.1 seems to be a natural choice.

Nada

At 22:30 3/18/98 -0800, you wrote:
>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 22:52:20 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Gutmann <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

Included below is the section from the X.509 style guide
(http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt) which covers
character set and string encoding issues, both the existing text on character
sets and the new bit on comparing strings.  I'd be interested in any comments
people have on this, in particular whether anyone has seriously looked at
implementing proper string handling on multiple platforms.  I have code which
implements this stuff if anyone wants it, the only condition for use is that
you have to send me a copy of any changes so I can keep things updated and
consistent.  I'd also like to get it tested by people in locales which use
DBCS's and other non-ASCII, non-8859-1 character sets.

Peter.

-- Snip --

Character Sets
--------------

Character strings are used in various places (most notably in DN's), and are
encumbered by the fact that ASN.1 defines a whole series of odd subsets of
ASCII/ISO 646 as character string types, but only provides a few peculiar and
strange oddball character encodings for anything outside this limited character
range.
                    The protruding upper halves of the letters now appear to
                    read, in the local language, "Go stick your head in a pig",
                    and are no longer illuminated, except at times of special
                    celebration.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

To use the example of DN's, the allowed string types are:

DirectoryString ::= CHOICE {
    teletexString           TeletexString (SIZE (1..maxSize)),
    printableString         PrintableString (SIZE (1..maxSize)),
    bmpString               BMPString (SIZE (1..maxSize)),
    universalString         UniversalString (SIZE (1..maxSize))
    }

The easiest one to use, if you can get away with it, is IA5String, which is
basically 7-bit ASCII, but with the dollar sign potentially replaced with a
"currency symbol".  In the DirectoryString case, you have to make do with
PrintableString, which is one of the odd ASCII/ISO 646 subsets (for example you
can't encode an '@', which makes it rather challenging to encode email
addresses).

Beyond that there is the T.61/TeletexString, which can select different
character sets using escape codes (this is one of the aforementioned "peculiar
and strange oddball encodings").  The character sets are Japanese Kanji (JIS C
6226-1983, set No. 87), Chinese (GB 2312-80, set No. 58), and Greek, using
shifting codes specified in T.61 or the international version, ISO 6937.  Some
of the characters have a variable-length encoding (ie it takes 2 bytes to
encode a character, with the interpretation being done in a context-specific
manner).  The reason I'm mentioning all this detail is to justify ending this
paragraph with the comment "Avoid this one".  Anyway: Avoid this one.

                    There are those who will say Danforth and I were utterly
                    mad not to flee for our lives after that; since our
                    conclusions were now completely fixed, and of a nature I
                    need not even mention to those who have read my account so
                    far.
                        - H.P.Lovecraft, "At the Mountains of Madness".

Next are the BMPString and UniversalString, with BMPString having 16-bit
characters and UniversalString having 32-bit characters, both encoded in
big-endian format.  BMPString is a subset of UniversalString, being the 16-bit
character range in the 0/0 plane (ie the UniversalString characters in which
the 16 high bits are 0, or UCS-2), corresponding to straight ISO 10646/Unicode
characters.  UniversalString apparently comes with its own set of complex
encoding issues involving mucking around with code tables and shift functions
and escape sequences and variable-length character encodings and God knows what
other horrors (another part of the standard however says that "Control
functions and signatures shall not be used").  In addition the ASN.1 standard
says that it should only be used if the encoding possibilities are constrained,
it's better to avoid it entirely and only use BMPString/ISO 10646/Unicode.

                    I might as well be frank in stating what we saw; though at
                    the time we felt that it was not to be admitted even to
                    each other.  The words reaching the reader can never even
                    suggest the awfulness of the sight itself.
                        - H.P.Lovecraft, "At the Mountains of Madness".

However, there is a problem with this: at the moment few implementors know how
to handle or encode BMPStrings, and people have made all sorts of guesses as to
how Unicode strings should be encoded: with or without Unicode byte order marks
(BOMs), possibly with a fixed endianness, and with or without the terminating
null character.

The correct format for BMPStrings is: big-endian 16-bit characters, no Unicode
byte order marks (BOMs), and no terminating null character (ISO 8825-1 section
8.20).

An exception to this is PFX/PKCS #12, where the passwords are converted to a
Unicode BMPString before being hashed.  However both Netscape and Microsoft's
early implementations treated the terminating null characters as being part of
the string, so the PKCS #12 standard was retroengineered to specify that the
null characters be included in the string.

Because of these problems, the SET designers produced their own alternative,
SETString, for places were DN's weren't required for compatibility purposes.
The design goals for the SETString were to both provide the best coverage of
ASCII and national-language character sets, and also to minimise implementation
pain.  The SETString type is defined as:

SETString ::= CHOICE {
    visibleString           VisibleString (SIZE (1..maxSIZE)),
    bmpString               BMPString (SIZE (1..maxSIZE))
    }

This provides complete ASCII/ISO 646 support using single byte characters, and
national language support through Unicode, which is in common use by industry.

In addition the SET designers decided to create their own version of the
DirectoryString which is a proper subset of the X.500 version.  The initial
version was just an X.500 DirectoryString with a number of constraints applied
to it, but just before publication this was changed to:

DirectoryString ::= CHOICE {
    printableString         PrintableString (SIZE(1..maxSIZE)),
    bmpString               BMPString (SIZE(1..maxSIZE))
    }

It was felt that this improved readablility and interoperability.  T61String
was never seriously considered in the design, and UniversalString with its
four-byte characters had no identifiable industry support and required too much
overhead.  If you want to produce certs which work for both generic X.509 and
SET, then using the SET version of the DirectoryString is a good idea.  It's
trivial to convert an ISO 8859-1 T61String to a BMPString and back (just
add/subtract a 0 byte every other byte).

A good rule of thumb when dealing with these character sets is to use the
"least inclusive" set when trying to determine which encoding to use.  This
means trying to encode as PrintableString first, then T61String, and finally
BMPString/UniversalString.  Microsoft goes from PrintableSting straight to
UniversalString encodings with the result that many cerficates have unnecessary
multibyte encodings, and can't be interpreted by any other software in
existence.  SET requires that either PrintableStrings or BMPStrings be used,
with TeletexStrings and UniversalStrings being forbidden.

>From this we can build the following set of recommendations:

- Use PrintableString if possible (or IA5String if this is allowed, because
  it's somewhat more versatile than PrintableString).
- If if won't go into a PrintableString, try for a BMPString.  However since
  noone's software really understands these, you may have to use a T61String
  instead.
- Only use a T61String if you really have to, and if you don't require SET
  compliance.  Avoid the use of anything involving shifting and escape codes at
  any cost - treat it as a pure ISO 8859-1 string.
- Avoid UniversalStrings.

Comparing DN's
--------------

This is an issue which is so problematic that it requires a section of its own
to cover it fully.  According to X.500, to compare a DN:

- The number of RDN's must match.
- RDN's must have the same number of AVA's.
- Corresponding AVA's must match for equality:
  - Leading and trailing spaces are ignored.
  - Multiple internal spaces are treated as a single internal space.
  - Characters (not code points, which are a particular encoding of a
    character) are matched in a case-insensitive manner.

As it turns out, this matching is virtually impossible to perform (more
specifically, it is virtually impossible to accurately compare two DN's for
equivalence).
                    This, many claim, is not merely impossible but clearly
                    insane, which is why the advertising executives of the star
                    system of Bastablon came up with this quote: 'If you've
                    done six impossible things this morning, why not round it
                    off with breakfast at Milliways, the Restaurant at the End
                    of the Universe?'.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

The reason for this is that, with the vast number of character sets, encodings,
and alternative encodings (code points) for the same character, and the often
very limited support for non-ASCII character sets available on many systems, it
isn't possible to accurately and portably compare any RDN's other than those
containing one of the basic ASCII string types.  The best you can probably do
is to use the strategy outlined below.

First, check whether the number of RDN's is equal.  If they match, break up the
DN's into RDN's and check that the RDN types match.  If they also match, you
need to compare the text in each RDN in turn.  This is where it gets tricky.

                    He walked across to the window and suddenly stumbled
                    because at that moment his Joo-Janta 200 Super-Chromatic
                    Peril Sensitive sunglasses had turned utterly black.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

First, take both strings and convert them to either ASCII (ISO646String) or
Unicode (BMPString) using the "least inclusive" rule.  This is quite a task in
itself, because several implementations aren't too picky about what they'll put
into a string, and will stuff T61String characters into a PrintableString, or
(more commonly) Unicode characters into a T61String or anything into a
BMPString.  Finding a T61String in a PrintableString or an 8-bit character set
string in a BMPString is relatively easy, but the best guess you can take at
detecting a Unicode string in a T61String is to check whether either the string
length is odd or all the characters are ASCII or ASCII with the high bit set.
If neither are true, it might be a Unicode string disguised as a T61String.

Once this is done, you need to canonicalise the strings into a format in which
a comparison can be done, either to compare strings of different types (eg
8-bit character set or DBCS string to BMPString) or strings with the same type
but different encodings (eg two T61Strings using alternative encodings).  To
convert ASCII-as-Unicode to ASCII, just drop the odd-numbered bytes. Converting
a T61String to Unicode is a bit more tricky.  Under Windows 95 and NT, you can
use MultiByteToWideChar(), although the conversion will depend on the current
code page in use.  On systems with widechar support, you can use mbstowcs()
directly if the widechar size is the same as the BMPString char size (which it
generally isn't), otherwise you need to first convert the string to a widechar
string with mbstowcs() and then back down again to a BMPString, taking the
machine endianness into account.  Again, the behaviour of mbstowcs() will
depend on the current locale in use.  If the system doesn't have widechar
support, the best you can do is a brute-force conversion to Unicode by hoping
it's ISO 8859-1 and adding a zero byte every other byte.

Now that you might have the strings in a format where they can be compared, you
can actually try and compare them.  Again, this often ends up as pure guesswork
if the system doesn't support the necessary character sets, or if the
characters use weird encodings which result in identical characters being
located at different code points.

First, check the converted character sets: If one is Unicode and the other
isn't, then the strings probably differ (depending on how well the
canonicalisation step went).  If the types are the same, strip leading,
trailing, and repeated internal spaces from the string, which isn't as easy as
it sounds since there are several possible code points allocated to a space.

Once you've had a go at stripping spaces, you can try to compare the strings.
If the string is a BMPString then under Windows NT (but not Windows 95) you can
use CompareString(), with the usual caveat that the comparison depends on the
current locale.  On systems which support towlower() you can extract the
characters from the string into widechars (taking machine endianness into
account) and compare the towlower() forms, with the usual caveat about locale
and the added problem that towlower() implementations vary from bare-bones
(8859-1 only under Solaris) to vague (Unicode under Win95, OSF/1).  If there's
no support for towlower(), the best you can do is use the normal tolower() if
the characters have a high byte of zero (some systems will support 8859-1 for
tolower(), the worst which can happen is that the characters will be returned
unchanged), and compare the code points directly if it isn't an 8-bit value.

                    Zaphods skin was crawling all over his body as if it was
                    trying to get off.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

Finally, if it's an ASCII string, you can just use a standard case-insensitive
string comparison function.

As you can see, there's almost no way to reliably compare two RDN elements. In
particular, no matter what you do:

- Some malicious users will deliberately pass DN checks with weird encodings.
- Some normal users will accidentally fail DN checks with weird encodings.

This becomes an issue when certain security checks depend on a comparison of
DN's (for example with excluded subtrees in the Name Constraints extension)
because it's possible to create multiple strings which are displayed
identically to the user (especially if you know which platform and/or software
to target) assuming they get displayed at all, but which compare as different
strings.  If you want to be absolutely certain about DN comparisons, you might
need to set a certificate policy of only allowing PrintableStrings in DN's,
because they're the only ones which can be reliably compared.

Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 19 Mar 1998 21:42:24 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] Current Tally on OCSP using ASN.1
To: [email-masked]

As of this posting I count 18 for ASN.1 and 3 opposed.

Unless there's a late surge of opposing write-in votes, I claim the ayes
have it; predictably so.  Point made. So let's get on with the work.

Mike

Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 19 Mar 1998 21:27:16 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

Ambarish,

-----Original Message-----
From: Ambarish Malpani <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, March 19, 1998 1:01 PM
Subject: Re: [IETF-PKIX] New OCSP Requirements

>>. . .
>> ASN.1
>> --------
>> Proposed Resolution:  I will be calling for a poll on this issue in a
>> separate posting and shall update the OCSP draft accordingly.
>
>I agree. A straw poll is a great idea!
>
>>
>> Multiple Certs In Request
>> -----------------------------------
>> The Notary Protocol already enables these more complex constructions.
OCSP
>> is intended to be a simple query on a single certificate.
>>
>> Proposed Resolution:  Allocate this requirement to the notary protocol.
A
>> proposal to add validation of multiple target certs, including a
>> cert-path for each target cert, to the Notary Protocol, was posted to the
>> PKIX list  recently.
>
>If you go with ASN.1, supporting multiple certs in a request is really
>no
>tougher than supporting a single cert. It also makes the solution
>significantly more scalable, because the server needs to provide just
>a single signature instead of multiple signatures.
>Its usage of bandwidth is also lower, since you don't need to make
>independent connections for each of the certificates you want to check.

See my response to Paul Hoffman on the same issue.  Bottom line:  OCSP needs
to accomodate multiple certs if for no other reason than a single S/MIME
message may contain both a signature certificate and an encryption
certificate.

>>
>> Multiple Response Types
>> ----------------------------------
>> OCSP speaks only to revocation information.  This is a well defined
>> spectrum.  Situations that might stimulate the production of other
response
>> types are only producable using more advanced mechanisms that are beyond
the
>> scope of OCSP.
>>
>> Proposed Resolution:  Allocate the requirement for "negotiated response
>> types" to the notary protocol.  The Malpani spec includes a variety of
>> additional information on a revoked certificate, e.g. revocation reason
and
>> invalidity date.  This would be a useful addition in both OCSP and the
>> notary protocol.
>
>Again, why not allow OCSP to support different kinds of responses in the
>future? The only change this needs in the protocol is adding a response
>type field in the header. Hopefully that doesn't make the protocol
>significantly harder to implement.

Agree.

>
>>
>> Ceritificate Identification
>> --------------------------------
>> The proposed alternative to certificate identification addresses
>> requirements that have been debated within X.509 and elsewhere, resulting
in
>> the construct AuthorityKeyIdentifier.  The alternative observes that CA
name
>> collisions are possible and thus proposes the cert ID be a function of CA
>> name and key.  However, the occurrence of this event seems remote given
the
>> prevailing practice of CA naming.
>>
>> Proposed Resolution:  Pending the outcome of the straw poll, revisit the
>> syntax of certId in OCSP.  If indeed the observation regarding CA name
>> collisions can be substantiated as a real-world problem, then PKIX may
wish
>> to consider a defect report to X.509 regarding the security risks
inherent
>> in the AuthorityCertIssuer option of AuthorityKeyIdentifier.
>
>Another simple modification to the protocol. OCSP hashes the entire
>certificate, RCSP hashes the issuer's DN and public key and sends the
>serial number along separately. That makes identification of the
>certificate
>being referred to stronger. It also lets the responder know which issuer
>the requestor is referring to, unlike OCSP, where you just get a hash
>and
>guess about whether you issued that certificate or not.

Please see my response to Paul Hoffman on this issue.

>Optionally, in RCSP, you can send the entire cert in the request.

OCSP enables one to send the entire cert in the request, albeit assuming
HTTP mechanisms.  We may need to revisit this requirement in light of both
the ASN.1 resolution and transport indenpendance.

>
>>
>> Address revocation only in OCSP, not validation
>> ----------------------------------------------------------------
>> Proposed resolution:  Language regarding or implying validation *of
>> certification paths to the target cert* will be removed from OCSP.   The
>> notary protocol may be updated to accomodate this and any additional
context
>> validation schemes.
>
>RCSP doesn't talk about validation of certificate paths either. A
>responder
>gets a set of certificates and responds about the status of each of
>them.
>It doesn't claim to check for paths - that is better done directly by
>the
>client.

Agree.

>
>>
>> Delegation of Authority
>> ------------------------------
>> The proposed delegation model should be revisited in the broader context
of
>> Attribute Certificates and certificate-based access control generally, a
>> topic that has often been informally discussed within PKIX but never
moved
>> forward to a work product.  Establishing point-wise solutions to this
>> problem creates a patchwork of what could and should be a unified
approach
>> to the subject.
>>
>> Proposed Resolution:   Defer discussion of specific delegation mechanisms
to
>> a future work product which consolidates all points of view and essential
>> requirements regarding certificate-based access control.  This future
work
>> product could easily address mechanisms that govern permissible use of
OCSP,
>> Notary Protocol and other essential PKI services.
>
>Both OCSP and RCSP do talk about delegating the task of generating
>responses
>to a responder, who could have a different public/private key pair than
>the
>CA. It makes good sense to allow this, because a CA doesn't really need
>to run 7x24, while a responder does. Also, by allowing delegation of
>OCSP responses, you allow a company, like Verisign, which runs multiple
>independent CAs, to have just a single responder, which replies to
>queries about each of those CAs.
>If you agree that delegation is a good idea, then we should be explicit
>about the implication of this delegation for the CA and how the
>delegation works.

The whole delgation issue needs to be considered in a broader context.
We've been talking about this concept for years but haven't done anything
about it.  It's high time we did.

Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 19 Mar 1998 21:03:02 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

Paul,

I've deleted from this response those points where there are no changes to
the Proposed Resolutions.

Mike

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, March 19, 1998 10:43 AM
Subject: Re: [IETF-PKIX] New OCSP Requirements

>>Multiple Certs In Request
>>-----------------------------------
>>The Notary Protocol already enables these more complex constructions.
OCSP
>>is intended to be a simple query on a single certificate.
>>
>>Proposed Resolution:  Allocate this requirement to the notary protocol.  A
>>proposal to add validation of multiple target certs, including a
>>cert-path for each target cert, to the Notary Protocol, was posted to the
>>PKIX list  recently.
>
>Disagree. I think multiple cert requests in OCSP would be valuable for both
>the end entity and the CA in reducing network traffic. Why waste multiple
>round trips when a single request and a single response will do? A
>real-world example of where this is useful is S/MIME messages that have
>multiple certificates that are from the same CA.
>
>If you trust a single un-nonced response, you will trust many of them in
>the same HTTP response. Of course, notary should allow this as well, but
>this isn't a "heavyweight" kind of requirement.

A good catch.  There could be separate signature and encryption
certificates for a single S/MIME message.  OCSP should accomodate
this scenario.

>>Multiple Response Types
>>----------------------------------
>>OCSP speaks only to revocation information.  This is a well defined
>>spectrum.  Situations that might stimulate the production of other
response
>>types are only producable using more advanced mechanisms that are beyond
the
>>scope of OCSP.
>
>I disagree with the problem statement. Multiple response types could easily
>be used without "more advanced mechanisms". Cutting off multiple response
>types limits the ability to later extend this protocol. This seems like a
>trivial addition to OCSP and would give future protocol developers greater
>flexibility.

The proposed resolution to this problem statement addresses the
syntatic element in the Malpani contribution that enables clients to
specify subsets of response types.  This I felt is beyond the scope of
OCSP.  I was not proposing that OCSP limit itself to a simple binary
response.  It never did.

I believe we are in agreement here that the current base OCSP spec
meets your needs for multiple response types.

>
>>Ceritificate Identification
>>--------------------------------
>>The proposed alternative to certificate identification addresses
>>requirements that have been debated within X.509 and elsewhere, resulting
in
>>the construct AuthorityKeyIdentifier.  The alternative observes that CA
name
>>collisions are possible and thus proposes the cert ID be a function of CA
>>name and key.  However, the occurrence of this event seems remote given
the
>>prevailing practice of CA naming.
>>
>>Proposed Resolution:  Pending the outcome of the straw poll, revisit the
>>syntax of certId in OCSP.  If indeed the observation regarding CA name
>>collisions can be substantiated as a real-world problem, then PKIX may
wish
>>to consider a defect report to X.509 regarding the security risks inherent
>>in the AuthorityCertIssuer option of AuthorityKeyIdentifier.
>
>A restatement of this resolution is "wait until there is a problem, then
>kick it to a different standards body". There is certainly a lot of
>precedent for this :-), but not in the best interest of the folks
>implementing OCSP. I think simply removing the "|" in the definition of
>"hash" in the current OCSP spec is a much better idea that will completely
>avoid the problem before it ever comes up. Computing the hash over a
>combination of two fields is not much more onerous than computing it over
>one or the other.

I can and will agree that the variation in hash computation is trival.
However, variation in the hash computation is not the issue raised by the
Proposed Resolution, but rather whether we as a group feel that the observed
security weakness is a real one.  If so, then I feel that owe it the ITU to
inform them of our conclusions regarding the security of their
recommendations on this point.  Members of PKIX have done so in the past as
we work to interpret X.509 for our needs.  If we haven't sufficient
consensus regarding the security risk to take this step, then I must
question the basis of the change.

To resolve this point, I would ask that participating members of PKIX
provide their opinion on the matter.  As with the ASN.1 issue, OCSP can and
will be adjusted to reflect that consensus.  Until then I would prefer to
maintain the spec of certID as is since it is aligned with concepts defined
in X.509.

My concern here is alignment with other PKI-based security protocols, not
the least of with is CMS.  Might I note that the SignerInfos syntax has as
an element issuerAndSerialNumber which is defined as:

IssuerAndSerialNumber ::= SEQUENCE {
        issuer Name,
        serialNumber SerialNumber }

SerialNumber ::= INTEGER

Approved-By:  Stephen Kent <[email-masked]>
Date:         Thu, 19 Mar 1998 20:45:07 -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] OCSP ASN.1 Poll
To: [email-masked]

Mike,

I vote for use of ASN.1.

Steve

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 13:09:31 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

I vote NO.

The arguments about ASN.1 parsers are completely bogus. Windows NT
ships with PKCS#7 parsing ironmongery but it does not ship with a generic
ASN.1 compiler. Similar arguments hold for other platforms.

I think the vote should also clearly point out that there is a loss of
functionality in going to ASN.1.The responses are no longer
cachable as HTTP requests.

It is easy to make arguments about consistency, I am concerned about
function.

    Phill

>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 15:01:04 -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: Charles Blauner <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

Folks;

I would also vote yes on the ASN.1 encoding question.

Charles Blauner
JP Morgan
Security & Internet Architecture

ambarish @ valicert.com on 03/19/98 02:51:33 PM

Please respond to [email-masked]

To:   IETF-PKIX @ LISTS.TANDEM.COM
cc:   (Charles Blauner)
Subject:  Re: [IETF-PKIX] OCSP ASN.1 Poll

YES

Ambarish

Michael Myers wrote:
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 19 Mar 1998 17:19:09 -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] Comments on pkix-ipki-part1
Comments: To: [email-masked]
To: [email-masked]

Extremely useful and interesting. I hadn't seen it, and it even has a quote of mine!

Thanks, Bruce, and especially, Peter.

Bob

>>> Bruce Greenblatt <[email-masked]> 03/19 4:17 PM >>>
Hey Bob,

Check out http://www.cs.auckland.ac.nz/~pgut001/...

Bruce

> -----Original Message-----
> From: Bob Jueneman [SMTP:[email-masked]]
> Sent: Thursday, March 19, 1998 11:44 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
>
> Peter,
>
> First of all, my condolances on your power outage situation. That's
> right up there with one of my other correspondent's having her entire
> town (Minden, North Dakota, US -- not exactly a huge metropolis like
> Auckland, but none heless devastating to her) flooded out and her
> basement full of mud.
>
> WRT the character encoding issue, I would be happy to reprise my
> collection of sends and receives if you were incommunicado and missed
> some. I am particularly interested in the problem of multilingual
> company names, both "official" (registered) and unofficial
> transliterations and translations.  And as a result of that
> discussion, I am increasingly interested in including jpeg logos in
> subjectaltname and issuerAltName.
>
> Even before you finish updating your style guide, which I confess not
> to have seen (a URL?), I would appreciate any comments you might have
> on "broken" attributes.  If you haven't notice it yet, one of my
> candiates is the explicitNotice field -- it's unusable without
> allowing multiples, with a language tag.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
>
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
>
> "The most dangerous strategy is to cross a chasm in two jumps."
>
>
> >>> Peter Gutmann <[email-masked]> 03/18 10:13 PM >>>
> [I'm sending this from an alternative address, mail from my usual
> address
>  either isn't getting or out is vanishing somewhere]
>
> While I was waiting for our local power monopoly to figure out how
> they were
> going to supply the central business district of the city with power
> (apparently the power outage we're currently in the middle of,
> documented at
> http://www.kcbbs.gen.nz/users/peterg/power.txt, rates as the worst
> peacetime
> power outage ever), I thought I'd poke around with cert extensions a
> bit so I
> could add them to the X.509 style guide.
>
> It's probably going to double in size.  I also need to reread my
> H.P.Lovecraft
> collection so I can find enough quotes about horror and madness to
> decorate
> the margins in the manner that the guide currently does :-).  I caught
> the
> tail end of the debate on character encodings, I'll have a long
> section
> devoted to that in there as well (there's at least one extension which
> breaks
> completely over this issue).
>
> In the meantime, here are a few quick comments on the 14 October draft
> of
> ipki-part1.  Some problems I noticed were:
>
> 4.2.1.2.
>
> This gives the subject key identifier as the hash of the
> subjectPublicKeyInfo
> *without* the tag and length.  Is this a mistake, or is it meant to be
> like
> that?  Every other instance in which an ASN.1 object is hashed (eg
> certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes
> the
> entire object.  In fact the PKIX CMP draft uses a hash of the full
> subjectPublicKeyInfo in the OOBCertHash, which would make it
> incompatible with
> the value in the subject key identifier.  Requiring a well-defined
> standard
> X.509 object to be broken up into pieces before processing it seems an
> extremely peculiar move, so I'm guessing it's some sort of mistake in
> the spec.
>
> In addition I really don't like the idea of dumping a raw hash into
> the
> KeyIdentifier OCTET STRING, because it's not possible to distinguish
> it from
> whatever anyone else decides to put in there.  Much better would be to
> use the
> PKCS #7 DigestInfo, which is well-defined and whose OID + data format
> uniquely
> identifies the contents (that is, make the KeyIdentifier an OCTET
> STRING hole
> for a DigestInfo rather than an opaque blob).  Given that a
> KeyIdentifier
> could potentially contain anything, it's somewhat risky to put raw,
> unidentified data in there.
>
> 4.2.1.3.
>
> The decipherOnly key usage indicates that the public key can only be
> used for
> deciphering data.  This would be quite a feat :-).  I assume this
> should say
> that the private key corresponding to the public key can only be used
> for
> deciphering data.
>
> Speaking of private vs public keys, it would be useful to have some
> standard
> unambiguous term defined to indicate the private key which is tied to
> the
> public key, eg "corresponding to" or "identified by" or "paired with"
> or
> something similar.  I've used "identified by" (eg "The end-user
> certificate
> should be signed by the private key identified by a CA certificate"),
> but I'm
> not sure if that sounds right.  The current draft seems to use
> different terms
> in different places.
>
> 7.3.2.
>
> This gives a redundant definition of the DH p and g values (the ASN.1
> definition is followed immediately by text which says exactly the same
> thing -
> actually the RSA definition does this too with n and e), but doesn't
> explain
> the INTEGER which is the DH public key (what *is* this value?  The
> only thing
> I can think of is g^x mod p, but that shouldn't be a fixed value).  It
> also
> goes to some lengths to explain the encoding of the INTEGER parameter
> as a BIT
> STRING, which seems very odd.
>
> D.1.
>
> The supposed CA certificate isn't actually a CA cert because the
> basicConstraints are empty.  Is this really what NIST CA certs look
> like? If
> it is, I should add another entry to the "Bugs" section of the X.509
> style
> guide :-).
>
> Peter.

Approved-By:  [email-masked]
Date:         Fri, 20 Mar 1998 09:52:33 +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: [email-masked]
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

Use ASN.1

> -----Original Message-----
> From: Michael Myers [SMTP:[email-masked]]
> Sent: Thursday, March 19, 1998 4:31 PM
> To:   [email-masked]
> Subject:      [IETF-PKIX] OCSP ASN.1 Poll
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

Approved-By:  "Matthew S. Hamrick" <[email-masked]>
Date:         Thu, 19 Mar 1998 17:43:14 -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: "Matthew S. Hamrick" <[email-masked]>
Organization: i2 Technologies
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

This is a multi-part message in MIME format.
--------------6700EFFC1B70A30C25E237F0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yes, provided it specifies DER encoding.

I believe that one's opinion of this topic is heavily influenced by how
good your ASN.1 / BER / DER tools are. I have a toolset that that
generates a remarkably good code footprint if you turn indefinite length
encoding off.

Michael Myers wrote:

> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

--------------6700EFFC1B70A30C25E237F0
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Matthew S. Hamrick
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Matthew S. Hamrick
n:              Hamrick;Matthew S.
org:            Uptronics Incorporated
adr:            298 S. Sunnyvale Ave.;;Suite 211;Sunnyvale;CA;96086;US
email;internet: [email-masked]
title:          Cryptologic Engineer
tel;work:       408.774.6207
tel;fax:        408.774.6201
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------6700EFFC1B70A30C25E237F0--

Approved-By:  Bruce Greenblatt <[email-masked]>
Date:         Thu, 19 Mar 1998 15:17:40 -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: Bruce Greenblatt <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

Hey Bob,

Check out http://www.cs.auckland.ac.nz/~pgut001/...

Bruce

> -----Original Message-----
> From: Bob Jueneman [SMTP:[email-masked]]
> Sent: Thursday, March 19, 1998 11:44 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
>
> Peter,
>
> First of all, my condolances on your power outage situation. That's
> right up there with one of my other correspondent's having her entire
> town (Minden, North Dakota, US -- not exactly a huge metropolis like
> Auckland, but none heless devastating to her) flooded out and her
> basement full of mud.
>
> WRT the character encoding issue, I would be happy to reprise my
> collection of sends and receives if you were incommunicado and missed
> some. I am particularly interested in the problem of multilingual
> company names, both "official" (registered) and unofficial
> transliterations and translations.  And as a result of that
> discussion, I am increasingly interested in including jpeg logos in
> subjectaltname and issuerAltName.
>
> Even before you finish updating your style guide, which I confess not
> to have seen (a URL?), I would appreciate any comments you might have
> on "broken" attributes.  If you haven't notice it yet, one of my
> candiates is the explicitNotice field -- it's unusable without
> allowing multiples, with a language tag.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
>
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
>
> "The most dangerous strategy is to cross a chasm in two jumps."
>
>
> >>> Peter Gutmann <[email-masked]> 03/18 10:13 PM >>>
> [I'm sending this from an alternative address, mail from my usual
> address
>  either isn't getting or out is vanishing somewhere]
>
> While I was waiting for our local power monopoly to figure out how
> they were
> going to supply the central business district of the city with power
> (apparently the power outage we're currently in the middle of,
> documented at
> http://www.kcbbs.gen.nz/users/peterg/power.txt, rates as the worst
> peacetime
> power outage ever), I thought I'd poke around with cert extensions a
> bit so I
> could add them to the X.509 style guide.
>
> It's probably going to double in size.  I also need to reread my
> H.P.Lovecraft
> collection so I can find enough quotes about horror and madness to
> decorate
> the margins in the manner that the guide currently does :-).  I caught
> the
> tail end of the debate on character encodings, I'll have a long
> section
> devoted to that in there as well (there's at least one extension which
> breaks
> completely over this issue).
>
> In the meantime, here are a few quick comments on the 14 October draft
> of
> ipki-part1.  Some problems I noticed were:
>
> 4.2.1.2.
>
> This gives the subject key identifier as the hash of the
> subjectPublicKeyInfo
> *without* the tag and length.  Is this a mistake, or is it meant to be
> like
> that?  Every other instance in which an ASN.1 object is hashed (eg
> certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes
> the
> entire object.  In fact the PKIX CMP draft uses a hash of the full
> subjectPublicKeyInfo in the OOBCertHash, which would make it
> incompatible with
> the value in the subject key identifier.  Requiring a well-defined
> standard
> X.509 object to be broken up into pieces before processing it seems an
> extremely peculiar move, so I'm guessing it's some sort of mistake in
> the spec.
>
> In addition I really don't like the idea of dumping a raw hash into
> the
> KeyIdentifier OCTET STRING, because it's not possible to distinguish
> it from
> whatever anyone else decides to put in there.  Much better would be to
> use the
> PKCS #7 DigestInfo, which is well-defined and whose OID + data format
> uniquely
> identifies the contents (that is, make the KeyIdentifier an OCTET
> STRING hole
> for a DigestInfo rather than an opaque blob).  Given that a
> KeyIdentifier
> could potentially contain anything, it's somewhat risky to put raw,
> unidentified data in there.
>
> 4.2.1.3.
>
> The decipherOnly key usage indicates that the public key can only be
> used for
> deciphering data.  This would be quite a feat :-).  I assume this
> should say
> that the private key corresponding to the public key can only be used
> for
> deciphering data.
>
> Speaking of private vs public keys, it would be useful to have some
> standard
> unambiguous term defined to indicate the private key which is tied to
> the
> public key, eg "corresponding to" or "identified by" or "paired with"
> or
> something similar.  I've used "identified by" (eg "The end-user
> certificate
> should be signed by the private key identified by a CA certificate"),
> but I'm
> not sure if that sounds right.  The current draft seems to use
> different terms
> in different places.
>
> 7.3.2.
>
> This gives a redundant definition of the DH p and g values (the ASN.1
> definition is followed immediately by text which says exactly the same
> thing -
> actually the RSA definition does this too with n and e), but doesn't
> explain
> the INTEGER which is the DH public key (what *is* this value?  The
> only thing
> I can think of is g^x mod p, but that shouldn't be a fixed value).  It
> also
> goes to some lengths to explain the encoding of the INTEGER parameter
> as a BIT
> STRING, which seems very odd.
>
> D.1.
>
> The supposed CA certificate isn't actually a CA cert because the
> basicConstraints are empty.  Is this really what NIST CA certs look
> like? If
> it is, I should add another entry to the "Bugs" section of the X.509
> style
> guide :-).
>
> Peter.

Approved-By:  Slava Galperin <[email-masked]>
Date:         Thu, 19 Mar 1998 15:04: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: Slava Galperin <[email-masked]>
Organization: Netscape Communications Corp
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

Michael Myers wrote:
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?

I guess I said YES already by contributing to the ASN.1-based
alternative proposal ;-)

--
Slava Galperin          Certified Certificate Certifier
[email-masked]   tel: 650.937.6757

 It doesn't matter so much whether you've won the war or lost it.
 What matters is who you have lost it to.
                            -- From the memoirs of a married man

Approved-By:  John Lowry <[email-masked]>
Date:         Thu, 19 Mar 1998 17:08:26 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: John Lowry <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

I vote for ASN.1

-- but then I _like_ ASN.1 ...

John Lowry

>----------
>From:  Michael Myers[SMTP:[email-masked]]
>Sent:  Thursday, March 19, 1998 1:30 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] OCSP ASN.1 Poll
>
>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Thu, 19 Mar 1998 16:43:50 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

I'll add my vote for ASN.1.

I hope someone's keeping track of all this so we don't need a re-count
at the end...  :-)

Carlisle.

>----------
>From:  Michael Myers[SMTP:[email-masked]]
>Sent:  Thursday, March 19, 1998 1:30 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] OCSP ASN.1 Poll
>
>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Thu, 19 Mar 1998 16:33: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: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

I think that I would prefer to see the protocol expressed in ASN.1.

        Robert Zuccherato
        Entrust Technologies

>----------
>From:  Michael Myers[SMTP:[email-masked]]
>Sent:  Thursday, March 19, 1998 1:30 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] OCSP ASN.1 Poll
>
>All,
>
>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?
>
>A rough consensus of YES would result in modifying the existing
>OCSP draft to change the request and response syntax appropriately.
>
>A rough consensus of NO would result in maintaining the current
>ABNF syntax.
>
>In either case, protocol elements may change as a result of the
>incorporation of additional requirements.
>
>Mike
>

Approved-By:  Todd Glassey <[email-masked]>
Date:         Thu, 19 Mar 1998 12:46:09 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msFBDDE29CC76111E8611F3ABA
Content-Type: multipart/mixed; boundary="------------9F8D9B49165CF14C0D4E0CBB"

This is a multi-part message in MIME format.
--------------9F8D9B49165CF14C0D4E0CBB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

yes, ASN.1 is better than ABNF notation styles

Todd

Ambarish Malpani wrote:

> YES
>
> Ambarish
>
> Michael Myers wrote:
> >
> > All,
> >
> > Here's the separate ASN.1 poll question mentioned in my prior message:
> >
> > Should OCSP request and response syntax be expressed in ASN.1?
> >
> > A rough consensus of YES would result in modifying the existing
> > OCSP draft to change the request and response syntax appropriately.
> >
> > A rough consensus of NO would result in maintaining the current
> > ABNF syntax.
> >
> > In either case, protocol elements may change as a result of the
> > incorporation of additional requirements.
> >
> > Mike
>
> --
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                              (650) 849-9880
> ValiCert, Inc.                                  [email-masked]
> 3160 W. Bayshore Road                         http://www.valicert.com
> Palo Alto, CA 94303

--
--------
--  Regards,
--  Todd Glassey

Todd's Latest Rant --
---------------------
"...Plan?, There ain't no plan, I though' you had the plan..."
      The Pig Killer - Mad Max: Beyond Thunderdome

--------------9F8D9B49165CF14C0D4E0CBB
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Glassey, Todd S.
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Todd S. Glassey
n:              Glassey;Todd S.
org:            Coastek, Inc.
adr:            5550 Scotts Valley Drive;;Suite 700;Scotts Valley;Ca;95066;USA
email;internet: [email-masked]
title:          Chief Scientist and Principal Founder
tel;work:       408.440.0180
tel;fax:        408.438.2979
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------9F8D9B49165CF14C0D4E0CBB--

--------------msFBDDE29CC76111E8611F3ABA
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msFBDDE29CC76111E8611F3ABA--

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Thu, 19 Mar 1998 12:49:16 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

Hi Mike/All,
    The changes we have proposed in RCSP were specifically designed to
make it easier to implement. Not harder. I am not sure why any of
these would make OCSP more "heavyweight".

Let's address each of the changes:

Michael Myers wrote:
>
> All,
>
> The recent discussion on OCSP has resulted in a list of candidate new
> requirements that have not yet received the full vetting of the group.  I
> spoke with Rich  regarding the relationship of these requirements to both
> OCSP and the notary protocol in the context of his recent posting on
> "lightweight" and "heavyweight" options.
>
> This discussion led to the following joint proposal.  The "lightweight"
> option is OCSP revised to accomodate requirements appropriate to its scope
> from among  those identified by the Malpani et. al. contribution.  The
> "heavyweight" option is the notary protocol equivalently revised to
> accomodate other of the of those requirements.
>
> Taking each point by point:
>
> ASN.1
> --------
> Proposed Resolution:  I will be calling for a poll on this issue in a
> separate posting and shall update the OCSP draft accordingly.

I agree. A straw poll is a great idea!

>
> Multiple Certs In Request
> -----------------------------------
> The Notary Protocol already enables these more complex constructions.  OCSP
> is intended to be a simple query on a single certificate.
>
> Proposed Resolution:  Allocate this requirement to the notary protocol.  A
> proposal to add validation of multiple target certs, including a
> cert-path for each target cert, to the Notary Protocol, was posted to the
> PKIX list  recently.

If you go with ASN.1, supporting multiple certs in a request is really
no
tougher than supporting a single cert. It also makes the solution
significantly more scalable, because the server needs to provide just
a single signature instead of multiple signatures.
Its usage of bandwidth is also lower, since you don't need to make
independent connections for each of the certificates you want to check.

>
> Transport Independance
> ---------------------------------
> The initial OCSP drafts was structure to enable transport independance.  The
> current draft is written to ensure that at least one transport mechanism is
> implemented.  Until recently, no exception was taken to that position.
>
> Proposed Resolution:  Correct the current OCSP draft to speak to the
> enablement of transport independance, but yet maintain HTTP as one
> well-defined mechanism.  Consideration is being given to a sockets-based
> specification in the base OCSP draft.  If other transports are desired,
> interested parties are encouraged to produce companion drafts.

Agree.

>
> Multiple Response Types
> ----------------------------------
> OCSP speaks only to revocation information.  This is a well defined
> spectrum.  Situations that might stimulate the production of other response
> types are only producable using more advanced mechanisms that are beyond the
> scope of OCSP.
>
> Proposed Resolution:  Allocate the requirement for "negotiated response
> types" to the notary protocol.  The Malpani spec includes a variety of
> additional information on a revoked certificate, e.g. revocation reason and
> invalidity date.  This would be a useful addition in both OCSP and the
> notary protocol.

Again, why not allow OCSP to support different kinds of responses in the
future? The only change this needs in the protocol is adding a response
type field in the header. Hopefully that doesn't make the protocol
significantly harder to implement.

>
> Ceritificate Identification
> --------------------------------
> The proposed alternative to certificate identification addresses
> requirements that have been debated within X.509 and elsewhere, resulting in
> the construct AuthorityKeyIdentifier.  The alternative observes that CA name
> collisions are possible and thus proposes the cert ID be a function of CA
> name and key.  However, the occurrence of this event seems remote given the
> prevailing practice of CA naming.
>
> Proposed Resolution:  Pending the outcome of the straw poll, revisit the
> syntax of certId in OCSP.  If indeed the observation regarding CA name
> collisions can be substantiated as a real-world problem, then PKIX may wish
> to consider a defect report to X.509 regarding the security risks inherent
> in the AuthorityCertIssuer option of AuthorityKeyIdentifier.

Another simple modification to the protocol. OCSP hashes the entire
certificate, RCSP hashes the issuer's DN and public key and sends the
serial number along separately. That makes identification of the
certificate
being referred to stronger. It also lets the responder know which issuer
the requestor is referring to, unlike OCSP, where you just get a hash
and
guess about whether you issued that certificate or not.
Optionally, in RCSP, you can send the entire cert in the request.

>
> Address revocation only in OCSP, not validation
> ----------------------------------------------------------------
> Proposed resolution:  Language regarding or implying validation *of
> certification paths to the target cert* will be removed from OCSP.   The
> notary protocol may be updated to accomodate this and any additional context
> validation schemes.

RCSP doesn't talk about validation of certificate paths either. A
responder
gets a set of certificates and responds about the status of each of
them.
It doesn't claim to check for paths - that is better done directly by
the
client.

>
> Delegation of Authority
> ------------------------------
> The proposed delegation model should be revisited in the broader context of
> Attribute Certificates and certificate-based access control generally, a
> topic that has often been informally discussed within PKIX but never moved
> forward to a work product.  Establishing point-wise solutions to this
> problem creates a patchwork of what could and should be a unified approach
> to the subject.
>
> Proposed Resolution:   Defer discussion of specific delegation mechanisms to
> a future work product which consolidates all points of view and essential
> requirements regarding certificate-based access control.  This future work
> product could easily address mechanisms that govern permissible use of OCSP,
> Notary Protocol and other essential PKI services.

Both OCSP and RCSP do talk about delegating the task of generating
responses
to a responder, who could have a different public/private key pair than
the
CA. It makes good sense to allow this, because a CA doesn't really need
to run 7x24, while a responder does. Also, by allowing delegation of
OCSP responses, you allow a company, like Verisign, which runs multiple
independent CAs, to have just a single responder, which replies to
queries about each of those CAs.
If you agree that delegation is a good idea, then we should be explicit
about the implication of this delegation for the CA and how the
delegation works.

>
> Mike

Regards,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 19 Mar 1998 12:45:56 -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 ASN.1 Poll
Comments: To: [email-masked]
To: [email-masked]

I think I'm on record for strongly favoring ASN.1.

Bob

>>> Michael Myers <[email-masked]> 03/18 11:30 PM >>>
All,

Here's the separate ASN.1 poll question mentioned in my prior message:

Should OCSP request and response syntax be expressed in ASN.1?

A rough consensus of YES would result in modifying the existing
OCSP draft to change the request and response syntax appropriately.

A rough consensus of NO would result in maintaining the current
ABNF syntax.

In either case, protocol elements may change as a result of the
incorporation of additional requirements.

Mike

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Thu, 19 Mar 1998 11:51:33 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

YES

Ambarish

Michael Myers wrote:
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 19 Mar 1998 12:43:47 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
Comments: To: Peter Gutmann <[email-masked]>
To: [email-masked]

Peter,

First of all, my condolances on your power outage situation. That's right up there with one of my other correspondent's having her entire town (Minden, North Dakota, US -- not exactly a huge metropolis like Auckland, but none heless devastating to her) flooded out and her basement full of mud.

WRT the character encoding issue, I would be happy to reprise my collection of sends and receives if you were incommunicado and missed some. I am particularly interested in the problem of multilingual company names, both "official" (registered) and unofficial transliterations and translations.  And as a result of that discussion, I am increasingly interested in including jpeg logos in subjectaltname and issuerAltName.

Even before you finish updating your style guide, which I confess not to have seen (a URL?), I would appreciate any comments you might have on "broken" attributes.  If you haven't notice it yet, one of my candiates is the explicitNotice field -- it's unusable without allowing multiples, with a language tag.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Peter Gutmann <[email-masked]> 03/18 10:13 PM >>>
[I'm sending this from an alternative address, mail from my usual address
 either isn't getting or out is vanishing somewhere]

While I was waiting for our local power monopoly to figure out how they were
going to supply the central business district of the city with power
(apparently the power outage we're currently in the middle of, documented at
http://www.kcbbs.gen.nz/users/peterg/power.txt, rates as the worst peacetime
power outage ever), I thought I'd poke around with cert extensions a bit so I
could add them to the X.509 style guide.

It's probably going to double in size.  I also need to reread my H.P.Lovecraft
collection so I can find enough quotes about horror and madness to decorate
the margins in the manner that the guide currently does :-).  I caught the
tail end of the debate on character encodings, I'll have a long section
devoted to that in there as well (there's at least one extension which breaks
completely over this issue).

In the meantime, here are a few quick comments on the 14 October draft of
ipki-part1.  Some problems I noticed were:

4.2.1.2.

This gives the subject key identifier as the hash of the subjectPublicKeyInfo
*without* the tag and length.  Is this a mistake, or is it meant to be like
that?  Every other instance in which an ASN.1 object is hashed (eg
certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes the
entire object.  In fact the PKIX CMP draft uses a hash of the full
subjectPublicKeyInfo in the OOBCertHash, which would make it incompatible with
the value in the subject key identifier.  Requiring a well-defined standard
X.509 object to be broken up into pieces before processing it seems an
extremely peculiar move, so I'm guessing it's some sort of mistake in the spec.

In addition I really don't like the idea of dumping a raw hash into the
KeyIdentifier OCTET STRING, because it's not possible to distinguish it from
whatever anyone else decides to put in there.  Much better would be to use the
PKCS #7 DigestInfo, which is well-defined and whose OID + data format uniquely
identifies the contents (that is, make the KeyIdentifier an OCTET STRING hole
for a DigestInfo rather than an opaque blob).  Given that a KeyIdentifier
could potentially contain anything, it's somewhat risky to put raw,
unidentified data in there.

4.2.1.3.

The decipherOnly key usage indicates that the public key can only be used for
deciphering data.  This would be quite a feat :-).  I assume this should say
that the private key corresponding to the public key can only be used for
deciphering data.

Speaking of private vs public keys, it would be useful to have some standard
unambiguous term defined to indicate the private key which is tied to the
public key, eg "corresponding to" or "identified by" or "paired with" or
something similar.  I've used "identified by" (eg "The end-user certificate
should be signed by the private key identified by a CA certificate"), but I'm
not sure if that sounds right.  The current draft seems to use different terms
in different places.

7.3.2.

This gives a redundant definition of the DH p and g values (the ASN.1
definition is followed immediately by text which says exactly the same thing -
actually the RSA definition does this too with n and e), but doesn't explain
the INTEGER which is the DH public key (what *is* this value?  The only thing
I can think of is g^x mod p, but that shouldn't be a fixed value).  It also
goes to some lengths to explain the encoding of the INTEGER parameter as a BIT
STRING, which seems very odd.

D.1.

The supposed CA certificate isn't actually a CA cert because the
basicConstraints are empty.  Is this really what NIST CA certs look like? If
it is, I should add another entry to the "Bugs" section of the X.509 style
guide :-).

Peter.

Approved-By:  John Pawling <[email-masked]>
Date:         Thu, 19 Mar 1998 14:21: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: John Pawling <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

All,

I vote to use ASN.1.

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

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 11:55: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: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

At 10:30 PM 3/18/98 -0800, you wrote:

>Here's the separate ASN.1 poll question mentioned in my prior message:
>
>Should OCSP request and response syntax be expressed in ASN.1?

I would vote NO, if it was clearly understood by everybody that OCSP is not
going to be extended or enhanced in any way and that all enhancements will
be done in the Notary Protocol.  Given IETF history, I don't believe this
for a minute.

Hal

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

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 12:07:34 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dave Horvath <[email-masked]>
Organization: Chromatix Inc.
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

My vote is:

        Yes

Michael Myers wrote:
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

--
               ================================================

      _/_/_/                   David J. Horvath
   _/      _/
  _/       _/                  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]

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 11:25: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: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
To: [email-masked]

At 05:13 PM 3/19/98 +1200, Peter Gutmann wrote:

>Speaking of private vs public keys, it would be useful to have some standard
>unambiguous term defined to indicate the private key which is tied to the
>public key, eg "corresponding to" or "identified by" or "paired with" or
>something similar.  I've used "identified by" (eg "The end-user certificate
>should be signed by the private key identified by a CA certificate"), but I'm
>not sure if that sounds right.  The current draft seems to use different
terms
>in different places.

How about "matched", e.g. matched-public key, matched-private key?

Hal

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

Approved-By:  Peter Sylvester <[email-masked]>
Date:         Thu, 19 Mar 1998 19:24:12 +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: Peter Sylvester <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

hello,

I wonder whether someone has considered to use a very
lightweight protocol for OCSP based on UDP for exemple
like mapping a request using DNS.

Peter Sylvester

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 19 Mar 1998 10:21:02 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] New OCSP Requirements
To: [email-masked]

>Multiple Certs In Request
>-----------------------------------
>The Notary Protocol already enables these more complex constructions.  OCSP
>is intended to be a simple query on a single certificate.
>
>Proposed Resolution:  Allocate this requirement to the notary protocol.  A
>proposal to add validation of multiple target certs, including a
>cert-path for each target cert, to the Notary Protocol, was posted to the
>PKIX list  recently.

Disagree. I think multiple cert requests in OCSP would be valuable for both
the end entity and the CA in reducing network traffic. Why waste multiple
round trips when a single request and a single response will do? A
real-world example of where this is useful is S/MIME messages that have
multiple certificates that are from the same CA.

If you trust a single un-nonced response, you will trust many of them in
the same HTTP response. Of course, notary should allow this as well, but
this isn't a "heavyweight" kind of requirement.

>Transport Independance
>---------------------------------
>The initial OCSP drafts was structure to enable transport independance.  The
>current draft is written to ensure that at least one transport mechanism is
>implemented.  Until recently, no exception was taken to that position.
>
>Proposed Resolution:  Correct the current OCSP draft to speak to the
>enablement of transport independance, but yet maintain HTTP as one
>well-defined mechanism.  Consideration is being given to a sockets-based
>specification in the base OCSP draft.  If other transports are desired,
>interested parties are encouraged to produce companion drafts.

Agree.

>Multiple Response Types
>----------------------------------
>OCSP speaks only to revocation information.  This is a well defined
>spectrum.  Situations that might stimulate the production of other response
>types are only producable using more advanced mechanisms that are beyond the
>scope of OCSP.

I disagree with the problem statement. Multiple response types could easily
be used without "more advanced mechanisms". Cutting off multiple response
types limits the ability to later extend this protocol. This seems like a
trivial addition to OCSP and would give future protocol developers greater
flexibility.

>Ceritificate Identification
>--------------------------------
>The proposed alternative to certificate identification addresses
>requirements that have been debated within X.509 and elsewhere, resulting in
>the construct AuthorityKeyIdentifier.  The alternative observes that CA name
>collisions are possible and thus proposes the cert ID be a function of CA
>name and key.  However, the occurrence of this event seems remote given the
>prevailing practice of CA naming.
>
>Proposed Resolution:  Pending the outcome of the straw poll, revisit the
>syntax of certId in OCSP.  If indeed the observation regarding CA name
>collisions can be substantiated as a real-world problem, then PKIX may wish
>to consider a defect report to X.509 regarding the security risks inherent
>in the AuthorityCertIssuer option of AuthorityKeyIdentifier.

A restatement of this resolution is "wait until there is a problem, then
kick it to a different standards body". There is certainly a lot of
precedent for this :-), but not in the best interest of the folks
implementing OCSP. I think simply removing the "|" in the definition of
"hash" in the current OCSP spec is a much better idea that will completely
avoid the problem before it ever comes up. Computing the hash over a
combination of two fields is not much more onerous than computing it over
one or the other.

>Address revocation only in OCSP, not validation
>----------------------------------------------------------------
>Proposed resolution:  Language regarding or implying validation *of
>certification paths to the target cert* will be removed from OCSP.   The
>notary protocol may be updated to accomodate this and any additional context
>validation schemes.

Agree.

>Delegation of Authority
>------------------------------
>The proposed delegation model should be revisited in the broader context of
>Attribute Certificates and certificate-based access control generally, a
>topic that has often been informally discussed within PKIX but never moved
>forward to a work product.  Establishing point-wise solutions to this
>problem creates a patchwork of what could and should be a unified approach
>to the subject.
>
>Proposed Resolution:   Defer discussion of specific delegation mechanisms to
>a future work product which consolidates all points of view and essential
>requirements regarding certificate-based access control.  This future work
>product could easily address mechanisms that govern permissible use of OCSP,
>Notary Protocol and other essential PKI services.

Agree. This is an important topic, but can be dealt with in a single work
that modifies the other PKIX documents at once.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 19 Mar 1998 09:48:31 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

Yes. I'm no fan of ASN.1, but it clearly is better for this protocol.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Thu, 19 Mar 1998 09:44:07 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

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

Content-Type: text/plain; charset=us-ascii

Michael Myers <[email-masked]> scrawled:
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>

Yes, use ASN.1.

Regardless of the merits or lack thereof of ASN.1 vs. ABNF, mixing the two
within PKIX doesn't seem wise.

                Marc

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

Approved-By:  Boby Joseph <[email-masked]>
Date:         Thu, 19 Mar 1998 11:14:46 -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: Boby Joseph <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

My vote is:

YES

Boby Joseph
3Com Corporation

Approved-By:  Kevin Kingdon <[email-masked]>
Date:         Thu, 19 Mar 1998 08:45:55 -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: Kevin Kingdon <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

My vote is:

YES

Kevin Kingdon
RSA Data Security, Inc.

> -----Original Message-----
> From: Michael Myers [SMTP:[email-masked]]
> Sent: Wednesday, March 18, 1998 10:31 PM
> To:   [email-masked]
> Subject:      [IETF-PKIX] OCSP ASN.1 Poll
>
> All,
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?
>
> A rough consensus of YES would result in modifying the existing
> OCSP draft to change the request and response syntax appropriately.
>
> A rough consensus of NO would result in maintaining the current
> ABNF syntax.
>
> In either case, protocol elements may change as a result of the
> incorporation of additional requirements.
>
> Mike

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Thu, 19 Mar 1998 11:29:12 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Question about the CMMF/CMRF drafts
To: [email-masked]

Hi Jim,

>----------
>From:  Jim Schaad (Exchange)[SMTP:[email-masked]]
>Sent:  Wednesday, March 18, 1998 4:28 PM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Question about the CMMF/CMRF drafts
>
>Are theses drafts suppose to stand along and be usable as an enrollment
>protocol?  Or are you required to use the CMC (or other equivalent) drafts
>in order to get a functional protocol?

CRMF/CMMF are meant to be used as message bodies within CMP, or CMC, or
some other spec.

Carlisle.

Approved-By:  Stephen Kent <[email-masked]>
Date:         Thu, 19 Mar 1998 10:50: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] Wouldnt adding a certified timestamp kill the issues re: multiple               keys/certificates
To: [email-masked]

Todd,

>Say all,
>So what I was wondering is wouldn't adding some secondary temporal
>authentication mechanisms, like a certified timestamp for instance,
>cleanup the
>Multiple Key per certificate dilemma.
>
>Seems like a no-brianer solution and strengthens the Certificate Value as
>well!
>What do you think?

No, but nice try ;-).  Multiple certs in force at the same time with the
same key pose a problem that is not addressed by time stamping.

Steve

Approved-By: [email-masked]
Date:         Wed, 18 Mar 1998 13:28:06 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Question about the CMMF/CMRF drafts
To: [email-masked]

Are theses drafts suppose to stand along and be usable as an enrollment
protocol?  Or are you required to use the CMC (or other equivalent) drafts
in order to get a functional protocol?

jim schaad

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 17:13:27 +1200
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 Gutmann <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on pkix-ipki-part1
Comments: cc: [email-masked]
To: [email-masked]

[I'm sending this from an alternative address, mail from my usual address
 either isn't getting or out is vanishing somewhere]

While I was waiting for our local power monopoly to figure out how they were
going to supply the central business district of the city with power
(apparently the power outage we're currently in the middle of, documented at
http://www.kcbbs.gen.nz/users/peterg/power.txt, rates as the worst peacetime
power outage ever), I thought I'd poke around with cert extensions a bit so I
could add them to the X.509 style guide.

It's probably going to double in size.  I also need to reread my H.P.Lovecraft
collection so I can find enough quotes about horror and madness to decorate
the margins in the manner that the guide currently does :-).  I caught the
tail end of the debate on character encodings, I'll have a long section
devoted to that in there as well (there's at least one extension which breaks
completely over this issue).

In the meantime, here are a few quick comments on the 14 October draft of
ipki-part1.  Some problems I noticed were:

4.2.1.2.

This gives the subject key identifier as the hash of the subjectPublicKeyInfo
*without* the tag and length.  Is this a mistake, or is it meant to be like
that?  Every other instance in which an ASN.1 object is hashed (eg
certificates, CRL's, issuerAndSerialNumber, the HASHED macro) hashes the
entire object.  In fact the PKIX CMP draft uses a hash of the full
subjectPublicKeyInfo in the OOBCertHash, which would make it incompatible with
the value in the subject key identifier.  Requiring a well-defined standard
X.509 object to be broken up into pieces before processing it seems an
extremely peculiar move, so I'm guessing it's some sort of mistake in the spec.

In addition I really don't like the idea of dumping a raw hash into the
KeyIdentifier OCTET STRING, because it's not possible to distinguish it from
whatever anyone else decides to put in there.  Much better would be to use the
PKCS #7 DigestInfo, which is well-defined and whose OID + data format uniquely
identifies the contents (that is, make the KeyIdentifier an OCTET STRING hole
for a DigestInfo rather than an opaque blob).  Given that a KeyIdentifier
could potentially contain anything, it's somewhat risky to put raw,
unidentified data in there.

4.2.1.3.

The decipherOnly key usage indicates that the public key can only be used for
deciphering data.  This would be quite a feat :-).  I assume this should say
that the private key corresponding to the public key can only be used for
deciphering data.

Speaking of private vs public keys, it would be useful to have some standard
unambiguous term defined to indicate the private key which is tied to the
public key, eg "corresponding to" or "identified by" or "paired with" or
something similar.  I've used "identified by" (eg "The end-user certificate
should be signed by the private key identified by a CA certificate"), but I'm
not sure if that sounds right.  The current draft seems to use different terms
in different places.

7.3.2.

This gives a redundant definition of the DH p and g values (the ASN.1
definition is followed immediately by text which says exactly the same thing -
actually the RSA definition does this too with n and e), but doesn't explain
the INTEGER which is the DH public key (what *is* this value?  The only thing
I can think of is g^x mod p, but that shouldn't be a fixed value).  It also
goes to some lengths to explain the encoding of the INTEGER parameter as a BIT
STRING, which seems very odd.

D.1.

The supposed CA certificate isn't actually a CA cert because the
basicConstraints are empty.  Is this really what NIST CA certs look like? If
it is, I should add another entry to the "Bugs" section of the X.509 style
guide :-).

Peter.

Approved-By: [email-masked]
Date:         Thu, 19 Mar 1998 08:20:37 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
Comments: To: [email-masked]
To: [email-masked]

no

>>> Michael Myers <[email-masked]> 03/18/98 11:30PM >>>
All,

Here's the separate ASN.1 poll question mentioned in my prior message:

Should OCSP request and response syntax be expressed in ASN.1?

A rough consensus of YES would result in modifying the existing
OCSP draft to change the request and response syntax appropriately.

A rough consensus of NO would result in maintaining the current
ABNF syntax.

In either case, protocol elements may change as a result of the
incorporation of additional requirements.

Mike
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!

Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 19 Mar 1998 07:23:29 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

Hi Dave,

Already had your vote on record Dave.  :-)

Mike

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, March 19, 1998 6:58 AM
Subject: Re: [IETF-PKIX] OCSP ASN.1 Poll

>> From: Michael Myers <[email-masked]>
>>
>> Here's the separate ASN.1 poll question mentioned in my prior message:
>>
>> Should OCSP request and response syntax be expressed in ASN.1?
>
>
>If I've already voted, do I have to do it again? :-)
>
>Regards,
>Dave Kemp
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 19 Mar 1998 09:36:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

> From: Michael Myers <[email-masked]>
>
> Here's the separate ASN.1 poll question mentioned in my prior message:
>
> Should OCSP request and response syntax be expressed in ASN.1?

If I've already voted, do I have to do it again? :-)

Regards,
Dave Kemp

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Thu, 19 Mar 1998 14:00:12 +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: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] Obtaining a certificate for user B.
To: [email-masked]

To the list,

Consider the situation, where user A wants the certificate
of another user B and a fully operational Directory is not
present (e.g. the situation described in CMC, page 13).

- Should the ASN.1 type be 'GetCert' ?
- How is this structure encapsulated in a PKIMessage ?

- Jakob

Approved-By:  Michael Myers <[email-masked]>
Date:         Wed, 18 Mar 1998 22:30:45 -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: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] OCSP ASN.1 Poll
To: [email-masked]

All,

Here's the separate ASN.1 poll question mentioned in my prior message:

Should OCSP request and response syntax be expressed in ASN.1?

A rough consensus of YES would result in modifying the existing
OCSP draft to change the request and response syntax appropriately.

A rough consensus of NO would result in maintaining the current
ABNF syntax.

In either case, protocol elements may change as a result of the
incorporation of additional requirements.

Mike

Approved-By:  Michael Myers <[email-masked]>
Date:         Wed, 18 Mar 1998 22:23:52 -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: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] New OCSP Requirements
To: [email-masked]

All,

The recent discussion on OCSP has resulted in a list of candidate new
requirements that have not yet received the full vetting of the group.  I
spoke with Rich  regarding the relationship of these requirements to both
OCSP and the notary protocol in the context of his recent posting on
"lightweight" and "heavyweight" options.

This discussion led to the following joint proposal.  The "lightweight"
option is OCSP revised to accomodate requirements appropriate to its scope
from among  those identified by the Malpani et. al. contribution.  The
"heavyweight" option is the notary protocol equivalently revised to
accomodate other of the of those requirements.

Taking each point by point:

ASN.1
--------
Proposed Resolution:  I will be calling for a poll on this issue in a
separate posting and shall update the OCSP draft accordingly.

Multiple Certs In Request
-----------------------------------
The Notary Protocol already enables these more complex constructions.  OCSP
is intended to be a simple query on a single certificate.

Proposed Resolution:  Allocate this requirement to the notary protocol.  A
proposal to add validation of multiple target certs, including a
cert-path for each target cert, to the Notary Protocol, was posted to the
PKIX list  recently.

Transport Independance
---------------------------------
The initial OCSP drafts was structure to enable transport independance.  The
current draft is written to ensure that at least one transport mechanism is
implemented.  Until recently, no exception was taken to that position.

Proposed Resolution:  Correct the current OCSP draft to speak to the
enablement of transport independance, but yet maintain HTTP as one
well-defined mechanism.  Consideration is being given to a sockets-based
specification in the base OCSP draft.  If other transports are desired,
interested parties are encouraged to produce companion drafts.

Multiple Response Types
----------------------------------
OCSP speaks only to revocation information.  This is a well defined
spectrum.  Situations that might stimulate the production of other response
types are only producable using more advanced mechanisms that are beyond the
scope of OCSP.

Proposed Resolution:  Allocate the requirement for "negotiated response
types" to the notary protocol.  The Malpani spec includes a variety of
additional information on a revoked certificate, e.g. revocation reason and
invalidity date.  This would be a useful addition in both OCSP and the
notary protocol.

Ceritificate Identification
--------------------------------
The proposed alternative to certificate identification addresses
requirements that have been debated within X.509 and elsewhere, resulting in
the construct AuthorityKeyIdentifier.  The alternative observes that CA name
collisions are possible and thus proposes the cert ID be a function of CA
name and key.  However, the occurrence of this event seems remote given the
prevailing practice of CA naming.

Proposed Resolution:  Pending the outcome of the straw poll, revisit the
syntax of certId in OCSP.  If indeed the observation regarding CA name
collisions can be substantiated as a real-world problem, then PKIX may wish
to consider a defect report to X.509 regarding the security risks inherent
in the AuthorityCertIssuer option of AuthorityKeyIdentifier.

Address revocation only in OCSP, not validation
----------------------------------------------------------------
Proposed resolution:  Language regarding or implying validation *of
certification paths to the target cert* will be removed from OCSP.   The
notary protocol may be updated to accomodate this and any additional context
validation schemes.

Delegation of Authority
------------------------------
The proposed delegation model should be revisited in the broader context of
Attribute Certificates and certificate-based access control generally, a
topic that has often been informally discussed within PKIX but never moved
forward to a work product.  Establishing point-wise solutions to this
problem creates a patchwork of what could and should be a unified approach
to the subject.

Proposed Resolution:   Defer discussion of specific delegation mechanisms to
a future work product which consolidates all points of view and essential
requirements regarding certificate-based access control.  This future work
product could easily address mechanisms that govern permissible use of OCSP,
Notary Protocol and other essential PKI services.

Mike

Approved-By:  Todd Glassey <[email-masked]>
Date:         Wed, 18 Mar 1998 12:43:05 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      [IETF-PKIX] Wouldnt adding a certified timestamp kill the issues re: multiple keys/certificates
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms137323960C72F5C5ED82D5B1
Content-Type: multipart/mixed; boundary="------------E689DCC0AD24C21396A92BAD"

This is a multi-part message in MIME format.
--------------E689DCC0AD24C21396A92BAD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Say all,
So what I was wondering is wouldn't adding some secondary temporal
authentication mechanisms, like a certified timestamp for instance, cleanup the
Multiple Key per certificate dilemma.

Seems like a no-brianer solution and strengthens the Certificate Value as well!
What do you think?

Todd

--
--------
--  Regards,
--  Todd Glassey

Todd's Latest Rant --
---------------------
"...Plan?, There ain't no plan, I though' you had the plan..."
      The Pig Killer - Mad Max: Beyond Thunderdome

--------------E689DCC0AD24C21396A92BAD
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Todd S. Glassey
n:              Glassey;Todd S.
org:            Coastek, Inc.
adr:            5550 Scotts Valley Drive;;Suite 700;Scotts Valley;Ca;95066;USA
email;internet: [email-masked]
title:          Chief Scientist and Principal Founder
tel;work:       408.440.0180
tel;fax:        408.438.2979
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------E689DCC0AD24C21396A92BAD--

--------------ms137323960C72F5C5ED82D5B1
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms137323960C72F5C5ED82D5B1--

Approved-By: [email-masked]
Date:         Wed, 18 Mar 1998 10:05:48 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: [email-masked]

In the MISPC, and elsewhere, if an extension is critical, then each reliant party's client software must be able to process the extension according to the issuing CA's CPS.  If followed (and, I think this will be rare), then the client software will have to "know" the CPS under which the cert is issued to act in accordance with those CPS constraints as part of the validation process.  This rule also addresses the issues Bob brought up with regard to multiple certificates (multiple CPS) for the same key pair tying the cert to the message.

If we abandon the critical extension processing rule, then the CPS reading becomes more critical for liability and risk assumption or re-direction.  If we enforce the rule, then liability and risk assumption becomes explicit.

>>> Stephen Kent <[email-masked]> 03/17/98 06:59PM >>>
Paul,

I think the question of who reads a CPS and how closely is relevant to this
discussion, even if it may be somewhat separable.

>
>Section 2.0 of the draft is quite clear on this:
>   A certificate user should review the certification practice Statement
>   (CPS) generated by the CA before relying on the authentication or
>   non-repudiation services associated with the public key in a
>   particular certificate.  To this end, this standard does not
>   prescribe legally binding rules or duties.

Yes, the draft says that now, and I want to suggest that we tone this down
a bit, since not all CAs will have a CPS.  The CPS notion is important for
3rd party CAs, and organizational CAs issuing certs for extranet purposes,
but proprietary CAs may not have to have one, unless they operate in Utah
;-).

>I think it would be a good idea to add words to this such as:
>
>To avoid confusion, a CPS should say which attributes of a certificate have
>been verified. Further, a CPS should not state that only part of any
>attribute is verified; either the entire attribute is verified, or none of
>the attribute is verified. This is particularly important for attributes
>with rfc822Name values, since the two parts of the value can be validated
>in different fashions, and many CAs will choose not to validate one part or
>the other.

Yes, one could do that, but actually assuming that users will pay close
enough attention to note these differences strikes me as unwarranted.   As
a "security guy" I know from experinece that users pay little attention to
various warnings and the average CPS is way too big to expect the average
user to really read it.  Remember the "Internet Exploder" program, an
ActuveX module that had a valid Microsoft ActiveX vendor signature on it?
People downloaded it and when it popped up a window that said it would shut
down the user's PC when clicked, most users actually cliked the button and
watched in surprize while their system shut down!  The metaphor I use in my
talks on CA policies is that of VCR programming: the vast majority of
(U.S.) VCR owners are incapable of performing this task and thus VCRPlus is
a big hit.  How much harder is it to evaluate a CPS, a complex "trust"
graph in a PKI, etc?

Steve
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!

Approved-By: [email-masked]
Date:         Wed, 18 Mar 1998 10:22:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] The argument for using NTPv4 as one of the basis of Certified Time in PKIX-land
To: [email-masked]

At 12:14 PM 3/17/98 -0800, Todd Glassey wrote:

>>>>

<excerpt>

<bold><bigger><bigger>As to time keeping and the IETF's intellectual
properties policies...

</bigger></bigger></bold>To me the question of whether the most important
piece of OLTP & non-repudiated record keeping, policy authentication, and
negotiation, i.e. the timestamps and most importantly - their time
source, is protected under a patent and thus "un-standardizable" is one
of the key reasons we, Coastek, are  proposing using an extended-evolved
version of the already ubiquitous NTPv3 (the upcoming NTPv4) as a primary
source of credible and certified time in networking facilities

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

Forgive my ignorance, but what patent are your referring to?

Hal

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

Harold W. Lockhart Jr.               Platinum technology, Solutions

Chief Technical Architect            8 New England Executive Park

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

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

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

Approved-By: [email-masked]
Date:         Wed, 18 Mar 1998 09:46:49 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and ignored.
From: [email-masked]
Subject:      [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ldapv2-schema-00.txt
To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

        Title           : Internet X.509 Public Key Infrastructure LDAPv2 Schema
        Author(s)       : T. Howes, S. Boeyen, P. Richard
        Filename        : draft-ietf-pkix-ldapv2-schema-00.txt
        Pages           : 6
        Date            : 16-Mar-98

     The schema defined in this document is a minimal schema to  support
     PKIX  in an LDAPv2 environment, as defined in draft-ietf-pkix-ipki-
     ldapv2-06.txt. Only PKIX-specific components  are  specified  here.
     LDAP  servers, acting as PKIX repositories should support the auxi-
     liary object classes defined in this  specification  and  integrate
     this  schema  specification with the generic and other application-
     specific schemas as appropriate, depending on the  services  to  be
     supplied by that server.

     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 with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pkix-ldapv2-schema-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-00.txt

Internet-Drafts directories are located at:

        Africa: ftp.is.co.za

        Europe: ftp.nordu.net
                ftp.nis.garr.it

        Pacific Rim: munnari.oz.au

        US East Coast: ds.internic.net

        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:      [email-masked].  In the body type:
        "FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-00.txt".

NOTE:   The mail server at ietf.org 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID:     <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-00.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ldapv2-schema-00.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--OtherAccess--

--NextPart--

Approved-By:  Warwick Ford <[email-masked]>
Date:         Tue, 17 Mar 1998 22:58:14 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Carlisle:

Thanks for raising that other problematic case -- another example to
support my contention that we should stick to traditional iterative
procedures if we want our work to progress smoothly.  And no, I was not
trying to be funny.  I'm kinda struggling getting my sense of humor
activated when processing PKIX mails these days.

Re OCSP editing, I am hopeful we are now at a point from which normal
procedures can prevail.  As you well know, an editor's task is not always
easy or enviable, and pressures to finish the job can sometimes result in
issues being given less attention than their contributors feel they
deserve.  I believe this point has been adequately brought to the attention
of the OCSP editors and that we can now move on to an orderly track for
resolving all change requests raised on OCSP and launching serious work on
the Notary protocol (or whatever it should be called).

Regards,
Warwick

At 04:02 PM 3/17/98 -0500, Carlisle Adams wrote:
>Hi Warwick,
>
>>----------
>>From:  Warwick Ford[SMTP:[email-masked]]
>>Sent:  Tuesday, March 17, 1998 12:17 AM
>>To:    [email-masked]
>>Subject:       Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
>>
>>Paul:
>>
>>This posting is about as unhelpful as they can get.  Other actions and
>>comments by various list members recently are also highly questionable, and
>>I think it is time we regained decorum as a group.
>
>...
>>
>>Almost as unhelpful is the approach taken by some list members to produce a
>>"competing draft" for OCSP.  The pre-existing OCSP document has already
>>been through many iterations, reflecting many concensus-reaching decisions.
>> The correct approach to making changes to the OCSP design at this stage is
>>to sumbit a contribution that proposes changes to the current draft,
>>providing rationale for such changes.  The issues are then debated on the
>>list.  This iterative procedure has always worked in the past and taking
>>any other approach could set a most undesirable precedent.
>
>I find it "interesting" (to say the least) that you could write a
>paragraph like the one above.
>
>Most of us either were at the Munich and Washington IETFs, or read the
>minutes of the Munich and Washington IETFs.  Consequently, most of us
>remember seeing a mature, two-year-old PKIX-3 spec., which represented
>the culmination of significant consensus-building efforts by the Working
>Group, turn into {CMP + CRMF + CRS (now CMC) + CMMF} as a result of a
>"competing draft" that showed up not only late in the process, but
>*after* the WG and IETF-wide Last Call periods had been completed.
>
>Is your last sentence above meant to be funny?
>
>>I propose that the "competing draft" be recast as a specific set of change
>>proposals to OCSP, along with rationale for each.
>
>The *only* reason there was a "competing draft" at all is because this
>precise approach had been taken and had met with no success.  The second
>course of action was to re-write the spec. taking into account the
>comments from the list.  Please note that this was deliberately *not*
>submitted as an Internet Draft, but instead was offered to the list (and
>specifically to the OCSP editors) as a basis for progression.  It was
>essentially presented in that form so as to save Mike and Rich the
>editing task of incorporating the list's comments.  Mike refused any
>association whatsoever with that re-write and gave the distinct
>impression that he did not intend to change OCSP.  Only then was it
>decided to submit this re-write as a stand-alone draft.
>
>>Then let's try to
>>quickly reach concensus on each point, acting in a grown-up and
>>professional manner.
>
>Mike now seems willing to do this.  Perhaps the RCSP submission was
>useful after all...  :-)
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>
******** PLEASE NOTE NEW CONTACT DETAILS ********
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 22:05:37 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName
To: [email-masked]

Paul,

I agree that we ought not venture into the area of what it means to
validate the accuracy of specific name types. Nonetheless, I reiterate my
position re the desirability of keeping comments out of 822 names, for the
reasons cited in my most recent messages.

Steve

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 5 Mar 1998 22:16:12 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

David,

If we were able to somehow add cryptographic binding of
the digital signature to the specific certificate that is s
supposed to be used to validate it, virtually all of my objections
to issuing more than one certificate per key would disappear,
and we would be left with some of the positive virtues of that
approach that others have mentioned.

However, I do NOT think that we should insist that each and
every protocol reinvent the wheel. Some will do it wrong (as per
your examples), and some just won't do it at all.

Unfortunately, the SIGNED macro doesn't include a version
indicator (will we _never_ learn?), so we can't do the version 3
trick that we pulled when we found that the X.509 certificate
wasn't adequate for our new extended purpose.

However, I think there is a way out, although from a purist
architectural standpoint it is an ugly hack. But hey, MISSI did
it, and what's good enough for the US Government ought to be
good enough for the rest of us, right?

What I'm proposing is that we define a new series of digital signature
algorithm OIDs, which would include the additional information that
is needed as part of the COMPONENTS.

We can debate the precise information that we might like to include later,
along with the optimum syntax, but this is the approach that as I
recall MISSI took to include clearance information and other parameters
that they had no place to put in the old V1 certificate format. Like I said,
an ugly, but noble hack.

One potential problem is that although currently in-vogue RSA and
DSA key lengths (1024 and 2048 bits) would probably be long enough
to directly include most of what we might like, the 512 bit lengths allowed
by US export (and some import) regulations might be pretty tight, and
would be extremely tight for elliptic curves.

One approach to solving this problem would be to use two message digests,
one for the ToBeSigned, and the other for the ancillary signature data (someone
has to think of a snappy attribute name ¯ I refuse to be blamed for "ancillarySignatureData"), and then include both message digests
within the signature.  This would work for algorithms of up to 320 bits
in length, which might still be tight for some elliptic curve algorithms.

The other approach, which could be extended to arbitrarily long
information, would be to effectively append the existing ToBeSigned
information (normally a message digest) to the ancillary information, and
then compute a super message digest over the entire collection. That
super message digest, plus any additional randomized padding (we
ought to fix that problem while we are at it) would then be the input
to the actual signing operation. This would support signature algorithms
and key lengths which only allow as little as 160 bits of input (or even
128 bits, for MD5)).

The second approach is obviously superior to the first, assuming
that the time for a second hash is considered negligible. But can
anyone think of an even better method?

The benefit of this scheme is that by simply implementing one
or more new enhanced signature algorithms (e.g., "RSA with
SHA-1 and ancillary data") within the underlying toolkits,
virtually all applications would benefit, with virtually no effort at all.

And if we do it right, we might even be able to achieve some degree of
backward compatibility by some sort of slight of hand involving
mapping the algorithm OIDs to existing algorithms
in such a way as to ignore the added information if the code doesn't yet
support it. Maybe some ASN.1 genius can think of a slick trick.

Let me let this sink in before I start talking about all of the stuff I
would like to see included. Hopefully this time we would do it right,
probably by defining the information to be included in ASN.1 with
strong typing, so that we additional information is proposed to be
added it will be simple to do. But that is tomorrow's homework
assignment.

At a minimum, however, it would have to include some form of
unique identification of the certificate to be used to validate the
signature, either issuerName and serial, authorityKeyId, or at
the very least a hash of the certificate contents (although that
wold cause some problems of circular definition if used within
the certificate itself.)  Certainly a URL or some other kind of hint
as to where to actually find the certificate would be a nice touch,
but we can discuss that independently of the primary issue.

Whaddaya think about the basic concept?

Bob

----

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

>>> "David P. Kemp" <[email-masked]> 3/5/98 13:03:16 >>>
> From: Bob Jueneman <[email-masked]>
>
> The problem, to the extent that there is one, is that the X.509
> definition of the "sign" macro does not provide any means of defining
> precisely which certificate in particular should be used to validate a
> particular signature, and thereby associate a particular set of
> name/rights attributes with that signature.
>
> (That's what often happens when a standard that was intended for one
> purpose is appropriated for another, entirely different purpose. We,
> the digital signature community, probably should have rethought that
> particular issue before adopting the X.509 definition of signature.
> Some other information, such as the date/time and signing and the
> identity of the platform ("location") on which the signature took place
> would have been handy, also.)

Bob,

The X.509 "SIGNED" macro might not have been designed with the intent
of supporting this purpose, and so may be excused for not including
a method of binding a certificate to the signed data.

However, the IETF CMS specification (aka PKCS#7) was designed for
precisely this purpose (providing non-repudiation grade signatures over
generic content), yet it still does not provide a clean method of
binding the signer's certificate to the content.

The CMS definition of SignedData includes {content, certs, crls,
signerInfos}, and some other fields.  There may be multiple signatures
applied to the content, each represented by a SignerInfo.  Each
SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
Because the issuerAndSerialNumber field, which uniquely identifies the
certificate used by the signer, is not covered by the signature, it is
not bound to the content.  I'm not sure why PKCS#7 was designed that
way, but it was, and so is CMS.

It would have been preferable to define an issuerAndSerialNumber
attribute, which could have been included either in
authenticateAttributes to bind it with the signature, or in
unauthenticatedAttributes if the current semantics of not binding the
signer's cert to the signed content is desired.

Perhaps defining a redundant copy of issuerAndSerialNumber, to be
included in authenticatedAttributes, could address the requirement
without breaking backward compatibility.  (It only covers the signer's
cert, not the full path, but it's a start.)
The uglier alternative is  is to double-sign everything, encapsulating a
signedData within another signedData for each parallel signature.

Since CMS is intended to be a generic security encapsulation mechanism,
not just an S/MIME-specific structure, those who feel that this
requirement is important (to address either multiple certification of
keys or proof-of-possession) should discuss it in the S/MIME working
group.  (A SigningTime attribute is already defined in CMS, but a
"location" attribute is not.)

Dave Kemp

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 20:59: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and
To: [email-masked]

Paul,

I think the question of who reads a CPS and how closely is relevant to this
discussion, even if it may be somewhat separable.

>
>Section 2.0 of the draft is quite clear on this:
>   A certificate user should review the certification practice Statement
>   (CPS) generated by the CA before relying on the authentication or
>   non-repudiation services associated with the public key in a
>   particular certificate.  To this end, this standard does not
>   prescribe legally binding rules or duties.

Yes, the draft says that now, and I want to suggest that we tone this down
a bit, since not all CAs will have a CPS.  The CPS notion is important for
3rd party CAs, and organizational CAs issuing certs for extranet purposes,
but proprietary CAs may not have to have one, unless they operate in Utah
;-).

>I think it would be a good idea to add words to this such as:
>
>To avoid confusion, a CPS should say which attributes of a certificate have
>been verified. Further, a CPS should not state that only part of any
>attribute is verified; either the entire attribute is verified, or none of
>the attribute is verified. This is particularly important for attributes
>with rfc822Name values, since the two parts of the value can be validated
>in different fashions, and many CAs will choose not to validate one part or
>the other.

Yes, one could do that, but actually assuming that users will pay close
enough attention to note these differences strikes me as unwarranted.   As
a "security guy" I know from experinece that users pay little attention to
various warnings and the average CPS is way too big to expect the average
user to really read it.  Remember the "Internet Exploder" program, an
ActuveX module that had a valid Microsoft ActiveX vendor signature on it?
People downloaded it and when it popped up a window that said it would shut
down the user's PC when clicked, most users actually cliked the button and
watched in surprize while their system shut down!  The metaphor I use in my
talks on CA policies is that of VCR programming: the vast majority of
(U.S.) VCR owners are incapable of performing this task and thus VCRPlus is
a big hit.  How much harder is it to evaluate a CPS, a complex "trust"
graph in a PKI, etc?

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 20:58: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Paul,

>>Most folks will not read a CPS, especially if it goes into that level of
>>detail, and thus what the fine print says will not matter unless one
>>litigates a dispute.
>
>But if you don't read the CPS, you have no idea if the non-comment part of
>an email address was verified. I could certainly believe that many CAs who
>do not do online enrollment (like corporate CAs) will accept as valid any
>information typed into them by the human CA administrator at a CA console.
>If I walk up to my human administrator and say "here's my common name and
>my email address; give me a cert", there's no sensible way for that human
>to verify that it is really my email address. I think you are thinking too
>much in the Verisign online enrollment model, which is only one way certs
>will be generated.

I am not thinking about any particular enrollment model, VS or otherwise.
And I'm willing to back down a bit from the notion that no user will read
any CPS (though I bet this will be true in the vast majority of the
cases!).  However, I do believe that even the few users who do read a CPS
will not read it very carefully.  Thus the fine distinction between whether
an 822 address is verified, or whether the address and the commented name
is verified, is somehting I am confident will escape almost every user.

>Basically, either someone reads the CPS or they don't. Saying "becasue they
>probably won't, this identifier is OK because it *could* be verified" is
>very dangerous, IMHO. Either it is verified (and th CPS says so), or it
>isn't (and it's not covered in the CPS, or the CPS says "we don't verify
>this").
>
>>I argue that we ought to be careful to not foster a situation that unduly
>>creates an opportunity for confusion.
>
>I fully agree. And I think pretending that a bare email address is verified
>and belongs to the named user is quite an opportunity for confusion.
>Remember, comments in an RFC 822 name *can* be verified. Both parts can be
>verified, or they can be not verified.

Yes, one can verify the comment as well, but I maintain that unless we
require that the comment is always verified, then we are unnecessarily
creating a situation that will confuse users.  The altertiave I proposed
would allow a common (comment?) name to be included separately if
appropriate, and would create an opportunity for the appropriate inclusion
of names based on what a CA really checks.

I;'m not trying to look at this is any strict legal sense, although soe
other list memebrs take that appraoch.  I'm trying to suggest what I
believe is a common sense approach to this issue that will minimize the
likelihood of confusion where it is easy to be confused and easy to avoid
confusion.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 20: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] Comments on sixth draft of IPKI X.509 Certificate and CRL Profile
To: [email-masked]

Tirthankar,

I'm not certain that the example you cite will prove to be a problem.  Not
only must an attacker construct a packet with a public key info field that
has the same hash value as the subject key identifier (for a good hash
algorithm this is generally infeasible if the public key in question
differs), but the public key in the purpored CA cert must correspond to the
private key used to sign the target certificate.  Now, if you're willing to
construct a CA cert with the same public key info and different other
parameters, that will work, but then  you'll have to cause the cert chain
to terminate at a (root) CA acceptable to the cert consumer.  Remember, the
intent of this backpointer is not to add security, but merely to facilitate
selection of the right cert from among several valid ones issued to the
same CA.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 20:58: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Cryptographic binding of certificates tosignatures
To: [email-masked]

Bob,

Sometimes we sign data for authentication and integrity, but not for
non-repudiation.  In such cases, the need to include a cert pointer in the
SIGNED macro may not be critical.  Also, in many instances there may be a
one-to-one correspondence of keys to certs, as we've discussed recently on
the list, so that too may mitigate the criticality of what you propose.
Finally, a protocol or application designer can always include the
necessary info in the signed data if it's critical, thought I admit that we
have examples where this is not the case, e.g., secure e-mail protocols.  I
don't mean to diminish the utility of your suggestion, but I'd rather not
have it delay the advancement of the PKIX standards.  if you want to pursue
this, let's do so independent of the current set of PKIX documents; after
all, it's a broad proposal that goes beyond the cert and CRL formats and
protocols that we are profiling here.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 17 Mar 1998 20:57: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Bob,

For some applications, CRLs are just fine, because there is not a need for
immediate notification of revocation nor retention of data in support of
non-repudaition.  In other cases, a real time attestation of certificate
validity is appropriate.  Because both caes exist, we have two classes of
mechanisms to address the revocation problem.  Let's not belabor this point.

Steve

Approved-By: [email-masked]
Date:         Tue, 17 Mar 1998 17:59:46 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

>However, regardless of whether you believe other working groups have
>conducted themselves in a decorous manner, the precedent for competing
>drafts has been set.  For how long were there two competing drafts
>for the replacement of SSL in the TLS WG?  For how long were there three
>competing drafts for a key management protocol in the IPSEC WG?

Forgive me if am wrong Dave but in those cases the drafts were presented
as precisely that - competing drafts with different names, authors and so
on.

The precedent is that if you want to propose a radically different approach
you do so by issuing an entirely independent draft or you write a mail
proposing
a series of changes.

If you wish to have the endorsement of the previous authors you ask for this
before issuing messages which may cause confusion.

At the very least this avoids the problem of the Malpani draft which misses
the series of edits I made to align it with the HTTP/1.1 specification which
took a considerable amount of time.

    Phill

Approved-By: [email-masked]
Date:         Tue, 17 Mar 1998 12:14:15 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      [IETF-PKIX] The argument for using NTPv4 as one of the basis of Certified Time in PKIX-land
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms87AE52D6C5F874B8D4621B66
Content-Type: multipart/mixed; boundary="------------DEA5BDF02E948F4667E01C67"

This is a multi-part message in MIME format.
--------------DEA5BDF02E948F4667E01C67
Content-Type: multipart/alternative; boundary="------------86AE88F1BD822C56FBC3D5ED"

--------------86AE88F1BD822C56FBC3D5ED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gentlefolk,
in response to some of the questions regarding the legal status of our standards
and standards efforts...

>> All,
>>
>> Does anybody have a patent regarding the protocols described in the Notary
>> Protocols I-D (draft-adams-notary-01.txt)??  Is there anybody who is in the
>> process of applying for a patent regarding the Notary Protocols described in
>> the draft??  Is there anybody that believes that he/she/it has intellectual
>> property in this area and plans to apply for a patent regarding the Notary
>> Protocols described in the draft??(Those of you who are interested  might want
to see RFC 2026 for clarification on the POISSON WG's standards for the IETF's
accepting patented materials for consideration under the IETF Processes).

Robert Zuccherato wrote:

> I believe that the protocols defined in the Notary Protocols Internet
> Draft (draft-adams-notary-01.txt) can be implemented without infringing
> any intellectual property for which Entrust has, or has applied for,
> patent protection.  Should this situation change in the future, we would
> be willing to license the technology on fair and reasonable terms.

>         Robert Zuccherato
>         Entrust Technologies

As to time keeping and the IETF's intellectual properties policies...

To me the question of whether the most important piece of OLTP & non-repudiated
record keeping, policy authentication, and negotiation, i.e. the timestamps and
most importantly - their time source, is protected under a patent and thus
"un-standardizable" is one of the key reasons we, Coastek, are  proposing using
an extended-evolved version of the already ubiquitous NTPv3 (the upcoming NTPv4)
as a primary source of credible and certified time in networking facilities

We need at least one source of time - EVERYWHERE

The real issue, IMHO, is that  we need at least one ubiquitous source of credible
time data for both Security and  and Networking WG's time-centric requirements.
This would allow us to focus on the deployment of user technology rather than
inventing (or reinventing) 200 more mechanisms to provide time to transactions.

Book the Winner - NTP is already "THE" standard per say

With that in mind, NTP is already pretty much an "IETF standard" and as such
extending it to meet the needs of all networking and electronic commerce/trust
systems is really a no-brainer. So with this in mind my question is "Why reinvent
a new wheel...", hopefully its not a NIH issue.

As to timestamping with NTP for non-repudiation and other PKIX services,

   * document & instrument stamping
   * or other digital notary services
   * desktop synchronization and general certified time deployment,

By using NTP as the basis of the time services the key critical component  is a
ubiquitous protocol already EVERYWHERE.

As to adding certified time to the X509 certificate  services, extending the NTP
daemons the use models are reasonably straight forward.

  1. Systems that need no total process end-to-end possession of their time data
     could  easily keep their reliance on the underlying Time Of Day (TOD) clocks
     of the underlying OS's (resynchronized through NTP) and thus deploy some
     sense of certified process based upon the sanctity of the timestamp.
  2. their counterparts that need the certainty of the timestamp as part of an
     embedded trust system, could use our Java based stamping API or
     roll-their-own solutions based upon the Coastek Specified NTP Certified
     Client API that Coastek will be proposing as part of its next IETF Draft.

please remember that because NTP technology has been around for a while and is
native almost all systems, it is robust and well tuned, simply put it is stable
and reasonably mature.

So what does this buy the PKIX WG?

We don't have to completely reinvent the wheel!. By having us within PKIX WG
acknowledging the PKI signed variant of NTP (NTPv4) as one of our certifiable
timesources for non-repudiation, we can create trust models with varying degrees
of time-centicity and support a single sense of time services throughout
networking.

Build your own Certificate Management API... but keep the source of the time
services as NTP

As to the end-user use models, various API style interfaces to allow for the
integration of time services at the CA level  that are easily based upon a simple
API to the PKI Extended NTPv4 Server (For an example see the Entrust Digital
Notary Draft - Draft-adams-notary-01.txt).

PKI X and Time Services

The PKIX WG to date has understood that time data is important but has shy'd away
from standardizing any form of it since commercially certifiable and credible
time sources were until very recently out of reach (expense wise) at the
application programmers level and thus too costly to include in everyday security
and process solutions. But with the new evolution in technology this is no longer
true.

The New Coastek Time Services Draft for PKIX WG

To this end - watch for a new draft from Michael McNeil and myself to be filed at
the end of this week, on PKIX specific use models for the Coastek/Mills
Extensions to NTP. This draft will include document/instrument stamping but is
centered around using certified time as the basis of non-repudiated event logging
and proof infrastructures.

Todd Glassey

--------
--  Regards,
--  Todd Glassey

Todd's Latest Rant --
---------------------
"...Plan?, There ain't no plan, I though' you had the plan..."
      The Pig Killer - Mad Max: Beyond Thunderdome

--------------86AE88F1BD822C56FBC3D5ED
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
Gentlefolk,
<BR>in response to some of the questions regarding the legal status of
our standards and standards efforts...

<P>>> All,
<BR>>>
<BR>>> Does anybody have a patent regarding the protocols described in
the Notary
<BR>>> Protocols I-D (draft-adams-notary-01.txt)??&nbsp; Is there anybody
who is in the
<BR>>> process of applying for a patent regarding the Notary Protocols
described in
<BR>>> the draft??&nbsp; Is there anybody that believes that he/she/it
has intellectual
<BR>>> property in this area and plans to apply for a patent regarding
the Notary
<BR>>> Protocols described in the draft??(Those of you who are interested&nbsp;
might want to see RFC 2026 for clarification on the POISSON WG's standards
for the IETF's accepting patented materials for consideration under the
IETF Processes).

<P>Robert Zuccherato wrote:
<BLOCKQUOTE TYPE=CITE>I believe that the protocols defined in the Notary
Protocols Internet
<BR>Draft (draft-adams-notary-01.txt) can be implemented without infringing
<BR>any intellectual property for which Entrust has, or has applied for,
<BR>patent protection.&nbsp; Should this situation change in the future,
we would
<BR>be willing to license the technology on fair and reasonable terms.</BLOCKQUOTE>

<BLOCKQUOTE TYPE=CITE>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Robert Zuccherato
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Entrust Technologies</BLOCKQUOTE>
&nbsp;
<H3>
As to time keeping and the IETF's intellectual properties policies...</H3>
To me the question of whether the most important piece of OLTP &amp; non-repudiated
record keeping, policy authentication, and negotiation, i.e. the timestamps
and most importantly - their time source, is protected under a patent and
thus "un-standardizable" is one of the key reasons we, Coastek, are&nbsp;
proposing using an extended-evolved version of the already ubiquitous NTPv3
(the upcoming NTPv4) as a primary source of credible and certified time
in networking facilities
<BR>&nbsp;
<H3>
We need at least one source of time - EVERYWHERE</H3>
The real issue, IMHO, is that&nbsp; we need at least one ubiquitous source
of credible time data for both Security and&nbsp; and Networking WG's time-centric
requirements. This would allow us to focus on the deployment of user technology
rather than inventing (or reinventing) 200 more mechanisms to provide time
to transactions.
<BR>&nbsp;
<H2>
Book the Winner - NTP is already "THE" standard per say</H2>
With that in mind, NTP is already pretty much an "IETF standard" and as
such extending it to meet the needs of all networking and electronic commerce/trust
systems is really a no-brainer. So with this in mind my question is "Why
reinvent a new wheel...", hopefully its not a NIH issue.

<P>As to timestamping with NTP for non-repudiation and other PKIX services,
<UL>
<LI>
document &amp; instrument stamping</LI>

<LI>
or other digital notary services</LI>

<LI>
desktop synchronization and general certified time deployment,</LI>
</UL>
By using NTP as the basis of the time services the key critical component&nbsp;
is a ubiquitous protocol already EVERYWHERE.

<P>As to adding certified time to the X509 certificate&nbsp; services,
extending the NTP daemons the use models are reasonably straight forward.
<OL>
<LI>
Systems that need no total process end-to-end possession of their time
data could&nbsp; easily keep their reliance on the underlying Time Of Day
(TOD) clocks of the underlying OS's (resynchronized through NTP) and thus
deploy some sense of certified process based upon the sanctity of the timestamp.</LI>

<LI>
their counterparts that need the certainty of the timestamp as part of
an embedded trust system, could use our Java based stamping API or roll-their-own
solutions based upon the Coastek Specified NTP Certified Client API that
Coastek will be proposing as part of its next IETF Draft.</LI>
</OL>
please remember that because NTP technology has been around for a while
and is native almost all systems, it is robust and well tuned, simply put
it is stable and reasonably mature.
<BR>&nbsp;
<H2>
So what does this buy the PKIX WG?</H2>
We don't have to completely reinvent the wheel!. By having us within PKIX
WG acknowledging the PKI signed variant of NTP (NTPv4) as one of our certifiable
timesources for non-repudiation, we can create trust models with varying
degrees of time-centicity and support a single sense of time services throughout
networking.
<BR>&nbsp;
<H3>
Build your own Certificate Management API... but keep the source of the
time services as NTP</H3>
As to the end-user use models, various API style interfaces to allow for
the integration of time services at the CA level&nbsp; that are easily
based upon a simple API to the PKI Extended NTPv4 Server (For an example
see the Entrust Digital Notary Draft - Draft-adams-notary-01.txt).
<BR>&nbsp;
<H4>
PKI X and Time Services</H4>
The PKIX WG to date has understood that time data is important but has
shy'd away from standardizing any form of it since commercially certifiable
and credible time sources were until very recently out of reach (expense
wise) at the application programmers level and thus too costly to include
in everyday security and process solutions. But with the new evolution
in technology this is no longer true.
<BR>&nbsp;
<H2>
The New Coastek Time Services Draft for PKIX WG</H2>
To this end - watch for a new draft from Michael McNeil and myself to be
filed at the end of this week, on PKIX specific use models for the Coastek/Mills&nbsp;
Extensions to NTP. This draft will include document/instrument stamping
but is centered around using certified time as the basis of non-repudiated
event logging and proof infrastructures.

<P>Todd Glassey

<P>--------
<BR>--&nbsp; Regards,
<BR>--&nbsp; Todd Glassey

<P>Todd's Latest Rant --
<BR>---------------------
<BR>"...Plan?, There ain't no plan, I though' you had the plan..."
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Pig Killer - Mad Max: Beyond Thunderdome
<BR>&nbsp;</HTML>

--------------86AE88F1BD822C56FBC3D5ED--

--------------DEA5BDF02E948F4667E01C67
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Todd S. Glassey
n:              Glassey;Todd S.
org:            Coastek, Inc.
adr:            5550 Scotts Valley Drive;;Suite 700;Scotts Valley;Ca;95066;USA
email;internet: [email-masked]
title:          Chief Scientist and Principal Founder
tel;work:       408.440.0180
tel;fax:        408.438.2979
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------DEA5BDF02E948F4667E01C67--

--------------ms87AE52D6C5F874B8D4621B66
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms87AE52D6C5F874B8D4621B66--

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 17 Mar 1998 16:02:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Hi Warwick,

>----------
>From:  Warwick Ford[SMTP:[email-masked]]
>Sent:  Tuesday, March 17, 1998 12:17 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
>
>Paul:
>
>This posting is about as unhelpful as they can get.  Other actions and
>comments by various list members recently are also highly questionable, and
>I think it is time we regained decorum as a group.

...
>
>Almost as unhelpful is the approach taken by some list members to produce a
>"competing draft" for OCSP.  The pre-existing OCSP document has already
>been through many iterations, reflecting many concensus-reaching decisions.
> The correct approach to making changes to the OCSP design at this stage is
>to sumbit a contribution that proposes changes to the current draft,
>providing rationale for such changes.  The issues are then debated on the
>list.  This iterative procedure has always worked in the past and taking
>any other approach could set a most undesirable precedent.

I find it "interesting" (to say the least) that you could write a
paragraph like the one above.

Most of us either were at the Munich and Washington IETFs, or read the
minutes of the Munich and Washington IETFs.  Consequently, most of us
remember seeing a mature, two-year-old PKIX-3 spec., which represented
the culmination of significant consensus-building efforts by the Working
Group, turn into {CMP + CRMF + CRS (now CMC) + CMMF} as a result of a
"competing draft" that showed up not only late in the process, but
*after* the WG and IETF-wide Last Call periods had been completed.

Is your last sentence above meant to be funny?

>I propose that the "competing draft" be recast as a specific set of change
>proposals to OCSP, along with rationale for each.

The *only* reason there was a "competing draft" at all is because this
precise approach had been taken and had met with no success.  The second
course of action was to re-write the spec. taking into account the
comments from the list.  Please note that this was deliberately *not*
submitted as an Internet Draft, but instead was offered to the list (and
specifically to the OCSP editors) as a basis for progression.  It was
essentially presented in that form so as to save Mike and Rich the
editing task of incorporating the list's comments.  Mike refused any
association whatsoever with that re-write and gave the distinct
impression that he did not intend to change OCSP.  Only then was it
decided to submit this re-write as a stand-alone draft.

>Then let's try to
>quickly reach concensus on each point, acting in a grown-up and
>professional manner.

Mike now seems willing to do this.  Perhaps the RCSP submission was
useful after all...  :-)

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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 17 Mar 1998 13:48:41 -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] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

Andreas,

Yes, I saw that.  My assumption was that was intended to be some kind of a
caveat or restriction, e.g., "Valid for code signing only" or some key
usage parameter.

It is interesting to consider whether including a Reliance Limit would govern
what is considered to be a "commercially reasonable" transaction, especially
in the absence of a more specific statute.

If I were an attorney, I could probably argue either side of the issue in
court with little difficulty!

Regards,

Bob

>>> Andreas Berger <[email-masked]> 03/13 7:17 AM >>>
In the German Signature Law, in "7, Inhalt von Zertifikaten" (Contents
of Certifictes) there is a possibility to restrict the use of
certificates to special applications or other limitation.

I think that this opens the possibilty to define a certificate extension
that specify an amount of money or a limit in liability.

Andreas
Sorry: I am not firm in legal english :-)
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Tue, 17 Mar 1998 11:55:05 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Hi Mike (and All),

Agree, never a dull moment in PKIX! I am responding to your posts in
sequence,
so that people can follow this discussion.

With regards to your post on Sunday:

I don't believe RCSP has introduced any problems. The OCSP spec allows
for a
trusted third party service provider but does not specify any details.
RCSP
has just laid out the details of how that should work. I have addressed
each
of your concerns specifically below:

Michael Myers wrote:
>
> Ambarish, Colleagues:
>
> Never a dull moment in PKIX!
>
> Setting aside ASN.1 debate for a moment, I have one concern regarding the
> suitability of this proposal to today's business practices.
>
> The requirement that "The certificate of an Authorized RCSP Responder
cannot
> be revoked."  is simply too dangerous to be implemented.  The proposal
> appears to anticipate this problem by asserting that the certificate be
> maintained on a very short validity period.  This approach however has at
> least four fatal flaws:
>

I disagree that this requirement is too dangerous. A CA can either (1)
issue
all its RCSP responses itself  or (2) leave it up to RCSP clients to
establish
explicit direct trust relationships with RCSP responers or (3) designate
an RCSP
responder. Your comment applies to case (3). If a CA authorizes another
key to
issue RCSP responses for it, the CA needs to ensure that that key is at
least
as well protected as its own private key.
This point deserves to be made explicitly clear in the specification
itself. The
purpose of stating the requirement explicitly is to alert a CA to the
fact that a
validation service provider must adhere to practice standards consistent
with the
CA's requirement. It would be improper for a CA to trust third party
service
providers willy-nilly. This model is not any different from the model
required
by a CA that outsources its operations to CA service companies.

> 1.  There is no means proposed whereby this certificate would be updated.
> Thus the proposal is incomplete; it cannot be implemented as written.

Not true. The proposal can absolutely be implemented as written and
accomodates
responses originating from the CA (a situation that is identical to the
OCSP
draft) as well as third party trust providers. Third party trust
providers
may obtain their certificates with a straightforward certificate signing
request & response.  Nonetheless, it is probably worth adding some
verbiage
describing how such certificates are updated.

>
> 2.  Even is such a means were well-defined, the proposal suffers serious
> scalability problems due to the frequent need to update the special
> certificate.  Assume the period is two weeks.  Further assume for the sake
> of concreteness that this mechanism is being used to support a Bank's
> customers.   Every two weeks each of those customers will need to make
> contact with a key management center, download the new certificate,
install
> it, review practices disclaimers, click on several buttons etc. etc. All
> that pain every two weeks.  Or four weeks.  For every relying party
wishing
> to do business with the bank.  Now multiply that scenario by a given
number
> of banks; by the number of branch offices in a major corporation; by the
> Internet.  Definitely not a success scenario in my opinion.

Not true at all. RCSP responses allow for the responder may include its
certificate along with the response.  Absolutely *NO* user clicks
required.

>
> 3.  This key management cycle reduces public key infrastructure to the
same
> key management discipline that was used for symmetric key management.  The
> proposal thus takes a giant step backward against the progress we've
> currently
> made on PKI architecture suitable for the Internet.

Just not true.  Perhaps, the spec is confusing somewhere? Please let me
know what
should be rephrased to avoid creating this impression.

>
> 4.  Most importantly, it provides no means to bound the risks of key
> compromise.  A lot can happen in two to four weeks.  Compromise of the
> trusted responder key could, among other things, enable previously revoked
> subscribers to appear to be be re-established.

Not applicable. Please refer to the answer for question 1.

> However, this role-based certificate is analogous to certificates used to
> authorize LRAs, MLAs and other abstract roles.  Would it not be the case
> that this certificate could and indeed should be listed on a CRL?  This
CRL
> could be maintained separate from other CRLs via an CRL extension to
> identify
> the purpose of the CRL.  This would be necessary to prevent the common CRL
> suppression attack.  There is no reason at all why one can't combine
> techniques to deliver an integrated solution.

The purpose of both OCSP and RCSP is to avoid all the problems
associated with CRLs.
The best way to achieve this objective is to clearly state the
requirements that RCSP
or OCSP responders must adhere to. We have already done this.  Given
this, it is
unclear that new CRLs add value or security.

>
> Mike
>

Best regards,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect        (650) 849-9880
ValiCert, Inc.         [email-masked]
3160 W. Bayshore Road               http://www.valicert.com
Palo Alto, CA 94303

Approved-By: [email-masked]
Date:         Fri, 13 Mar 1998 15:17:24 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

In the German Signature Law, in "7, Inhalt von Zertifikaten" (Contents
of Certifictes) there is a possibility to restrict the use of
certificates to special applications or other limitation.

I think that this opens the possibilty to define a certificate extension
that specify an amount of money or a limit in liability.

Andreas
Sorry: I am not firm in legal english :-)
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 17 Mar 1998 12:22:34 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and RCSP
To: [email-masked]

> From: Rich Ankney <[email-masked]>
>
> Can we reach consensus on the need for two protocols
> (lightweight and heavyweight)?

That depends on whether we reach consensus that the problems being
solved by the two protocols are disjoint.

If one protocol can satisfy the requirements of both heavyweight and
lightweight applications (by having a mandatory lightweight core and
optional extensions to handle extra functionality), then it will be
difficult to argue that two separate standards track protocols are
appropriate.

There is precedent for documenting existing practice in an Informational
RFC, while using the standards track to develop a more flexible
alternative.  Is there a disadvantage to following that approach?

Approved-By:  Rich Ankney <[email-masked]>
Date:         Tue, 17 Mar 1998 11:31:32 -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:      [IETF-PKIX] OCSP and RCSP
To: [email-masked]

As one of the authors of both OCSP and RCSP (and also very interested
in the notary protocol), I thought I'd contribute my $.02 worth to the
debate.

I believe there was agreement at the DC meeting to proceed with OCSP
as currently formulated (with the addition of extensions as is done in
the latest draft).  I also agree that further extensions to OCSP are going
to be difficult; an ASN.1-based version would be useful at such a time.

I'd like to see OCSP as currently formulated proceed along the
standards track.  I'd also like to start on a more {flexible|robust|
heavyweight} version of the protocol (the "bigger hammer" referred to
in Mike's Email).  This can be based on the RCSP protocol; it could
also be based on the notary protocol.  Can we reach consensus on
the need for two protocols (lightweight and heavyweight)?  Besides
extensibility, other things in the heavyweight protocol might include
the things suggested by Bob J. in recent messages (I think the
notary protocol does most of these things quite well already).

Regards,
Rich

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 17 Mar 1998 09:23:31 -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] Cryptographic binding of certificates tosignatures
Comments: To: [email-masked]
To: [email-masked]

Denis, I was not really proposing to change the SIGNED macro, but
instead was  proposing a new signature algorithm, in hopes of finding
a magic bullet that would solve this problem once and for all.

If the consensus is that we should rely on the S/MIME group to resolve
this issue, I will go along, but I am uncomfortable, as I believe this is a core
PKIX issue, and should not be relegated to a group dedicated to only one
protocol. I don't mean to slight their competance, only their scope, and the
degree to which other groups may or may not be inclined to follow their lead.

I WOULD recommend that if we agree to defer to the S/MIME group to solve
this problme, that we record the final decision within the PKIX document,
so it will be more likely to be read and followed by other groups.

Bob

>Bob,
>
>You are raising a valid point, but IMO the solution to the problem is
>NOT to change the SIGNED macro. This problem is currently being debated
>in the smime working group while discussing the document "Cryptographic
>Message Syntax".
>
>Some changes to the document draft-ietf-smime-cms-03.txt are being
>considered and discussed, i.e. the addition of an attribute in the
>section 11 (Useful Attributes) on page 23. This document will not only
>apply to S/MIME but to other contexts as well.
>
>Please switch to the smime mailing list to participate (as I did).
>
>I propose(d) to open a time slot in the pkix agenda so that we can
>report the status of the discussion of the smime group to the pkix group
>during the LA meeting.
>
>Denis

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 17 Mar 1998 07:39:17 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Dave,

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, March 17, 1998 6:37 AM
Subject: Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts

>> From: Warwick Ford <[email-masked]>
>>
>> I think it is time we regained decorum as a group.
>
>
>Decorum is good, no doubt about it.
>
>However, regardless of whether you believe other working groups have
>conducted themselves in a decorous manner, the precedent for competing
>drafts has been set.  For how long were there two competing drafts
>for the replacement of SSL in the TLS WG?  For how long were there three
>competing drafts for a key management protocol in the IPSEC WG?
>How many secure email protocols does the IETF currently sponsor?
>It's probably unnecessary to point out that PKIX had for several years
>a single managment protocol before a competing draft emerged.
>

Fair enough, but in this particular case our differences are minor relative
to that which we can agree on, and resolveable at that.  ASN.1 in OCSP has
now been vigorously defended in public.  That was not the case during the
D.C. IETF nor was there any substantive debate on the issue on the list
coming out of D.C.  I'm prepared at this point to move the existing OCSP
draft forward to meet the WG's consensus, to establish a single draft we can
all work towards.

>Sometimes a single set of editors working hard to achieve consensus is
>the most efficient approach; sometimes that approach apparently does
>not meet the needs of all stakeholders, and a start-from-scratch
>proposal is the best way of focusing discussion.  I've heard "put up
>or shut up" more than once in various Working Groups. Interoperability
>considerations, IESG guidelines, and the best interests of all involved
>nearly guarantee that in the end, a single protocol will make it to
>Full Standard.  That's what matters.

Well, in defense, the alternative draft is not a start-from-scratch
approach.  It's more or less the existing text with ASN.1 instead of ABNF.
Having gotten past the ASN.1 debate, this is why I'm confident we can arrive
at a single draft in very short order.

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Tue, 17 Mar 1998 10:07: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: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

I believe that the protocols defined in the Notary Protocols Internet
Draft (draft-adams-notary-01.txt) can be implemented without infringing
any intellectual property for which Entrust has, or has applied for,
patent protection.  Should this situation change in the future, we would
be willing to license the technology on fair and reasonable terms.

        Robert Zuccherato
        Entrust Technologies

>----------
>From:  John Pawling[SMTP:[email-masked]]
>Sent:  Tuesday, March 10, 1998 2:35 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] New Notary Protocol Draft
>
>All,
>
>Does anybody have a patent regarding the protocols described in the Notary
>Protocols I-D (draft-adams-notary-01.txt)??  Is there anybody who is in the
>process of applying for a patent regarding the Notary Protocols described in
>the draft??  Is there anybody that believes that he/she/it has intellectual
>property in this area and plans to apply for a patent regarding the Notary
>Protocols described in the draft??
>
>================================
>John Pawling
>[email-masked]
>J.G. Van Dyke & Associates, Inc.
>================================
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 17 Mar 1998 09:20:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

> From: Warwick Ford <[email-masked]>
>
> I think it is time we regained decorum as a group.

Decorum is good, no doubt about it.

However, regardless of whether you believe other working groups have
conducted themselves in a decorous manner, the precedent for competing
drafts has been set.  For how long were there two competing drafts
for the replacement of SSL in the TLS WG?  For how long were there three
competing drafts for a key management protocol in the IPSEC WG?
How many secure email protocols does the IETF currently sponsor?
It's probably unnecessary to point out that PKIX had for several years
a single managment protocol before a competing draft emerged.

Sometimes a single set of editors working hard to achieve consensus is
the most efficient approach; sometimes that approach apparently does
not meet the needs of all stakeholders, and a start-from-scratch
proposal is the best way of focusing discussion.  I've heard "put up
or shut up" more than once in various Working Groups. Interoperability
considerations, IESG guidelines, and the best interests of all involved
nearly guarantee that in the end, a single protocol will make it to
Full Standard.  That's what matters.

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Tue, 17 Mar 1998 14:35:02 -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] Cryptographic binding of certificates to signatures
To: [email-masked]

Bob,

You are raising a valid point, but IMO the solution to the problem is
NOT to change the SIGNED macro. This problem is currently being debated
in the smime working group while discussing the document "Cryptographic
Message Syntax".

Some changes to the document draft-ietf-smime-cms-03.txt are being
considered and discussed, i.e. the addition of an attribute in the
section 11 (Useful Attributes) on page 23. This document will not only
apply to S/MIME but to other contexts as well.

Please switch to the smime mailing list to participate (as I did).

I propose(d) to open a time slot in the pkix agenda so that we can
report the status of the discussion of the smime group to the pkix group
during the LA meeting.

Denis

> Lars,
>
> What I'm about to say may seem arrogant, but we got to this point
> despite the fact that a lot of pretty bright and involved people,
> including some real security experts -- how shall I say it --
> basically blew it on this point.  The basic SIGNED macro was
> perhaps OK for verifying X.500 directory access, but not
> good enough for signing documents. (I'm including myself in
> the list of people to blame, if not the other attributes.)
>
> That being the case, I have to say that I have a MUCH lower
> level of trust in protocol designers who are not necessarily
> security experts, but are rather experts in their particular
> protocol expertise.  Some of course will get it right.  But
> some won't.
>
> As I said in the answer to another note, we frequently rush
> to get something working, fully intending to come back and
> fix it, only to find out that the budgets have been cut, other
> priorities have arisen, etc., etc. Hoyt Kesterson tells an
> amusing but wry story tracing the width of railroad tracks
> in the US to the de facto standards for ox-drawn wagons in the
> Roman empire.
>
> So even though changing ANYTHING inevitably causes some
> pain and incompatibility, it is no worse than the RSA/DSA
> compatibility issue.  As soon as some minimal level of use
> occurs, applications will very quickly adopt the new algorithm,
> and the pain will be over.
>
> As the Texaco advertisement used to say, "You can pay me now,
> or you can pay me later."  I know everyone thinks that there would
> be too great an impact to change things now, but in reality,
> even SSL is seeing VERY limited use so far, S/MIME is
> just beginning to emerge, and IPSEC is still on the horizon.
> We could certainly fix these problems now, at a negligible cost
> compared to fixing it later on.
>
> Remember when everyone used to think that all of the programs
> that were coded using a two digit date would be obsolete and long
> gone before the year 2000 rolled around?
>
> Bob

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 17 Mar 1998 00:40:21 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Cryptographic binding of certificates tosignatures
Comments: To: [email-masked]
To: [email-masked]

Lars,

What I'm about to say may seem arrogant, but we got to this point
despite the fact that a lot of pretty bright and involved people,
including some real security experts -- how shall I say it --
basically blew it on this point.  The basic SIGNED macro was
perhaps OK for verifying X.500 directory access, but not
good enough for signing documents. (I'm including myself in
the list of people to blame, if not the other attributes.)

That being the case, I have to say that I have a MUCH lower
level of trust in protocol designers who are not necessarily
security experts, but are rather experts in their particular
protocol expertise.  Some of course will get it right.  But
some won't.

As I said in the answer to another note, we frequently rush
to get something working, fully intending to come back and
fix it, only to find out that the budgets have been cut, other
priorities have arisen, etc., etc. Hoyt Kesterson tells an
amusing but wry story tracing the width of railroad tracks
in the US to the de facto standards for ox-drawn wagons in the
Roman empire.

So even though changing ANYTHING inevitably causes some
pain and incompatibility, it is no worse than the RSA/DSA
compatibility issue.  As soon as some minimal level of use
occurs, applications will very quickly adopt the new algorithm,
and the pain will be over.

As the Texaco advertisement used to say, "You can pay me now,
or you can pay me later."  I know everyone thinks that there would
be too great an impact to change things now, but in reality,
even SSL is seeing VERY limited use so far, S/MIME is
just beginning to emerge, and IPSEC is still on the horizon.
We could certainly fix these problems now, at a negligible cost
compared to fixing it later on.

Remember when everyone used to think that all of the programs
that were coded using a two digit date would be obsolete and long
gone before the year 2000 rolled around?

Bob

>>> <[email-masked]> 03/16 1:54 AM >>>
Bob,

[email-masked] wrote:
>
> Lars, I appreciate your "European" hard-token perspective.
> Certainly, how the keys are generated and how they are
> incorporated into certificates can substantially change the risks.

Right, thanks for your appreciation!

> Just to clarify one thing however. Although I mentioned the
> possibility of changing the SIGNED macro, it was only to
> highlight the original source of the problem. I realize that changing
> the basic definition at this time is probably not a viable
> possibility.
>
> However, my final recommendation and conclusion was that we
> consider creating a new set of signature algorithm IDs that would
> end up using RSA, DSA, etc., but would also include additional
> information such as the issuerName and serial number, or perhaps
> just a hash of the certificate, so that the certificate to be used
> is irrevocably tied to the signed text.

Ok, so that would allow some protocols to switch over by using the
new set of algorithm IDs while others can continue using the old ones.

That doesn't change my original criticism however. What may seem
as an improvement in flexibility is really just going back to the original
situation (with some "safe" protocols using the new set of algorithm
IDs and other protocols still being "unsafe"). Why then not leave this
to the protocol designers or, as I suggested, to the key holder and
relying party?

> I also mention the desirability of including some additional information
> such as date/time and possibly the identity of the platform on which
> the signature was applied, for audit purposes.

I can think of many different information fileds that can be useful. Let me
just give you one example: Charcter set coding. Suppose that I sign a
document and include my certificate serial number '123' and later
discover that I'd rather liked to have used the certificate with serial
number '342'. Well then I could try to claim in court that I actually used
the special "Swahilian ASCII coding" (or something like that), where
3=49, 4=50 and 2=51. (There's no limit to my imagination of the usefulness
of this technique ;-).

My point is that we shouldn't put any restrictions to what must be included
in a signature (unless it's really cryptographically relevant like randomness
and formatting for example). If we do, then we'll most certainly run in to the
situation where we find that the standard is too limited. Again, let
this thing be
taken care of by the application designers!

> (You might be particularly interested in the later, from your hard-token
> perspective. Assuming that the token only generates the signature, and
> maybe the message digest that goes into it, the token has no way of
> knowing what the user saw on the screen that was supposed to be
> signed, as opposed to what the application actually presented to be signed.
> Unless the token is limited to only signing once per insertion, a rogue
> merchant could cause the token to sign all sorts of things, while the
> user thinks that she is only buying a dishrag. Including an authenticated
> identification of the platform would help point a smoking gun in such cases.)

Actually, I'm not interested in that possibility. My primary interest
is to have a
common PKI for both smart cards and soft tokens. If smart cards should use
a different signature algorithm than everyone else, it would be a bad thing.

> Other people may have their own pet ideas which should be considered.
> For example, I foresee a time in the relatively near future where
biometrics will
> be combined with digital signatures to circumvent some of the control issues
> that neither a password encrypted key nor a smart token solve, since
either can
> be given away.  It would no doubt be very useful to incorporate the biometric
> indicia into the signature itself, so that it would later be
validated against
> the biometric template included in the certificate. Without
supporting such a
> basic mechanism now, while the industry is still in the process of
writing lots of
> new applications, adding such features would require modifications to
a very large
> number of individual applications -- an almost hopeless task.

Spooky, indeed!

> But I'm not trying at this time to suggest precisely what ancillary
information
> should be included. We are still trying to sort out whether it should be
> done at all. Of course, even if a new signature algorithm ID is
> defined, it doesn't have to be used, so it would be optional from that
> standpoint. For the sake of interoperability, however, it would be a new
> algorithm that would have to be widely supported, unless we can figure
> out a mechanism for making the additional parameters transparent.
>
> I do believe that specifying the suite of signature algorithms that are to be
> supported is one of the functions of this group, so I believe the
discussion is
> appropriate for this list.

Well, I disagree on this point. Let's have the standards finished as soon as
possible so we can start using them. They may not be perfect but we must
remember that there's no such thing as absolute security (unless of course
you don't communicate at all :-).

Kind regards,
/Lars Johansson
Sweden Post

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 17 Mar 1998 00:04:17 -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] RFC 822 names in SubjectAltName and otherextensions
Comments: To: [email-masked]
To: [email-masked]

>>> Dean Povey <[email-masked]> 03/16 2:47 PM >>>
>
>There is a 5th option, create a non-critical comment extension:
>
>id-ce-comment OBJECT IDENTIFIER ::= { ... }
>
>Comment ::= SEQUENCE OF Extension
>
>The Comment Extension has the semantics that anything defined under the
>Comment extension is not verified.
>
>Just my $0.02.
>

Dean, I think this is an excellent idea.  One technical ASN.1 question --
this would allow a particular extension to be a Comment in one
certificate, and not a comment in another certificate. Correct?

However, the context of the original discussion, the RFC822
names, has skewed the discussion somewhat.

To my way of thinking, Nonverified Subscriber Information is not just
a comment -- semantic sugar -- but a legally (presumably) binding
representation made by the Subscriber to the CA, which, however, the
CA is not in a position to independently verify at an economical cost.
So I would not like to see the extension labeled as Comment.

nonverifiedSubscriberInformation is a bit cumbersome, but fortunately
we don't have to DER-encode the attribute names!

A couple of other comments:

I agree that trying to define an attribute that is partially verified and partially
not verified is a recipe for disaster.  Unfortunately, rather than following
the original layout of names proposed in X.521 and the original x.500
implementations, most certificate generation programs (and browsers, etc.)
are rather brain-dead, and tend to seriously overload commonName.

So if someone wants a certificate that includes their honors and degrees,
today they would almost be forced to use something like
commonName="Sir John Smith, MD, Ph.D., Esq., Realtor"

Now, should the CA be required to verify that Mr. Smith has been
knighted (by the Queen of which country?), and has a valid
medical degree, Ph.D., law degree, and is a licensed Realtor?

Generally speaking, I would think not, although some CA might of course
define a certificate class where they would perform such due diligence
diligence.

The better way would be to break out the commonName from
the titles, honors, degrees, generational qualifiers, etc., and allow
people to make representations regarding their honors and degrees
without requiring that the CA independently validate them.

Following this line of reasoning, we should break up the RFC822 name into
two components, the verified e-mail address, and the comment field.

In this case, the name "comment" is perhaps appropriate based
on the terminology of RFC822, but I would still feel that the
comment field should constitute a representation made to
the CA, and not just something of no consequence.

In other words, even if the CA doesn't verify the comment portion,
I should not be able to list someone else's name without running
a serious risk of being sued for misrepresentation.  It might be
a little more difficult to track me down, but if I mislead someone, I
ought to expect to be held accountable for such an act.

Bob

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 16 Mar 1998 21:48: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:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
Comments: To: [email-masked]
To: [email-masked]

Mike,

Since I respect you personally and professionally, I won't comment
on whether your horse has feathers and/or can fly. :-)

However, I'd like to reiterate some of the comments that I have
made in the past, while acknowledging that I have not had the time
to become really substantially involved in the overall subject:

1.  I would GREATLY prefer a common syntax.  Anyone processing
certificates necessarily has some kind of ASN.1 capability, whether
based on a commercial compiler or some home-grown tools. Adding
another syntax virtually guarantees adding another set of tools, for
which high-quality commercial tools may not be available.  I simply
don't understand the "thin client" issue.  We haven't even mentioned
Java, but that is another option, and certainly Java will have ASN.1 tools
available.

2. Since Sead Mufit and I originally pointed out that the entire CRL
notion was outmoded and rather brain dead (four or so years ago,
on the PEM list), I have been arguing that we do NOT need
a certificate status checking protocol, NOR to we need a notary
protocol.  What we DO need is a combination of the two that would
allow a relying party to submit a digital signature and either the
certificates themselves or a reference to them, and have the CA
(or a Repository or other TTP) simply bind the certificate status
to the digital signature, thereby avoiding the entire comparison of
clocks, separately time-stamping the document and the CRLs,
etc., etc.

3. In addition to validating the digital signature, it would be very useful
to support the use of the insurance model, whereby the relying party
declares a assessed valuation and declares a willingness to pay
a standard proportional fee for well-defined Errors and Omissions
insurance against a screw up by the CA, or potentially a compromise
of the signer's keys.

Unfortunately, I do not seem to have been sufficiently persuasive, as
to the best of my knowledge neither the OCSP nor the notary protocol
has embraced these principles.  For this reason, I cannot get at all excited
about implementing either of the two protocols.

As I said, I have not been able to follow all of the discussion, or read
all of the drafts, so if I have misunderstood or missed something, I will
be happy to retract the above conclusions.  But for now, I would vote
against progressing the current drafts any further along the standards track.

Sometimes there seems to such a great rush to get something available
right now, despite known problems, assuming we can fix it later.
Unfortunately, we never seem to get around to the "later".

Bob

Approved-By: [email-masked]
Date:         Mon, 16 Mar 1998 08:54: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: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and otherextensions
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked], [email-masked]
To: [email-masked]

Doesn't the liability for the binding of all information in the signed objects come back to haunt the  CA - even if its (75 page) policy says somewhere that it has not verified some parts of the information it bound to the identity provided by the key pair holder?

I often feel that we are trying to put too much information into the certs and their extensions, so as to make them unworkable.

If we separate the user operations from the "binding", then ancillary information can be added to the directory or database by the certificate holder under signed conditions.  This way, the liability and responsibility for the correctness of the information stays with the person verifying it (the holder).

I posit that any necessary information to be provided to the directory/database by the customer can best be done AFTER the cert is issued and the cert holder has digital signing capability.

Michael

>>> "David P. Kemp" <[email-masked]> 03/16/98 07:49AM >>>
> From: Robert Jueneman <[email-masked]>
>
> Steve, I agree with that burying Non-verified Subscriber Informatioon (NVI/ NSI?) in a CPS won't do.  But on the other hand, there is a clear and compelling need for NSI, especially for proprietary attributes.
>
> It would certainly be nice if we had a convenient indicator, much like the Critical indicator.
>
> Perhaps someone can think of a good way of extending the standard to facilitate this?

Bob,

I agree too that there should be a way to indicate "comment" information
that is either not verified by the CA or not intended to be acted upon
(enforced) by the relying party.   X.509 apparently recognizes this need
too; unfortunately the mechanism chosen to implement it was to overload
the meaning of the CRITICAL extension bit.

The CRITICAL bit was originally intended (when unset) to allow
implementations which do not understand a particular extension to use
the remainder of the certificate in which it appears.  However, the
description of several extensions now use that bit to modify the
meaning of the particular extension in implementations which *do*
support it.

I don't know of a good way of extending the standard to facilitate the
inclusion of Non-Verified or Non-mandatory information in certificates,
but can think of four ways with varying degrees of badness:

* Define the v4 Extension syntax to include both a CRITICAL
  bit and a COMMENT bit.  This would be non-backward compatible in
  the same sense that v3 is not compatible with v1 - the COMMENT
  bit would be DEFAULT FALSE and v4 would not be used unless some
  extension had it set TRUE.  It's probably unthinkable to do a
  version rev at this point - forget I mentioned it :-).

* Redefine the syntax of each extension (such as subjectAltName) to
  include a NVI/COMMENT/NON-REQUIRED bit, superceding the OIDs for
  the existing extensions.

* Define duplicate parallel extension OIDs, (such as subjectAltName
  and nvSubjectAltName) to denote verified/mandatory and non-verified/
  optional information.

* Continue along the current path, and overload the CRITICAL bit
  to modify the extension's meaning.  In the case of subjectAltName,
  this would not allow one portion of an RFC822 name to be verified
  and another to be non-verified; the entire extension would have the
  same status, and there can be only one instance of that extension in
  a certificate.
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!

Approved-By: [email-masked]
Date:         Mon, 16 Mar 1998 09:34:18 PST
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: Tirthankar Barari <[email-masked]>
Subject:      [IETF-PKIX] Comments on sixth draft of IPKI X.509 Certificate and CRL Profile
Comments: cc: [email-masked]
To: [email-masked]

I wanted to share my thoughts, stated below, on the
sixth draft of the Internet Public Key Infrastructure
X.509 Certificate and CRL Profile.

In section 4.2.1.2 on Subject Key Identifier, it is defined that :

   "The subject key identifier extension provides a means of identifying
   the particular public key used in an application.  Where a reference
   to a public key identifier is needed (as with an Authority Key
   Identifier) and one is not included in the associated certificate, a
   SHA-1 hash of the subject public key shall be used."

Now, it may so happen that in the Certificate path:

One CA’s  SHA-1 hash of the subject public key  matches, octet by octet,
the SubjectKeyIdentifier of another CA, in the chain, (who choose to
insert an octet string from its own imagination into the
SubjectKeyIdentifier field).

In this case, the uniqueness of the keyIdentifier field is lost.

However, if key identifier And issuer name And serial number are present
in the authority key identifier extension, then the above problem is
resolved.

Hence, I think that the following line in section 4.2.1.1

   "The identification can be based on either the key identifier (the
   subject key identifier in the issuer's certificate) or on the issuer
   name and serial number."

should be modified to :

"The identification can be based on either the key identifier (the
   subject key identifier in the issuer's certificate) or on the issuer
   name and serial number or on the key identifier and issuer name
  and serial number."

and the ASN1 definition of AuthorityKeyIdentifier modified accordingly.

Let me know if more clarification is needed. Also, please send your
comments.

Thanks.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Approved-By:  Warwick Ford <[email-masked]>
Date:         Mon, 16 Mar 1998 21:17:53 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Paul:

This posting is about as unhelpful as they can get.  Other actions and
comments by various list members recently are also highly questionable, and
I think it is time we regained decorum as a group.

For the benefit of everyone, let me summarize how we traditionaly operate.
Having identified a project (e.g., OCSP) we seek a voluntary editor or
editors to lead the process of creating a first draft then iterating that
draft, taking into account comments from the WG, and endeavoring to steer
the project to a concensus result.  Mike Myers and Rich Ankney have been
jointly filling that role wrt OCSP now for many months, and have put in
enormous efforts to steer this project towards a concensus result in the
face of several non-trivial design tradeoffs.

Flaming the volunteer editors in this way is IMHO totally unacceptable.
Our editors, who put in many more hours on our projects than the
sideliners, deserve respect from all of us.

Almost as unhelpful is the approach taken by some list members to produce a
"competing draft" for OCSP.  The pre-existing OCSP document has already
been through many iterations, reflecting many concensus-reaching decisions.
 The correct approach to making changes to the OCSP design at this stage is
to sumbit a contribution that proposes changes to the current draft,
providing rationale for such changes.  The issues are then debated on the
list.  This iterative procedure has always worked in the past and taking
any other approach could set a most undesirable precedent.

I propose that the "competing draft" be recast as a specific set of change
proposals to OCSP, along with rationale for each.  Then let's try to
quickly reach concensus on each point, acting in a grown-up and
professional manner.

Warwick

At 09:19 AM 3/16/98 -0800, Paul Hoffman / IMC wrote:
>Mike:
>
>I would like to add another "horsefeathers" to Dave's comments:
>
>>First, OCSP is on the standards track.
>
>Horsefeathers. Nothing is on standards track until it has achieved working
>group consensus, gone through working group last call, gone through IESG
>last call, and been published. OCSP is *far* from that.
>
>You have steadfastly refused to acknowledge working group consensus on the
>use of ASN.1. This alone is enough to keep it from getting through working
>group last call, much less on standards track. If you don't have the
>consensus of the working group, and it appears you don't, the draft is as
>good as dead, and an alternative draft can be inserted in its place.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>
>
******** PLEASE NOTE NEW CONTACT DETAILS ********
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
---------------------------------------------------------------------

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 16 Mar 1998 17:49:17 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] OCSP alternative comments
To: [email-masked]

Ambarish, Colleagues:

Never a dull moment in PKIX!

Setting aside ASN.1 debate for a moment, I have one concern regarding the
suitability of this proposal to today's business practices.

The requirement that "The certificate of an Authorized RCSP Responder cannot
be revoked."  is simply too dangerous to be implemented.  The proposal
appears to anticipate this problem by asserting that the certificate be
maintained on a very short validity period.  This approach however has at
least four fatal flaws:

1.  There is no means proposed whereby this certificate would be updated.
Thus the proposal is incomplete; it cannot be implemented as written.

2.  Even is such a means were well-defined, the proposal suffers serious
scalability problems due to the frequent need to update the special
certificate.  Assume the period is two weeks.  Further assume for the sake
of concreteness that this mechanism is being used to support a Bank's
customers.   Every two weeks each of those customers will need to make
contact with a key management center, download the new certificate, install
it, review practices disclaimers, click on several buttons etc. etc. All
that pain every two weeks.  Or four weeks.  For every relying party wishing
to do business with the bank.  Now multiply that scenario by a given number
of banks; by the number of branch offices in a major corporation; by the
Internet.  Definitely not a success scenario in my opinion.

3.  This key management cycle reduces public key infrastructure to the same
key management discipline that was used for symmetric key management.  The
proposal thus takes a giant step backward against the progress we've
currently
made on PKI architecture suitable for the Internet.

4.  Most importantly, it provides no means to bound the risks of key
compromise.  A lot can happen in two to four weeks.  Compromise of the
trusted responder key could, among other things, enable previously revoked
subscribers to appear to be be re-established.

However, this role-based certificate is analogous to certificates used to
authorize LRAs, MLAs and other abstract roles.  Would it not be the case
that this certificate could and indeed should be listed on a CRL?  This CRL
could be maintained separate from other CRLs via an CRL extension to
identify
the purpose of the CRL.  This would be necessary to prevent the common CRL
suppression attack.  There is no reason at all why one can't combine
techniques to deliver an integrated solution.

Mike

-----Original Message-----
From: Ambarish Malpani <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, March 16, 1998 2:37 PM
Subject: [IETF-PKIX] New Draft for Checking the Status of a Certificate -
RCSP

>Hi PKIX-land,
>
>    This message is to announce the existance of the draft:
>
>"Internet Public Key Infrastructure Real Time Certificate Status
>Protocol - RCSP", C. Adams, Ambarish Malpani, Rich Ankney, Slava
>Galperin, 03/13/1998. (22007 bytes)
>
>You can find it at:
>
>ftp://ietf.org/internet-drafts/draft-malpani-rcsp-00.txt
>
>It uses ASN.1 and fixes a bunch of other issues with OCSP.
>Some of the main fixes are:
>- uses ASN.1
>- it is independent of the transport layer
>- allows checking of multiple certs/cert chains in a single query
>- supports multiple response types
>- supports a better way of identifying certificates
>- talks explicitly about revoked/non-revoked rather than valid/invalid
>- clearly identifies who is authorized to respond to requests and
>    how you can identify responders.
>
>
>I would like to hear comments about it and people's feeling of
>whether this addresses their needs better than OCSP.
>
>Thanks,
>Ambarish
>
>--
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect                                              (650) 849-9880
>ValiCert, Inc.                                  [email-masked]
>3160 W. Bayshore Road                         http://www.valicert.com
>Palo Alto, CA 94303
>

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Mon, 16 Mar 1998 14:17:46 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] New Draft for Checking the Status of a Certificate - RCSP
To: [email-masked]

Hi PKIX-land,

    This message is to announce the existance of the draft:

"Internet Public Key Infrastructure Real Time Certificate Status
Protocol - RCSP", C. Adams, Ambarish Malpani, Rich Ankney, Slava
Galperin, 03/13/1998. (22007 bytes)

You can find it at:

ftp://ietf.org/internet-drafts/draft-malpani-rcsp-00.txt

It uses ASN.1 and fixes a bunch of other issues with OCSP.
Some of the main fixes are:
- uses ASN.1
- it is independent of the transport layer
- allows checking of multiple certs/cert chains in a single query
- supports multiple response types
- supports a better way of identifying certificates
- talks explicitly about revoked/non-revoked rather than valid/invalid
- clearly identifies who is authorized to respond to requests and
    how you can identify responders.

I would like to hear comments about it and people's feeling of
whether this addresses their needs better than OCSP.

Thanks,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Dean Povey <[email-masked]>
Date:         Tue, 17 Mar 1998 07:47:08 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dean Povey <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

>I don't know of a good way of extending the standard to facilitate the
>inclusion of Non-Verified or Non-mandatory information in certificates,
>but can think of four ways with varying degrees of badness:
>
>* Define the v4 Extension syntax to include both a CRITICAL
>  bit and a COMMENT bit.  This would be non-backward compatible in
>  the same sense that v3 is not compatible with v1 - the COMMENT
>  bit would be DEFAULT FALSE and v4 would not be used unless some
>  extension had it set TRUE.  It's probably unthinkable to do a
>  version rev at this point - forget I mentioned it :-).
>
>* Redefine the syntax of each extension (such as subjectAltName) to
>  include a NVI/COMMENT/NON-REQUIRED bit, superceding the OIDs for
>  the existing extensions.
>
>* Define duplicate parallel extension OIDs, (such as subjectAltName
>  and nvSubjectAltName) to denote verified/mandatory and non-verified/
>  optional information.
>
>* Continue along the current path, and overload the CRITICAL bit
>  to modify the extension's meaning.  In the case of subjectAltName,
>  this would not allow one portion of an RFC822 name to be verified
>  and another to be non-verified; the entire extension would have the
>  same status, and there can be only one instance of that extension in
>  a certificate.

There is a 5th option, create a non-critical comment extension:

id-ce-comment OBJECT IDENTIFIER ::= { ... }

Comment ::= SEQUENCE OF Extension

The Comment Extension has the semantics that anything defined under the
Comment extension is not verified.

Just my $0.02.

--
Dean Povey,                             |  Email: [email-masked]
Research Scientist, Security Unit,      |  Phone: +61 7 3864 2799
CRC for Distributed Systems Technology  |  Fax:   +61 7 3864 1282
Brisbane, Australia                     |  http://www.dstc.qut.edu.au/MSU/

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 16 Mar 1998 12:45:57 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName
To: [email-masked]

>The type of verification
>a CA does on a name is fundamentally different than what it does on an
>SMTP address, regardless of whether one is stronger than the other.

Quite right.

>If the CPS states that an entire attribute is verified, it seems
>inconsistent to have the two parts of a single attribute verified using
>separate procedures.

It doesn't seem inconsistent to me. Are you saying that if a CPS says "We
have verified the following two attributes: common name and email address",
you would find that inconsistent?

>  If the procedures are "equivalent" strength,
>there may not be a problem.

Ah, I think I see the problem. A CPS says what attributes it will vouch
for, and might say how the CA chooses to make this trust. These are two
different issues. An end entity MUST care about what is assured, and SHOULD
care about how that assurance comes about. However, if both the common name
and the email address are vouched for, it shouldn't matter if the common
name appears as part of the email address attribute, nor should it matter
if it doesn't. That is, the end entity takes the set of what is assured and
trusts that (and, hopefully, trusts only that).

The rfc822Name isn't the only type that will have the problem you see.
otherName and EDIPartyName will as well. These are all two-part names where
each part can be verified using very different methods. However, all three
can have the parts be equally assured because the CA trusts whoever
presented the credentials for the attribute. A CPS that says "we trust
these attributes because we know the person, and he wouldn't lie to us" is
a perfectly valid CPS, and one that most corporate CAs would issue.

I don't want PKIX to go down the slippery slope (into the slimy slop) of
saying how to verify the contents of the attributes. How would you "verify"
a uniformResourceIdentifier? An iPAddress? A dNSName? Requiring these be
"verified", as compared to "vouched for", is impossible and therefore
confusing to end users.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 16 Mar 1998 14:34: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName
To: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
>
> I think it would be a good idea to add words to this such as:
>
> To avoid confusion, a CPS should say which attributes of a certificate have
> been verified. Further, a CPS should not state that only part of any
> attribute is verified; either the entire attribute is verified, or none of
> the attribute is verified. This is particularly important for attributes
> with rfc822Name values, since the two parts of the value can be validated
> in different fashions, and many CAs will choose not to validate one part or
> the other.

This goes a long way in the right direction, but I'm still worried that
a full rfc822Name is a mixed-mode expression.  The type of verification
a CA does on a name is fundamentally different than what it does on an
SMTP address, regardless of whether one is stronger than the other.

If the CPS states that an entire attribute is verified, it seems
inconsistent to have the two parts of a single attribute verified using
separate procedures.  If the procedures are "equivalent" strength,
there may not be a problem.

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 16 Mar 1998 09:31:52 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and
To: [email-masked]

>In the "normal" case, where the CA does some validation of the address
>but no validation of the name,

I completely disagree that this is the "normal" case, or that it should be
assumed to be inthe future.

> there is no reason to include the name
>comment in the certificate.  Mail user agents are free to include
>copies of To:/From: headers, including names, in the signed portion of
>the message.

...and should be free to include a verified name in any appropriate and
verified part of the cert.

The proposal to disallow putting the common name in the 822 address is
orthogonal to the proposal that we should assume that no one reads the CPS.
If you don't read the CPS, then you must assume that all fields are
unverified. If you read the CPS, then you should assume that only the
fields listed in the CPS as verified are verified. If a CPS says "all parts
of the 822 name are verified", then it is silly for us to tell CA makers
that they can't use a valid RFC 822 address there.

Section 2.0 of the draft is quite clear on this:
   A certificate user should review the certification practice Statement
   (CPS) generated by the CA before relying on the authentication or
   non-repudiation services associated with the public key in a
   particular certificate.  To this end, this standard does not
   prescribe legally binding rules or duties.

I think it would be a good idea to add words to this such as:

To avoid confusion, a CPS should say which attributes of a certificate have
been verified. Further, a CPS should not state that only part of any
attribute is verified; either the entire attribute is verified, or none of
the attribute is verified. This is particularly important for attributes
with rfc822Name values, since the two parts of the value can be validated
in different fashions, and many CAs will choose not to validate one part or
the other.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 16 Mar 1998 09:19:05 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

Mike:

I would like to add another "horsefeathers" to Dave's comments:

>First, OCSP is on the standards track.

Horsefeathers. Nothing is on standards track until it has achieved working
group consensus, gone through working group last call, gone through IESG
last call, and been published. OCSP is *far* from that.

You have steadfastly refused to acknowledge working group consensus on the
use of ASN.1. This alone is enough to keep it from getting through working
group last call, much less on standards track. If you don't have the
consensus of the working group, and it appears you don't, the draft is as
good as dead, and an alternative draft can be inserted in its place.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Rich Salz <[email-masked]>
Date:         Mon, 16 Mar 1998 12:05:51 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Rich Salz <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

>I would love to see a code-size bakeoff between OCSPs; I am conviced
>that Malpani OCSP would fit into a smartcard or palmtop with more room
>and cycles to spare than Myers/Ankney OCSP.

A tempting question, but not one that can be answered.

Many smartcards already have ASN1 and PKCS libraries.
Many web servers and browsers already have HTTP and BASE64 libraries.

And of course, some of each have some of all of the above. :)

My OCSP server implementation is about 50 lines of code, FWIW.
        /r$

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 16 Mar 1998 11:52:31 -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] RFC 822 names in SubjectAltName and
To: [email-masked]

other extensions
X-Sun-Charset: US-ASCII

> From: Mike Smith <[email-masked]>
>
> I often feel that we are trying to put too much information into the certs and their extensions, so as to make them unworkable.
>
> If we separate the user operations from the "binding", then ancillary information can be added to the directory or database by the certificate holder under signed conditions.  This way, the liability and responsibility for the correctness of the information stays with the person verifying it (the holder).
>
> I posit that any necessary information to be provided to the directory/database by the customer can best be done AFTER the cert is issued and the cert holder has digital signing capability.

This is an excellent argument in favor of including only the delivery
address portion of an RFC822 name in certificates.

In the "normal" case, where the CA does some validation of the address
but no validation of the name, there is no reason to include the name
comment in the certificate.  Mail user agents are free to include
copies of To:/From: headers, including names, in the signed portion of
the message.

As Steve pointed out, if the CA verifies a name, it is possible to
include it in a Common Name.  I side with those who believe that
it is less confusing to always put a common name (if verified by the
CA) into the subject Name field, and include only the address in an
RFC822 name.

Approved-By:  Peter Lipp <[email-masked]>
Date:         Mon, 16 Mar 1998 17:46:28 +0100
Reply-To: Peter Lipp <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Lipp <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

>And I think pretending that a bare email address is verified
>and belongs to the named user is quite an opportunity for confusion.

Agreed. Obviously it might be the case that the comment field can be verified
and the email-adress not.

What I'd like to see is that the full SubjectAltName is verified, i.e. if
it contains a comment that this also is verified - or it's non-verified, then
both parts are not verified. The CPS specifies which way a CA does it.
Mixed-mode seems to be a good source of confusion, and while of course
specifyable in the CPS, I'd rather avoid it.

Peter

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 16 Mar 1998 11:08:02 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

> From: Michael Myers <[email-masked]>
>
> The expressive power of ASN.1 is overkill in this case.  It burdens the
> implementor with a steep learning curve, expensive tools, and delays in
> market access just to gain access to an integer value expressing the current
> state of a certificate's status.

Horsefeathers.  How long has Netscape included the KEYGEN construct in
their product line?

(For those not familiar with KEYGEN, it is a component of FORM which
does ASN.1 encoding of a certification request, Base64 encodes the
result, and includes it in an HTTP name=value response just like all
other application/x-www-form-urlencoded FORM components).

Has the use of KEYGEN produced a steep learning curve, expensive tools,
and delays to market for Netscape or for any CAs which work with
web browser input?

> This issue is not one of thin-client vs. full client but more with the
> fundamental problem being addressed and a rational balance
> between that problem's scope and the tools needed to effect
> its solution.

What kind of "rational balance"?  Isn't a syntax which is simple for
simple cases and incrementally extensible to handle more complex
requirements preferable to one which works only for simple requirements
and succombs to baroqueness when faced with anything else?

I would love to see a code-size bakeoff between OCSPs; I am conviced
that Malpani OCSP would fit into a smartcard or palmtop with more room
and cycles to spare than Myers/Ankney OCSP.

Nonetheless, after speaking with Rich, I am not inclined to suggest
that PKIX endorse the use of Malpani OCSP in lieu of Myers/Ankney
OCSP.  Instead, it may be preferable to use the Notary protocol,
perhaps with components of Malpani OCSP rolled in, as a vehicle for
both simple and extended validation requirements.  For online use with
HTTP/TLS, the Notary protocol messages can be neatly encapsulated as
Ambarish suggests, while still being usable over other
transport/protection mechanisms such as SMTP/CMS.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 16 Mar 1998 09:49:02 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

> From: Robert Jueneman <[email-masked]>
>
> Steve, I agree with that burying Non-verified Subscriber Informatioon (NVI/ NSI?) in a CPS won't do.  But on the other hand, there is a clear and compelling need for NSI, especially for proprietary attributes.
>
> It would certainly be nice if we had a convenient indicator, much like the Critical indicator.
>
> Perhaps someone can think of a good way of extending the standard to facilitate this?

Bob,

I agree too that there should be a way to indicate "comment" information
that is either not verified by the CA or not intended to be acted upon
(enforced) by the relying party.   X.509 apparently recognizes this need
too; unfortunately the mechanism chosen to implement it was to overload
the meaning of the CRITICAL extension bit.

The CRITICAL bit was originally intended (when unset) to allow
implementations which do not understand a particular extension to use
the remainder of the certificate in which it appears.  However, the
description of several extensions now use that bit to modify the
meaning of the particular extension in implementations which *do*
support it.

I don't know of a good way of extending the standard to facilitate the
inclusion of Non-Verified or Non-mandatory information in certificates,
but can think of four ways with varying degrees of badness:

* Define the v4 Extension syntax to include both a CRITICAL
  bit and a COMMENT bit.  This would be non-backward compatible in
  the same sense that v3 is not compatible with v1 - the COMMENT
  bit would be DEFAULT FALSE and v4 would not be used unless some
  extension had it set TRUE.  It's probably unthinkable to do a
  version rev at this point - forget I mentioned it :-).

* Redefine the syntax of each extension (such as subjectAltName) to
  include a NVI/COMMENT/NON-REQUIRED bit, superceding the OIDs for
  the existing extensions.

* Define duplicate parallel extension OIDs, (such as subjectAltName
  and nvSubjectAltName) to denote verified/mandatory and non-verified/
  optional information.

* Continue along the current path, and overload the CRITICAL bit
  to modify the extension's meaning.  In the case of subjectAltName,
  this would not allow one portion of an RFC822 name to be verified
  and another to be non-verified; the entire extension would have the
  same status, and there can be only one instance of that extension in
  a certificate.

Approved-By:  [email-masked]
Date:         Mon, 16 Mar 1998 09:54:07 +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] Cryptographic binding of certificates tosignatures
Comments: cc: [email-masked]
To: [email-masked]

Bob,

[email-masked] wrote:
>
> Lars, I appreciate your "European" hard-token perspective.
> Certainly, how the keys are generated and how they are
> incorporated into certificates can substantially change the risks.

Right, thanks for your appreciation!

> Just to clarify one thing however. Although I mentioned the
> possibility of changing the SIGNED macro, it was only to
> highlight the original source of the problem. I realize that changing
> the basic definition at this time is probably not a viable
> possibility.
>
> However, my final recommendation and conclusion was that we
> consider creating a new set of signature algorithm IDs that would
> end up using RSA, DSA, etc., but would also include additional
> information such as the issuerName and serial number, or perhaps
> just a hash of the certificate, so that the certificate to be used
> is irrevocably tied to the signed text.

Ok, so that would allow some protocols to switch over by using the
new set of algorithm IDs while others can continue using the old ones.

That doesn't change my original criticism however. What may seem
as an improvement in flexibility is really just going back to the original
situation (with some "safe" protocols using the new set of algorithm
IDs and other protocols still being "unsafe"). Why then not leave this
to the protocol designers or, as I suggested, to the key holder and
relying party?

> I also mention the desirability of including some additional information
> such as date/time and possibly the identity of the platform on which
> the signature was applied, for audit purposes.

I can think of many different information fileds that can be useful. Let me
just give you one example: Charcter set coding. Suppose that I sign a
document and include my certificate serial number '123' and later
discover that I'd rather liked to have used the certificate with serial
number '342'. Well then I could try to claim in court that I actually used
the special "Swahilian ASCII coding" (or something like that), where
3=49, 4=50 and 2=51. (There's no limit to my imagination of the usefulness
of this technique ;-).

My point is that we shouldn't put any restrictions to what must be included
in a signature (unless it's really cryptographically relevant like randomness
and formatting for example). If we do, then we'll most certainly run in to the
situation where we find that the standard is too limited. Again, let
this thing be
taken care of by the application designers!

> (You might be particularly interested in the later, from your hard-token
> perspective. Assuming that the token only generates the signature, and
> maybe the message digest that goes into it, the token has no way of
> knowing what the user saw on the screen that was supposed to be
> signed, as opposed to what the application actually presented to be signed.
> Unless the token is limited to only signing once per insertion, a rogue
> merchant could cause the token to sign all sorts of things, while the
> user thinks that she is only buying a dishrag. Including an authenticated
> identification of the platform would help point a smoking gun in such cases.)

Actually, I'm not interested in that possibility. My primary interest
is to have a
common PKI for both smart cards and soft tokens. If smart cards should use
a different signature algorithm than everyone else, it would be a bad thing.

> Other people may have their own pet ideas which should be considered.
> For example, I foresee a time in the relatively near future where
biometrics will
> be combined with digital signatures to circumvent some of the control issues
> that neither a password encrypted key nor a smart token solve, since
either can
> be given away.  It would no doubt be very useful to incorporate the biometric
> indicia into the signature itself, so that it would later be
validated against
> the biometric template included in the certificate. Without
supporting such a
> basic mechanism now, while the industry is still in the process of
writing lots of
> new applications, adding such features would require modifications to
a very large
> number of individual applications -- an almost hopeless task.

Spooky, indeed!

> But I'm not trying at this time to suggest precisely what ancillary
information
> should be included. We are still trying to sort out whether it should be
> done at all. Of course, even if a new signature algorithm ID is
> defined, it doesn't have to be used, so it would be optional from that
> standpoint. For the sake of interoperability, however, it would be a new
> algorithm that would have to be widely supported, unless we can figure
> out a mechanism for making the additional parameters transparent.
>
> I do believe that specifying the suite of signature algorithms that are to be
> supported is one of the functions of this group, so I believe the
discussion is
> appropriate for this list.

Well, I disagree on this point. Let's have the standards finished as soon as
possible so we can start using them. They may not be perfect but we must
remember that there's no such thing as absolute security (unless of course
you don't communicate at all :-).

Kind regards,
/Lars Johansson
Sweden Post

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 16 Mar 1998 09:45:43 -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:      [IETF-PKIX] URLs for CMMF and CMC drafts
To: [email-masked]

> I haven't yet seen any notification to this effect yet but the following two
> drafts are available for review and comment on the IETF web site:

Michael,

The addresses you gave are incorrect. You switched draft and ietf. The
corrected URLs are below.

> -- Certificate Management Message Formats
>       ietf-draft-pkix-cmmf-00.txt

ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-cmmf-00.txt

> -- Certificate Management over CMS
>       ietf-draft-pkix-cmc-00.txt

ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-cmc-00.txt

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  [email-masked]
Date:         Mon, 16 Mar 1998 09:01:21 +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] Multiple certificates for same key?
To: [email-masked]

Dave & Phill,

Some short replies...

[email-masked] wrote:
>
> > From: [email-masked]
> >
> > Some people have argued that there's too many security risks
> > involved when dealing with multiple certificates of the same
> > key that it should be prohibited (or at least not recommended :-).
> > I could give you many reasons why there shouldn't be any such
> > restrictions but let me just give you an alternative perspective.
>
> Please list some reasons for preferring multiple certificates per
> key - that is one of the critical items of information missing from
> the discussion so far.
>
> What precisely are the three or four most important advantages of
> multiple certification of keys?  Saving memory on tokens has already
> been mentioned.

My main point was that something that isn't prohibited should be
permitted. Most of the risks that have been discussed so far can
be handled by the policy. But if you want examples I can give you
some:

Saving memory is a valid reson but it can also be interpreted
as saving money. Setting up a PKI based on smart cards is quite
expensive (believe me) so the more certificates/roles that can be
bound to the same token the better. A lot of people are fed up with
how many different cards they have to carry in their wallet already.

I think everyone on this list sees the need for different certificates
(one being the integrity risks).

> Private key storage mechanisms and multiple certificates are
> separate issues.  When you have one security weakness (software
> key storage) it tends to exacerbate security problems in other
> areas (multiple certification).  But saying (or requiring) keys
> to always be stored on tokens does not make the other problems
> go away.  Sure, the private key(s) cannot be extracted from the
> token without perhaps destructive reverse engineering.  But the
> token can still be used by malicious applications to sign things
> the user didn't intend to have signed.  The only way to prevent
> that is to allow segregation of keys by purpose, and not store
> the sensitive keys on tokens that will be highly exposed.

I tend to agree with you that private key storage and multiple
certificates are somewhat separate issues. Perhaps my original
comment should be rehrased as: the security risks are CA's that
certify locally generated keys without careful checking of the
key holders identity.

Your comment on smart cards is in line with Phill's so I'll answer
them both below.

[email-masked] wrote:
>

[...]

>
> The ambiguity problem is considerably worse with a smart
> card than a soft certificate. The one declarative action that
> is possible with the chip in card format is to insert the device
> into a reader. Any variation in semantics must be captured
> by the terminal - which cannot be considered as secure as
> the card itself.

My intention is not to start a debate on the security of smart cards
vs. soft tokens. And I would definitively not like to suggest that
keys should be to always be stored on tokens. There is a need
for both.

However, as you both point out, there are risks with smart cards
as well (not worse than soft tokens though). There's always
something that you must put your trust on, your local workstation
being one example, but that is no different than with soft tokens.

> On the other hand I don't think we should wire any prohibition
> on dual certification of keys into the standard, the practical
> reason being that such a prohibition could not be enforced.
> People are bound to do it whether or not it is a good idea.
> Therefore it would not be a good thing for clients to rely on
> it not taking place.
>
> If there is not going to be an impact on the specififcation we
> do not need to discuss it.

I'm glad to see that we have the same opinion in this case.
I totally agree with you!

Kind regards,
/Lars Johansson
Sweden Post

Approved-By:  Michael Myers <[email-masked]>
Date:         Sun, 15 Mar 1998 22:40:28 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
Comments: To: [email-masked]
To: [email-masked]

Anil,

First, a couple of comments on this general state of affairs and then some
more specific comments on your analysis.

First, OCSP is on the standards track.  It has gone through several
iterations, culminating in  the recent joint authorship of myself and Rich
Ankney, which effort took into account the comments of many interested
parties.  The core concepts have been available for review for three IETFs
and have not fundamentally changed in that time, including the syntatic
approach.  A number of parties are testing the spec with trial
implementations.   At this point It is about as ready for last call as any
work product PKIX has yet produced.

Secondly, further extension of OCSP is counterproductive.  We need to get
something out that is useful in a "good enough" sense ( in the same sense
that CRLs are good enough for many needs) and address more sophisticated
needs with more sophisticated mechanisms. Let's match the size of the hammer
to the size of the nail.

Now, beyond that, your analysis provides us the opportunity to further
examine the core issues.

Mike

-----Original Message-----
From: Anil R. Gangolli <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, March 12, 1998 4:17 PM
Subject: [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts

>Attached are some cursory comments on both the Malpani and
>PKIX OCSP drafts.  Some additional notes pertaining only to
>the Malpani draft are included at the end.
>
>--a.

>Comments on the Malpani OCSP recommendation and PKIX OCSP
>Full Validation vs. Revocation

>There appears to be an implicit motivation in the PKIX OCSP
>(draft-ietf-pkix-ocsp-02.txt) work that is missed by the Malpani spec.
>The PKIX spec seems intended to support not only revocation checking
>but full cert path validation for "thin clients" that might have only
>one trust point defined and trust OCSP servers for all more general
>cert path validation tasks.  I believe the PKIX OCSP spec requires
>further elaboration if it is intended to support this, but the Malpani
>spec doesn't provide for this at all.

If I may reiterate a point I've made several times in the past, OCSP was and
is primarily intended as a drop-in replacement for CRL processing where the
unique characteristics of OCSP lend themselves to the problem at hand.
Several commentators have noted the need for additional requirements
regarding validation.  I've agreed over the course of editing the document
to accomodate these needs.  I agree with Rich however that sophisticated
context validation schemes are beyond its scope.

>Some of the wierd hacks in the PKIX OCSP may credibly be explained by
>this motivation.  e.g. the avoidance of ASN.1 and the way the Cert ID
>hash argument is formed by straight concatenation rather than DER
>encoding a sequence.

Indeed, this is exactly the basis for the syntax and its constructions.
Whether or not they are wierd hacks or intuitively obvious implementation
choices may depend upon one's frame of reference.

>Use of ASN.1 and/or HTTP
>I expect that Malpani's revised OCSP using ASN.1 embedded within HTTP
>will be a better framework for the request/response specification than
>the PKIX OCSP scheme using ad hoc encodings over HTTP, but the "thin
>client" issue needs to be discussed.  Is the PKIX scheme trying to
>meet "thin client" requirements?

Most definitely, although not exclusively.  More generally, it addresses
requirements for simplicity in implementation within a well-defined problem
space.

The expressive power of ASN.1 is overkill in this case.  It burdens the
implementor with a steep learning curve, expensive tools, and delays in
market access just to gain access to an integer value expressing the current
state of a certificate's status.

>Is it succeeding?

Yes.  In the best IETF tradition, trial implementations are underway to
prove the concept.  I'm aware of at least two efforts that are directed
at a well-defined market need.

>What is the delta
>between what is required in a thin client that uses certs at all and a
>thin client that uses PKIX OCSP vs. Malpani OCSP?

This issue is not one of thin-client vs. full client but more with the
fundamental problem being addressed and a rational balance
between that problem's scope and the tools needed to effect
its solution.

>If the current PKIX OCSP HTTP scheme is used, the URL encoding should
>be brought more in line with current practice in browsers and other
>HTTP clients.  Use the format of application/x-www-form-urlencoded for
>attribute-value sets both in POSTed requests and all responses.
>Similarly use the more common encoding conventions for GET urls, eg.
>GET /ocsp/ver/1?arg1=value1&arg2=value2... in GET urls.

The spec enables developers of thin clients to export the complexity of CRL
processing to an external server.  I've heard this observation from several
of my larger enterprise customers and major technology partners.  This
effect has nothing to do with timeliness and everything to do with what
might be considered an indirect "feature".  In many such instances the need
for absolute timeliness is less acute.  One is then led to consider the
means by which OCSP can be further enhanced through the natural caching
effects of HTTP.  It is widely known that certain URL constructions, such as
you propose, are inherently non-cacheable. The OCSP request spec advantages
its implementors by proposing construction of a request that enables the
OCSP request to look like a cacheable object.  The ASN.1 approach eliminates
this option.

>Validity Time
>Both the current PKIX OCSP and the Malpani spec need clarification on
>the interperetation of the time interval and the assertion that the
>responder is making relative to these times.
>First, I suggest that "producedAt" be replaced by "validAt", and it be
>interpreted that way.

The intent here is to align with the same notions in CRL for "thisUpdate"
and "nextUpdate".  The corresponding semantics would apply.

>For example an OCSP responder may be producing a response based on a
>CRL that was generated somewhat earlier.  It cannot reasonably extend
>its assertion of validity beyond that of the CRL's "thisUpdate" time.
>The validUntil name is also misleading.  It should, as for CRLs, be
>"nextUpdate" or better "nextExpectedUpdate".

You must not be referencing the latest version as posted to the PKIX group's
link off the IETF web page. The current draft has a "nextUpdate".  The only
change left is to do the right thing and change the "producedAt"
non-terminal to "thisUpdate."

>The validity assertion claimed by the response holds only at any the
>"validAt" time.  In general the relying party must decide whether the
>difference between its current time and the "validAt" time of response
>meets its application requirements.

In general the relying party must decide whether or not to accept  *any*
assertion regarding the fitness of a certificate for a given purpose.  In
particular, RPs should pay attention to unilateral assertions of a
certificate's reliability when those assertions are not provably sourced
by the issuer of the certificate.  Those RPs also have a compelling
need to know when they may next expect or means by which they
may acquire fresher information from the issuing CA.

>The time "nextExpectedUpdate" provides a hint to the relying party on
>the time that new information is expected to be available from the
>responder.  The responder MAY generate new information before the time
>expressed in nextExpectedUpdate.  The responder SHOULD generate new
>information no later than the time expressed in nextExpectedUpdate.

We looked at this problem going into the last IETF.  To summarize those
discussions, if a CA makes revocation information available
asynchronously--that is, before RPs otherwise expect it to be available as
represented by a nextUpdate field--certain of those RPs may be led into
concluding that they have no need to go after fresher information than that
which they've currently cached (either locally or via proxy mechanisms).
Knowing this, an attacker could trick an RP into accepting a signature
as valid--substantiate by local cache and not refreshed due to nextUpdate
logic--when in fact the attacker has a priori recieved a reponse from
the CA showing the certificate as revoked.  Thus CAs that generate new
information before it is expected risk causing their RPs to incorrectly rely
on a certificate.

The situation is analogous to the CRL suppression problem.

These considerations led to the following requirement:

"If responses are pre-produced, then for a given certificate, the
periodicity of this pre-production SHOULD match the response validity
interval of the most recently produced response."

One way of solving this problem is go into a complete "push" mode, but that
still wouldn't solve the problem of the offline RP.

>One might want to add:
>        The relying party SHOULD NOT use a response indicating a
>        certificate's validity beyond the nextExpectedUpdate time.

This seems a reasonable requirement on RPs, but the OCSP spec
cannot place requirements on humans.

>but one should considier that this might better be left to
>application-level standards.
>The only thing that may be important to
>the application is the difference between current time and validAt
>time, if the cost of getting updated information is too hight.  (see
>related notes on Nonce below.)

I agree that it remains within the scope of implementations to determine
what to do in this instance.  It does seem however that there are only two
course of action: either enable users to override the trust engine of their
software, or to automatically cease further processing if the value for
nextUpdate is earlier than the machine's current time.  This later case no
doubt would obtain in the case of machines processing certificates.
IPSEC comes to mind.

>Nonce
>The assertion being claimed by a signed OCSP response is not changed
>by replay.  So it would seem that the purpose of the nonce is not to
>prevent replay attacks but rather to bind the response to a particular
>request in order to allow the relying party later to claim some
>sequence of events (e.g. the relying party must have done the OCSP
>check specifically for transaction X, because it included hash(X) in
>the nonce).

It is the replay of an error responses that's at issue here in the event
when the CA failed for some reason to successfully process a prior request.
This response can be captured for subsequent replay in instances when
subsequent successful requests would have yeilded a VALID response.

>In general I believe that applications and application-level standards
>should define a minimum requirement on revocation checking based on a
>"maximum tolerance window" specifying the maximum allowed difference
>between the current time and a revocation check on that certificate,
>rather than a per-transaction check.

But what if a signer's key is compromised, and the transaction being
processed within this so-called "safe window" is a high-value transaction
worthy of immediate status?  I doubt that applications are going to be
configurable to the granularity of attributes of single transactions.
In fact, I suspect that all we're likely to get in the near term is an
on/off switch on revocation.

>The nonce would be useful in situations where the application or
>application-level standard requires a per-transaction check against
>one of an approved set of responders.  I expect that this will prove
>costly to scale up with OCSPs individually-signed responses.

Rather, any online mechanism must address reliability and availability, from
IP routing networks to DNS name resolution.  The fundamental question is:
who pays for the infrastructure implied by the quite obvious means to
achieve responsive service levels?  This is an open question at this point,
but it is well beyond the scope of the OCSP draft to articulate such
answers.

>This
>starts becoming akin to the function of a notary.

I wholeheartedly agree.

>It is not clear it
>belongs in this spec, but I agree it is cheap to include.

Agree.

>Individual Signatures
>I still have a lot of trouble believing that individually signed
>responses, whether pre-computed or not will scale well for OCSP.

As I've said before, OCSP is not a systems-level design document.  It is an
interface specification between two endpoints such that any requestor A can
interoperate with any responder B.  In this regard it is no different than
any other pairwise interface protocol.  SMTP comes to mind; HTTP; DNS.  I
would further offer that OCSP can be used to actually *improve* the
scalability of some security protocols.  Consider for example the instance
when an OCSP response is included in an S/MIME message or in an ISAKMP main
mode exchange.

>I think that the Malpani spec could be extended to include
>alternate response mechanisms easily.

As your analysis implies, this spec is clearly vectored towards statements
of context validation and as such is much more closely linked to the Notary
Protocol.

Mike

Approved-By:  Michael Myers <[email-masked]>
Date:         Sun, 15 Mar 1998 22:21:32 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Paul,

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Sunday, March 15, 1998 1:05 PM
Subject: Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other
extensions

>Steve:
>I think you are thinking too
>much in the Verisign online enrollment model, which is only one way certs
>will be generated.

Actually, we have several enrollment models.  You may be most familiar with
the Internet variety.  We also enable enterprise-level local registration
authorities who, with appropriate a priori arrangments, are held to be
authoritative for well-defined jurisdictions.

Mike

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Sun, 15 Mar 1998 12:41: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Steve:

We still disagree here, but unlike in many arguments in PKIX, it is clear
where we disagree. :-)

>Most folks will not read a CPS, especially if it goes into that level of
>detail, and thus what the fine print says will not matter unless one
>litigates a dispute.

But if you don't read the CPS, you have no idea if the non-comment part of
an email address was verified. I could certainly believe that many CAs who
do not do online enrollment (like corporate CAs) will accept as valid any
information typed into them by the human CA administrator at a CA console.
If I walk up to my human administrator and say "here's my common name and
my email address; give me a cert", there's no sensible way for that human
to verify that it is really my email address. I think you are thinking too
much in the Verisign online enrollment model, which is only one way certs
will be generated.

Basically, either someone reads the CPS or they don't. Saying "becasue they
probably won't, this identifier is OK because it *could* be verified" is
very dangerous, IMHO. Either it is verified (and th CPS says so), or it
isn't (and it's not covered in the CPS, or the CPS says "we don't verify
this").

>I argue that we ought to be careful to not foster a situation that unduly
>creates an opportunity for confusion.

I fully agree. And I think pretending that a bare email address is verified
and belongs to the named user is quite an opportunity for confusion.
Remember, comments in an RFC 822 name *can* be verified. Both parts can be
verified, or they can be not verified.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Robert Jueneman <[email-masked]>
Date:         Sat, 14 Mar 1998 18:14:08 -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: Robert Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and otherextensions
Comments: To: [email-masked]
To: [email-masked]

Steve, I agree with that burying Non-verified Subscriber Informatioon (NVI/ NSI?) in a CPS won't do.  But on the other hand, there is a clear and compelling need for NSI, especially for proprietary attributes.

It would certainly be nice if we had a convenient indicator, much like the Critical indicator.

Perhaps someone can think of a good way of extending the standard to facilitate this?

Bob

>>> Stephen Kent <[email-masked]> 03/14/98 01:18PM >>>
Paul,

Sorry to have let this languish in my inbox.  When last we discussed this
issue we had resolved that we were in opposite camps re inclusion of
non-verified data in certs, in general, so the matter of including comments
along with the portion of the mailbox name that is used to control delivery
is just one example of this difference of opinion. I'm not sure we have
discussed the NVI matter as much on PKIX ad it had been discussed on PEM in
the past, but there never seems to be complete resolution.  In general, I
think that if a CA does elect to include NVI in a cert, it ought to be
included in extensions that don't have widespread use and a common
interpretation that could result in users being mislead.  Private
extensions are the obvious examples.

As you point out, the CPS for a CA can state whether the more "user
friendly" part of a mailbox name has been verified or not, just as it
states other aspects of the authenitcation process. However, I fear this is
begging the question.
Most folks will not read a CPS, especially if it goes into that level of
detail, and thus what the fine print says will not matter unless one
litigates a dispute.

I argue that we ought to be careful to not foster a situation that unduly
creates an opportunity for confusion.  While 822 addresses (and DNS names)
have a suitable infrastructure for establishing accuracy and uniqueness,
once one adds other, informal identifiers added to them pose more of a
problem. If one wants to include this other info in a cert, how about
including it as a common name component of a DN?

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Sat, 14 Mar 1998 15:18:12 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Paul,

Sorry to have let this languish in my inbox.  When last we discussed this
issue we had resolved that we were in opposite camps re inclusion of
non-verified data in certs, in general, so the matter of including comments
along with the portion of the mailbox name that is used to control delivery
is just one example of this difference of opinion. I'm not sure we have
discussed the NVI matter as much on PKIX ad it had been discussed on PEM in
the past, but there never seems to be complete resolution.  In general, I
think that if a CA does elect to include NVI in a cert, it ought to be
included in extensions that don't have widespread use and a common
interpretation that could result in users being mislead.  Private
extensions are the obvious examples.

As you point out, the CPS for a CA can state whether the more "user
friendly" part of a mailbox name has been verified or not, just as it
states other aspects of the authenitcation process. However, I fear this is
begging the question.
Most folks will not read a CPS, especially if it goes into that level of
detail, and thus what the fine print says will not matter unless one
litigates a dispute.

I argue that we ought to be careful to not foster a situation that unduly
creates an opportunity for confusion.  While 822 addresses (and DNS names)
have a suitable infrastructure for establishing accuracy and uniqueness,
once one adds other, informal identifiers added to them pose more of a
problem. If one wants to include this other info in a cert, how about
including it as a common name component of a DN?

Steve

Approved-By:  Michael Myers <[email-masked]>
Date:         Fri, 13 Mar 1998 18:08:08 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] CMMF and CMC drafts
To: [email-masked]

All,

I haven't yet seen any notification to this effect yet but the following two
drafts are available for review and comment on the IETF web site:

-- Certificate Management Message Formats
      ietf-draft-pkix-cmmf-00.txt

-- Certificate Management over CMS
      ietf-draft-pkix-cmc-00.txt

CMMF integrates PKI message bodies into one document (although points to
CRMF).

The CMC draft carries forward the CRS work which was submitted at the last
IETF to the S/MIME group and which was subsequently redirected to PKIX.

Mike

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Fri, 13 Mar 1998 15:51: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: Robert Zuccherato <[email-masked]>
Subject:      [IETF-PKIX] New Time Stamp Protocols Draft
To: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BD4E97.E9C32330
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Our new Time Stamp Protocols Draft is now available.  We submitted it,
again, as an independent draft since the PKIX charter hasn't yet been
modified to include this work.  It is available at:
ftp://ftp.ietf.org/internet-drafts/draft-adams-time-stamp-01.txt
and has also been attached to this message.

The changes to this draft include CMS (PKCS #7) encapsulation and the
inclusion of a nonce and version number in the request and responses.

As usual, comments are appreciated.

        Robert Zuccherato.

------ =_NextPart_000_01BD4E97.E9C32330
Content-Type: text/plain; name="time01.txt"
Content-Transfer-Encoding: 7bit

                                          C. Adams(Entrust Technologies)
Internet Draft                                             P. Cain (BBN)
expires in six months                                   D. Pinkas (Bull)
                                     R. Zuccherato(Entrust Technologies)
                                                          March 12, 1998

                          Time Stamp Protocols

                    <draft-adams-time-stamp-01.txt>

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This document describes the format of the data returned by a Time
Stamp Authority and the protocols to be used when communicating with it.
The time stamping service can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]).  In order to reduce the amount of trust required of a TSA we
introduce (in Appendix C) the optional Temporal Data Authority (TDA)
whose function is to provide further corroborating evidence of the time
contained in the token.  We also give an example of how to place a
signature at a particular point in time, from which the appropriate
certificate status information (e.g. CRLs) may be checked.

1.  Introduction

In order to associate a message with a particular point in time, a
Time Stamp Authority (TSA) may need to be used.  This Trusted Third
Party provides a "proof-of-existence" for this particular message at an
instant in time.  A TSA may also be used when a trusted time reference
is required and when the local clock available cannot be trusted by all
parties.  The TSA's role is to time stamp a message to establish
evidence indicating the time before which the message was generated.
This can then be used, for example, to verify that a digital signature
was applied before the certificate was revoked thus allowing a revoked
public key certificate to be used for verifying signatures created prior
to the time of revocation.  This is an important public key

Document Expiration:  September 12, 1998                         Page 1

infrastructure operation.  The TSA can also be used to indicate the time
of submission when a deadline is critical, or to indicate the time of
transaction for entries in a log.  An exhaustive list of possible uses
of a TSA is beyond the scope of this document.

2. The TSA

The TSA is a TTP that creates time stamp tokens in order to indicate
that a message existed at a particular point in time.

For the remainder of this document a 'valid request' shall mean one that
can be decoded correctly, is of the form specified in Section 2.4 and
contains the correct TSA name.

2.1. Requirements of the TSA

The TSA is required:
     1. to only provide a trusted source of time.
     2. not to examine or verify the requesting entities in any way.
     3. not to examine the imprint being time stamped in any way.
     4. to include a monotonically incrementing value of the time of day
        into its time stamp token.
     5. to produce a time stamp token upon receiving a valid request
        from the requester.
     6. to include within each time stamp token an identifier to
        uniquely indicate the trust and validation policy under which
        the token was created.
     7. to only time stamp a hash representation of the message, i.e. a
        data imprint associated with a one-way collision resistant hash-
        function OID.
     8. to examine the OID of the one-way collision resistant hash-
        function and to verify that this function is "sufficient" (see
        Section 2.4).
     9. to sign each time stamp token using a key generated exclusively
        for this purpose and have this property of the key indicated on
        the corresponding certificate.
    10. to include supplementary temporal information in the time stamp
        token (from TDA's) if asked by the requester.  If this is not
        possible, the TSA shall respond with an error message.
    11. to provide a signed receipt (i.e. in the form of an
        appropriately defined time stamp token) to the requester, where
        appropriate, as defined by policy.

2.2. TSA Transactions

As the first message of this mechanism, the requesting entity requests a
time stamp token by sending a request (which is or includes a
TimeStampReq, as defined below) to the Time Stamping Authority.  As the
second message, the Time Stamping Authority responds by sending a
response (which is or includes a TimeStampToken, as defined below) to
the requesting entity.

Upon receiving the token, the requesting entity verifies its validity
by verifying the digital signature in the TimeStampToken and by
verifying that what was time stamped corresponds to what was requested
to be time stamped.  The requester should verify that the TimeStampToken

Document Expiration:  September 12, 1998                         Page 2

contains the correct TSA name, the correct data imprint and the correct
hash algorithm OID.  It should then verify the timeliness of the
response by verifying either the time included in the response against a
local trusted time reference, if one is available, and/or the value of
the nonce included in the response against the value included in the
request.  Since the TSA's certificate may have been revoked, the status
of the certificate should be checked (e.g. by checking the appropriate
ARL) to verify that the certificate is still valid.  If
TemporalDataToken's are included in the TimeStampToken, then these
should also be verified as was the TimeStampToken (see Appendix C).  The
token can now be used to establish a trusted time reference.

2.3. Identification of the TSA

The TSA must sign all time stamp messages with a key reserved
specifically for that purpose.  The corresponding certificate must
contain the extended key usage field extension as defined in [CCP]
Section 4.2.1.14 with KeyPurposeID having value id-kp-timeStamping.
This extension must be critical.

2.4. Request and Token Formats

A time stamping request is as follows.

TimeStampReq ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     requester                [0] GeneralName OPTIONAL,
     reqPolicy                [1] PolicyInformation OPTIONAL,
     tsa                      [2] GeneralName,
     tdas                         SEQUENCE OF GeneralName OPTIONAL,
     nonce                        Integer,
     messageImprint               MessageImprint
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
}

The requester field, if included indicates the name of the requester.
This value is not verified by the TSA, but blindly copied in the
response and may be also copied in the audit trail.

The reqPolicy field, if included, indicates the policy under which the
TimeStampToken should be provided.  PolicyInformation is defined in
Section 4.2.1.5 of [CCP].

The tsa field identifies the name of the TSA.  GeneralName is defined
in Section 4.2.1.7 of [CCP].

The tdas field identifies those TDAs which are requested to provide
supplementary temporal evidence in the time stamp token.  (See Appendix
C.)

MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }

Document Expiration:  September 12, 1998                         Page 3

The hash algorithm indicated in the hashAlgorithm field must be a strong
hash algorithm.  That means that it must be one-way and collision
resistant.  It is up to the Time Stamp Authority to decide whether or
not the given hash algorithm is "sufficient" (based on the current state
of knowledge in cryptanalysis and the current state of the art in
computational resources, for example).

The hashedMessage field should contain the hash of the message to be
time stamped.  The hash is represented as an OCTET STRING.

A TimeStampToken is as follows.  It is encapsulated as a SignedData
construct [CMS].  The content is of type TSTInfo, which is indicated by
the OID:

TSTInfo OBJECT IDENTIFIER  ::= { ??????  }

The time stamp token must contain only the signature of the TSA.  In
some environments, the CA might not perform a proof-of-possession of
the private key when issuing certificates.  In these instances, either
the certificate of the TSA, or the certificate issuer and serial number
shall be included as an authenticated attribute.

TSTInfo ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     policy                       PolicyInformation,
     status                       PKIStatusInfo,
     requester               [0]  GeneralName OPTIONAL,
       --must be present if the requester field is present in
       --TimeStampReq, and must be identical to that field
     tsa                     [1]  GeneralName,
     genTime                      GeneralizedTime,
     tdaTokens                    SEQUENCE OF TemporalDataToken
                                    OPTIONAL,
     nonce                        Integer,
       --this field must have the same value as the similar field
       --in TimeStampReq
     messageImprint               MessageImprint
       --this field must have the same value as the similar field
       --in TimeStampReq
}

PKIStatusInfo is defined in Section 3.2.3 of [CMP].  If the PKIStatus
field has value 'waiting' (3), then this token is a receipt, as defined
in Section 2.1.  Otherwise, the status field is present to indicate
whether or not the time stamping request was fulfilled and, if not, the
reason it was rejected. A valid time stamp token will always have value
0 (granted) in the PKIStatus field of PKIStatusInfo.  Since not all
environments will require the use of receipts, support for the value
'waiting' is optional.

The purpose of the tsa field is to identify the name of the TSA.  It
must correspond to one of the subject names included in the certificate
that is to be used to verify the token.

Document Expiration:  September 12, 1998                         Page 4

TemporalDataToken is defined in Appendix C of this document.  The
tdaTokens field contains the supplementary evidence requested in the
TimeStampReq.

CertId is defined in Section 3.2.4 of [CMP].

3. Transports

There is no mandatory transport mechanism in this document.  All
mechanisms are optional.

3.1. File Based Protocol

A file containing a time stamp message must contain only the DER
encoding of one PKI message, i.e. there must be no extraneous header or
trailer information in the file.

Such files can be used to transport time stamp messages using for
example, FTP.

3.2. Socket Based Protocol

The socket based protocol for time stamp messages is identical to that
used in [CMP] Section 5.2 except that port 309 must be used.

3.3. Time Stamp Protocol Using E-mail

This section specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 2 and Appendix C via
Internet mail.

A simple MIME object is specified as follows.

   Content-Type: application/timestamp
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded Time Stamp message, base64-encoded>>

This MIME object can be sent and received using common MIME processing
engines and provides a simple Internet mail transport for Time Stamp
messages.

3.4. Time Stamp Protocol via HTTP

This subsection specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 2 and Appendix C via the
HyperText Transfer Protocol.

A simple MIME object is specified as follows.

   Content-Type: application/timestamp

   <<the ASN.1 DER-encoded Time Stamp message>>

Document Expiration:  September 12, 1998                         Page 5

This MIME object can be sent and received using common HTTP processing
engines over WWW links and provides a simple browser-server transport
for Time Stamp messages.

4. Security Considerations

This entire document concerns security considerations.

When designing a TSA/TDA service, the following considerations have been
identified that have an impact upon the validity or "trust" in the time
stamp token.

     1. When there is a reason to believe that the TSA can no longer
        be trusted, the authority's certificate must be revoked and
        placed on the appropriate ARL.  Thus, at any future time the
        tokens signed with the corresponding key will not be valid.
     2. The TSA private key is compromised and the corresponding
        certificate is revoked.  In this case, any token signed by the
        TSA using that private key cannot be trusted.  For this
        reason, it is imperative that the TSA's private key be
        guarded with proper security and controls in order to minimize
        the possibility of compromise.  In case the private key does
        become compromised, an audit trail of all tokens generated by
        the TSA may provide a means to discriminate between genuine
        and false tokens.
     3. The TSA signing key must be of a sufficient length to allow
        for a sufficiently long lifetime.  Even if this is done, the key
        will have a finite lifetime.  Thus, any token signed by the
        TSA should be time stamped again (if authentic copies of old
        CRLs are available) or notarized (if they aren't) at a later
        date to renew the trust that exists in the TSA's signature.
        Time stamp tokens could also be kept with an Evidence Recording
        Authority to maintain this trust.
     4. Since the TSA does not verify message data or the identity of
        the entities, the requester field in TimeStampReq and
        TimeStampToken should be considered untrusted.  If
        authentication of this field is needed, it is recommended that
        the Notary Authority be used, as described in [NOTARY].
     5. An application using the TSA service should be concerned about
        the amount of time it is willing to wait for a response.  A
        `man-in-the-middle' attack can introduce delays.  Thus, any
        TimeStampToken that takes more than an acceptable period of time
        should be considered suspect.
     6. In certain circumstances, a TSA may not be able to
        produce a valid response to a request (for example, if it is
        unable to compute signatures for a period of time).  In these
        situations the TSA must wait until it is again able to produce a
        valid response before responding, if this is possible.  If this
        is not possible, it must ignore the requests and not respond.
        Under no circumstances shall a TSA produce an unsigned response
        to a request.
     7. This protocol assumes that the CA has conducted a test for proof
        of possession for each user's signing private key (including
        the TSA signing private key).  If this is not the case, or when
        additional assurances are required, the certificate or
        certificate serial number and issuer of the TSA shall be

Document Expiration:  September 12, 1998                         Page 6

        included in the encapsulation of the time stamp token as an
        authenticated attribute.

5. References

[CMP] C. Adams, S. Farrell, "Internet Public Key Infrastructure,
Certificate Management Protocols," draft-ietf-pkix-ipki3cmp-
0X.txt, 1997 (work in progress).

[NOTARY] C. Adams, R. Zuccherato, "Notary Protocols,"  draft-adams-
notary-0X.txt, 1998 (work in progress).

[CCP] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key
Infrastructure, X.509 Certificate and CRL Profile," draft-
ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress).

[ISONR] ISO/IEC 10181-5:  Security Frameworks in Open Systems.
Non-Repudiation Framework.

[CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).

6. Authors' Addresses

Carlisle Adams                        Pat Cain
Entrust Technologies                  BBN
750 Heron Road                        70 Fawcett Street
Ottawa, Ontario                       Cambridge, MA 02138
K1V 1A7                               U.S.A.
CANADA                                [email-masked]
[email-masked]

Denis Pinkas                          Robert Zuccherato
Bull S.A.                             Entrust Technologies
Rue Jean Jaures                       750 Heron Road
B.P. 68                               Ottawa, Ontario
78340 Les Clayes sous Bois            K1V 1A7
FRANCE                                CANADA
[email-masked]                 [email-masked]

Document Expiration:  September 12, 1998                         Page 7

APPENDIX A - Storage of Data and Token

A time stamp token is meaningless without its associated data.  Thus, a
method is required to allow users to store the data and token together
securely.  They may be stored as a PKCS #7 SignedData object as
described in [CMS].  That is, the contentType is signedData and
contentInfo is Data, which contains the message associated with the time
stamp token.  The SignedData object is signed by the person storing the
data and token.  This signature is to be used only for storage and for
verifying the integrity of the token and data. Anyone using the token
and data at some future time must verify the data and token at that
time.  This is just a method for keeping the two pieces of information
together, with some integrity.

For this purpose, we define a PKCS #9 [PKCS9] time stamp token attribute
type.  This attribute type specifies the time stamp token, which must be
included as an authenticated attribute of the SignedData object.  The
time stamp token attribute type has ASN.1 type TimeStampToken (as
defined in Section 2.4 of this document).  A time stamp token attribute
must have a single attribute value.

The object identifier timeStampToken identifies the time stamp token
attribute type.

timeStampToken ::= { pkcs-9 n <<To be supplied>> }

[CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).

[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City, California, November
1993 Release.

APPENDIX B - Placing a Signature At a Particular Point in Time

We present an example of a possible use of this general time stamping
service. It places a signature at a particular point in time, from
which the appropriate certificate status information (e.g. CRLs) must be
checked.  This application is intended to be used in conjunction with
evidence generated using a digital signature mechanism.

Signatures can only be verified according to a non-repudiation policy.
This policy may be implicit or explicit (i.e., indicated in the
evidence provided by the signer). The non-repudiation policy can
specify, among other things, the time period allowed by a signer to
declare the compromise of a signature key used for the generation of
digital signatures. Thus a signature may not be guaranteed to be valid
until the termination of this time period.

To verify a signature that incorporates an untrusted time, the following
basic technique may be used:

A) Time stamping information needs to be obtained by the signer or
a verifier.

Document Expiration:  September 12, 1998                         Page 8

     1) The signature is presented to the Time Stamping Authority (TSA).
        The TSA then returns a TimeStampToken (TST) upon that signature.
     2) The invoker of the service must then verify that the
        TimeStampToken is correct.

B) The validity of the evidence must be verified :

     1) The date/time indicated by the signer in the signature shall be
        compared with the date/time in the TST. If they are not close
        enough (e.g., less than a few hours) the evidence is considered
        to be invalid.
     2) The certificate included in the signed message should be
        verified to be valid at the time of the signature. It must
        first be verified and then the appropriate CRL must be
        checked.

The signature has now been placed at a particular point in time.  The
appropriate CRLs or other certificate status information mechanism may
be examined to determine the validity of the signature at that time.

Appendix C - The TDA

The Temporal Data Authority is a TTP that creates a temporal data
token.  This temporal data token associates a message with a particular
event and provides supplementary evidence for the time included in the
time stamp token.  For example,  a TDA could associate the message with
the most recent closing value of the Dow Jones Average.  The temporal
data with which the message is associated should be unpredictable in
order to prevent forward dating of tokens.  Authentic values of this
data should also be available from a large number of trustworthy sources
in order to make collusion or corruption of data more difficult.  For a
list of possible types of temporal data, see Appendix D.

C.1. Requirements of the TDA

The TDA is required:
     1. to only provide a trusted source of temporal data.
     2. not to examine the imprint being time stamped.
     3. to include the current data associated with a specific
        unpredictable event in each temporal data token.
     4. to produce a temporal data token upon receiving a valid request
        from the TSA.
     5. to only produce a temporal data token on a hash representation
        of the message.
     6. to sign each temporal data token using a key generated
        exclusively for this purpose and have this property of the key
        indicated on the corresponding certificate.

C.2. TDA Transactions

As the first message of this mechanism, the TSA requests a temporal data
token by sending a request (which is or includes a TemporalDataReq, as
defined below) to the TDA.  As the second message, the TDA responds by
sending a response (which is or includes a TemporalDataToken, as defined
below) to the TSA.

Document Expiration:  September 12, 1998                         Page 9

C.3. Verifying a TemporalDataToken

The TSA is required to verify the structure of the TemporalDataToken.
It must verify the digital signature in the TemporalDataToken and also
verify that what was signed corresponds to what was requested to be
signed.  The requester should verify that the TemporalDataToken contains
the correct TDA name, the correct data imprint and the correct hash
algorithm OID.  It should also verify the timeliness of the response by
verifying the value of the nonce included in the response against the
value included in the request (exact match needed). Since the TDA's
certificate may have been revoked, the status of the certificate should
be checked (e.g. by checking the appropriate ARL) to verify that the
certificate is still valid.

In order to verify the TemporalData inside a TemporalDataToken, it is
necessary to know the form of the temporal data that the TDA has
included in the token.

The TSA is not required to verify the TemporalData. However, either the
entity requesting a Time Stamping Token or an entity verifying a Time
Stamping Token containing temporal information may be interested in such
a verification.

In the first case, it is unlikely that the temporal information will be
available ahead of time and thus the entity requesting a Time Stamping
Token may need to enter into an online protocol with the TDA, or some
other entity, to obtain it. A secure link with that trusted source will
be necessary, i.e. the communication channel or the information itself
must be authenticated and integrity protected.  Such a protocol is TDA
dependent and is outside the scope of this document.

In the second case, if the verification occurs some time after the Time
Stamping Token has been produced, then it is possible to rely on an
authentic source (e.g. a newspaper or a CD-ROM) to verify it against.
The exact method of verification is TDA dependent and is thus outside
the scope of this document.

C.4. Identification of the TDA

The TDA must sign all temporal data tokens with a key reserved
specifically for that purpose.  The corresponding certificate must
contain the extended key usage field extension as defined in [CCP]
Section 4.2.1.14 with KeyPurposeID having value id-kp-temporalData.
This extension must be critical.

id-kp-temporalData    OBJECT IDENTIFIER ::= {id-kp  ??}
  -- Providing temporal data in support of time stamping services.  Key
  -- usage bits that may be consistent:  digitalSignature,
  -- nonRepudiation

C.5. Request and Token Formats

A temporal data request from a TSA is as follows.

TemporalDataReq ::= SEQUENCE  {
     version                      Integer  { v1(0) },

Document Expiration:  September 12, 1998                         Page 10

     tda                          GeneralName,
     nonce                        Integer,
       --must be the same value as the corresponding field in
       --TimeStampReq
     messageImprint               MessageImprint
       --a hash of the data to be time stamped, must be the same
       --value as the corresponding field in TimeStampReq
}

A TemporalDataToken is as follows.  It is encapsulated as a SignedData
construct [CMS].  The content is of type TDTInfo, which is indicated by
the OID:

TDTInfo OBJECT IDENTIFIER  ::= { ??????  }

The temporal data token must contain only the signature of the TDA. In
some environments, the CA might not perform a proof-of-possession of
the private key when issuing certificates.  In these instances, either
the certificate of the TDA, or the certificate issuer and serial number
shall be included as an authenticated attribute.

TDTInfo ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     tda                          GeneralName,
     nonce                        Integer,
       --must have the same value as the corresponding field in
       --TimeStampReq
     temporalData                 TemporalData,
     messageImprint               MessageImprint
       --must have the same value as the corresponding field in
       --TimeStampReq
}

The temporalData field contains the actual temporal data that will
be used as substantiating evidence in the time stamp token.

TemporalData ::= SEQUENCE  {
     format                       TEMPORALDATACLASS.&id,   --objid
     rawdata                      TEMPORALDATACLASS.&Type  --open type
}

TEMPORALDATACLASS ::= CLASS  {
     &id                          OBJECT IDENTIFIER UNIQUE,
     &Type                                                    }
WITH SYNTAX  { &Type IDENTIFIED BY &id }

C.6. Security Considerations

When designing a TDA service, the following considerations have been
identified that have an impact upon the validity or "trust" in the
temporal data token.

     1. When there is a reason to believe that the TDA can no longer
        be trusted, the authority's certificate must be revoked and
        placed on the appropriate ARL.  Thus, at any future time the

Document Expiration:  September 12, 1998                         Page 11

        tokens signed with the corresponding key will not be valid.
     2. The TDA private key is compromised and the corresponding
        certificate is revoked.  In this case, any token signed by the
        TDA using that private key cannot be trusted.  For this
        reason, it is imperative that the TDA's private key be
        guarded with proper security and controls in order to minimize
        the possibility of compromise.  In case the private key does
        become compromised, an audit trail of all tokens generated by
        the TDA may provide a means to discriminate between genuine
        and false tokens.
     3. The TDA signing key must be of a sufficient length to allow
        for a sufficiently long lifetime.  Even if this is done, the key
        will have a finite lifetime.  Thus, any time stamp token
        containing the TDA's signature should be time stamped again (if
        authentic copies of old CRLs are available) or notarized (if
        they aren't) at a later date to renew the trust that exists in
        the TDA's signature. Time stamp tokens could also be kept with
        an Evidence Recording Authority to maintain this trust.
     4. In certain circumstances, a TDA may not be able to produce a
        valid response to a request (for example, if it is unable to
        compute signatures for a period of time).  In these situations
        the TDA must wait until it is again able to produce a valid
        response before responding, if this is possible.  If this is not
        possible, it must ignore the requests and not respond.  Under no
        circumstances shall a TDA produce an unsigned response to a
        request.
     5. This protocol assumes that the CA has conducted a test for proof
        of possession for each user's signing private key (including
        the TDA signing private key)..  If this is not the case, or when
        additional assurances are required, the certificate or
        certificate serial number and issuer of the TDA shall be
        included in the encapsulation of the temporal data token as an
        authenticated attribute.

[CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).

APPENDIX D - Possible Types of Temporal Data

1)  Stock market information
2)  Sports results
3)  Official weather data for a specific location
4)  Lottery results
5)  Birth or death announcements in specific newspapers
6)  Headlines in specific newspapers
7)  Information linking the request with previous and subsequent requests
   (e.g. hash values) that can be verified against information that is
    made public by the TDA.
8) A signed packet from a secure time source.

Document Expiration:  September 12, 1998                         Page 12

------ =_NextPart_000_01BD4E97.E9C32330--

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Fri, 13 Mar 1998 13:04: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: Sharon Boeyen <[email-masked]>
Subject:      [IETF-PKIX] Revised draft-ietf-pkix-ipki2opp-07.txt
Comments: cc: harald alvestrand <[email-masked]>, keith moore <[email-masked]>
To: [email-masked]

The PKIX LDAPv2 protocol profile was not approved by the IESG. There
were two areas of
concern raised.

A revised version of the profile has just been submitted, which
addresses one of those
concerns (that the security considerations section recommend stronger
authentication for
the CA modification of PKI data and mention the risk of denial of
service attacks which can be mounted if stronger authentication is not
used). No other changes were made.

The other requirement is that at least a minimal schema specification be
completed to
accompany this profile. A draft will be submitted for that before the
deadline this afternoon
as well.

Sharon

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 13 Mar 1998 09:43:08 -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] Multiple certificates for same key?
To: [email-masked]

>Bob:
>
>I must disaree.  PKIX cannot provide non-repudiation.  PKIX provides
>necessary stuff, but the signing application must do other things that are
>beyond the scope of PKIX.  S/MIME is one such application.
>
>Russ

Russ, I don't disagree that PKIX cannot provide non-repudiation in and of itself.
The questions is whether PKIX is in fact providing the "necessary stuff", or
whether each application has to solve the problem of binding certificates to
documents, over and over again.

I don't believe this issue affects non-repudiation exclusively. I might have to
think for a second, but I think I could come up with a scenario where which
certificate is used would affect access controls and similar uses in SSL, IPSEC,
and other evolving protocols. so I don't want to relegate the issue to the S/MIME
group alone.

To say it another way, I think we (the technical community at large)
made a fundamental blunder in the past in not cryptographically binding the
certificate to the message, document, etc., at the time of signing.
And now I am suggesting that we consider whether, and how, we
could fix that fundamental problem.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Fri, 13 Mar 1998 09:33:04 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification and SEP protocol
To: [email-masked]

Hi Oronzo,

>----------
>From:  [email-masked][SMTP:[email-masked]]
>Sent:  Friday, March 13, 1998 5:19 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Cross Certification and SEP protocol
>
>I'm not a PKIX specialist and I need to check some information.
>
>Reading Entrust/Manager documentation I read:
>"....In Entrust, users receive a secure copy of the CA public key as
>part of the Secure Exchange Protocol (SEP). ..."
>
>AFAIK, SEP is an Entrust proprietary protocol used among CA server and
>clients, is this correct?
>
>If SEP is a proprietary protocol, is it correct to say that this should
>be solved in PKIX using PKIX-2 operational protocols
>specification?

No.  This is not an "operational protocols" issue; this is a
"certificate management protocols" issue (i.e., PKIX-CMP).  This is
exactly the reason that PKIX-CMP (which used to be called PKIX-3) was
invented and brought into the PKIX Working Group:  so that the protocols
and procedures necessary to achieve certificate management functionality
could be accomplished between PKI components (EE, CA, RA) in a
standards-compliant way.

SEP was created because back when we were first implementing full
certificate management functionality (over four years ago) there was no
other protocol that could be used.  However, we're not fond of
proprietary protocols and recognize that they have no benefit in terms
of encouraging interoperable components in a PKI.  This is why we have
been so vigorous in pursuing PKIX-3 within the IETF for more than two
years now.

Thanks for asking  --  I hope this helps to clarify things.

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

>From: Oronzo Berlen <[email-masked]>
Approved-By:  [email-masked]
Date:         Fri, 13 Mar 1998 11:19:02 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Organization: Olivetti Ricerca SCpA
Subject:      [IETF-PKIX] Cross Certification and SEP protocol
Comments: To: cert-talk <[email-masked]>
To: [email-masked]

I'm not a PKIX specialist and I need to check some information.

Reading Entrust/Manager documentation I read:
"....In Entrust, users receive a secure copy of the CA public key as
part of the Secure Exchange Protocol (SEP). ..."

AFAIK, SEP is an Entrust proprietary protocol used among CA server and
clients, is this correct?

If SEP is a proprietary protocol, is it correct to say that this should
be solved in PKIX using PKIX-2 operational protocols
specification?

Thanks in advance
--
____________________________________________________________________
Oronzo Berlen                   | tel. 080.635-2112
Olivetti Ricerca                | fax. 080.635-2089
S.S. 271 Contrada la Marchesa | Email:[email-masked]
70020 Bitritto (BA)             |

>From: Oronzo Berlen <[email-masked]>
Approved-By:  [email-masked]
Date:         Fri, 13 Mar 1998 09:49:19 +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]
Organization: Olivetti Ricerca SCpA
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: Bob Jueneman <[email-masked]>, Unix Security Italiana <[email-masked]>
Comments: cc: MSAF-ETSG <[email-masked]>
To: [email-masked]

In the italian draft legislation there is nothing like that; the only thing which is required for a CA
to operate is
to have a society form and available capital equal to that needed in Italy to operate as a Bank; this
recalls the liability
question, but not related to a specific certificate, but to the CA as a whole.

Bob Jueneman wrote:

> >What a reliance limit exactly is?
> >I know the Italian legislation which is going to be approved, where it seems there is nothing which
> >sound like what you need.
>
> Several people have asked "what's a reliance limit", so I guess I should
> have provided a definition.
>
> The Utah Digital Signature Act provides a means of limiting a
> CA's liability (and presumably the subscriber's liability), by putting
> a "Reliance Limit" in the certificate as a way of indicating the
> monetary value or upper limit of a transaction that might be
> considered "commercially reasonable":
>
> "46-3-309 Recommended reliance limits and liability
>
> (1) By specifying a recommended reliance limit in a certificate,
> the issuing certification authority and the accepting subscriber
> recommend that persons rely on the certificate only to the
> extent that the total amount at risk does not exceed the
> recommended reliance limit."
>
> Paragraph (2) of that section goes on at some length to define
> the limits of liability that would apply to a CA that is licensed under
> the Utah statute, and how someone can recover from the CA in
> the event someone is harmed. The Utah regulations also require
> that a CA provide a "suitable guaranty" in the form of surety bond
> or irrevocable letter of credit in an amount that is a percentage
> of the aggregate amount of the reliance limit of all currently valid
> certificates issued, in order to back up such liability limits. C.f.
> http://www.commerce.state.ut.us/web/commerce/digsig/act.htm,
> section 46-3-310 and 310.
>
> There are, of course, a number of problems that could occur in
> anything other than a closed loop system where the CA becomes
> involved in validating every certificate -- the CA normally has no
> knowledge of how many times the subscriber uses his digital
> signature, and even the subscriber may have no idea how many
> times even a given signature is validated, e.g., on a piece of
> operating system code signed by Microsoft, or a Java applet signed
> by some web server. Even if the Reliance Limit is 1 penny, the
> CA's liability is potentially infinity squared in that case.
>
> Nonetheless, even in an open loop, open PKI system, some
> form of caveat or limitation on a certificate is probably better than nothing.
>
> To date, no CA I am aware of includes a Reliance Limit attribute extension
> in their certificates. VeriSign in their CPS does claim an overall liability limit
> on a per certificate basis based on their certificate class, but they don't
> refer to it in their certificate, except by incorporating by reference their CPS.
> Whether such an aggregate liability limit would hold up in court without some
> form of statutory authority is an interesting question.
>
> We are considering  including a optional Reliance Limit attribute extension
> in certificates which our CA toolkit will produce, and at present I'm thinking
> about specifying both a per transaction and per certificate liability cap or
> reasonableness indicator, denominated in a particular ISO-country currency
> (user's choice), or perhaps in troy ounces of gold. When and if we do so, we will
> post an informational RFC defining the syntax and semantics of the attribute
> (along with others we are defining) so that browser vendors and others will know
> how to display the attribute. The attribute could be Critical or non-Critical at the
> user's choice, although marking it Critical would obviously limit interoperability.
>
> Although putting such an attribute into a certificate wouldn't be particularly
> difficult, translating the input screens and the corresponding display screens
> into all of the foreign languages that Novell supports worldwide does involve
> some effort, so the question is whether such a concept is worth implementing
> on a world-wide basis.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
>
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
>
> "The most dangerous strategy is to cross a chasm in two jumps."

--
____________________________________________________________________
Oronzo Berlen                   | tel. 080.635-2112
Olivetti Ricerca                | fax. 080.635-2089
S.S. 271 Contrada la Marchesa | Email:[email-masked]
70020 Bitritto (BA)             |

Approved-By:  Russ Housley <[email-masked]>
Date:         Fri, 13 Mar 1998 00:53:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Bob:

I must disaree.  PKIX cannot provide non-repudiation.  PKIX provides
necessary stuff, but the signing application must do other things that are
beyond the scope of PKIX.  S/MIME is one such application.

Russ

At 03:22 PM 3/11/98 -0700, Bob Jueneman wrote:
>Denis,
>
>I agree with you.  (Maybe you would like a framed and notarized copy? :-)
>
>Russ,
>
>Before we relegate this problem to the S/MIME group, I'd like to
>explore the possibility of a more general solution just a bit more. Although
>it may be that the overhead, impact, yada, yada, of slightly revising the
SIGNED
>macro (or defining a new signature oid) will be too great for some
>applications, the use of a specific signature algorithm OID would allow
>that to be controlled.
>
>Ideally, of course, the API calls wouldn't even change, except for the
>OID definition. That may be a bit much to hope for, unless all of the
>information is already in the certificate or can be obtained from the
>operating system without an API call (e.g., the date/time).
>
>But I would rather revise the one or two applications now to make use
>of a common interface, rather than wait and have to revise applcations
>one at a time later on.
>
>Bob
>
>
>>>> Denis Pinkas <[email-masked]> 03/11 3:04 PM >>>
>Stephen,
>
>As Russ said, this discussion also relates to the CMS document from the
>smime wg and we should schedule a time slot in the pkix wg to talk about
>it at the LA meeting.
>
>In addition I would like to make a few comments on your two E-mails from
>yesterday.
>
>> Bob,
>>
>> I feel that the discussion of "which cert goes with this signature" is
>> overblown.  I would argue that a relying party needs to acquire a cert that
>> is valid and that contains a public key that validates the signature of the
>> signed data.
>
>This is the wrong way. The signer has to indicate which certificate must
>be used. The verifier should have no free choice.
>
>> If there is a only ine cert with a key that conforms to these
>> requirements, we're done.
>
>No. I would not like to re-open the POP discussion ... but if the
>certificate identifier of the signer is part of the signed stuff, then
>we can do "real-time" POP.
>
>> if there's more than one, then the relying party
>> has been given the opportunity to choose whichever one he wants. Many
>> applications I know of send the end user cert as part of a transaction,
>> messages, or session establishment protocol.
>
>The basic question is whether the end user cert is signed or not.
>Currently, it is not signed and this is the problem.
>
>> Thus the relying party is
>> saved the trouble of having to guess, and ambuigity is avoided.  When
>> non-repudiation is an issue, then it is important to understand the
>> implications of multuiple certification and users and CAs should behave
>> accordingly.  However, if they choose poorly and create opportunities for
>> abmiguity and possible deception, I'd back the relying party if he can
>> produce a valid cert that is plausibly associated with the user and which
>> works from a signature validation perspective.
>>
>> Steve
>
>Second E-mail:
>
>(... stuff deleted ...)
>
>> Thus, I am not persuaded that we need to preclude multiple certification of
>> a public key in PKIX, but I am in favor of including a brief warning about
>> the possible pitfalls of this practice, and a suggestion that this practice

>> be avoided for end user certs in most circumstances.
>
>I do not think this is the right way to present the problem. You seem to
>assume that the single problem has to do with the same user with two
>certificates that contain the same public key. As indicated above, in
>addition, we need to consider two different users each one with a
>certificate that contains the same public key (the POP problem).
>
>The recommendation should be, for the non-repudiation case, to make sure
>that the signature at least includes the identifier of the certificate
>(or the certificate itself). It might also include a certification path
>(ie. a sequence of certificate identifiers).
>
>Denis
>
>--
>      Denis Pinkas     Bull S.A.          mailto:[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
>

Approved-By:  "Anil R. Gangolli" <[email-masked]>
Date:         Thu, 12 Mar 1998 15:44:08 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Anil R. Gangolli" <[email-masked]>
Organization: Structured Arts Computing Corp.
Subject:      [IETF-PKIX] Comments on Malpani and PKIX OCSP drafts
To: [email-masked]

This is a multi-part message in MIME format.
--------------CD0945263BFD9E4F9EF0261A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Attached are some cursory comments on both the Malpani and
PKIX OCSP drafts.  Some additional notes pertaining only to
the Malpani draft are included at the end.

--a.

--
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:[email-masked]
--------------CD0945263BFD9E4F9EF0261A
Content-Type: text/plain; charset=us-ascii; name="ocsp-comments.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="ocsp-comments.txt"

Comments on the Malpani OCSP recommendation and PKIX OCSP

Full Validation vs. Revocation

There appears to be an implicit motivation in the PKIX OCSP
(draft-ietf-pkix-ocsp-02.txt) work that is missed by the Malpani spec.

The PKIX spec seems intended to support not only revocation checking
but full cert path validation for "thin clients" that might have only
one trust point defined and trust OCSP servers for all more general
cert path validation tasks.  I believe the PKIX OCSP spec requires
further elaboration if it is intended to support this, but the Malpani
spec doesn't provide for this at all.

Some of the wierd hacks in the PKIX OCSP may credibly be explained by
this motivation.  e.g. the avoidance of ASN.1 and the way the Cert ID
hash argument is formed by straight concatenation rather than DER
encoding a sequence.

Use of ASN.1 and/or HTTP

I expect that Malpani's revised OCSP using ASN.1 embedded within HTTP
will be a better framework for the request/response specification than
the PKIX OCSP scheme using ad hoc encodings over HTTP, but the "thin
client" issue needs to be discussed.  Is the PKIX scheme trying to
meet "thin client" requirements?  Is it succeeding?  What is the delta
between what is required in a thin client that uses certs at all and a
thin client that uses PKIX OCSP vs. Malpani OCSP?

If the current PKIX OCSP HTTP scheme is used, the URL encoding should
be brought more in line with current practice in browsers and other
HTTP clients.  Use the format of application/x-www-form-urlencoded for
attribute-value sets both in POSTed requests and all responses.
Similarly use the more common encoding conventions for GET urls, eg.
GET /ocsp/ver/1?arg1=value1&arg2=value2... in GET urls.

Validity Time

Both the current PKIX OCSP and the Malpani spec need clarification on
the interperetation of the time interval and the assertion that the
responder is making relative to these times.

First, I suggest that "producedAt" be replaced by "validAt", and it be
interpreted that way.

For example an OCSP responder may be producing a response based on a
CRL that was generated somewhat earlier.  It cannot reasonably extend
its assertion of validity beyond that of the CRL's "thisUpdate" time.

The validUntil name is also misleading.  It should, as for CRLs, be
"nextUpdate" or better "nextExpectedUpdate".

The validity assertion claimed by the response holds only at any the
"validAt" time.  In general the relying party must decide whether the
difference between its current time and the "validAt" time of response
meets its application requirements.

The time "nextExpectedUpdate" provides a hint to the relying party on
the time that new information is expected to be available from the
responder.  The responder MAY generate new information before the time
expressed in nextExpectedUpdate.  The responder SHOULD generate new
information no later than the time expressed in nextExpectedUpdate.

One might want to add:
        The relying party SHOULD NOT use a response indicating a
        certificate's validity beyond the nextExpectedUpdate time.
but one should considier that this might better be left to
application-level standards.  The only thing that may be important to
the application is the difference between current time and validAt
time, if the cost of getting updated information is too hight.  (see
related notes on Nonce below.)

Nonce

The assertion being claimed by a signed OCSP response is not changed
by replay.  So it would seem that the purpose of the nonce is not to
prevent replay attacks but rather to bind the response to a particular
request in order to allow the relying party later to claim some
sequence of events (e.g. the relying party must have done the OCSP
check specifically for transaction X, because it included hash(X) in
the nonce).

In general I believe that applications and application-level standards
should define a minimum requirement on revocation checking based on a
"maximum tolerance window" specifying the maximum allowed difference
between the current time and a revocation check on that certificate,
rather than a per-transaction check.

The nonce would be useful in situations where the application or
application-level standard requires a per-transaction check against
one of an approved set of responders.  I expect that this will prove
costly to scale up with OCSPs individually-signed responses.  This
starts becoming akin to the function of a notary.  It is not clear it
belongs in this spec, but I agree it is cheap to include.

Individual Signatures

I still have a lot of trouble believing that individually signed
responses, whether pre-computed or not will scale well for OCSP.
I think that the Malpani spec could be extended to include
alternate response mechanisms easily.

Additional Minor Notes on Malpani's spec
----------------------------------------

Here are some additional minor notes applying only to the Malpani
spec.

Computation of the hash value
        Be specific about the calculation of this value. e.g. The
        SHA-1 hash computed over the full DER encoding of the
        IssuerNameAndKey structure including identifier, length, and
        contents octets.

Response Syntax
        "The actual formatting of the message could vary..."  Insist
        on DER encoding at a minimum, or clarify that this is what you
        mean.

BasicOCSPResponse
        Switch the order of the signatureAlgorithm and ResponseData to
        conform to the convention of the X.509 SIGNED macro.

eventTime in SingleResponse
        I couldn't find a definition of this in the document.

CrlID
        CrlURL doesn't provide an adequate basis for defining a
        particular CRL.

Section 4 Reference to X.208
        DER encoding was defined originally in X.509 and updated in
        X.690.  It is not in X.208.

Section 4.4.4.4
        One needs to elaborate a bit on how the semantics of CRL entry
        extensions apply to the OCSP response.

--------------CD0945263BFD9E4F9EF0261A--

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 12 Mar 1998 16:20:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

Thanks, Marc.  The text is essentially the equivalent of the Utah text.

I'm still interested if anyone finds any others, but the next question is
whether any CA or CA toolkit is presently including such an attribute in their
certs.

Bob

Bob Jueneman <[email-masked]> scrawled:
>
> Is anyone aware of any legislation, passed or pending, which takes any legal
> recognition of a "Reliance Limit", other than the Utah Digital Signature Act?
>
> I would be particularly interested to learn of any non-US jurisdictions who m
> ight be interested in  this.
>

Last I saw it, the Washington State Electronic Authentication Act called for
reliance limits.  Surfez-vous to

        http://leginfo.leg.wa.gov/pub/rcw/title_19/chapter_034/

Reliance limits are specifically discussed in rcw_19_34_280.

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Thu, 12 Mar 1998 13:47:14 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      [IETF-PKIX] Bad signature? (was: Re: [IETF-PKIX] Reliance limits in statutes)
To: [email-masked]

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

Content-Type: text/plain; charset=us-ascii

It seems that something somewhere is mucking with my posts to this list.  In
any lines that start with one or more TAB characters, the TABs are
translated into spaces.  This, of course, invalidates my PGP signature on
the message.

Sigh.

           Marc (used spaces here this time)

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

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Thu, 12 Mar 1998 09:53:14 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

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

Content-Type: text/plain; charset=us-ascii

Bob Jueneman <[email-masked]> scrawled:
>
> Is anyone aware of any legislation, passed or pending, which takes any legal
> recognition of a "Reliance Limit", other than the Utah Digital Signature Act?
>
> I would be particularly interested to learn of any non-US jurisdictions who m
> ight be interested in  this.
>

Last I saw it, the Washington State Electronic Authentication Act called for
reliance limits.  Surfez-vous to

        http://leginfo.leg.wa.gov/pub/rcw/title_19/chapter_034/

Reliance limits are specifically discussed in rcw_19_34_280.

                Marc

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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 12 Mar 1998 09:59:20 -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] Reliance limits in statutes
Comments: To: [email-masked]
To: [email-masked]

>What a reliance limit exactly is?
>I know the Italian legislation which is going to be approved, where it seems there is nothing which
>sound like what you need.

Several people have asked "what's a reliance limit", so I guess I should
have provided a definition.

The Utah Digital Signature Act provides a means of limiting a
CA's liability (and presumably the subscriber's liability), by putting
a "Reliance Limit" in the certificate as a way of indicating the
monetary value or upper limit of a transaction that might be
considered "commercially reasonable":

"46-3-309 Recommended reliance limits and liability

(1) By specifying a recommended reliance limit in a certificate,
the issuing certification authority and the accepting subscriber
recommend that persons rely on the certificate only to the
extent that the total amount at risk does not exceed the
recommended reliance limit."

Paragraph (2) of that section goes on at some length to define
the limits of liability that would apply to a CA that is licensed under
the Utah statute, and how someone can recover from the CA in
the event someone is harmed. The Utah regulations also require
that a CA provide a "suitable guaranty" in the form of surety bond
or irrevocable letter of credit in an amount that is a percentage
of the aggregate amount of the reliance limit of all currently valid
certificates issued, in order to back up such liability limits. C.f.
http://www.commerce.state.ut.us/web/commerce/digsig/act.htm,
section 46-3-310 and 310.

There are, of course, a number of problems that could occur in
anything other than a closed loop system where the CA becomes
involved in validating every certificate -- the CA normally has no
knowledge of how many times the subscriber uses his digital
signature, and even the subscriber may have no idea how many
times even a given signature is validated, e.g., on a piece of
operating system code signed by Microsoft, or a Java applet signed
by some web server. Even if the Reliance Limit is 1 penny, the
CA's liability is potentially infinity squared in that case.

Nonetheless, even in an open loop, open PKI system, some
form of caveat or limitation on a certificate is probably better than nothing.

To date, no CA I am aware of includes a Reliance Limit attribute extension
in their certificates. VeriSign in their CPS does claim an overall liability limit
on a per certificate basis based on their certificate class, but they don't
refer to it in their certificate, except by incorporating by reference their CPS.
Whether such an aggregate liability limit would hold up in court without some
form of statutory authority is an interesting question.

We are considering  including a optional Reliance Limit attribute extension
in certificates which our CA toolkit will produce, and at present I'm thinking
about specifying both a per transaction and per certificate liability cap or
reasonableness indicator, denominated in a particular ISO-country currency
(user's choice), or perhaps in troy ounces of gold. When and if we do so, we will
post an informational RFC defining the syntax and semantics of the attribute
(along with others we are defining) so that browser vendors and others will know
how to display the attribute. The attribute could be Critical or non-Critical at the
user's choice, although marking it Critical would obviously limit interoperability.

Although putting such an attribute into a certificate wouldn't be particularly
difficult, translating the input screens and the corresponding display screens
into all of the foreign languages that Novell supports worldwide does involve
some effort, so the question is whether such a concept is worth implementing
on a world-wide basis.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  [email-masked]
Date:         Thu, 12 Mar 1998 09:06:17 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Lynn Wheeler <[email-masked]>
Subject:      Re: [IETF-PKIX] Fwd: Re: [IETF-PKIX] Multiple Certificates (resend)
To: [email-masked]

... this is resend ..our corporate gateway switched to full first/last
mapping ... my nominal subscription
was under my firstname ... which doesn't come thru anymore & I've had to
resubscribe.

To:   [email-masked]
cc:   [email-masked], [email-masked],
      [email-masked], [email-masked]

re: gold & green card certificates;
note that the financial transanction includes the account number ... and
the digital signature signs the transaction (including the data element
that is the account number). The account number is the entity that
selects the card ... not the certificate. The certificate is
(theoritically) used to validate the signature (on the transaction); not to
select the identity.
the credit card flow for x9.59 transactions might make it a little clearer:
http://lists.commerce.net/lists/open/ansi-epay/msg00139.html
also see the rest of the discussion on account vis-a-vis certificate
validation of digital signatures at:
           http://www.garlic.com/~lynn/
In the set world ... since the account number can't be disclosed in the
certificate ... and the account number wouldn't be carried in the
transaction in the clear ... there is no way the merchant can determine
whether a particular certificate is in any way related to a specific
account. The best that can be determined is that the CA issuing the
certificate (pushed along with the transaction) had authenticated
something. Whatever that the authenticated something (by the CA) ... might
be useful in tracking back to a specific entity ... if after the fact,
somebody discovered that the (cloaked) account number (in the transaction)
was used incorrectly.
In x9.59 ... the transaction digital signature is authenticated at the
consumer's financial institution ... not with a public key registered in a
certificate ... but a public key registered in the consumer's account
record. It is somewhat clearer in X9.59 ... that a consumer's public key
might be registered in more than one place (account records &/or
certificates) ... but the number of places that a public key is registered
... is orthogonal to the transaction contents that have been signed with
that public key.

Also, in x9.59, since the account number doesn't have to be hidden, it
is in clear in the transaction ... and can optionally be included in a
certificate issued by a consumer's financial institution (at the time the
consumer's public key is registered). This opens the opportunity for
the merchant doing some prescreening on transaction by crosschecking
the account number specified in the transaction with one that might be
carried in a signed certificate from a financial institution.
In this scenerio, it is even more clear that even if the same public key is
carried in one hundred different certificates ... if the specific
certificate associated with the specific account number listed in the
transaction ... wasn't pushed along with the transaction ... the
transaction has high probability of being rejected (even if the digital
signature was validated by a merchant prescreening operation).

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 12 Mar 1998 09:24:02 -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] Cryptographic binding of certificates tosignatures
Comments: To: [email-masked]
To: [email-masked]

Lars, I appreciate your "European" hard-token perspective.
Certainly, how the keys are generated and how they are
incorporated into certificates can substantially change the risks.

Just to clarify one thing however. Although I mentioned the
possibility of changing the SIGNED macro, it was only to
highlight the original source of the problem. I realize that changing
the basic definition at this time is probably not a viable
possibility.

However, my final recommendation and conclusion was that we
consider creating a new set of signature algorithm IDs that would
end up using RSA, DSA, etc., but would also include additional
information such as the issuerName and serial number, or perhaps
just a hash of the certificate, so that the certificate to be used
is irrevocably tied to the signed text.

I also mention the desirability of including some additional information
such as date/time and possibly the identity of the platform on which
the signature was applied, for audit purposes.

(You might be particularly interested in the later, from your hard-token
perspective. Assuming that the token only generates the signature, and
maybe the message digest that goes into it, the token has no way of
knowing what the user saw on the screen that was supposed to be
signed, as opposed to what the application actually presented to be signed.
Unless the token is limited to only signing once per insertion, a rogue
merchant could cause the token to sign all sorts of things, while the
user thinks that she is only buying a dishrag. Including an authenticated
identification of the platform would help point a smoking gun in such cases.)

Other people may have their own pet ideas which should be considered.
For example, I foresee a time in the relatively near future where biometrics will
be combined with digital signatures to circumvent some of the control issues
that neither a password encrypted key nor a smart token solve, since either can
be given away.  It would no doubt be very useful to incorporate the biometric
indicia into the signature itself, so that it would later be validated against
the biometric template included in the certificate. Without supporting such a
basic mechanism now, while the industry is still in the process of writing lots of
new applications, adding such features would require modifications to a very large
number of individual applications -- an almost hopeless task.

But I'm not trying at this time to suggest precisely what ancillary information
should be included. We are still trying to sort out whether it should be
done at all. Of course, even if a new signature algorithm ID is
defined, it doesn't have to be used, so it would be optional from that
standpoint. For the sake of interoperability, however, it would be a new
algorithm that would have to be widely supported, unless we can figure
out a mechanism for making the additional parameters transparent.

I do believe that specifying the suite of signature algorithms that are to be
supported is one of the functions of this group, so I believe the discussion is
appropriate for this list.

Bob>
>
>
>>>> <[email-masked]> 03/12 1:56 AM >>>
>All,
>
>In order to deal with the situation that a key-holder have
>multiple certificates and signs a message without giving any
>reference to which certificate should be used by the relying
>party when verifying the signature, Bob have proposed a
>redefinition of the ASN.1 signature macro.
>
>I think that this is a particularly bad idea...
>
>I agree that it should be recommended to clearly state under
>which role/certificate one signs something. But that is the
>responsibility of the signer and not of the CA. Also, stipulations
>of this kind is, IMHO, an application-level issue, not part of the
>PKI (and outside of this WG's charter). It may even be unnecessary.
>
>Suppose that Mr. X have two certificates (of the same key)
>for his two roles: as a private person and as an employee of
>a big company. Now this Mr. X signs a contract for that big
>company (as being an employee) but forgets to state in the
>signature which certificate that should be used to verify the
>signature. If that contract is bad business for the big company,
>then it may want to try to claim that it was signed by the private
>person X, not by the employee.
>
>It's clear that it can't be proved (cryptographicly) in court
>which certificate that is the correct one. But remember that
>it's as hard for the opponent, the big company, to prove that
>it was the private person X that signed the contract as it is
>for Mr. X to prove that it was him as an employee. In the worst
>case, the signature (and contract) could be judged as being
>unresolved (which may be bad enough though).
>
>I think this shows that when dealing with valuable signatures,
>such as contracts, it is in both parties (the key holder and the
>relying party) interest to clearly state which certificate that should
>be used. Even if the certificate isn't contained in the message to
>be signed due to flaws in the application design it could be the
>signers' responsibility to include it anyway (e.g. as a signed
>attachment).
>
>Regards,
>/Lars Johansson
>Sweden Post

Approved-By:  "Phillip M. Hallam-Baker" <[email-masked]>
Date:         Thu, 12 Mar 1998 10:43:19 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

>Sorry for this late reaction but it's been quite a task
>just to read all the contributions to this thread. I think
>the discussion so far have been very biased to, let me say,
>the "American soft-token" perspective. So, being a native
>European, let me improve that situation slightly.

I am also a European. I have not noticed a bias towards
soft certificates.

VeriSign certificates can be loaded onto a smartcard
(Gemplus or Schlumberger), I have a card and reader
myself. As a practical matter however smartcards
and readers are not yet ubiquitous.

The ambiguity problem is considerably worse with a smart
card than a soft certificate. The one declarative action that
is possible with the chip in card format is to insert the device
into a reader. Any variation in semantics must be captured
by the terminal - which cannot be considered as secure as
the card itself.

On the other hand I don't think we should wire any prohibition
on dual certification of keys into the standard, the practical
reason being that such a prohibition could not be enforced.
People are bound to do it whether or not it is a good idea.
Therefore it would not be a good thing for clients to rely on
it not taking place.

If there is not going to be an impact on the specififcation we
do not need to discuss it.

        Phill

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Thu, 12 Mar 1998 10:32:26 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

Rich;

>----------
>From:  Rich Ankney[SMTP:[email-masked]]
>Sent:  Wednesday, March 11, 1998 12:42 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] New Notary Protocol Draft
>
>----------
>> From: Robert Zuccherato <[email-masked]>
>> To: [email-masked]'; [email-masked]'
>> Subject: RE: [IETF-PKIX] New Notary Protocol Draft
>> Date: Wednesday, March 11, 1998 9:55 AM
>>
>> Rich;
>>
>> Thanks for your comments.  My responses are below.
>>
>> >----------
>> >From:        Rich Ankney[SMTP:[email-masked]]
>> >Sent:        Tuesday, March 10, 1998 1:16 PM
>> >To:  Robert Zuccherato; [email-masked]
>> >Subject:     Re: [IETF-PKIX] New Notary Protocol Draft
>> >
>> >
>> >2.  Is it possible to verify multiple signatures in the "ns" case?  I'm
>> >thinking of the case where I send a message of type (CMS) signedData
>> >which has multiple signerInfos attached.
>>
>> This is something I hadn't thought about before.  I don't know if I
>> really see the utility of allowing this (presently only one signature is
>> allowed).  Do you have a particular application in mind.
>
>I was thinking of ANSI X9.45 and related standards in the healthcare
>arena that use PKCS #7 (now CMS) SignedData with multiple
>signatures quite extensively.  Granted, the most common case of
>SignedData has just one SignerInfo, but I see no reason to preclude
>the case where multiple SignerInfo's are present.

Okay, fair enough.  I think we can allow multiple signers.
>
>> >
>> >3.  The relationship between request type, SignedData, and the embedded
>> >data is a little murky.
>>
>> Yeah, the idea behind separating the two services was to allow one to
>> get someone else's signature notarized (use the embedded data), but also
>> to give a format for the requester to have just their possession of the
>> data notarized, and to combine the services.  Any other thoughts on this
>> would be appreciated.
>>
>
>I like the idea of separating the two services.  I just think the text
>could
>be a little clearer.  Having complained, I'll of course draft some text to
>(hopefully) make things clearer.

Thanks.
>
>> >6.  Should the notary be able to do full path validation per X.509 v3
>> >(and PKIX-1)?  I.e. should the requester be able to pass the initial
>> >policy set and other stuff to the notary, and receive the policy
>> >qualifiers etc. back?
>>
>> Yes, that is what we are trying to accomplish here.  If we are missing
>> anything from the protocol that would allow this to happen, let me know.
>
>I'll take a look at the X.509/PKIX path processing algorithm and see
>what additional inputs/outputs are needed.  Question:  is the policy in
>the NotaryRequest and NotaryResponse supposed to identify a
>certificate policy?  It's not clear from the current text.

Presently the document says that the policy should indicate either the
policy under which the notarization is requested or the policy for which
the certificate validity is to be reported.  I could imagine actually
having two policy fields in the request and response, one for the
notarization policy and one for the certificate policy, if people
thought that would be useful.

        Robert.
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 12 Mar 1998 09:05:32 -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] Multiple certificates for same key?
To: [email-masked]

> From: [email-masked]
>
> Some people have argued that there's too many security risks
> involved when dealing with multiple certificates of the same
> key that it should be prohibited (or at least not recommended :-).
> I could give you many reasons why there shouldn't be any such
> restrictions but let me just give you an alternative perspective.

Please list some reasons for preferring multiple certificates per
key - that is one of the critical items of information missing from
the discussion so far.

What precisely are the three or four most important advantages of
multiple certification of keys?  Saving memory on tokens has already
been mentioned.

> In my point of view, multiple certificates of the same public key
> is not the problem. I think this is entirely a policy issue. The
> problem is instead storing of the private keys in software.
>
> In the Swedish electronic ID-card project (www.seis.se) the
> private keys are centrally generated by the CA and stored in
> the key-holders smart card. The RSA operations are performed
> on the chip so the private key never leaves the card. It is even
> unknown to the key-holder. This is of course stated in the CA's
> policy and CPS.

Private key storage mechanisms and multiple certificates are
separate issues.  When you have one security weakness (software
key storage) it tends to exacerbate security problems in other
areas (multiple certification).  But saying (or requiring) keys
to always be stored on tokens does not make the other problems
go away.  Sure, the private key(s) cannot be extracted from the
token without perhaps destructive reverse engineering.  But the
token can still be used by malicious applications to sign things
the user didn't intend to have signed.  The only way to prevent
that is to allow segregation of keys by purpose, and not store
the sensitive keys on tokens that will be highly exposed.

Approved-By:  Dan Geer <[email-masked]>
Date:         Thu, 12 Mar 1998 09:03:37 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dan Geer <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
To: [email-masked]

Q:
"What is a PKI?"

A:
This being a world of competition and/or
marketectures, I'd imagine that for practical
purposes Lewis Carroll had it right:
  forall(I) "A word means what I choose it to mean"

If that sounds flip, one could say that just
as the final word in software documentation is
the source so, in like manner, the final word
in PKI definition will be precisely what finally
works well enough for someone important to
actually base a mission critical business on.
We are not there yet.

Were it not for electronic commerce, a PKI would
be of mere academic interest.  Investments in
EC are made to make money, largely on the cost
reduction side of the ledger (which is the easiest
money to make).  Since there is no commerce without
contract, no contract without recourse, no recourse
without evidence, no evidence without signature,
and no signature without PKI, it looks like EC
is Applied PKI to me.  The rest is just bits.

--dan

>From: Oronzo Berlen <[email-masked]>
Approved-By:  [email-masked]
Date:         Thu, 12 Mar 1998 11:25:40 +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]
Organization: Olivetti Ricerca SCpA
Subject:      Re: [IETF-PKIX] Reliance limits in statutes
To: [email-masked]

What a reliance limit exactly is?
I know the italian legislation which is giong to be approved, where it seems there is nothig which sound like what you need.

Anyway there is a good description of international laws about digital signature and related matters at:
http://www.qmw.ac.uk/~tl6345/index.htm

Bob Jueneman wrote:

> Is anyone aware of any legislation, passed or pending, which takes any legal recognition of a "Reliance Limit", other than the Utah Digital Signature Act?
>
> I would be particularly interested to learn of any non-US jurisdictions who might be interested in  this.
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Products Group
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> [email-masked]
>
> "If you are trying to get to the moon, climbing a tree,
> although a step in the right direction, will not prove
> to be very helpful."
>
> "The most dangerous strategy is to cross a chasm in two jumps."

--
____________________________________________________________________
Oronzo Berlen                   | tel. 080.635-2112
Olivetti Ricerca                | fax. 080.635-2089
S.S. 271 Contrada la Marchesa | Email:[email-masked]
70020 Bitritto (BA)             |

Approved-By:  [email-masked]
Date:         Thu, 12 Mar 1998 09:56:38 +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] Cryptographic binding of certificates to signatures
To: [email-masked]

All,

In order to deal with the situation that a key-holder have
multiple certificates and signs a message without giving any
reference to which certificate should be used by the relying
party when verifying the signature, Bob have proposed a
redefinition of the ASN.1 signature macro.

I think that this is a particularly bad idea...

I agree that it should be recommended to clearly state under
which role/certificate one signs something. But that is the
responsibility of the signer and not of the CA. Also, stipulations
of this kind is, IMHO, an application-level issue, not part of the
PKI (and outside of this WG's charter). It may even be unnecessary.

Suppose that Mr. X have two certificates (of the same key)
for his two roles: as a private person and as an employee of
a big company. Now this Mr. X signs a contract for that big
company (as being an employee) but forgets to state in the
signature which certificate that should be used to verify the
signature. If that contract is bad business for the big company,
then it may want to try to claim that it was signed by the private
person X, not by the employee.

It's clear that it can't be proved (cryptographicly) in court
which certificate that is the correct one. But remember that
it's as hard for the opponent, the big company, to prove that
it was the private person X that signed the contract as it is
for Mr. X to prove that it was him as an employee. In the worst
case, the signature (and contract) could be judged as being
unresolved (which may be bad enough though).

I think this shows that when dealing with valuable signatures,
such as contracts, it is in both parties (the key holder and the
relying party) interest to clearly state which certificate that should
be used. Even if the certificate isn't contained in the message to
be signed due to flaws in the application design it could be the
signers' responsibility to include it anyway (e.g. as a signed
attachment).

Regards,
/Lars Johansson
Sweden Post

Approved-By:  [email-masked]
Date:         Thu, 12 Mar 1998 09:38:13 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Sorry for this late reaction but it's been quite a task
just to read all the contributions to this thread. I think
the discussion so far have been very biased to, let me say,
the "American soft-token" perspective. So, being a native
European, let me improve that situation slightly.

(I've noted that this thread actually has been split up in two.
Therefore I'll respond to the issue of "cryptographic binding
of certificates to signatures" in a separate mail.)

Some people have argued that there's too many security risks
involved when dealing with multiple certificates of the same
key that it should be prohibited (or at least not recommended :-).
I could give you many reasons why there shouldn't be any such
restrictions but let me just give you an alternative perspective.

In my point of view, multiple certificates of the same public key
is not the problem. I think this is entirely a policy issue. The
problem is instead storing of the private keys in software.

In the Swedish electronic ID-card project (www.seis.se) the
private keys are centrally generated by the CA and stored in
the key-holders smart card. The RSA operations are performed
on the chip so the private key never leaves the card. It is even
unknown to the key-holder. This is of course stated in the CA's
policy and CPS.

Now, if another CA would issue an alternative certificate to the
same key-holder and the same key (e.g. containing a different
email-address) this wouldn't normally cause any problems.

Either the other CA could require the key-holder to present his
"base" certificate in the certificate request before a new certificate
could be issued. In that case, the 2nd CA could check the original
CA's policy and CPS to see how the key was generated. It would
also be a way of prohibiting the key-holder from getting a certificate
in another persons name.

Or, in the other case, the 2nd CA doesn't do any such checking
against any base certificate in which case the relying party could
chose not to trust that CA's policy. Identification of key-holders and
key generation is perhaps the two most important issues within a
policy or CPS document.

What's needed is an option of sending an older certificate within a
certificate request to the CA.

Obviously, things gets more complicated when dealing with soft
tokens. That’s why we've chose not to do that (primarily) in the
Swedish SEIS project.

Kind regards,
/Lars Johansson
Sweden Post

Approved-By:  "Anil R. Gangolli" <[email-masked]>
Date:         Wed, 11 Mar 1998 16:29:58 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Anil R. Gangolli" <[email-masked]>
Organization: Structured Arts Computing Corp.
Subject:      Re: [IETF-PKIX] PKIX questions (DH key and Key Identifier)
To: [email-masked]

> 2. My other question is partly related to the above discussion, but
> regarding the algorithm for calculation of key identifier extensions.
> Ipki-part1 describes only in one place the way of calculating the value of
> key identifier. It is in section 4.2.1.2:
>
>    "The subject key identifier extension provides a means of identifying
>    the particular public key used in an application.  Where a reference
>    to a public key identifier is needed (as with an Authority Key
>    Identifier) and one is not included in the associated certificate, a
>    SHA-1 hash of the subject public key shall be used.  The hash shall
>    be calculated over the value (excluding tag and length) of the
>    subject public key field in the certificate.  This extension should
>    be marked non-critical."

Unfortunately "subject public key field" here is ambiguous.  I think this should
be clarified.  The implementations I know of that already do this use the
hash over the DER encoding of the whole SubjectPublicKeyInfo.  I think this is
the best interpretation as it includes the algorithm info as well as the key
in the hash.

--a.

--
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:[email-masked]

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 11 Mar 1998 15:50:41 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
To: [email-masked]

Given the understanding that "mechanically verified signed data" implies both

(a) "data was held and signed by keyholder" and
(b) "data has not been altered between point-of-signing and point-of-verify,"

I would define a PKI as:

  "a collection of protocols and procedures supporting broad automation in
  the assurance that the given keyholder possesses the (identity, authority,
  or attributes) to so vouch for or represent the data submitted in a given
  transaction."

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 11 Mar 1998 15:28:09 -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] Reliance limits in statutes
To: [email-masked]

Is anyone aware of any legislation, passed or pending, which takes any legal recognition of a "Reliance Limit", other than the Utah Digital Signature Act?

I would be particularly interested to learn of any non-US jurisdictions who might be interested in  this.

Bob

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 11 Mar 1998 15:22:02 -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] Multiple certificates for same key?
Comments: To: [email-masked], Russ Housley <[email-masked]>
To: [email-masked]

Denis,

I agree with you.  (Maybe you would like a framed and notarized copy? :-)

Russ,

Before we relegate this problem to the S/MIME group, I'd like to
explore the possibility of a more general solution just a bit more. Although
it may be that the overhead, impact, yada, yada, of slightly revising the SIGNED
macro (or defining a new signature oid) will be too great for some
applications, the use of a specific signature algorithm OID would allow
that to be controlled.

Ideally, of course, the API calls wouldn't even change, except for the
OID definition. That may be a bit much to hope for, unless all of the
information is already in the certificate or can be obtained from the
operating system without an API call (e.g., the date/time).

But I would rather revise the one or two applications now to make use
of a common interface, rather than wait and have to revise applcations
one at a time later on.

Bob

>>> Denis Pinkas <[email-masked]> 03/11 3:04 PM >>>
Stephen,

As Russ said, this discussion also relates to the CMS document from the
smime wg and we should schedule a time slot in the pkix wg to talk about
it at the LA meeting.

In addition I would like to make a few comments on your two E-mails from
yesterday.

> Bob,
>
> I feel that the discussion of "which cert goes with this signature" is
> overblown.  I would argue that a relying party needs to acquire a cert that
> is valid and that contains a public key that validates the signature of the
> signed data.

This is the wrong way. The signer has to indicate which certificate must
be used. The verifier should have no free choice.

> If there is a only ine cert with a key that conforms to these
> requirements, we're done.

No. I would not like to re-open the POP discussion ... but if the
certificate identifier of the signer is part of the signed stuff, then
we can do "real-time" POP.

> if there's more than one, then the relying party
> has been given the opportunity to choose whichever one he wants. Many
> applications I know of send the end user cert as part of a transaction,
> messages, or session establishment protocol.

The basic question is whether the end user cert is signed or not.
Currently, it is not signed and this is the problem.

> Thus the relying party is
> saved the trouble of having to guess, and ambuigity is avoided.  When
> non-repudiation is an issue, then it is important to understand the
> implications of multuiple certification and users and CAs should behave
> accordingly.  However, if they choose poorly and create opportunities for
> abmiguity and possible deception, I'd back the relying party if he can
> produce a valid cert that is plausibly associated with the user and which
> works from a signature validation perspective.
>
> Steve

Second E-mail:

(... stuff deleted ...)

> Thus, I am not persuaded that we need to preclude multiple certification of
> a public key in PKIX, but I am in favor of including a brief warning about
> the possible pitfalls of this practice, and a suggestion that this practice
> be avoided for end user certs in most circumstances.

I do not think this is the right way to present the problem. You seem to
assume that the single problem has to do with the same user with two
certificates that contain the same public key. As indicated above, in
addition, we need to consider two different users each one with a
certificate that contains the same public key (the POP problem).

The recommendation should be, for the non-repudiation case, to make sure
that the signature at least includes the identifier of the certificate
(or the certificate itself). It might also include a certification path
(ie. a sequence of certificate identifiers).

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  John Hughes <[email-masked]>
Date:         Wed, 11 Mar 1998 22:21:14 +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: John Hughes <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
To: [email-masked]

I have also, at a more detailed level, in an abstract way, defined it
as:

THE AUTHENTICATION FRAMEWORK:  the infrastructure used to provide
authentication services, such as digital signatures.

THE CONFIDENTIALITY FRAMEWORK:  the framework used to enable two
communicating entities to share a secret key for the purpose of
encrypting/decrypting data.

KEY GENERATION:  how and where the keys are generated:  public/private
key pair for signatures,  public/private pair for symmetric key
distribution and symmetric keys for encryption.

MECHANISMS:  the algorithms used to provide a number of the services.

PROTOCOLS:  the protocols used between entities to transfer information.

However one could also define it according to the PKI management entities
described in Part III - but the Part III definition does not touch upon
the above.

John

At 13:03 11/03/98 -0800, you wrote:

>>>>

<excerpt>I have a definition:

<paraindent><param>left,out</param><italic>A framework that mediates the
transfer of all and only the

information to all and only the participants in a transaction.

</italic></paraindent>

Unfortunately, most approaches to PKI don't meet this deceptively
simple

definition, which I admittedly created to emphasize this inability ;)

It's been argued that a framework able to accomplish the above goes

beyond the requirements of a PKI.  I'm still wrestling with that, but

point out that the Xcert approach to on-line validation meets the above

definition while remaining compliant with the standards in existence.

A less ambitious definition might be:

<paraindent><param>left</param><italic>A system for maintaining the
privacy of private keys and the

publicity of public keys in a public key cryptosystem.

</italic></paraindent>

At least, fewer arguments will result from the latter definition ;)

Andrew

At 20:22 3/11/98 +0000, John Hughes wrote:

>>>>

<excerpt>I know this is a strange question, but

<paraindent><param>left</param>"What is a PKI?

</paraindent>This question was sparked off by some e-mail exchanges with
my ex-Bull colleague Denis Pinkas.  Denis got me thinking and I looked
through a number of papers/books/documents and I could not find a
definition - at least not a succinct one (which was in the order of 1/2
page to 1 page).

I have been involved with PKI "many" years (including, as may of you will
know, with the SOS TDP) and also having issued to the list some months
ago (as part of the SOS TDP project) an overview/intro on PKIX - I have
to admit I've never had recourse to define what is a PKI.

Does any one have anything - or is it too difficult to define in more
than a few sentences and less than half a book.  And more importantly can
we agree on the definition!

John

<paraindent><param>left</param>

</paraindent>

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

| John Hughes             [email-masked]                 |

| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |

|                         Main Office Tel:       +44(0)181 876 8666 |

| www.entegrity.com       Mobile:                +44(0)468 055070   |

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

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

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

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

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

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

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

| John Hughes             [email-masked]                 |

| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |

|                         Main Office Tel:       +44(0)181 876 8666 |

| www.entegrity.com       Mobile:                +44(0)468 055070   |

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

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 11 Mar 1998 15:09: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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
Comments: To: [email-masked]
To: [email-masked]

Andrew, your message comes though in a very awkward format -- no message body, but a part.000 attachment that contains the message in HTML (it appears).  I've have to click on the message to access it, and then it is difficult to read once netwcape comes up to interpret the html.

Could you see if you can train Eudora to send non-MIME message if the abilities are MIME aren't really needed?

bob

>>> Andrew Csinger <[email-masked]> 03/11 2:03 PM >>>

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 11 Mar 1998 14:14:27 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Fwd: Re: [IETF-PKIX] Multiple Certificates
Comments: To: [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

Thanks, Brian. That's in accord with my recollection, but I wasn't sure.

With regard to Tony's Green card/Gold card scenario, I understood
that to be more or an illustrative example or metaphor than an actual
attack against SET or whatever.  He was merely pointing out
an easily understood (if not technically accurate) scenario whereby
either the originator or the recipient of a transaction might have some
reason to misattribute a given transaction against a set of credentials.

One could conceivably come up with something similar involving the use of
a woman's married name (Mrs. John Smith) vs. personal name (Susy Smith),
perhaps involving liability for debts in a messy divorce. Again, it is the
example rather than letter of the law that is moe important here.

Bob

>>> Brian Korver <[email-masked]> 03/11 11:49 AM >>>
Bob Jueneman writes:
> +----------------------------------------------------------------------+
> This message was addressed to:  [email-masked]
> +----------------------------------------------------------------------+
> The following message was posted in a discussion on the IETF-PKIX list, in =
> connection with an ongoing discussion of the desirability of allowing/depre=
> cating the issuance of multiple certificates containing a common public =
> key.
>
> To what extent does SET uniquely identify the certificate that is supposed =
> to be used to validate a digital signature? I.e., is the certificate =
> cryptographically bound to the transaction, or could a different certificat=
> e be substituted?

Bob,

The certificate is not always cryptographically bound to a transaction.
BTW, SET states no opinion about whether a given public key can appear in
multiple certificates.  My guess is that this will occur.

For computing a signature across data, SET uses PKCS#7 SignedData, which
uses IssuerAndSerialNumber to uniquely identify the certificate that
contains the public key portion of the keypair that generated the
signature.  Neither the signature nor the IssuerAndSerialNumber contained
in a raw (unencrypted) PKCS#7 SignedData are cryptographically protected
against substitution.  That is, for raw SignedData, an attacker is free to
change the IssuerAndSerialNumber, or to take the inner content and
re-compute a different SignedData message.  If SET had wanted to
cryptographically bind the signature to a certificate using a general
mechanism, it would have been possible to put IssuerAndSerialNumber
(or some other unique identifier) into the AuthenticatedAttributes.
These attributes are contained in the signature.

As for attacks described by Tony....  The cardholder chooses which
credit card (and therefore brand) to use for a transaction.  So it
isn't very interesting that the cardholder can substitute a different
credit card for the one that he/she initially used.

Conversely, the merchant cannot alter the signature because the
signature (the SignedData) is encrypted for the bank.  The merchant merely
passes the encrypted blob ("payment instructions" in SET lingo) on
to the bank.

As for the bank, even if the cardholder has the same keypair for both
brand X and brand Y, the bank cannot switch brands on the transaction.  The
credit card for brand X has different credit card number from the card for
Brand Y.  The credit card number is cryptographically protected by
the signature (at least for signed transactions).  Of course, if you are
this paranoid about the banks, then you probably should be using credit
cards.

> I certainly don't remember any such binding while I was working on the =
> spec in the early days, but things might have changed since. Does SET use =
> the standard X.509 SIGNED macro definition?

SET only uses the X.509 SIGNED macro for keying material.  All "data"
signatures use PKCS#7 SignedData (which, as I mentioned above, doesn't
cryptographically bind the signature to a certificate either).

Approved-By:  Andrew Csinger <[email-masked]>
Date:         Wed, 11 Mar 1998 13:03:08 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Andrew Csinger <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
To: [email-masked]

I have a definition:

<paraindent><param>left,out</param><italic>A framework that mediates the
transfer of all and only the

information to all and only the participants in a transaction.

</italic></paraindent>

Unfortunately, most approaches to PKI don't meet this deceptively
simple

definition, which I admittedly created to emphasize this inability ;)

It's been argued that a framework able to accomplish the above goes

beyond the requirements of a PKI.  I'm still wrestling with that, but

point out that the Xcert approach to on-line validation meets the above

definition while remaining compliant with the standards in existence.

A less ambitious definition might be:

<paraindent><param>left</param><italic>A system for maintaining the
privacy of private keys and the

publicity of public keys in a public key cryptosystem.

</italic></paraindent>

At least, fewer arguments will result from the latter definition ;)

Andrew

At 20:22 3/11/98 +0000, John Hughes wrote:

>>>>

<excerpt>I know this is a strange question, but

<paraindent><param>left</param>"What is a PKI?

</paraindent>This question was sparked off by some e-mail exchanges with
my ex-Bull colleague Denis Pinkas.  Denis got me thinking and I looked
through a number of papers/books/documents and I could not find a
definition - at least not a succinct one (which was in the order of 1/2
page to 1 page).

I have been involved with PKI "many" years (including, as may of you will
know, with the SOS TDP) and also having issued to the list some months
ago (as part of the SOS TDP project) an overview/intro on PKIX - I have
to admit I've never had recourse to define what is a PKI.

Does any one have anything - or is it too difficult to define in more
than a few sentences and less than half a book.  And more importantly can
we agree on the definition!

John

<paraindent><param>left</param>

</paraindent>

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

| John Hughes             [email-masked]                 |

| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |

|                         Main Office Tel:       +44(0)181 876 8666 |

| www.entegrity.com       Mobile:                +44(0)468 055070   |

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

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

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

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

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

Approved-By:  Peter Whittaker <[email-masked]>
Date:         Wed, 11 Mar 1998 15:44: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: Peter Whittaker <[email-masked]>
Subject:      Re: [IETF-PKIX] What is a PKI
To: [email-masked]

>From:  John Hughes[SMTP:[email-masked]]
>I know this is a strange question, but

>       "What is a PKI?
>
>This question was sparked off by some e-mail exchanges with
>my ex-Bull colleague Denis Pinkas.  Denis got me thinking and I looked
>through a number of papers/books/documents and I could not find a
>definition - at least not a succinct one (which was in the order of 1/2
>page to 1 page).
>
>I have been involved with PKI "many" years (including, as may of you will
>know, with the SOS TDP) and also having issued to the list some months
>ago (as part of the SOS TDP project) an overview/intro on PKIX - I have
>to admit I've never had recourse to define what is a PKI.
>
>Does any one have anything - or is it too difficult to define in more
>than a few sentences and less than half a book.  And more importantly can
>we agree on the definition!

The paper available at

        http://www.entrust.com/resources/pdf/pki.pdf

may be of interest.

pww

>

Approved-By:  John Hughes <[email-masked]>
Date:         Wed, 11 Mar 1998 20:22:18 +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: John Hughes <[email-masked]>
Subject:      [IETF-PKIX] What is a PKI
To: [email-masked]

I know this is a strange question, but

<paraindent><param>left</param>"What is a PKI?

</paraindent>This question was sparked off by some e-mail exchanges with
my ex-Bull colleague Denis Pinkas.  Denis got me thinking and I looked
through a number of papers/books/documents and I could not find a
definition - at least not a succinct one (which was in the order of 1/2
page to 1 page).

I have been involved with PKI "many" years (including, as may of you will
know, with the SOS TDP) and also having issued to the list some months
ago (as part of the SOS TDP project) an overview/intro on PKIX - I have
to admit I've never had recourse to define what is a PKI.

Does any one have anything - or is it too difficult to define in more
than a few sentences and less than half a book.  And more importantly can
we agree on the definition!

John

<paraindent><param>left</param>

</paraindent>

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

| John Hughes             [email-masked]                 |

| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |

|                         Main Office Tel:       +44(0)181 876 8666 |

| www.entegrity.com       Mobile:                +44(0)468 055070   |

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

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Wed, 11 Mar 1998 09:55:07 -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] New Notary Protocol Draft
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

Rich;

Thanks for your comments.  My responses are below.

>----------
>From:  Rich Ankney[SMTP:[email-masked]]
>Sent:  Tuesday, March 10, 1998 1:16 PM
>To:    Robert Zuccherato; [email-masked]
>Subject:       Re: [IETF-PKIX] New Notary Protocol Draft
>
>1.  Could we add an extension capability to the request and response?

Yes, we certainly could.  Would something like the "extensions" field in
v3 certificates be what you are looking for?  That can easily be added.

I don't know if we need to define any specific extensions in this
document, we could just let people define their own.  Any thoughts?
>
>2.  Is it possible to verify multiple signatures in the "ns" case?  I'm
>thinking of the case where I send a message of type (CMS) signedData
>which has multiple signerInfos attached.

This is something I hadn't thought about before.  I don't know if I
really see the utility of allowing this (presently only one signature is
allowed).  Do you have a particular application in mind.
>
>3.  The relationship between request type, SignedData, and the embedded
>data is a little murky.

Yeah, the idea behind separating the two services was to allow one to
get someone else's signature notarized (use the embedded data), but also
to give a format for the requester to have just their possession of the
data notarized, and to combine the services.  Any other thoughts on this
would be appreciated.

>I interpret it as the following:
>
>   a)  All requests and responses are contained in SignedData.
>   For the ns and nc cases, this need not actually contain a
>   signature (SignerInfo); for npd and responses, it must contain
>   one SignerInfo.

Correct.
>
>   b)  For npd, the data must be of type "message".  For ns, the data
>   may be "message" or "messageImprint".  For nc, the data is "cert".

Not quite.  For npd, the data could be either "message",
"messageImprint" or "cert".  For this service the Notary Authority
doesn't examine the data, so it can be anything.  This service just
provides evidence that the requester possessed the data (and the
signature key) at that time.  The use of "messageImprint" allows this
evidence to be produced for private data.  The utility of using "cert"
in this situation is dubious, but it isn't disallowed.

Also, for ns the data must be of type "message".  For this service the
signature is contained in the "message", so it is not possible to use
"messageImprint"
>
>4.  It might be good to mention some useful formats in the Message
>structure, such as id-data and id-signedData.

Certainly.  Are there any others that should be included.
>
>5.  Since I may have multiple signatures on a message, can the "cert"
>option be extended to request status on multiple (signer) certificates?
>E.g. something like:
>
>       SEQUENCE {
>               targets         SEQUENCE OF Certificate,
>               chains          SEQUENCE OF Certificate }
>
>where targets are what I want status for, and chains contains the
>certificates needed to build the paths from targets to a trusted root.

That is a very good idea.  Yes, it can.
>
>6.  Should the notary be able to do full path validation per X.509 v3
>(and PKIX-1)?  I.e. should the requester be able to pass the initial
>policy set and other stuff to the notary, and receive the policy
>qualifiers etc. back?

Yes, that is what we are trying to accomplish here.  If we are missing
anything from the protocol that would allow this to happen, let me know.

        Robert.
>

Approved-By:  Rich Ankney <[email-masked]>
Date:         Wed, 11 Mar 1998 12:42:44 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
Comments: To: Robert Zuccherato <[email-masked]>
To: [email-masked]

----------
> From: Robert Zuccherato <[email-masked]>
> To: [email-masked]'; [email-masked]'
> Subject: RE: [IETF-PKIX] New Notary Protocol Draft
> Date: Wednesday, March 11, 1998 9:55 AM
>
> Rich;
>
> Thanks for your comments.  My responses are below.
>
> >----------
> >From:        Rich Ankney[SMTP:[email-masked]]
> >Sent:        Tuesday, March 10, 1998 1:16 PM
> >To:  Robert Zuccherato; [email-masked]
> >Subject:     Re: [IETF-PKIX] New Notary Protocol Draft
> >
> >1.  Could we add an extension capability to the request and response?
>
> Yes, we certainly could.  Would something like the "extensions" field in
> v3 certificates be what you are looking for?  That can easily be added.
>
> I don't know if we need to define any specific extensions in this
> document, we could just let people define their own.  Any thoughts?

The extensions field from the v3 certificate would be fine.  We have some
application-specific things in mind, but I don't think they need to be
standardized.

> >
> >2.  Is it possible to verify multiple signatures in the "ns" case?  I'm
> >thinking of the case where I send a message of type (CMS) signedData
> >which has multiple signerInfos attached.
>
> This is something I hadn't thought about before.  I don't know if I
> really see the utility of allowing this (presently only one signature is
> allowed).  Do you have a particular application in mind.

I was thinking of ANSI X9.45 and related standards in the healthcare
arena that use PKCS #7 (now CMS) SignedData with multiple
signatures quite extensively.  Granted, the most common case of
SignedData has just one SignerInfo, but I see no reason to preclude
the case where multiple SignerInfo's are present.

> >
> >3.  The relationship between request type, SignedData, and the embedded
> >data is a little murky.
>
> Yeah, the idea behind separating the two services was to allow one to
> get someone else's signature notarized (use the embedded data), but also
> to give a format for the requester to have just their possession of the
> data notarized, and to combine the services.  Any other thoughts on this
> would be appreciated.
>

I like the idea of separating the two services.  I just think the text
could
be a little clearer.  Having complained, I'll of course draft some text to
(hopefully) make things clearer.

> >I interpret it as the following:
> >
> >   a)  All requests and responses are contained in SignedData.
> >   For the ns and nc cases, this need not actually contain a
> >   signature (SignerInfo); for npd and responses, it must contain
> >   one SignerInfo.
>
> Correct.
> >
> >   b)  For npd, the data must be of type "message".  For ns, the data
> >   may be "message" or "messageImprint".  For nc, the data is "cert".
>
> Not quite.  For npd, the data could be either "message",
> "messageImprint" or "cert".  For this service the Notary Authority
> doesn't examine the data, so it can be anything.  This service just
> provides evidence that the requester possessed the data (and the
> signature key) at that time.  The use of "messageImprint" allows this
> evidence to be produced for private data.  The utility of using "cert"
> in this situation is dubious, but it isn't disallowed.
>
> Also, for ns the data must be of type "message".  For this service the
> signature is contained in the "message", so it is not possible to use
> "messageImprint"

OK.  I get it now...

> >
> >4.  It might be good to mention some useful formats in the Message
> >structure, such as id-data and id-signedData.
>
> Certainly.  Are there any others that should be included.

Those are the only two I can think of right now.

> >
> >5.  Since I may have multiple signatures on a message, can the "cert"
> >option be extended to request status on multiple (signer) certificates?
> >E.g. something like:
> >
> >     SEQUENCE {
> >             targets         SEQUENCE OF Certificate,
> >             chains          SEQUENCE OF Certificate }
> >
> >where targets are what I want status for, and chains contains the
> >certificates needed to build the paths from targets to a trusted root.
>
> That is a very good idea.  Yes, it can.
> >
> >6.  Should the notary be able to do full path validation per X.509 v3
> >(and PKIX-1)?  I.e. should the requester be able to pass the initial
> >policy set and other stuff to the notary, and receive the policy
> >qualifiers etc. back?
>
> Yes, that is what we are trying to accomplish here.  If we are missing
> anything from the protocol that would allow this to happen, let me know.

I'll take a look at the X.509/PKIX path processing algorithm and see
what additional inputs/outputs are needed.  Question:  is the policy in
the NotaryRequest and NotaryResponse supposed to identify a
certificate policy?  It's not clear from the current text.

>
>       Robert.
> >

Regards,
Rich

Approved-By:  David Boyce <[email-masked]>
Date:         Wed, 11 Mar 1998 15:36:36 +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] PKIX questions (DH key and Key Identifier)
To: [email-masked]

I wrote:
>
>For a BIT STRING, the unused bits octet is part of the length field and should
> therefore be omitted.

I then decided to check the standard.  That octet is part of the content octets rather than the length field, as I had erroneously stated.  So Nada's question still stands.

My apologies for speaking too soon.
--
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;

Approved-By:  David Boyce <[email-masked]>
Date:         Wed, 11 Mar 1998 15:27:13 +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] PKIX questions (DH key and Key Identifier)
To: [email-masked]

John Hughes writes on behalf of Nada (no email address supplied):

>In other words, there is a difference in the first byte of the bit string
>coding that tells how many bits in the last byte are unused (in the case of
>sequence none - hence the zero byte to start bit string with).
>
>My question is which of these two values should be used for the calculation
>of key identifier?

For a BIT STRING, the unused bits octet is part of the length field and should therefore be omitted.

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

Approved-By:  John Hughes <[email-masked]>
Date:         Wed, 11 Mar 1998 14:22:44 +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: John Hughes <[email-masked]>
Subject:      [IETF-PKIX] PKIX questions (DH key and Key Identifier)
To: [email-masked]

Nada has asked me to post the following questions.  For some reason she is
prevented from talking on the list.

John

________________________________________________

To authors of part 1 on certificate and CRL profile,

I have two questions:

1. The first one is regarding the coding of SubjectPublicKey in case of DSA
and DH keys.
Section 7.3.3 states that:

   "The DSA public key shall be ASN.1 encoded as an INTEGER; this
   encoding shall be used as the contents (i.e., the value) of the
   subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
   data element.

        DSAPublicKey ::= INTEGER -- public key Y"

However, section 7.3.2 uses completely different rules for coding
Diffe-Hellman public key, which is also an integer:

   "The Diffie-Hellman public key (an INTEGER) is mapped to a
   subjectPublicKey (a BIT STRING) as follows: the most significant bit
   (MSB) of the INTEGER becomes the MSB of the BIT STRING; the least
   significant bit (LSB) of the INTEGER becomes the LSB of the BIT
   STRING."

Is there any reason for this inconsistency?
It would be natural to code DH key in the same way as DSA key (and RSA key
which is a sequence of two ASN.1 coded integers).

2. My other question is partly related to the above discussion, but
regarding the algorithm for calculation of key identifier extensions.
Ipki-part1 describes only in one place the way of calculating the value of
key identifier. It is in section 4.2.1.2:

   "The subject key identifier extension provides a means of identifying
   the particular public key used in an application.  Where a reference
   to a public key identifier is needed (as with an Authority Key
   Identifier) and one is not included in the associated certificate, a
   SHA-1 hash of the subject public key shall be used.  The hash shall
   be calculated over the value (excluding tag and length) of the
   subject public key field in the certificate.  This extension should
   be marked non-critical."

I have a problem interpreting the sentence "The hash shall be calculated
over the value (excluding tag and length) of the subject public key field
in the certificate."

SubjectPublicKey is defined as a BIT STRING:

   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

and a value of the BIT STRING depends on the type of the public key. For
example for RSA keys it is:

      RSAPublicKey ::= SEQUENCE {
         modulus       INTEGER, -- n
         publicExponent     INTEGER  -- e }

So, I guess one should just take the value of bit string without its tag
and length. However, this value does not necessarily have to be the same as
the DER coding of RSAPublicKey.

>From an example RSA certificate in appendix D.3 subject public key is coded
as follows (page 107):

             { subject's public key }
             03 6b  BIT STRING length 107 bytes (856 bits)
                               0030 6802 6100 beaa 8b77 54a3 afca 779f
                               2fb0 cf43 88ff a66d 7955 5b61 8c68 ec48
                               1e8a 8638 a4fe 19b8 6217 1d9d 0f47 2cff
                               638f 2991 04d1 52bc 7f67 b6b2 8f74 55c1
                               3321 6c8f ab01 9524 c8b2 7393 9d22 6150
                               a935 fb9d 5750 32ef 5652 5093 abb1 8894
                               7856 15c6 1c8b 0203 0100 01

So, the value of bit string, without its tag and length, is:

                               0030 6802 6100 beaa 8b77 54a3 afca 779f
                               2fb0 cf43 88ff a66d 7955 5b61 8c68 ec48
                               1e8a 8638 a4fe 19b8 6217 1d9d 0f47 2cff
                               638f 2991 04d1 52bc 7f67 b6b2 8f74 55c1
                               3321 6c8f ab01 9524 c8b2 7393 9d22 6150
                               a935 fb9d 5750 32ef 5652 5093 abb1 8894
                               7856 15c6 1c8b 0203 0100 01

However, the coding of RSAPublicKey is only the part:

                               30 6802 6100 beaa 8b77 54a3 afca 779f
                               2fb0 cf43 88ff a66d 7955 5b61 8c68 ec48
                               1e8a 8638 a4fe 19b8 6217 1d9d 0f47 2cff
                               638f 2991 04d1 52bc 7f67 b6b2 8f74 55c1
                               3321 6c8f ab01 9524 c8b2 7393 9d22 6150
                               a935 fb9d 5750 32ef 5652 5093 abb1 8894
                               7856 15c6 1c8b 0203 0100 01

In other words, there is a difference in the first byte of the bit string
coding that tells how many bits in the last byte are unused (in the case of
sequence none - hence the zero byte to start bit string with).

My question is which of these two values should be used for the calculation
of key identifier?

I apologize for giving so many details, but I felt this is the easiest way
to explain the problem.

Regards,

Nada

 -------------------------------------------------------------------
| John Hughes             [email-masked]                 |
| ENTEGRITY Solutions     Home Office Tel:       +44(0)1525 380160  |
|                         Main Office Tel:       +44(0)181 876 8666 |
| www.entegrity.com       Mobile:                +44(0)468 055070   |
 -------------------------------------------------------------------

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Wed, 11 Mar 1998 14:04:40 -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] Multiple certificates for same key?
To: [email-masked]

Stephen,

As Russ said, this discussion also relates to the CMS document from the
smime wg and we should schedule a time slot in the pkix wg to talk about
it at the LA meeting.

In addition I would like to make a few comments on your two E-mails from
yesterday.

> Bob,
>
> I feel that the discussion of "which cert goes with this signature" is
> overblown.  I would argue that a relying party needs to acquire a cert that
> is valid and that contains a public key that validates the signature of the
> signed data.

This is the wrong way. The signer has to indicate which certificate must
be used. The verifier should have no free choice.

> If there is a only ine cert with a key that conforms to these
> requirements, we're done.

No. I would not like to re-open the POP discussion ... but if the
certificate identifier of the signer is part of the signed stuff, then
we can do "real-time" POP.

> if there's more than one, then the relying party
> has been given the opportunity to choose whichever one he wants. Many
> applications I know of send the end user cert as part of a transaction,
> messages, or session establishment protocol.

The basic question is whether the end user cert is signed or not.
Currently, it is not signed and this is the problem.

> Thus the relying party is
> saved the trouble of having to guess, and ambuigity is avoided.  When
> non-repudiation is an issue, then it is important to understand the
> implications of multuiple certification and users and CAs should behave
> accordingly.  However, if they choose poorly and create opportunities for
> abmiguity and possible deception, I'd back the relying party if he can
> produce a valid cert that is plausibly associated with the user and which
> works from a signature validation perspective.
>
> Steve

Second E-mail:

(... stuff deleted ...)

> Thus, I am not persuaded that we need to preclude multiple certification of
> a public key in PKIX, but I am in favor of including a brief warning about
> the possible pitfalls of this practice, and a suggestion that this practice
> be avoided for end user certs in most circumstances.

I do not think this is the right way to present the problem. You seem to
assume that the single problem has to do with the same user with two
certificates that contain the same public key. As indicated above, in
addition, we need to consider two different users each one with a
certificate that contains the same public key (the POP problem).

The recommendation should be, for the non-repudiation case, to make sure
that the signature at least includes the identifier of the certificate
(or the certificate itself). It might also include a certification path
(ie. a sequence of certificate identifiers).

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Russ Housley <[email-masked]>
Date:         Wed, 11 Mar 1998 04:51:32 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Denis:

I suggest that the [email-masked] lists is the place for this
discussion.  PLease raise this issue there, and we can discuss it ...

Russ

At 03:11 PM 3/9/98 -0800, Denis Pinkas wrote:
>David,
>
>You posted a VERY important E-mail last week and I am bringing my
>support to it.
>
>> The X.509 "SIGNED" macro might not have been designed with the intent
>> of supporting this purpose, and so may be excused for not including
>> a method of binding a certificate to the signed data.
>>
>> However, the IETF CMS specification (aka PKCS#7) was designed for
>> precisely this purpose (providing non-repudiation grade signatures over
>> generic content), yet it still does not provide a clean method of
>> binding the signer's certificate to the content.
>
>True.
>
>> The CMS definition of SignedData includes {content, certs, crls,
>> signerInfos}, and some other fields.  There may be multiple signatures
>> applied to the content, each represented by a SignerInfo.  Each
>> SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
>> Because the issuerAndSerialNumber field, which uniquely identifies the
>> certificate used by the signer, is not covered by the signature, it is
>> not bound to the content.  I'm not sure why PKCS#7 was designed that
>> way, but it was, and so is CMS.
>
>I believe that at the time, PKCS#7 was written, the authors had not
>non-repudiation in mind, but simply using a digital signature for
>authenticating a message in real time. For that purpose, the format was
>fine.
>
>> It would have been preferable to define an issuerAndSerialNumber
>> attribute, which could have been included either in
>> authenticateAttributes to bind it with the signature, or in
>> unauthenticatedAttributes if the current semantics of not binding the
>> signer's cert to the signed content is desired.
>
>As the CMS standard is being rewritten in the smime working group,
>(draft-ietf-smime-cms-03.txt) and since the editor is Russ Housley also
>a member of the PKIX working group I think it is the perfect time to
>suggest to make changes. What do you think Russ ?
>
>> Perhaps defining a redundant copy of issuerAndSerialNumber, to be
>> included in authenticatedAttributes, could address the requirement
>> without breaking backward compatibility.  (It only covers the signer's
>> cert, not the full path, but it's a start.)
>
>Yes. Without breaking compatibility we could also support a SEQUENCE OF
>issuerAndSerialNumber. The simple change that is needed is to add this
>attribute in the section 11 (Useful Attributes) from the CMS document.
>In addition we should mandate the support of such an attribute, if the
>signed data is to be used in a non-repudiation process.
>
>> The uglier alternative is  is to double-sign everything, encapsulating a
>> signedData within another signedData for each parallel signature.
>>
>> Since CMS is intended to be a generic security encapsulation mechanism,
>> not just an S/MIME-specific structure, those who feel that this
>> requirement is important (to address either multiple certification of
>> keys or proof-of-possession) should discuss it in the S/MIME working
>> group.  (A SigningTime attribute is already defined in CMS, but a
>> "location" attribute is not.)
>

>Unfortunately I am not yet on this mailing list, so why I respond here.
>
>Denis
>
>--
> ***  Please note that the E-mail address has changed ! Update it.  ***
>      Denis Pinkas     Bull S.A.          mailto:[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
>

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 11 Mar 1998 00:33: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

Bob,

I feel that the discussion of "which cert goes with this signature" is
overblown.  I would argue that a relying party needs to acquire a cert that
is valid and that contains a public key that validates the signature of the
signed data.  If there is a only ine cert with a key that conforms to these
requirements, we're done.  if there's more than one, then the relying party
has been given the opportunity to choose whichever one he wants. Many
applications I know of send the end user cert as part of a transaction,
messages, or session establishment protocol.  Thus the relying party is
saved the trouble of having to guess, and ambuigity is avoided.  When
non-repudiation is an issue, then it is important to understand the
implications of multuiple certification and users and CAs should behave
accordingly.  However, if they choose poorly and create opportunities for
abmiguity and possible deception, I'd back the relying party if he can
produce a valid cert that is plausibly associated with the user and which
works from a signature validation perspective.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 11 Mar 1998 00:33:45 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

Folks,

Here is my take on the multiple certs with the same key issue:

        - there are legitimate circumstances when this will happen, e.g.,
unidirectional cross-certification and cert reissuance

        - there are circumstances where this is a terrible idea, e.g.,
conflicting key usage constraints or in some non-repudiation contexts

        - some complaints about the problem in a non-repudiation context
are overblown, i.e., one can argue that if you manage to have the same key
in multiple certs with different liability or authorization implications,
then a "relying party" can produce the cert of its choice to substantiate
why a signed message/document was accepted and in many cases the user will
not be able to refute this assertion.  in such cases, the user gets what he
deserves for having  allowed a key to be legitimately, multiply certified!

        - most software we use today avoids this problem, by default, as do
some (most) crypto tokens

        - smart cards may want to make use of this feature because of
storage limitations

        - a CA who insists on not multiplying certifying a key should state
so in a CPS, and/or embody technical measures o minimize the likelihood
that this will happen

        - it would be hard to enumerate the circumstances where multiple
certification it's OK, vs. not OK

Thus, I am not persuaded that we need to preclude multiple certification of
a publci key in PKIX, but I am in favor of including a brief warning about
the possiboe pitfalls of this practice, and a suggestion that this practice
be avoided for end user certs in mosy circumstances.

Steve

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 10 Mar 1998 19:34:09 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Tony,
>
>I am curious that no one took me up on what might be another source of
>key-overloading;  A "low-cost CA" willing to issue a narrow attribute,
>role or authorization certificate, and relying upon the existence of a
>"classy ID certificate" for its validity, the CA essentially riding
>piggy-back upon the due diligence of the more reputable CA.
>Good examples don't come to mind, but I just get a feeling...

Here's one: A company collects code signing certificates issued by
VeriSign for Netscape or Microsoft browsers, extracts the public
keys, and creates certificates granting "Pond-Scum Platinum"
status to the company which was issued the code-signing certificate.

Unfortunately, the software vendor, believing that the only exposure
which he might face in connection with the use of his certificate lay in
erroneously signing code containing bugs, has very carefully isolated
the use of the key to within the QC department, but has not implemented
any other procedures.  Now a evil malefactor in QC decides to use his
new Platinum card certificate and the code signing key to which he has
legitimate access to order a brand new Lear jet. It is charged to
the company card and is to be delivered to a small private airstrip in the
New Mexico desert. He flies off, laughing, never to be seen again.
Pond-scum Platinum says to the company, "You digitally signed
for it, ergo you bought it. What happened then isn't our concern."

The company retorts that they never requested the issuance of the certificate,
but the CA claims that the missing employee gave the verbal OK.

Bob

Approved-By:  Dan Geer <[email-masked]>
Date:         Tue, 10 Mar 1998 19:55: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: Dan Geer <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

    >>>>> "David" == David P Kemp <[email-masked]> writes:

     David> Tony's characterization is eloquent enough that it cannot be
     David> improved upon, but merely restated.  By following the "wallet
     David> and paper signature" model and having a single public key
     David> which announces "This Is Me!", users would be voluntarily
     David> adopting the very thing they refuse to have imposed upon them
     David> externally: a national ID.

    That it true if one were to adopt a restriction that any particular
    user MUST have exactly one key.  But I don't believe that has been
    proposed.

yeah, here we go again.  if the name and the key
don't have many to many mappings, you lose liberty.

--dan

MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Approved-By:  Frank O'Dwyer <[email-masked]>
Date:         Tue, 10 Mar 1998 22:04:15 -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: "Frank O'Dwyer" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

>Few application protocols (and according to the chair of the S/MIME
>working group, *no* email protocols) include any means of preventing
>certificate substitution, so key sharing is a vulnerability.
>
>Am I missing something?

Well, it can equally be argued that having one key per certificate
introduces a single point of failure and violates the principle
of least privilege (from the perspective of a relying party attempting
to minimise threats due to trusting CAs).

In other words, assuming that there could be two or more
independent certificates for the same key, then a relying party could
require several certs before accepting a key (protecting against rogue
CAs), and can also temporarily "fly on one engine" should one of the
CAs be compromised or otherwise break down. The CAs are also
individually less attractive targets for an attacker.

Also as you point out the case you raise can be addressed by
having different key pairs per context, or by binding certificates
to messages (actually I think it would be better to just bind
selected attributes to messages, as in general a signer has
no way of predicting which certificate(s) relying parties will
trust).

Cheers,
Frank O'Dwyer.

MMDF-Warning:  Parse error in original version of preceding line at post.mail.demon.net
Approved-By:  Frank O'Dwyer <[email-masked]>
Date:         Tue, 10 Mar 1998 22:01:02 -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: "Frank O'Dwyer" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

>But do we sign with a certificate, or with a key?  I don't think that key
>and certificate are synonymous.  If the context of the certificate matters
>to the signature, then I should include the certificate in the signed
>message.

Unfortunately in general a signer has no reliable means
of predicting which certificate(s) a verifier will trust. For
example it is pointless to demand that verifiers use your
Verisign certificate if some of your audience simply don't
trust Verisign.

What really seems intended, and what might work instead,
would be to include the intended certified attributes in the
signature - in effect the signer would say "I intend to make
this signature as Joe Bloggs with extension OIDs a.b.c=foo,
x.y.z=bar".  Then it would be up to each verifier to find some
certificate(s) that authenticated those attributes for it.  The
signer could include some certificates as hints perhaps,
and/or as a convenient syntax for asserting the desired
attributes.

The above seems like an application matter, though. Also
it may be simpler to just use a different private key for
each context.

Cheers,
Frank O'Dwyer.

Approved-By:  "Brian M. Thomas" <[email-masked]>
Date:         Tue, 10 Mar 1998 14:10:02 -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] Cryptographic binding of certificates to signatures
To: [email-masked]

David Kemp wrote:
> I look at it somewhat differently.  Issuing a single certificate
> per key provides the cryptographic binding between the signature
> and the certificate; proposals to share keys between certificates
> reduce that to a binding between the signature and the union of
> all certificates which share the key.
>

Unless I really misunderstand you here, I must say that this is simply
false.  *Proof* of the issuance of a single certificate per key could
provide the cryptographic binding of signature to certificate; I invite
the cryptographers to show me how this could be accomplished.

What am I missing?

brian

Approved-By:  John Pawling <[email-masked]>
Date:         Tue, 10 Mar 1998 14:35:46 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: John Pawling <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

All,

Does anybody have a patent regarding the protocols described in the Notary
Protocols I-D (draft-adams-notary-01.txt)??  Is there anybody who is in the
process of applying for a patent regarding the Notary Protocols described in
the draft??  Is there anybody that believes that he/she/it has intellectual
property in this area and plans to apply for a patent regarding the Notary
Protocols described in the draft??

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

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Tue, 10 Mar 1998 11:13:56 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP using ASN.1
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

Hi Mike (and All),
    Didn't ever want to imply that the OCSP draft I posted had your
endorsement (I thought my preamble made that clear, but perhaps I should
have been clearer). Since I took a lot of material from your original
draft,
I didn't feel right about removing your name from the author list. If
this
was a breach of protocol, I apologize. I'll remove your name from the
author list in any future posts.

Would still be interested in your comments about the writeup itself.

Regards,
Ambarish

Michael Myers wrote:
>
> All,
>
> I want folks to know that the OCSP draft distributed by Ambarish does not
> have my endorsement.  My name was placed on it without my consent.  As the
> primary author of OCSP, I wish to point out that Ambarish's draft should be
> considered an individual submission.  The standards-track OCSP draft is
> available for review on the IETF web site.
>
> I have discussed the basis of the ASN.1 requirement with Rich Ankney, my
> co-author on the OCSP standards-track draft.  We agree that OCSP is and
> should remain a very simple protocol to solve a very simple problem and that
> the current OCSP syntax is sufficient for the requirements being addressed.
> We recognize however that it may not provide all the capabilities that an
> ASN.1-based version could address.  We further agree that the scope of
> problems addressed by this counter-proposal would actually be better couched
> as extensions to the Notary Protocol draft.
>
> Mike

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Tue, 10 Mar 1998 11:10:32 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
Comments: cc: "David P. Kemp" <[email-masked]>
To: [email-masked]

At 09:32 AM 3/10/98 -0500, you wrote:
>> From: "Balluffi, Frank" <[email-masked]>
>>
>> What is the foundation or context for this discussion: WHAT ATTACKS ARE
>> WE CONCERNED ABOUT?
>
>
>In addition to the four operational disadvantages listed in a prior
>message, I thought up the following actual attack this morning
>in the shower :-)
>
>Consider two credit cards with different policies: the Green card
>is free and offers no benefits; the Gold card costs .1% per transaction
>but offers replacement insurance up to $1000 on goods purchased.
>
>It is in the user's interest to use the Green card for every transaction,
>unless the goods received turn out to be defective, in which case the
>user might try to substitute the Gold card on the purchase transaction.
>
>The credit card company has the opposite incentive, to switch all
>transactions to the Gold card.  And if the merchant pays a different
>fee or gets a different commission from the two cards, the merchant
>has an incentive to swap certificates too.
>
>Certificate substitution would be prevented by using different keys,
>by binding the cert to the transaction, or both.  In the case of
>credit cards, any reasonable commerce protocol would bind the cert
>into the transaction.  But the attack applies whenever there
>are certificates with a shared key and conflicting incentives;
>the incentives could be information-based rather than monetary.
>Few application protocols (and according to the chair of the S/MIME
>working group, *no* email protocols) include any means of preventing
>certificate substitution, so key sharing is a vulnerability.
>
>Am I missing something?

No.  And I really like this example!  It neatly illustrates motivations
for certificate substitution in both directions.  And your last paragraph
addresses most of my questions regarding your point in the previous letter
concerning varied key expirations - linking usage to certificate would
largely obviate the problem, true?

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Tue, 10 Mar 1998 10:53:41 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: cc: "David P. Kemp" <[email-masked]>
To: [email-masked]

Dave,

At 08:57 AM 3/10/98 -0500, David Kemp wrote, in part:
>
>Tony's characterization is eloquent enough that it cannot be improved
>upon, but merely restated.  By following the "wallet and paper signature"
>model and having a single public key which announces "This Is Me!", users
>would be voluntarily adopting the very thing they refuse to have
>imposed upon them externally: a national ID.

Thank you for the generous characterization.

>My primary objection to multiple certification is the lack of handling
>flexibility, not usage tracking.  If certificates are analogous to the
>contents of a wallet, then I would like to be able to dynamically decide
>what to carry in my wallet depending on where I'm going.  Normally I'd
>carry everything, for convenience.  But if I'm going on a trip, I'd
>remove the cards I'm not expecting to need so that if the wallet is
>lost or stolen, I don't have to cancel everything.

[minor snip]

>I might normally want to keep my "AMEX Platinum" key on my smartcard,
>but if I were going to plug that smartcard into a mall kiosk or an IETF
>terminal room machine, I'd rather take the AMEX key off and leave just
>an S/MIME email key on the card.

Agreed.  This is another Very Good Reason for separate keys.

>The third objection to multiple certification is that it leads
>inexorably to a permanent key that cannot be updated.  Although it is
>impossible for a single CA to verify that a key has not been certified
>somewhere else, it is certainly possible and often desirable for that
>CA to ensure that the key is changed at renewal.  But if a single key
>is used for all certificates, and the validity dates for all CAs are
>not synchronized, then it is impossible for any CA to rekey it's own
>subjects' certificates, much less establish rekey periods that are
>appropriate for the purpose of the certificates.

This is the one point I don't quite follow.  If a CA feels that the time
has come to expire *its certification* of a key, and to require that the
owner have a new key certified, I don't quite see how independent
certifications that have not expired need to be factored in.

At least, not "in principle."  Of course, this assumes that the relying
party can demand the key possesses a valid certificate suitable for the
*purposes of the transaction*, and did so at the time of the signing.
This "missing linkage" of signature to certificate, and how to address it,
is being debated by Bob Jueneman and Denis Pinkas at present.

And as Dwight Arthur pointed out, "cross certification" cannot exist
without there being multiple certificates on a single key, and so the
protocol must deal with the situation.  If in particular, then perhaps
best in general.  Granted that in this case, the certificates may be
considered "equipotent" and so the issue of "which one" is less pressing.

Personally, I would avoid overloading any key, of course, for the other
reasons you have given.

I am curious that no one took me up on what might be another source of
key-overloading;  A "low-cost CA" willing to issue a narrow attribute,
role or authorization certificate, and relying upon the existence of a
"classy ID certificate" for its validity, the CA essentially riding
piggy-back upon the due diligence of the more reputable CA.
Good examples don't come to mind, but I just get a feeling...

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 10 Mar 1998 13:48: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] Cryptographic binding of certificates to signatures
To: [email-masked]

> From: Bob Jueneman <[email-masked]>
>
> If we were able to somehow add cryptographic binding of
> the digital signature to the specific certificate that is s
> supposed to be used to validate it, virtually all of my objections
> to issuing more than one certificate per key would disappear,
> and we would be left with some of the positive virtues of that
> approach that others have mentioned.

I look at it somewhat differently.  Issuing a single certificate
per key provides the cryptographic binding between the signature
and the certificate; proposals to share keys between certificates
reduce that to a binding between the signature and the union of
all certificates which share the key.

I agree that it would be desirable to increase assurance by creating new
signature algorithms and/or new application-protocol capabilities to
bind the cert to the signature.  But that won't happen overnight.

What are the positive virtues of shared keys?  The only ones I've
seen are the possibility of saving some memory, and the gut feeling
that it would be nice to have one signature key represent one person.

There are some circumstances where using the same key in multiple
certificates is reasonable:

* cross-certification: the union of all certificates with the same
  CA as a subject offers no advantage over any particular single
  certificate, thus there's no benefit to be gained by swapping
  certs.  The purpose of a CA key is to sign certificates and CRLs
  which can later be validated - if more than one path leading through
  a particular CA can be constructed and validated, then the properties
  of any single path are not affected by whether other paths use the
  same key.

* renewal: if certificates are issued periodically with no change
  in contents except the validity period, then there is no vulnerability
  (except increased key lifetime) introduced by recertifying the
  same key.  Or, to put it another way, if a key is used for a fixed
  period (say 5 years), then there is no difference between issuing
  a single cert with 5 year validity or 5 otherwise identical certs
  with 1 year validities.  Since shorter validities may make CRLs
  shorter, recertifying the same key is useful.

Once you get beyond the cases where sharing keys is clearly harmless,
things get more difficult to understand.  Is it OK to recertify a
key if just the person's name changed?  I dunno. It seems reasonable
that a person would have the identical liabilities and obligations
regardless of what name that person used.  But if there were some
instance where Alice Smith has different legal responsibilities
than Mrs. Alice Smith-Jones, then they should use different keys
lest either Alice or an adversary would find it profitable to
swap certs on some signed item.

Approved-By:  John Pawling <[email-masked]>
Date:         Tue, 10 Mar 1998 13:38:22 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: John Pawling <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

Robert,

Does Nortel/Entrust have a patent on the protocols described in the Notary
Protocols I-D (draft-adams-notary-01.txt)??  Is Nortel/Entrust in the
process of applying for a patent on the Notary Protocols described in the
draft??  Does Nortel/Entrust have any plans to apply for a patent on the
Notary Protocols described in the draft??

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

Approved-By:  "Brian M. Thomas" <[email-masked]>
Date:         Tue, 10 Mar 1998 11:56:20 -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] Multiple Certificates
To: [email-masked]

> In addition to the four operational disadvantages listed in a prior
> message, I thought up the following actual attack this morning
> in the shower :-)

Those are the best kind.

> Consider two credit cards with different policies: the Green card
> is free and offers no benefits; the Gold card costs .1% per transaction
> but offers replacement insurance up to $1000 on goods purchased.
>
> It is in the user's interest to use the Green card for every transaction,
> unless the goods received turn out to be defective, in which case the
> user might try to substitute the Gold card on the purchase transaction.
>
> The credit card company has the opposite incentive, to switch all
> transactions to the Gold card.  And if the merchant pays a different
> fee or gets a different commission from the two cards, the merchant
> has an incentive to swap certificates too.
>
> Certificate substitution would be prevented by using different keys,
> by binding the cert to the transaction, or both.  In the case of
> credit cards, any reasonable commerce protocol would bind the cert
> into the transaction.  But the attack applies whenever there
> are certificates with a shared key and conflicting incentives;
> the incentives could be information-based rather than monetary.
> Few application protocols (and according to the chair of the S/MIME
> working group, *no* email protocols) include any means of preventing
> certificate substitution, so key sharing is a vulnerability.
>
> Am I missing something?
>

I don't think you're missing anything, really.  In my yet-incipient
concepts of electronic transactions, it seems absolutely essential that
all terms of an agreement be explicit, incorporated by reference, or
legally inferrable from the transaction itself.  The key itself offers
no such evidence; only the certificates that confer the authorization
to spend the money in the accounts.  Therefore the transaction does not
say merely "I will give you some money" but "I authorize payment by this
means and under these terms ..." specifying the payment mechanisms, account
numbers, etc.  The other party would only accept the contract if these were
all spelled out as part of the contract.  So I would agree with the notion
that the authorizing certificate needs to be a part of any signed contract,
irrespective of your position on multiple certs per key.

brian

Brian Thomas, CISSP - Distributed Systems Architect  [email-masked]
Southwestern Bell                                    [email-masked]
One Bell Center,  Room 34G3                          Tel: 314 235 3141
St. Louis, MO 63101                                  Fax: 314 235 0162

Approved-By:  Rich Ankney <[email-masked]>
Date:         Tue, 10 Mar 1998 13:16:53 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
Comments: To: [email-masked]
To: [email-masked]

A few comments on the new draft:

1.  Could we add an extension capability to the request and response?

2.  Is it possible to verify multiple signatures in the "ns" case?  I'm
thinking of the case where I send a message of type (CMS) signedData
which has multiple signerInfos attached.

3.  The relationship between request type, SignedData, and the embedded
data is a little murky.  I interpret it as the following:

   a)  All requests and responses are contained in SignedData.
   For the ns and nc cases, this need not actually contain a
   signature (SignerInfo); for npd and responses, it must contain
   one SignerInfo.

   b)  For npd, the data must be of type "message".  For ns, the data
   may be "message" or "messageImprint".  For nc, the data is "cert".

4.  It might be good to mention some useful formats in the Message
structure, such as id-data and id-signedData.

5.  Since I may have multiple signatures on a message, can the "cert"
option be extended to request status on multiple (signer) certificates?
E.g. something like:

        SEQUENCE {
                targets         SEQUENCE OF Certificate,
                chains          SEQUENCE OF Certificate }

where targets are what I want status for, and chains contains the
certificates needed to build the paths from targets to a trusted root.

6.  Should the notary be able to do full path validation per X.509 v3
(and PKIX-1)?  I.e. should the requester be able to pass the initial
policy set and other stuff to the notary, and receive the policy
qualifiers etc. back?

Regards,
Rich

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 10 Mar 1998 09:01:47 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using ASN.1
Comments: To: Ambarish Malpani <[email-masked]>
To: [email-masked]

All,

I want folks to know that the OCSP draft distributed by Ambarish does not
have my endorsement.  My name was placed on it without my consent.  As the
primary author of OCSP, I wish to point out that Ambarish's draft should be
considered an individual submission.  The standards-track OCSP draft is
available for review on the IETF web site.

I have discussed the basis of the ASN.1 requirement with Rich Ankney, my
co-author on the OCSP standards-track draft.  We agree that OCSP is and
should remain a very simple protocol to solve a very simple problem and that
the current OCSP syntax is sufficient for the requirements being addressed.
We recognize however that it may not provide all the capabilities that an
ASN.1-based version could address.  We further agree that the scope of
problems addressed by this counter-proposal would actually be better couched
as extensions to the Notary Protocol draft.

Mike

Approved-By:  Paul Koning <[email-masked]>
Date:         Tue, 10 Mar 1998 11:45:58 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

 David> Tony's characterization is eloquent enough that it cannot be
 David> improved upon, but merely restated.  By following the "wallet
 David> and paper signature" model and having a single public key
 David> which announces "This Is Me!", users would be voluntarily
 David> adopting the very thing they refuse to have imposed upon them
 David> externally: a national ID.

That it true if one were to adopt a restriction that any particular
user MUST have exactly one key.  But I don't believe that has been
proposed.

What was proposed instead is that it should be up to user discretion
as to how many keys there are for that user.  It might be one, it
might be as many as the number of certificates held by that user.  If
the choice is up to the user, my expectation is that the average
number will be higher than one but probably not a great deal higher.
Certainly you give a good reason why the average would be higher than
one.

        paul

--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, C-24183
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: [email-masked]
! Pgp:   27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859

Approved-By:  "Phillip M. Hallam-Baker" <[email-masked]>
Date:         Tue, 10 Mar 1998 11:38: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: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

>(personally, I'd consider "is to:" as being a lot nearer "MUST" than
>"MAY" - so it does make quite a difference to the way I perceive what
>this point is saying (feel free to tell me why I'm wrong though))

No, it must be either a MUST or a MAY or a SHOULD. The whole point
of using this language form is to avoid the ambiguities of constructs like
"is to".

        Phill

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Tue, 10 Mar 1998 11:27:37 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

Stephen;

My apologies on these typos.  My global search and replace skills need
some work, I guess.:-)

Both of the mentioned MAY's should be REQUIRED's.

        Robert.

>----------
>From:  Stephen P. Wilson[SMTP:[email-masked]]
>Sent:  Tuesday, March 10, 1998 11:16 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] New Notary Protocol Draft
>
>Robert Zuccherato wrote:
>>
>> 2. Requirements of the Notary Authority
>>
>> The Notary Authority is MAY to:
>
>What does this mean? - should it either read "is to:" or "MAY:" ?
>
>(personally, I'd consider "is to:" as being a lot nearer "MUST" than
>"MAY" - so it does make quite a difference to the way I perceive what
>this point is saying (feel free to tell me why I'm wrong though))
>
>> 7.  Security Considerations
>>
>> This entire document discusses security considerations.
>>
>> When designing a notary service, the following considerations have
>> been identified that have an impact upon the validity or "trust" in
>> the notary token.
>>
>> 1.  The enclosed certificate is revoked or the signer's key is
>>     compromised and the corresponding certificate is revoked before
>>     the notary acts upon the request. The notary is MAY to validate
>>     appropriate information within the request before it constructs
>>     the notary token.  It is therefore mandated that the NA have
>>     access to current information regarding certificate status before
>>     it creates the token.  In this situation, the notarization process
>>     would produce an error.
>
>"is MAY to" again.
>
>Stephen.
>
>--
>+-----------------------------------------+----------------------------+
>| Stephen Wilson. BSc (hons), AMIEE.      | [email-masked]  |
>| Defence Evaluation & Research Agency,   | http://www.dera.gov.uk/    |
>| St Andrews Road,                        |                            |
>| Malvern,                                | Tel: +44 (0)1684 894153.   |
>| WR14 3PS.                               | Fax: +44 (0)1684 896113.   |
>| United Kingdon.                         |                            |
>+-----------------------------------------+----------------------------+
>| Standard disclaimer: "The Information contained in this E-Mail and   |
>| any subsequent correspondence is private and is intended solely for  |
>| the intended recipient(s). For those other than the intended         |
>| recipient any disclosure, copying, distribution, or any action taken |
>| or omitted to be taken in reliance on such information is prohibited |
>| and may be unlawful."                                                |
>+----------------------------------------------------------------------+
>

Approved-By:  "Stephen P. Wilson" <[email-masked]>
Date:         Tue, 10 Mar 1998 16:16:49 +0000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Stephen P. Wilson" <[email-masked]>
Organization: Defence Evaluation & Research Agency.
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

Robert Zuccherato wrote:
>
> 2. Requirements of the Notary Authority
>
> The Notary Authority is MAY to:

What does this mean? - should it either read "is to:" or "MAY:" ?

(personally, I'd consider "is to:" as being a lot nearer "MUST" than
"MAY" - so it does make quite a difference to the way I perceive what
this point is saying (feel free to tell me why I'm wrong though))

> 7.  Security Considerations
>
> This entire document discusses security considerations.
>
> When designing a notary service, the following considerations have
> been identified that have an impact upon the validity or "trust" in
> the notary token.
>
> 1.  The enclosed certificate is revoked or the signer's key is
>     compromised and the corresponding certificate is revoked before
>     the notary acts upon the request. The notary is MAY to validate
>     appropriate information within the request before it constructs
>     the notary token.  It is therefore mandated that the NA have
>     access to current information regarding certificate status before
>     it creates the token.  In this situation, the notarization process
>     would produce an error.

"is MAY to" again.

Stephen.

--
+-----------------------------------------+----------------------------+
| Stephen Wilson. BSc (hons), AMIEE.      | [email-masked]  |
| Defence Evaluation & Research Agency,   | http://www.dera.gov.uk/    |
| St Andrews Road,                        |                            |
| Malvern,                                | Tel: +44 (0)1684 894153.   |
| WR14 3PS.                               | Fax: +44 (0)1684 896113.   |
| United Kingdon.                         |                            |
+-----------------------------------------+----------------------------+
| Standard disclaimer: "The Information contained in this E-Mail and   |
| any subsequent correspondence is private and is intended solely for  |
| the intended recipient(s). For those other than the intended         |
| recipient any disclosure, copying, distribution, or any action taken |
| or omitted to be taken in reliance on such information is prohibited |
| and may be unlawful."                                                |
+----------------------------------------------------------------------+

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 10 Mar 1998 10:57:31 -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] Cryptographic binding of certificates to signatures
To: [email-masked]

Bob,
  I'm sorry not to have replied sooner.  The approach sounds promising,
but I haven't thought about the details enough to comment substantially.
Offhand, I don't see a problem with defining new signature algorithms,
with new OIDs, which compute signatures over the concatenation of
the ToBeSigned message digest and the ancillary information.

I do see a problem with including salt (randomized padding) in the
signature computation - it would have to be transmitted as part of the
signature value, which would expand the size of the signature: DSA
signatures would become something like:

  DSASignatureValue ::= SEQUENCE {
      r      INTEGER,
      s      INTEGER,
      salt   OCTET STRING }

Can't this "problem", if it exists, be addressed at the application
layer?

Dave Kemp

> From: Bob Jueneman <[email-masked]>
>
> What I'm proposing is that we define a new series of digital signature
> algorithm OIDs, which would include the additional information that
> is needed as part of the COMPONENTS.
>
>   [...]
>
> The other approach, which could be extended to arbitrarily long
> information, would be to effectively append the existing ToBeSigned
> information (normally a message digest) to the ancillary information, and
> then compute a super message digest over the entire collection. That
> super message digest, plus any additional randomized padding (we
> ought to fix that problem while we are at it) would then be the input
> to the actual signing operation. This would support signature algorithms
> and key lengths which only allow as little as 160 bits of input (or even
> 128 bits, for MD5)).

Approved-By:  "Stephen P. Wilson" <[email-masked]>
Date:         Tue, 10 Mar 1998 16:00: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: "Stephen P. Wilson" <[email-masked]>
Organization: Defence Evaluation & Research Agency.
Subject:      Re: [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

Robert Zuccherato wrote:
>
> Comments are appreciated.
>
>         Robert Zuccherato.
>
>   ---------------------------------------------------------------
>                                      C. Adams(Entrust Technologies)
> Internet Draft                  R. Zuccherato(Entrust Technologies)
> expires in six months                             February 27, 1997

OK, so I'm just being really pedantic - but according to this, this
document has already expired (unless I've gone back in a timewarp or
something)  :-)

My first post to the group, and it's such a silly one... let's hope I
can improve next time...

Stephen.

--
+-----------------------------------------+----------------------------+
| Stephen Wilson. BSc (hons), AMIEE.      | [email-masked]  |
| Defence Evaluation & Research Agency,   | http://www.dera.gov.uk/    |
| St Andrews Road,                        |                            |
| Malvern,                                | Tel: +44 (0)1684 894153.   |
| WR14 3PS.                               | Fax: +44 (0)1684 896113.   |
| United Kingdon.                         |                            |
+-----------------------------------------+----------------------------+
| Standard disclaimer: "The Information contained in this E-Mail and   |
| any subsequent correspondence is private and is intended solely for  |
| the intended recipient(s). For those other than the intended         |
| recipient any disclosure, copying, distribution, or any action taken |
| or omitted to be taken in reliance on such information is prohibited |
| and may be unlawful."                                                |
+----------------------------------------------------------------------+

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Tue, 10 Mar 1998 09:56: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: Robert Zuccherato <[email-masked]>
Subject:      [IETF-PKIX] New Notary Protocol Draft
To: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_000_01BD4C0A.BD78B3B0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello All;

For those of you that are interested, we have submitted a new version of
our Notary Protocols Internet Draft.  It is now available at:
ftp://ds.internic.net/internet-drafts/draft-adams-notary-01.txt
I have also included the document with this email.

We submitted it, again, as an independent draft since changes to the
PKIX charter that would allow this haven't been made yet.  The changes
to this draft include:
1) CMS (PKCS #7) encapsulation.
2) Removal of the "Notarize Data" service.  The protocol now only
supports notarization of signatures (possession of data) and
certificates.
3) Inclusion of a version number and nonce.

Comments are appreciated.

        Robert Zuccherato.

------ =_NextPart_000_01BD4C0A.BD78B3B0
Content-Type: text/plain; name="notary012.txt"
Content-Transfer-Encoding: 7bit

                                          C. Adams(Entrust Technologies)
Internet Draft                       R. Zuccherato(Entrust Technologies)
expires in six months                                  February 27, 1997

                          Notary Protocols

                     <draft-adams-notary-01.txt>

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

This document describes a general notary service and the protocols to
be used when communicating with it.  The Notary Authority is a Trusted
Third Party (TTP) that can be used as one component in building reliable
non-repudiation services (see [ISONR]).  Useful Notary Authority
responsibilities in a PKI are to validate signatures and to provide up-
to-date information regarding the status of certificates.  We give
examples of how to use the notary to extend the lifetime of a signature
beyond key expiry or revocation and to query the notary regarding the
status of a certificate.

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119 [RFC2119].

1. Introduction

A Notary Authority (NA) is a Trusted Third Party that verifies the
correctness of specific data submitted to it.  The Notary Authority
provides the notary service in order that non-repudiation evidence may
be constructed relating to the validity and correctness of an entity's
claim to possess data, the validity and revocation status of an entity's
public key certificate and/or the validity and correctness of another
entity's signature.  When notarizing possession of data or another
entity's signature, the NA verifies the mathematical correctness of the
actual signature value contained in the request and also checks the full

Document Expiration:  August 27, 1998                            Page 1

certification path from the signing entity to a trusted point (e.g., the
NA's CA, or the root CA in a hierarchy).  The NA MAY be able to rely on
all relevant CRLs and ARLs, or the NA MAY need to supplement this with
access to more current status information from the CA.  It then includes

a trusted time and creates a notary token.  (See Appendix B.)

When notarizing a certificate, the NA verifies that the certificate
included in the request is a valid certificate and determines its
revocation status at a specified time.  Again, it checks the full
certification path from the certificate signing entity to a trusted
point.  The NA MAY be able to rely on all relevant CRLs and ARLs, or the
NA MAY need to supplement this with access to more current status
information from the CA.  It includes this information, along with a
trusted time, to create a Notary Token.  (See Appendix C.)

The presence of a notary token supports non-repudiation in two ways.
It provides evidence that a signature or certificate was valid at the
time of notarization.  This token can be used even after the
corresponding certificate expires and its revocation information is
no longer available on CRLs (for example).  The production of a notary
token in response to a signed request for notarization of another
signature or certificate also provides evidence that due diligence
was performed by the requester in validating the signature or
certificate.

In all cases, the trust that PKI entities have in the Notary Authority
is transferred to the contents of the notary token (just as trust in a
CA is transferred to the certificates that it issues).  As a particular
example, a notary token pertaining to a signature may be useful for
extending the life of that signature beyond the expiry or subsequent
revocation of its corresponding verification certificate.

2. Requirements of the Notary Authority

The Notary Authority is MAY to:

     1. verify the correctness of the enclosed digital signature using
        all appropriate status information and public key certificates
        and produce a signed notary token attesting to the validity of
        the signature, if asked by the requester.
     2. verify the validity (according to [CCP]) of the enclosed
        certificate and its revocation status at the specified time
        using all appropriate status information and public key
        certificates and produce a signed notary token attesting to the
        validity and revocation status of the certificate, if asked by
        the requester.
     3. include a monotonically incrementing value of the time of day
        or a time stamp token into its notary token.
     4. include within each signed notary token an identifier to
        uniquely determine the trust and validation policy used for this
        signature.
     5. sign each notary token using a key generated exclusively for
        this purpose and have this property of the key indicated on the
        corresponding certificate.

Document Expiration:  August 27, 1998                            Page 2

     6. indicate in the token whether or not the signature or
        certificate verified, and if not, the reason the verification
        failed.
     7. provide a signed receipt (i.e., in the form of an appropriately
        defined notary token) to the requester, where appropriate, as
        defined by policy.

3. Notary Transactions

As the first transaction of this mechanism, the requesting entity
requests a notarization by sending a request (which is or includes a
notary request, as defined below), including the data for which validity
and/or possession is to be notarized, to the Notary Authority.  Upon
receiving the request, the Notary Authority reviews and checks the
validity of the request.  A valid request is of the form described in
Section 5 of this document and can be properly decoded.  If the request
is valid, the Notary Authority performs the notarization and sends a
response (which is or includes a notary token, as defined below) to the
requesting entity.  Otherwise, the Notary Authority returns an error
message (i.e., in the form of an appropriately defined notary token).

Upon receiving the token, the requesting entity verifies its validity.
The requester SHOULD verify that it contains the correct time, the
correct name for the NA, the correct data imprint, a valid signature,
and satisfactory status, service and policy fields.  Since the NA's
certificate may have been revoked, the appropriate status information
SHOULD be checked to verify that the certificate is still valid.  The
token can now be used to authenticate the correctness or possession of
the corresponding data.

4. Identification of the NA

The NA MUST sign all notary messages with a key reserved specifically
for that purpose.  The corresponding certificate MUST contain the
extended key usage field extension as defined in [CCP] Section
4.2.1.14 with KeyPurposeID having value id-kp-notary.  This extension
MUST be critical.

id-kp-notary    OBJECT IDENTIFIER ::= {id-kp  ??}
  -- Notarizing the validity of certain information.  Key usage bits
  -- that may be consistent:  digitalSignature, nonRepudiation

5. Request and Token Formats

The ServiceType type indicates which type of Notary Service is required.

ServiceType ::= INTEGER  { npd(1), ns(2), nc(3) }

The value npd (Notarize Possession of Data) is used when only the
signature on the notary request (i.e., possession of the data in the
request) is to be verified.  In this case the Notary Authority would be
merely providing evidence that the requester possessed the data in the
request and a valid signature key at the time indicated.  This is really
an extension of the Time Stamp Authority [TSA] in that we are given the
additional assurance about the validity of the signature, as well as the
time before which it was applied.  The value ns (Notarize Signature) is

Document Expiration:  August 27, 1998                            Page 3

used when another entity's signature is to be validated.  The resulting
token can then be used to support non-repudiation services or to allow
use of the signature beyond certificate revocation or expiry.

The value nc (Notarize Certificate) is used when the validity and
revocation status of the certificate included in the request is to be
verified.  This service can be used to supplement the use of CRLs when
timely information regarding a certificate's revocation state is
required (e.g. high value funds transfer or the compromise of a highly
sensitive key) or when evidence supporting non-repudiation is required.
A given NA MAY support any subset of the above services.

Upon receiving a signed request for either service ns or nc the NA MUST
also verify the signature on the request as is done for the npd service.
Note however, that signed requests for the ns or nc service are not
required.

A notary request is as follows.  It is encapsulated as a SignedData
construct [CMS].  The content is of type NotaryReqData, which is
indicated by the OID:

NotaryReqData OBJECT IDENTIFIER  ::= { ??????  }

The notary request MUST contain only the signature of the requester.

The data and information that will be notarized are contained in the
content field of the SignedData content type.

NotaryReqData ::= SEQUENCE  {
     notaryReqInfo                NotaryReqInfo,
     data                         Data
       --the data to be notarized
       --this field MUST be of type Message if the service type is ns
       --and of type SEQUENCE OF Certificate if the service type is nc
}

The notaryReqInfo field contains information pertaining to the notary
request.

NotaryReqInfo ::= SEQUENCE  {
     version                      Integer { v1(0) },
     service                      ServiceType,
     requester                    GeneralName OPTIONAL,
      --MUST be present if the service field is npd
      --MUST match the identity (subjectName or subjectAltName
      --extension) for the corresponding signing certificate
     reqPolicy                    PolicyInformation OPTIONAL,
     notary                       GeneralName,
     nonce                        Integer,
     reqTime                      ReqTime OPTIONAL   }

ReqTime ::= CHOICE  {
     genTime                      GeneralizedTime,
     timeStampToken               TimeStampToken   }

Document Expiration:  August 27, 1998                            Page 4

In situations where the Notary Authority will verify the identity of the
requester (i.e., when the service field is npd), the notary request MUST
be signed by the requester using the signerInfos field.

Similarly, in situations where the Notary Authority will certify the
time included in the request (i.e., when stipulated by the policy of the
Notary Authority), the notary request MUST include the reqTime field in
NotaryReqInfo. Thus, when verifying a certificate, the presence of this
field indicates the time for which the validity and revocation status of
the certificate SHOULD be reported.  If this field is not present, the
current time is assumed. TimeStampToken is defined in Sect 2.4 of [TSA].

PolicyInformation is defined in Section 4.2.1.5 of [CCP].  The
reqPolicy field SHOULD indicate the policy under which the notarization
is requested or the policy for which certificate validity is to be
reported.  This field MUST be checked by the NA to verify agreement
with its own policy or to determine certificate validity.  The absence
of this field indicates that any policy is acceptable.

The Data type is defined to be either the message itself, a hash of
the message (this allows a signature indicating possession of private
data to be notarized) or the certificate to be verified.

Data ::= CHOICE  {
     message                [0]  Message,
     messageimprint         [1]  MessageImprint,
     cert                   [2]  SEQUENCE SIZE (1..MAX) OF Certificate
}

In order to specify the format (i.e. the type) of the message so that
it may be parsed and understood by the NA or any verifying entity, we
define the Message data type.

Message ::= SEQUENCE  {
     format                       MESSAGECLASS.&id,   --objid
     rawdata                      MESSAGECLASS.&Type  --open type
}

MESSAGECLASS ::= CLASS  {
     &id                          OBJECT IDENTIFIER UNIQUE,
     &Type                                                    }
WITH SYNTAX  { &Type IDENTIFIED BY &id }

If the requester prefers to send a hash of the message instead, the
MessageImprint data type SHOULD be used.

MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage                OCTET STRING  }

The hash algorithm indicated in the hashAlgorithm field SHOULD be a
"strong" hash algorithm (that is, it SHOULD be one-way and collision
resistant).  It is up to the Notary Authority to decide whether or not
the given hash algorithm is sufficiently "strong" (based on the current
state of knowledge in cryptanalysis and the current state of the art in
computational resources, for example).

Document Expiration:  August 27, 1998                            Page 5

The hashedMessage field SHOULD contain the hash of the DER encoding of
the message expressed as a Message data type.  The hash is represented
as an OCTET STRING.

The cert field SHOULD contain the certificate to be notarized.  If the
sequence has length greater than 1, then the certificates MUST indicate
a chain of trust to be used when notarizing the certificate.

A notary token is as follows.  It is encapsulated as a SignedData
construct [CMS].  The content is of type NotaryInfo, which is indicated
by the OID:

NotaryInfo OBJECT IDENTIFIER  ::= { ??????  }

The notary token MUST contain only the signature of the NA.

NotaryInfo ::= SEQUENCE  {
     notaryReqInfo                NotaryReqInfo,
       --MUST be the same value as the notaryReqInfo field in
       --NotaryReqData
     messageImprint               MessageImprint,
       --if the data field in NotaryReqData is MessageImprint, this
       --MUST contain that same value, otherwise it contains a hash of
       --the data field in NotaryReqData using the hash algorithm
       --specified in the digestAlgorithm parameter of SignerInfo in
       --the notary token
     reqSignature                 SignerInfo OPTIONAL,
       --MUST be present if service field of notaryReqInfo is npd
       --MUST be the same value as the signerInfo field in notary
request
     policy                       PolicyInformation,
     status                       PKIStatusInfo,
     time                         NotaryTime,
     chainCerts              [0]  SEQUENCE OF Certificate OPTIONAL,
       --if present, MUST indicate the chain of trust that was used by
       --the NA to verify the signature or certificate in NotaryReqData
     crls                    [2]  SEQUENCE OF CertificateList OPTIONAL
   }

NotaryTime ::= CHOICE  {
     genTime                      GeneralizedTime,
     timeStampToken               TimeStampToken   }

PKIStatusInfo is defined in Section 3.2.3 of [CMP].  If the PKIStatus
field has value `waiting' (3), then this token is a receipt, as defined
in Section 2.  Otherwise, the status field indicates whether or not the
notary request was fulfilled and, if not, failInfo indicates the reason
it was rejected.  A valid notary token will have a PKIStatus field with
value `granted' (0).  For the purposes of the NA, we define
PKIFailureInfo for use in PKIStatusInfo.

PKIFailureInfo ::= BITSTRING  {
    badAlg           (0),
      -- unrecognized or unsupported Algorithm Identifier
    badMessageCheck  (1),
      -- integrity check failed (e.g., signature did not verify)

Document Expiration:  August 27, 1998                            Page 6

    badRequest       (2),
      -- transaction not permitted or supported
    badTime          (3),
      -- messageTime was not sufficiently close to the system time,
      -- as defined by local policy
    badCertId        (4),
      -- no certificate could be found matching the provided criteria
    badDataFormat    (5),
      -- the data submitted has the wrong format
    wrongAuthority   (6),
      -- the authority indicated in the request is different from the
      -- one creating the response token
    incorrectData    (7),
      --the requester's data (i.e. signature) is incorrect
      --(i.e. invalid)
    missingTimeStamp (8),
      -- when the timestamp is missing but should be there (by policy)
    certInvalid      (9),
      -- the certificate fails to validate against Section 6 of [CCP]
    certRevoked      (10),
      -- the certificate is revoked
    certExpired      (11),
      -- the certificate has expired
    certOnHold       (12),
      -- the certificate has been operationally suspended
    certNotActive    (13)
      -- the certificate was not active at the given time
}

The statusString field of PKIStatusInfo can be used to include reason
text such as "CA's public key revoked".

CertId is defined in Section 7.5 of [CRMF].

The crls field (if present) SHOULD contain a sequence of certificate and
authority revocation lists that is sufficient to verify the chain of
trust indicated in the chainCerts field.

The reqSignature, chainCerts and crls fields are included as OPTIONAL.
They SHOULD be present, when policy dictates, for use as supplementary
evidence when resolving possible disputes.  Dispute resolution would
most likely be handled by one or more humans, in an off-line
environment, and is beyond the scope of this document.

6. Transports

6.1. File Based Notary Protocol

A file containing a notary message MUST contain only the DER encoding of
one PKI message, i.e. there MUST be no extraneous header or trailer
information in the file.

Such files can be used to transport notary messages using for example,
FTP.

Document Expiration:  August 27, 1998                            Page 7

6.2. Socket Based Notary Protocol

The socket based protocol for notary messages is identical to that used
in [CMP] Section 5.2 except that port 309 MUST be used.

6.3. Notary Protocol Using Email

This section specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 4 via Internet mail.

A simple MIME object is specified as follows.

   Content-Type: application/notary
   Content-Transfer-Encoding: base64

   <<the ASN.1 DER-encoded Notary message, base64-encoded>>

This MIME object can be sent and received using MIME processing engines
and provides a simple Internet mail transport for Notary messages.

6.4. Notary Protocol via HTTP

This subsection specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 4 via the HyperText
Transfer Protocol.

A simple MIME object is specified as follows.

   Content-Type: application/notary

   <<the ASN.1 DER-encoded Notary message>>

This MIME object can be sent and received using common HTTP processing
engines over WWW links and provides a simple browser-server transport
for Notary messages.

7.  Security Considerations

This entire document discusses security considerations.

When designing a notary service, the following considerations have been
identified that have an impact upon the validity or "trust" in the
notary token.

1.  The enclosed certificate is revoked or the signer's key is
        compromised and the corresponding certificate is revoked before
        the notary acts upon the request. The notary is MAY to
        validate appropriate information within the request before it
        constructs the notary token.  It is therefore mandated that the
        NA have access to current information regarding certificate
        status before it creates the token.  In this situation, the
        notarization process would produce an error.
     2. The enclosed certificate is revoked or the signer's key is
        compromised and the corresponding certificate is revoked after
        the notary acts upon the request. This is not a concern to the
        NA once the notary has constructed the token, as long as the

Document Expiration:  August 27, 1998                            Page 8

        compromise date in the CRL is not before the time of
        notarization.  If it is, this situation would have to be
        handled by off-line, possibly human-aided, means specific to the
        situation at hand.
     3. The notary's private key is compromised and the corresponding
        certificate is revoked.  In this case, any token signed by the
        notary cannot be trusted.  For this reason, it is imperative
        that the notary's key be guarded with proper security and
        controls in order to minimize the possibility of compromise.
        Nevertheless, in case the private key does become compromised,
        an audit trail of all the tokens generated by the NA SHOULD be
        kept as a means to help discriminate between genuine and false
        tokens.
     4. The NA signing key MUST be of a sufficient length to allow for
        a sufficiently long lifetime.  Even if this is done, the key
        will have a finite lifetime.  Thus, any token signed by the NA
        SHOULD be time stamped (if authentic copies of old CRLs
        are available) or notarized again (if they aren't) at a later
        date to renew the trust that exists in the NA's signature.
        Notary tokens could also be kept with an Evidence Recording
        Authority [ISONR] to maintain this trust.
     5. When there is a reason to believe that the NA can no longer
        be trusted, the authority's certificate MUST be revoked and
        placed on the appropriate ARL.  Thus, at any future time the
        tokens signed with the corresponding key will not be trusted.
6.  In certain circumstances, an NA may not be able to produce a
        valid response to a request (for example, if it is unable to
        compute signatures for a period of time).  In these situations
        the NA MUST wait until it is again able to produce a valid
        response and then respond to the request.  Under no
        circumstances shall an NA produce an unsigned response to a
        request.
7.  This protocol assumes that the CA has conducted a test for proof
        of possession for each user's signing private key.  If this is
        not the case, or when additional assurances are required, the
        certificate of the reqester (resp. NA) SHALL be included in the
        encapsulation of the notary request (resp. notary token) as an
        authenticated attribute.

8. References

[TSA] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, "Time Stamp
Protocols," draft-adams-time-stamp-0X.txt, 1997 (work in progress).

[CMP] C. Adams, S. Farrell, "Internet Public Key Infrastructure,
Certificate Management Protocols," draft-ietf-pkix-ipki3cmp-
0X.txt, 1997 (work in progress).

[CRMF] C. Adams, "Internet Public Key Infrastructure, Certificate
Request Message Format," draft-ietf-pkix-crmf-0X.txt, 1998 (work in
progress).

[CCP] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public Key
Infrastructure, X.509 Certificate and CRL Profile," draft-
ietf-pkix-ipki-part1-0X.txt, 1997 (work in progress).

Document Expiration:  August 27, 1998                            Page 9

[CMS] R. Housley "Cryptographic Message Syntax", draft-ietf-smime-cms-
02.txt, 1998 (work in progress).

[ISONR] ISO/IEC 10181-5:  Security Frameworks in Open Systems.
Non-Repudiation Framework.

[RFC2119] Key works for use in RFCs to Indicate Requirement Levels,
S. Bradner, RFC 2119, March 1997.

9. Authors' Addresses

Carlisle Adams
Entrust Technologies
750 Heron Road
Ottawa, Ontario
K1V 1A7
CANADA
[email-masked]

Robert Zuccherato
Entrust Technologies
750 Heron Road
Ottawa, Ontario
K1V 1A7
CANADA
[email-masked]

Document Expiration:  August 27, 1998                            Page 10

APPENDIX A - Storage of Data and Token

A notary token is useless without the data to which it applies.  For
this reason tokens and their related data MUST be securely stored
together.  The change of a single bit in either the data or the token
renders the entire notarization process for that data meaningless.
Storage of tokens and data in a secure (e.g., tamper proof) environment
is strongly RECOMMENDED.

When data and notary tokens are stored together, the following ASN.1
data type MAY be used.

DataAndToken ::= SEQUENCE  {
     message                      Message,
     notaryToken                  Content Info  }

Note that this object does not need to be signed, as the notary token
already verifies the integrity of the data in the message.  Any
supplementary information whose integrity needs to be protected SHOULD
be part of the message or token.

APPENDIX B - Extending the Life of a Signature

We present an example of a possible use of this notary service.
It produces a stand-alone token that can be used to extend the life of a
signature.  This example assumes that we have total trust in the Notary
Authority.

Signature algorithms and keys have a definite lifetime.  Therefore,
signatures have a definite lifetime.  The Notary Authority can be used
to extend the lifetime of a signature.

In order to extend the lifetime of a signature in this way, the
following technique MAY be used.

A) The signature needs to be notarized.

     1) The signed message is presented to the Notary in the data
        field of NotaryReqInfo under service type ns and an appropriate
        policy.

     2) The Notary verifies that the signature and verification key are
        valid at that time by checking expiry dates and status
        information, and returns a notary token.

B)  The notarized signature MUST be verified.

     1) The signature of the Notary in notary token SHALL be verified
        using the Notary's valid verification key.

In this situation the signer's signing key (and therefore, its
signature) is only valid until some specified time T1.  The NA's
signing key (and therefore, its signature) is valid until some specified
time T2 that is (usually) after time T1.  Without notarization, the

Document Expiration:  August 27, 1998                            Page 11

signer's signature would only be valid until time T1.  With
notarization, the signer's signature remains valid until time T2,
regardless of subsequent revocation or expiry at time T1.

If the signature of the NA is valid, the trust we have in the NA allows
us to conclude that the original signature on the data was valid at
the time included in the notaryInfo field of the notary token.

APPENDIX C - Verifying the Status of a Certificate

We now present an example of how to produce a stand-alone token that can
be used to confirm the revocation status of a certificate.

CRLs and ARLs are updated according to a schedule at regular intervals.
For some purposes, the granularity provided by the CRLs and ARLs is not
fine enough.  Up-to-date revocation status may be needed before the next
CRL or ARL update.  Since the NA MUST have access to current information
regarding certificate status, it can be used to verify the revocation
status of a certificate in this situation.

In order to produce such a token, the following technique MAY be used.

A) The certificate needs to be notarized.

     1) The certificate is presented to the Notary in the data field of
        NotaryReqInfo under service type nc and an appropriate policy.

2)  The Notary verifies that the certificate is valid and that it
        hasn't been revoked and then returns a notary token.

B)  The notary token MUST be verified.

     1) The signature of the Notary in notary token SHALL be verified
        using the Notary's valid verification key.

This notary token can now be used when verifying signatures using the
key corresponding to the certificate.  This service provided by the
NA can be thought of as a supplement to the usual method of checking
revocation status.

Document Expiration:  August 27, 1998                            Page 12

------ =_NextPart_000_01BD4C0A.BD78B3B0--

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 10 Mar 1998 09:32:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

> From: "Balluffi, Frank" <[email-masked]>
>
> What is the foundation or context for this discussion: WHAT ATTACKS ARE
> WE CONCERNED ABOUT?

In addition to the four operational disadvantages listed in a prior
message, I thought up the following actual attack this morning
in the shower :-)

Consider two credit cards with different policies: the Green card
is free and offers no benefits; the Gold card costs .1% per transaction
but offers replacement insurance up to $1000 on goods purchased.

It is in the user's interest to use the Green card for every transaction,
unless the goods received turn out to be defective, in which case the
user might try to substitute the Gold card on the purchase transaction.

The credit card company has the opposite incentive, to switch all
transactions to the Gold card.  And if the merchant pays a different
fee or gets a different commission from the two cards, the merchant
has an incentive to swap certificates too.

Certificate substitution would be prevented by using different keys,
by binding the cert to the transaction, or both.  In the case of
credit cards, any reasonable commerce protocol would bind the cert
into the transaction.  But the attack applies whenever there
are certificates with a shared key and conflicting incentives;
the incentives could be information-based rather than monetary.
Few application protocols (and according to the chair of the S/MIME
working group, *no* email protocols) include any means of preventing
certificate substitution, so key sharing is a vulnerability.

Am I missing something?

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 10 Mar 1998 08:57: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] Multiple certificates for same key?
To: [email-masked]

The PKIX list server seems to be back up, but this message from Monday
hasn't popped out yet, so we'll try again.

   dpk

----- Begin Included Message -----

> From: Tony Bartoletti <[email-masked]>
>
> > From: [email-masked]
> >
> >Wrong mailing list.  What you said above is the SPKI notion, but it's not
> >the PKIX notion, of the semantics of the subject name field in a
> >certificate.
> >
> >Steve
>
> I agree with your characterization of subject name SPKI vis-a-vis PKIX.
>
> Dan makes a secondary point, in that the cost of carrying different keys
> for every usage (identification or authorization, I suppose) be weighed
> against the potential privacy concern of having one key (especially in
> the case of an identity role) employed so widely that tracking usage on
> the one key produces a virtual dossier on the owner.

Tony's characterization is eloquent enough that it cannot be improved
upon, but merely restated.  By following the "wallet and paper signature"
model and having a single public key which announces "This Is Me!", users
would be voluntarily adopting the very thing they refuse to have
imposed upon them externally: a national ID.

My primary objection to multiple certification is the lack of handling
flexibility, not usage tracking.  If certificates are analogous to the
contents of a wallet, then I would like to be able to dynamically decide
what to carry in my wallet depending on where I'm going.  Normally I'd
carry everything, for convenience.  But if I'm going on a trip, I'd
remove the cards I'm not expecting to need so that if the wallet is
lost or stolen, I don't have to cancel everything.

In a token or key database, if every certificate's copy of the
private key has the same value (or in Paul Koning's model, which I
haven't heard of being supported in commercially available tokens or
applications, every certificate refers to the same storage location for
the private key), then the assignment of certificates to storage
modules is done once at issuance.  But if every certificate uses a
different private key, then those keys can be moved in and out of the
storage module as needed to accommodate where the module will be used.
I might normally want to keep my "AMEX Platinum" key on my smartcard,
but if I were going to plug that smartcard into a mall kiosk or an IETF
terminal room machine, I'd rather take the AMEX key off and leave just
an S/MIME email key on the card.

The third objection to multiple certification is that it leads
inexorably to a permanent key that cannot be updated.  Although it is
impossible for a single CA to verify that a key has not been certified
somewhere else, it is certainly possible and often desirable for that
CA to ensure that the key is changed at renewal.  But if a single key
is used for all certificates, and the validity dates for all CAs are
not synchronized, then it is impossible for any CA to rekey it's own
subjects' certificates, much less establish rekey periods that are
appropriate for the purpose of the certificates.

In summary, the disadvantages of a shared key across certificates include:

* inability of the user to change the contents of a storage module
* inability for any CA to establish a policy of rekeying on reissuance
* enables usage tracking
* not supported by current applications (counterexamples welcome)

The advantages include:

* might save memory (if each cert doesn't keep it's own copy of the
  private key).

With regard to comments that a standard requiring users not to share
keys is "unenforceable":  so is any standard recommending behavior that
is in the user's interest.  No one is going to jail for failing
to eat their Recommended Daily Allowance of Vitamin A.  But it is
nonetheless useful to publish RDA numbers ("standards") for vitamins
and minerals to allow consumers to make educated decisions based on
information published by nutrition experts and food producers.

PKIX is an information resource, not just a technical interoperability
specification.  Let's write security considerations that provide some
useful guidance on choosing a key sharing policy.

Dave Kemp

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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Tue, 10 Mar 1998 14:54:09 -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] Multiple certificates for same key?
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

> Denis, David was responding to my original post, which pointed out that
> most of the difficulties we are having with mutliple certificates for the same
> key is due to the fact that the certificate information is not cryptographically
> bound to the message itself.
>
> But did you see my follow up back to him?  I'm somewhat surprised that
> no one responded to it. I suggested that instead of solving this problem
> over and over again for each separate application we should fix
> the root cause, the SIGNED macro itself.

Bob, I am sorry and I should have responded to your message as well.
When I read your message (I did see it), I was not very enthusiastic
with your first proposal (i.e. modifying the SIGNED MACRO) and ... did
not go until the end, so I missed the second proposal which is much
better.

> I then proposed a way of doing that which would not invalidate existing
> code, but would merely require the definition of a new set of signature
> algorithm IDs, where the additional information we might like to cryptographically
> bind would be snuck in as COMPONENTS of the signature. We might even
> be able to find a way to make those additional components optional.
>
> Such components should include the issuer and serial number at a minimum,

You mean issuer name and serial number (not issuer serial number).

> and I
> could come up with a list of additional information that could at least
> be debated as to whether it was worthy of being included. Date/time would be
> certainly be worth discussing, as would some indication of the platform on which
> the signature was created (for audit purposes).

Don't put too much !

> If biometrics were used there
> might be some additional information that would be useful, etc., etc., etc.
>
> If you didn't see the original message, I'd be happy to send it again -- my
> e-mail system was rather flakey that particular evening.

Hereafter is your original message again :

> David,
>
> If we were able to somehow add cryptographic binding of
> the digital signature to the specific certificate that is s
> supposed to be used to validate it, virtually all of my objections
> to issuing more than one certificate per key would disappear,
> and we would be left with some of the positive virtues of that
> approach that others have mentioned.
>
> However, I do NOT think that we should insist that each and
> every protocol reinvent the wheel. Some will do it wrong (as per
> your examples), and some just won't do it at all.
>
> Unfortunately, the SIGNED macro doesn't include a version
> indicator (will we _never_ learn?), so we can't do the version 3
> trick that we pulled when we found that the X.509 certificate
> wasn't adequate for our new extended purpose.
>
> However, I think there is a way out, although from a purist
> architectural standpoint it is an ugly hack. But hey, MISSI did
> it, and what's good enough for the US Government ought to be
> good enough for the rest of us, right?

Let us skip this and go directly to the second proposal.

> What I'm proposing is that we define a new series of digital signature
> algorithm OIDs, which would include the additional information that
> is needed as part of the COMPONENTS.
>
> We can debate the precise information that we might like to include later,
> along with the optimum syntax, but this is the approach that as I
> recall MISSI took to include clearance information and other parameters
> that they had no place to put in the old V1 certificate format. Like I said,
> an ugly, but noble hack.
>
> One potential problem is that although currently in-vogue RSA and
> DSA key lengths (1024 and 2048 bits) would probably be long enough
> to directly include most of what we might like, the 512 bit lengths allowed
> by US export (and some import) regulations might be pretty tight, and
> would be extremely tight for elliptic curves.
>
> One approach to solving this problem would be to use two message digests,
> one for the ToBeSigned, and the other for the ancillary signature data (someone
> has to think of a snappy attribute name ¯ I refuse to be blamed for
> "ancillarySignatureData"), and then include both message digests
> within the signature.  This would work for algorithms of up to 320 bits
> in length, which might still be tight for some elliptic curve algorithms.

Here starts the second proposal.

> The other approach, which could be extended to arbitrarily long
> information, would be to effectively append the existing ToBeSigned
> information (normally a message digest) to the ancillary information, and
> then compute a super message digest over the entire collection. That
> super message digest, plus any additional randomized padding (we
> ought to fix that problem while we are at it) would then be the input
> to the actual signing operation. This would support signature algorithms
> and key lengths which only allow as little as 160 bits of input (or even
> 128 bits, for MD5)).

I agree in principle with the approach. We need to consider two one-way
functions.

> The second approach is obviously superior to the first, assuming
> that the time for a second hash is considered negligible. But can
> anyone think of an even better method?
>
> The benefit of this scheme is that by simply implementing one
> or more new enhanced signature algorithms (e.g., "RSA with
> SHA-1 and ancillary data") within the underlying toolkits,
> virtually all applications would benefit, with virtually no effort at all.

I see it slightly differently. If I want to sign a message with a length
of 1 Mo together with ancillary information, I would like to sign the
message digest of the message instead of the message.

Considering that we are not going to optimize the scheme for messages
smaller than 160 bits, we could always consider to sign the hash of the
message, instead of the message itself. Thus we would sign what is
sometimes called the "imprint" of the message. What is nice is that the
imprint of a message is a characteristic of the message that can be
computed independently of the context of the signature. It can be
generated or check in advance or in parallel. The last step would then
be to compute a hash over that message imprint and the ancillary
information. If there no ancillary information this appears useless, but
there will be !

I do not see this as a replacement to what exists today, but as a new
format "to be used where necessary". To make it clear, instead of "RSA
with SHA-1 and ancillary data" I would prefer to keep "RSA with SHA-1"
but sign an explicit message digest plus ancillary data. When looking
again to the E-mail I sent yesterday, although the addition of
authenticated attributes solves the problem from a security point of
view, it suffers from the performance mentionned above. If you want to
take a look at the CMS specification, it is available at :
ftp://ietf.org/internet-drafts/draft-ietf-smime-cms-03.txt

> And if we do it right, we might even be able to achieve some degree of
> backward compatibility by some sort of slight of hand involving
> mapping the algorithm OIDs to existing algorithms
> in such a way as to ignore the added information if the code doesn't yet
> support it. Maybe some ASN.1 genius can think of a slick trick.

I would prefer a solution without the help of an ASN.1 genius so that
everyone can understand it.  :-)

> Let me let this sink in before I start talking about all of the stuff I
> would like to see included. Hopefully this time we would do it right,
> probably by defining the information to be included in ASN.1 with
> strong typing, so that we additional information is proposed to be
> added it will be simple to do. But that is tomorrow's homework
> assignment.
>
> At a minimum, however, it would have to include some form of
> unique identification of the certificate to be used to validate the
> signature, either issuerName and serial,

This is indeed the minimum, although a SEQUENCE would be more
appropriate and solve the problem of unique names.

> authorityKeyId, or at
> the very least a hash of the certificate contents (although that
> wold cause some problems of circular definition if used within
> the certificate itself.)  Certainly a URL or some other kind of hint
> as to where to actually find the certificate would be a nice touch,
> but we can discuss that independently of the primary issue.

Don't put too much in the same boat ...  :-)

> Whaddaya think about the basic concept?
> Bob

You are certainly on the right track, but do not overload the boat ...

Denis

P.S. My original E-mail follows.

> >David,
> >
> >You posted a VERY important E-mail last week and I am bringing my
> >support to it.
> >
> >> The X.509 "SIGNED" macro might not have been designed with the intent
> >> of supporting this purpose, and so may be excused for not including
> >> a method of binding a certificate to the signed data.
> >>
> >> However, the IETF CMS specification (aka PKCS#7) was designed for
> >> precisely this purpose (providing non-repudiation grade signatures over
> >> generic content), yet it still does not provide a clean method of
> >> binding the signer's certificate to the content.
> >
> >True.
> >
> >> The CMS definition of SignedData includes {content, certs, crls,
> >> signerInfos}, and some other fields.  There may be multiple signatures
> >> applied to the content, each represented by a SignerInfo.  Each
> >> SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
> >> Because the issuerAndSerialNumber field, which uniquely identifies the
> >> certificate used by the signer, is not covered by the signature, it is
> >> not bound to the content.  I'm not sure why PKCS#7 was designed that
> >> way, but it was, and so is CMS.
> >
> >I believe that at the time, PKCS#7 was written, the authors had not
> >non-repudiation in mind, but simply using a digital signature for
> >authenticating a message in real time. For that purpose, the format was
> >fine.
> >
> >> It would have been preferable to define an issuerAndSerialNumber
> >> attribute, which could have been included either in
> >> authenticateAttributes to bind it with the signature, or in
> >> unauthenticatedAttributes if the current semantics of not binding the
> >> signer's cert to the signed content is desired.
> >
> >As the CMS standard is being rewritten in the smime working group,
> >(draft-ietf-smime-cms-03.txt) and since the editor is Russ Housley also
> >a member of the PKIX working group I think it is the perfect time to
> >suggest to make changes. What do you think Russ ?
> >
> >> Perhaps defining a redundant copy of issuerAndSerialNumber, to be
> >> included in authenticatedAttributes, could address the requirement
> >> without breaking backward compatibility.  (It only covers the signer's
> >> cert, not the full path, but it's a start.)
> >
> >Yes. Without breaking compatibility we could also support a SEQUENCE OF
> >issuerAndSerialNumber. The simple change that is needed is to add this
> >attribute in the section 11 (Useful Attributes) from the CMS document.
> >In addition we should mandate the support of such an attribute, if the
> >signed data is to be used in a non-repudiation process.
> >
> >> The uglier alternative is  is to double-sign everything, encapsulating a
> >> signedData within another signedData for each parallel signature.
> >>
> >> Since CMS is intended to be a generic security encapsulation mechanism,
> >> not just an S/MIME-specific structure, those who feel that this
> >> requirement is important (to address either multiple certification of
> >> keys or proof-of-possession) should discuss it in the S/MIME working
> >> group.  (A SigningTime attribute is already defined in CMS, but a
> >> "location" attribute is not.)
> >
> >Unfortunately I am not yet on this mailing list, so why I respond here.
> >
> >Denis

--
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Peter Sylvester <[email-masked]>
Date:         Tue, 10 Mar 1998 11:30:53 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Sylvester <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP using ASN.1
To: [email-masked]

hello,

For the mapping to HTTP I think one should not underestimate the
simplicity of a html page containing something like:

<form action="http://www.edelweb.fr/cgi-bin/eurotrust/certificat-validation" method="post">

  <input type="hidden" name="response-type" value="html">
  <table>

  <tr><td>Hash of IssuerNameAndKey<td><input type="text" name="hash" size=60><br>
  <tr><td>CertificateSerialNumber<td><input type="text" name="serialnumber" size=15>

  <tr><td><td><input type="submit" name="request" value="Submit Request">

  </table>
</form>

Thus a real mapping to HTTP/HTML constructs and not just an encapsulation
might be another appendix of that document?

Peter Sylvester -- EdelWeb France

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Mon, 9 Mar 1998 10:36:18 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP in ASN.1
Comments: cc: "[email-masked]" <[email-masked]>
To: [email-masked]

This is a multi-part message in MIME format.
--------------59992754DCE81649B0461645
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Mike,

Given the number of people requesting (1) OCSP provide better support
for ASN.1 (2) OCSP not be necessarily tied to HTTP (but be able to
benefit from HTTP),  I have taken the liberty making some fairly major
changes to the OCSP spec and would like to offer it up as a basis for
moving forward.

 I believe this re-write has technical merit on the following grounds:

(1) It separates OCSP from HTTP but at the same time the protocol can
be implemented using HTTP (both GET and POST).
(2) It is easier to implement (a new ABNF parser is not required --
uses standard ASN.1)
(3) It is more extensible and more consistent with existing crypto
applications (by virtue of using ASN.1).
(4) It allows multiple cryptographic algorithms in the response (RSA
signatures, Diffie Hellman signatures, revocation tree based responses,
iterated hashing based responses etc.)

There are some other minor changes which I think are important but
details (a) certificate status uses notRevoked instead of valid (since
this protocol just checks revocation status - not validity for
a particular task)
(b) usage of both SHA and MD5 is changed to just a hashing algorithm
(preferrably SHA)
(c) certs are identified by both issuer DN and issuer public key
(explanation in the text) and the serial number.
(d) post is a default method
(e) multiple certificates can be supported in a single request.

Eager to receive your feedback (and also others on the net).

Regards,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303
--------------59992754DCE81649B0461645
Content-Type: text/plain; charset=us-ascii; name="draft-ietf-pkix-ocsp-03.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="draft-ietf-pkix-ocsp-03.txt"

PKIX Working Group                                Mike Myers (VeriSign)
draft-ietf-pkix-ocsp-03.txt                        Rich Ankney (CertCo)
Expires in 6 months                          Ambarish Malpani(ValiCert)
                                              Slava Galperin (Netscape)
                                                             March 1998

                  Internet Public Key Infrastructure
              Online Certificate Status Protocol - OCSP
                    <draft-ietf-pkix-ocsp-03.txt>

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups MAY also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and MAY be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories  on  ftp.is.co.za  (Africa),  nic.nordu.net  (Europe),
munnari.oz.au  (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

1. Abstract

The protocol conventions described in this document satisfy some of
the operational requirements of the Internet Public Key Infrastructure
(PKI). This document specifies a protocol useful in determining the
current status of a digital certificate without the use of CRLs.
Additional mechanisms addressing PKIX operational requirements are
specified in separate documents.

Section 2 provides an overview of the protocol. Section 3 goes through
the functional requirements, while section 4 provides the details of
the protocol. In section 5 we cover security issues with the
protocol. Appendix A demonstrates OCSP over HTTP.

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

2. Protocol Overview

In lieu of or as a supplement to checking against a periodic CRL, it MAY
be necessary to obtain timely status regarding a certificate's
revocation status (cf. PKIX Part 1, Section 3.3). Examples include high-
value fund transfers or the compromise of a highly sensitive key.

The Online Certificate Status Protocol (OCSP) enables applications to
determine the validity and revocation state of an identified
certificate. An OCSP client issues a status request to an OCSP
responder and suspends acceptance of the subject certificate until the
responder provides a response.

This protocol specifies the data that needs to be exchanged between an
application checking the revocation status of a certificate and the
server providing that status.

2.1 Request

An OCSP request contains the following data:

- protocol version
- service request
- target identifier for one or more certificates to be checked
- optional extensions which MAY be processed by the OCSP responder

Upon receipt of a request, an OCSP responder determines if: 1) the
message is well formed, 2) the responder is configured to provide the
requested service, and 3) the responder can perform the requested
service for the certificate in question. If any of the prior
conditions are not met, the OCSP responder produces an error message;
otherwise, it returns a definitive response.

2.2 Response

All definitive responses SHALL be digitally signed. The key
used to sign definitive responses need not be the same key
used to sign the certificate. The key used to sign the response can
belong to one of the following:

- a Trusted Responder, whose key is already embedded in the application
- the CA who issued the certificate in question
- an Authorized Responder, with a certificate which has a special extension
authorizing it to sign OCSP responses

A definitive response message is composed of:

- response type identifier (to allow for different response types)
- response validity interval
- target certificate identifier
- certificate status value
- identification of public key needed to validate the signature
- signature algorithm OID
- optional extensions
- signature computed across hash of previous six values

This specification defines the following definitive response indicators
for use in the certificate status value:

- notRevoked
- revoked
- onHold

The notRevoked state indicates that the certificate is not revoked. It
does not necessarily mean that the certificate was ever issued. Nor
does it mean that the certificate is in its validity interval. A
notRevoked state by an OCSP responder DOES NOT absolve the application
checking the certificate from checking its validity period and
signature.

The revoked state indicates that the certificate has been revoked.

The onHold state corresponds to valid certificates that are
operationally suspended in accordance with PKIX Part 1.

In case of errors, the OCSP Responder may return an error message. Errors
can be of the following types:

- malformedRequest
- requestorUnauthorized
- internalError
- tryLater

A server produces the malformedRequest response if the request received
does not conform to the OCSP syntax.

The response requestorUnauthorized is used in cases where the server
does not consider the client authorized to query it. Authorization
data is not explicitly a part of the request or this protocol.
However, certain responders may choose to require clients to ship an
authorization token with the request and may choose to refuse service
to clients that do not ship a correct authorization token.

The response internalError indicates that the OCSP responder reached
and inconsistent internal state. The query should be retried, potentially
with another responder.

The response tryLater is produced in any circumstance in which the
server has received a well formed OCSP request but is unable to process
it.

2.3 Response Pre-production

The response validity interval noted in the prior section is composed of
a {produced-at, valid-until} pair of elements in the response syntax.
Section 4.2 provides details of the response syntax.

OCSP responders MAY pre-produce signed responses reflecting the current
status of certificates at the time the response was produced. The time
at which the response was produced SHALL be reflected in the produced-at
field of the response.

The producer of the response MAY include a value for valid-until. The
exact interval between produced-at and valid-until for a given
response is a matter of local security and operational policy. If the
valid-until field is not present, the response was known to be correct
at the produced-at time. No assertions are being made about the
current state of the certificate.

If responses are pre-produced, then for a given certificate, the
periodicity of this pre-production SHOULD match the response validity
interval of the most recently produced response.

3. Functional Requirements

3.1 Certificate Content

In order to convey to OCSP clients a well-known point of information
access, CAs SHALL provide the capability to include the
AuthorityInfoAccess extension (defined in PKIX Part 1, section
4.2.2.1) in certificates intended to be applied to the service.

CAs that support an OCSP service, either hosted locally or provided by a
Trusted Third Party, SHALL provide a value for a
uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp
for the accessMethod in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate
corresponds to the URL placed into an OCSP request.

3.2 Error Responses

Upon receipt of a request which fails to parse, the receiving OCSP
responder SHALL respond with an error message. Error responses MAY be
signed.

3.3 Signed Response Acceptance Requirements

Prior to accepting a signed response as valid, OCSP clients SHALL
confirm that:

- The certificate identified in a received response corresponds to
that which was identified in a former request.
- The signature on the response is valid.
- The identity of the signer matches the intended recipient of the
request.
- The signer is currently authorized to sign the response.

4. Detailed Protocol

The ASN.1 syntax imports terms defined in the X.509 Certificate and CRL
Profile Internet Draft. For signature calculation, the data to be signed is
encoded using the ASN.1 distinguished encoding rules (DER) [X.208].

ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.

The terms imported from elsewhere are:
Version, Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name,
AlgorithmIdentifier, GeneralizedTime

4.1 Request Syntax

OCSPRequest     ::=     SEQUENCE {
        version                 [0]     EXPLICIT Version DEFAULT v1,
        hash                            AlgorithmIdentifier,
        requestList                     SEQUENCE OF Request,
        requestExtensions       [1]     EXPLICIT Extensions OPTIONAL
}

Request                 ::=     SEQUENCE {
        issuerNameAndKeyHash            Hash,
        serialNumber                    CertificateSerialNumber,
        cert                    [0]     EXPLICIT Certificate OPTIONAL
}

IssuerNameAndKey                ::=     SEQUENCE {
        issuer                          Name,
        issuerPublicKey                 SubjectPublicKeyInfo
}

Hash                    ::=     OCTET STRING --hash of IssuerNameAndKey--

The issuerNameAndKeyHash is computed by hashing an IssuerNameAndKey
field constructed for the CA in question using a cryptographic hash
function (e.g., SHA-1) specified as the hash algorithm in the request.
There are two reasons to use both the name and the public key to identify the
issuer.

- The Name may be NULL.
- It is possible that two CAs may choose to use the same Name
(uniqueness in the Name is a recommendation that cannot be enforced).
Two CAs will never, however, have the same public key unless the CAs
either explicitly decided to share their private key, or the key of
one of the CAs was compromised).

Support for extensions is OPTIONAL. The critical flag SHOULD NOT be
set for any of them. This standard suggests several useful extensions
in Section 4.4. Additional extensions MAY be defined in additional
RFCs. Unrecognized extensions SHOULD be ignored.

4.2 Response Syntax

This section specifies the ASN.1 specification for a confirmation
response. The actual formatting of the message could vary depending on
the transport mechanism used (http, smtp, ldap, etc.).

4.2.1 ASN.1 Specification of the OCSP Response

OCSPResponse            ::=     SEQUENCE {
        responseStatus                  OCSPResponseStatus,
        responseBytes           [0]     EXPLICIT ResponseBytes OPTIONAL
}

OCSPResponseStatus      ::=     ENUMERATED {
        successful              ( 0 ),  --Response has valid confirmations--
        malformedRequest        ( 1 ),  --Illegal confirmation request--
        requestorUnauthorized   ( 2 ),  --User not authorized to use issuer--
        internalError           ( 3 ),  --Internal error in issuer--
        unsupportedRequest      ( 4 ),  --Server can't support the request--
        tryLater                ( 5 )   --Try again later--
}

ResponseBytes           ::=     SEQUENCE {
        responseType                    OBJECT IDENTIFIER,
        response                        OCTET STRING
}

If the responseStatus is one of the error conditions, responseBytes
are not set.

For a basic OCSP responder, responseType will be id-pkix-ocsp-basic, where:
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-pkix ? }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }

The response will be the DER encoding of BasicOCSPResponse

BasicOCSPResponse       ::=     SEQUENCE {
        version                 [0]     EXPLICIT Version DEFAULT v1,
        signatureAlgorithm              AlgorithmIdentifier,
        responseData                    ResponseData,
        signature                       BIT STRING
}

ResponseData            ::=     SEQUENCE {
        responses                       SEQUENCE OF SingleResponse,
        responseExtensions      [0]     EXPLICIT Extensions OPTIONAL
}

SingleResponse          ::=     SEQUENCE {
        request                         Request,
        certStatus                      CertStatus,
        producedAt                      GeneralizedTime,
        validUntil              [0]     EXPLICIT GeneralizedTime OPTIONAL,
        eventTime               [1]     EXPLICIT GeneralizedTime OPTIONAL,
        singleExtensions        [2]     EXPLICIT Extensions OPTIONAL
}

CertStatus              ::=     CHOICE {
        certStatusType          [0]    EXPLICIT CertStatusType
                                        (notRevoked | onHold),
        statusWithTime          [1]    EXPLICIT StatusWithTime
}

StatusWithTime          ::=     SEQUENCE {
        certStatusType                  CertStatusType (revoked),
        time                            GeneralizedTime
}

CertStatusType          ::=     ENUMERATED {
        notRevoked              (0),    --This serial number is not revoked--
        revoked                 (1),    --Serial number was revoked--
        onHold                  (2),    --Cert is on hold--
}

The semantics of time in StatusWithTime are:
- for revoked, time is the time of revocation

The producedAt and validUntil fields define a validity interval. This
interval corresponds to the {thisUpdate, nextUpdate} CRL validity
interval. Responses whose validUntil value is earlier than the local
system time value SHOULD be considered unreliable. Responses where the
validUntil value is not set are equivalant to a CRL with no time for
nextUpdate.

4.3 Mandatory and Optional Cryptographic Algorithms

Clients that request OCSP services SHALL be capable of processing
responses signed used DSA keys identified by the DSA sig-alg-oid
specified in section 7.2.2 of PKIX Part 1. Clients SHOULD also be
capable of processing RSA signatures as specified in section 7.2.1 of
PKIX Part 1. OCSP responders SHALL support the SHA1 hash algorithm.

4.4 Extensions

This section defines the way to support some commonly requested
tasks. Support for all extensions is OPTIONAL.

4.4.1 Nonce

The nonce cryptographically binds a request and response, to prevent
replay attacks. The nonce is included as one of the requestExtensions,
in requests, while in response it would be included as one of the
responseExtensions.  In both the request and the response, the nonce
will be identified by the object identifier id-pkix-ocsp-nonce, while
the extnValue is the value of the nonce.

id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }

4.4.2 Signed Requests

This extension allows the requestor to sign the request. The
requestor includes an extension that has the signatureIdentifier, the
actual bits of the signature and a sequence of certificates to allow
the OCSP responder to verify the signature. The data to be
signed is just the basic request (none of the extensions). The OCSP
Responder can verify the signature, potentially using certificates
that have been included with the extension. The signature on a request
will be identified by id-pkix-ocsp-signature, while the value will
be SignatureData, where:

id-pkix-ocsp-signature OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }
SignatureData           ::=     SEQUENCE {
        signatureAlgorithm      AlgorithmIdentifier,
        signature               BIT STRING,
        certs           [0]     EXPLICIT SEQUENCE OF Certificate OPTIONAL
}

4.4.3 CRL References

It MAY be desirable for the OCSP responder to indicate the CRL on which
a revoked or held certificate is found. This can be useful where OCSP
is used between repositories, and also as an auditing mechanism. The
CRL may be specified by a URL (the URL at which the CRL is available),
a number (CRL number) or a time (the time at which the relevant CRL
was created). These extensions will be specified as singleExtensions.
The identifier for this extension will be id-pkix-ocsp-crl, while the value
will be CrlID.

id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }
CrlID           ::=     SEQUENCE {
        crlUrl          [0]     EXPLICIT IA5String OPTIONAL,
        crlNum          [1]     EXPLICIT INTEGER OPTIONAL,
        crlTime         [2]     EXPLICIT GeneralizedTime OPTIONAL
}

For the choice crlUrl, the IA5String will specify the URL at which the
CRL is available. For crlNum, the INTEGER will specify the value of the CRL
number extension of the relevant CRL. For crlTime, the GeneralizedTime
will indicate the time at which the relevant CRL was issued.

4.4.4 Other Extensions

CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are also
supported as singleExtensions.

5. Security Considerations

For this service to be effective, systems using certificates must
connect to the certificate status service provider. In the event such
a connection cannot be obtained, these systems could implement CRL
processing logic as a fall-back position.

If a CA authorizes another public key to sign OCSP responses,
compromise of that key is as serious as the compromise of the CA's key
as long as the authorization is valid.

A denial of service vulnerability is evident with respect to a flood
of queries constructed to produce error responses. The production of a
cryptographic signature significantly affects response generation
cycle time, thereby exacerbating the situation. Unsigned error
responses provide a reasonable tradeoff against this particular
attack.

Unsigned error responses open up the protocol to a denial of
service attack, where the attacker sends false error responses.

The use of precomputed responses may allow replay attacks in which
an old (notRevoked) response is replayed prior to its expiration but after
the certificate has been revoked.

This data is information which may conceivably be used to enforce
legal contracts, resolve disputes or transfer financial risk from one
party to another. The design of software that processes this type
should be trustworthy in its design and operations.

6. References

[HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee,
       R. Fielding & H. Frystyk, RFC 1945, May 1996.

[MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels,
 S. Bradner, RFC 2119, March 1997.

[URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter,
M.  McCahill, RFC 1738, December 1994.

7. Author's Address

Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019
[email-masked]

Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA  20151
[email-masked]

Ambarish Malpani
ValiCert, Inc.
3160 W. Bayshore Drive
Palo Alto, CA 94303
[email-masked]

Appendix A

A.1 OCSP over HTTP

This section describes the formatting that will be done to the request and
response to support HTTP.

A.1.1 Request

An OCSP request is an HTTP 1.0 POST method. The Content-Type header
has the value "application/ocsp-request", while the body of the
message is the DER encoding of the OCSPRequest.

A.1.2 Response

An HTTP-based OCSP response is composed of the appropriate HTTP headers,
followed by the DER encoding of the OCSPResponse. The Content-Type
header has the value "application/ocsp-response". The Content-Length
header SHOULD specify the length of the response. Other HTTP headers
MAY be present and MAY be ignored if not understood by the requestor.

Published specification: This document.

--------------59992754DCE81649B0461645--

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 9 Mar 1998 20:24:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Denis, David was responding to my original post, which pointed out that
most of the difficulties we are having with mutliple certificates for the same
key is due to the fact that the certificate information is not cryptographically
bound to the message itself.

But did you see my follow up back to him?  I'm somewhat surprised that
no one responded to it. I suggested that instead of solving this problem
over and over again for each separate application we should fix
the root cause, the SIGNED macro itself.

I then proposed a way of doing that which would not invalidate existing
code, but would merely require the definition of a new set of signature
algorithm IDs, where the additional information we might like to cryptographically
bind would be snuck in as COMPONENTS of the signature. We might even
be able to find a way to make those additional components optional.

Such components should include the issuer and serial number at a minimum, and I
could come up with a list of additional information that could at least
be debated as to whether it was worthy of being included. Date/time would be
certainly be worth discussing, as would some indication of the platform on which
the signature was created (for audit purposes). If biometrics were used there
might be some additional information that would be useful, etc., etc., etc.

If you didn't see the original message, I'd be happy to send it again -- my
e-mail system was rather flakey that particular evening.

Bob

>David,
>
>You posted a VERY important E-mail last week and I am bringing my
>support to it.
>
>> The X.509 "SIGNED" macro might not have been designed with the intent
>> of supporting this purpose, and so may be excused for not including
>> a method of binding a certificate to the signed data.
>>
>> However, the IETF CMS specification (aka PKCS#7) was designed for
>> precisely this purpose (providing non-repudiation grade signatures over
>> generic content), yet it still does not provide a clean method of
>> binding the signer's certificate to the content.
>
>True.
>
>> The CMS definition of SignedData includes {content, certs, crls,
>> signerInfos}, and some other fields.  There may be multiple signatures
>> applied to the content, each represented by a SignerInfo.  Each
>> SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
>> Because the issuerAndSerialNumber field, which uniquely identifies the
>> certificate used by the signer, is not covered by the signature, it is
>> not bound to the content.  I'm not sure why PKCS#7 was designed that
>> way, but it was, and so is CMS.
>
>I believe that at the time, PKCS#7 was written, the authors had not
>non-repudiation in mind, but simply using a digital signature for
>authenticating a message in real time. For that purpose, the format was
>fine.
>
>> It would have been preferable to define an issuerAndSerialNumber
>> attribute, which could have been included either in
>> authenticateAttributes to bind it with the signature, or in
>> unauthenticatedAttributes if the current semantics of not binding the
>> signer's cert to the signed content is desired.
>
>As the CMS standard is being rewritten in the smime working group,
>(draft-ietf-smime-cms-03.txt) and since the editor is Russ Housley also
>a member of the PKIX working group I think it is the perfect time to
>suggest to make changes. What do you think Russ ?
>
>> Perhaps defining a redundant copy of issuerAndSerialNumber, to be
>> included in authenticatedAttributes, could address the requirement
>> without breaking backward compatibility.  (It only covers the signer's
>> cert, not the full path, but it's a start.)
>
>Yes. Without breaking compatibility we could also support a SEQUENCE OF
>issuerAndSerialNumber. The simple change that is needed is to add this
>attribute in the section 11 (Useful Attributes) from the CMS document.
>In addition we should mandate the support of such an attribute, if the
>signed data is to be used in a non-repudiation process.
>
>> The uglier alternative is  is to double-sign everything, encapsulating a
>> signedData within another signedData for each parallel signature.
>>
>> Since CMS is intended to be a generic security encapsulation mechanism,
>> not just an S/MIME-specific structure, those who feel that this
>> requirement is important (to address either multiple certification of
>> keys or proof-of-possession) should discuss it in the S/MIME working
>> group.  (A SigningTime attribute is already defined in CMS, but a
>> "location" attribute is not.)
>
>Unfortunately I am not yet on this mailing list, so why I respond here.
>
>Denis
>
>--
> ***  Please note that the E-mail address has changed ! Update it.  ***
>      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Mon, 9 Mar 1998 17:23:15 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP using ASN.1
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

This is a multi-part message in MIME format.
--------------C02ED1D918D2DB363986E6E7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If you have already received this message, I appologize - it didn't
seem to ever come back to me.

Ambarish

Hi Mike,

Given the number of people requesting (1) OCSP provide better support
for ASN.1 (2) OCSP not be necessarily tied to HTTP (but be able to
benefit from HTTP),  I have taken the liberty making some fairly major
changes to the OCSP spec and would like to offer it up as a basis for
moving forward.

 I believe this re-write has technical merit on the following grounds:

(1) It separates OCSP from HTTP but at the same time the protocol can
be implemented using HTTP (both GET and POST).
(2) It is easier to implement (a new ABNF parser is not required --
uses standard ASN.1)
(3) It is more extensible and more consistent with existing crypto
applications (by virtue of using ASN.1).
(4) It allows multiple cryptographic algorithms in the response (RSA
signatures, Diffie Hellman signatures, revocation tree based responses,
iterated hashing based responses etc.)

There are some other minor changes which I think are important but
details (a) certificate status uses notRevoked instead of valid (since
this protocol just checks revocation status - not validity for
a particular task)
(b) usage of both SHA and MD5 is changed to just a hashing algorithm
(preferrably SHA)
(c) certs are identified by both issuer DN and issuer public key
(explanation in the text) and the serial number.
(d) post is a default method
(e) multiple certificates can be supported in a single request.

Eager to receive your feedback (and also others on the net).

Regards,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303
--------------C02ED1D918D2DB363986E6E7
Content-Type: text/plain; charset=us-ascii; name="draft-ietf-pkix-ocsp-03.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="draft-ietf-pkix-ocsp-03.txt"

PKIX Working Group                                Mike Myers (VeriSign)
draft-ietf-pkix-ocsp-03.txt                        Rich Ankney (CertCo)
Expires in 6 months                          Ambarish Malpani(ValiCert)
                                              Slava Galperin (Netscape)
                                                             March 1998

                  Internet Public Key Infrastructure
              Online Certificate Status Protocol - OCSP
                    <draft-ietf-pkix-ocsp-03.txt>

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups MAY also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and MAY be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories  on  ftp.is.co.za  (Africa),  nic.nordu.net  (Europe),
munnari.oz.au  (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

1. Abstract

The protocol conventions described in this document satisfy some of
the operational requirements of the Internet Public Key Infrastructure
(PKI). This document specifies a protocol useful in determining the
current status of a digital certificate without the use of CRLs.
Additional mechanisms addressing PKIX operational requirements are
specified in separate documents.

Section 2 provides an overview of the protocol. Section 3 goes through
the functional requirements, while section 4 provides the details of
the protocol. In section 5 we cover security issues with the
protocol. Appendix A demonstrates OCSP over HTTP.

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

2. Protocol Overview

In lieu of or as a supplement to checking against a periodic CRL, it MAY
be necessary to obtain timely status regarding a certificate's
revocation status (cf. PKIX Part 1, Section 3.3). Examples include high-
value fund transfers or the compromise of a highly sensitive key.

The Online Certificate Status Protocol (OCSP) enables applications to
determine the validity and revocation state of an identified
certificate. An OCSP client issues a status request to an OCSP
responder and suspends acceptance of the subject certificate until the
responder provides a response.

This protocol specifies the data that needs to be exchanged between an
application checking the revocation status of a certificate and the
server providing that status.

2.1 Request

An OCSP request contains the following data:

- protocol version
- service request
- target identifier for one or more certificates to be checked
- optional extensions which MAY be processed by the OCSP responder

Upon receipt of a request, an OCSP responder determines if: 1) the
message is well formed, 2) the responder is configured to provide the
requested service, and 3) the responder can perform the requested
service for the certificate in question. If any of the prior
conditions are not met, the OCSP responder produces an error message;
otherwise, it returns a definitive response.

2.2 Response

All definitive responses SHALL be digitally signed. The key
used to sign definitive responses need not be the same key
used to sign the certificate. The key used to sign the response can
belong to one of the following:

- a Trusted Responder, whose key is already embedded in the application
- the CA who issued the certificate in question
- an Authorized Responder, with a certificate which has a special extension
authorizing it to sign OCSP responses

A definitive response message is composed of:

- response type identifier (to allow for different response types)
- response validity interval
- target certificate identifier
- certificate status value
- identification of public key needed to validate the signature
- signature algorithm OID
- optional extensions
- signature computed across hash of previous six values

This specification defines the following definitive response indicators
for use in the certificate status value:

- notRevoked
- revoked
- onHold

The notRevoked state indicates that the certificate is not revoked. It
does not necessarily mean that the certificate was ever issued. Nor
does it mean that the certificate is in its validity interval. A
notRevoked state by an OCSP responder DOES NOT absolve the application
checking the certificate from checking its validity period and
signature.

The revoked state indicates that the certificate has been revoked.

The onHold state corresponds to valid certificates that are
operationally suspended in accordance with PKIX Part 1.

In case of errors, the OCSP Responder may return an error message. Errors
can be of the following types:

- malformedRequest
- requestorUnauthorized
- internalError
- tryLater

A server produces the malformedRequest response if the request received
does not conform to the OCSP syntax.

The response requestorUnauthorized is used in cases where the server
does not consider the client authorized to query it. Authorization
data is not explicitly a part of the request or this protocol.
However, certain responders may choose to require clients to ship an
authorization token with the request and may choose to refuse service
to clients that do not ship a correct authorization token.

The response internalError indicates that the OCSP responder reached
and inconsistent internal state. The query should be retried, potentially
with another responder.

The response tryLater is produced in any circumstance in which the
server has received a well formed OCSP request but is unable to process
it.

2.3 Response Pre-production

The response validity interval noted in the prior section is composed of
a {produced-at, valid-until} pair of elements in the response syntax.
Section 4.2 provides details of the response syntax.

OCSP responders MAY pre-produce signed responses reflecting the current
status of certificates at the time the response was produced. The time
at which the response was produced SHALL be reflected in the produced-at
field of the response.

The producer of the response MAY include a value for valid-until. The
exact interval between produced-at and valid-until for a given
response is a matter of local security and operational policy. If the
valid-until field is not present, the response was known to be correct
at the produced-at time. No assertions are being made about the
current state of the certificate.

If responses are pre-produced, then for a given certificate, the
periodicity of this pre-production SHOULD match the response validity
interval of the most recently produced response.

3. Functional Requirements

3.1 Certificate Content

In order to convey to OCSP clients a well-known point of information
access, CAs SHALL provide the capability to include the
AuthorityInfoAccess extension (defined in PKIX Part 1, section
4.2.2.1) in certificates intended to be applied to the service.

CAs that support an OCSP service, either hosted locally or provided by a
Trusted Third Party, SHALL provide a value for a
uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp
for the accessMethod in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate
corresponds to the URL placed into an OCSP request.

3.2 Error Responses

Upon receipt of a request which fails to parse, the receiving OCSP
responder SHALL respond with an error message. Error responses MAY be
signed.

3.3 Signed Response Acceptance Requirements

Prior to accepting a signed response as valid, OCSP clients SHALL
confirm that:

- The certificate identified in a received response corresponds to
that which was identified in a former request.
- The signature on the response is valid.
- The identity of the signer matches the intended recipient of the
request.
- The signer is currently authorized to sign the response.

4. Detailed Protocol

The ASN.1 syntax imports terms defined in the X.509 Certificate and CRL
Profile Internet Draft. For signature calculation, the data to be signed is
encoded using the ASN.1 distinguished encoding rules (DER) [X.208].

ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.

The terms imported from elsewhere are:
Version, Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name,
AlgorithmIdentifier, GeneralizedTime

4.1 Request Syntax

OCSPRequest     ::=     SEQUENCE {
        version                 [0]     EXPLICIT Version DEFAULT v1,
        hash                            AlgorithmIdentifier,
        requestList                     SEQUENCE OF Request,
        requestExtensions       [1]     EXPLICIT Extensions OPTIONAL
}

Request                 ::=     SEQUENCE {
        issuerNameAndKeyHash            Hash,
        serialNumber                    CertificateSerialNumber,
        cert                    [0]     EXPLICIT Certificate OPTIONAL
}

IssuerNameAndKey                ::=     SEQUENCE {
        issuer                          Name,
        issuerPublicKey                 SubjectPublicKeyInfo
}

Hash                    ::=     OCTET STRING --hash of IssuerNameAndKey--

The issuerNameAndKeyHash is computed by hashing an IssuerNameAndKey
field constructed for the CA in question using a cryptographic hash
function (e.g., SHA-1) specified as the hash algorithm in the request.
There are two reasons to use both the name and the public key to identify the
issuer.

- The Name may be NULL.
- It is possible that two CAs may choose to use the same Name
(uniqueness in the Name is a recommendation that cannot be enforced).
Two CAs will never, however, have the same public key unless the CAs
either explicitly decided to share their private key, or the key of
one of the CAs was compromised).

Support for extensions is OPTIONAL. The critical flag SHOULD NOT be
set for any of them. This standard suggests several useful extensions
in Section 4.4. Additional extensions MAY be defined in additional
RFCs. Unrecognized extensions SHOULD be ignored.

4.2 Response Syntax

This section specifies the ASN.1 specification for a confirmation
response. The actual formatting of the message could vary depending on
the transport mechanism used (http, smtp, ldap, etc.).

4.2.1 ASN.1 Specification of the OCSP Response

OCSPResponse            ::=     SEQUENCE {
        responseStatus                  OCSPResponseStatus,
        responseBytes           [0]     EXPLICIT ResponseBytes OPTIONAL
}

OCSPResponseStatus      ::=     ENUMERATED {
        successful              ( 0 ),  --Response has valid confirmations--
        malformedRequest        ( 1 ),  --Illegal confirmation request--
        requestorUnauthorized   ( 2 ),  --User not authorized to use issuer--
        internalError           ( 3 ),  --Internal error in issuer--
        unsupportedRequest      ( 4 ),  --Server can't support the request--
        tryLater                ( 5 )   --Try again later--
}

ResponseBytes           ::=     SEQUENCE {
        responseType                    OBJECT IDENTIFIER,
        response                        OCTET STRING
}

If the responseStatus is one of the error conditions, responseBytes
are not set.

For a basic OCSP responder, responseType will be id-pkix-ocsp-basic, where:
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-pkix ? }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }

The response will be the DER encoding of BasicOCSPResponse

BasicOCSPResponse       ::=     SEQUENCE {
        version                 [0]     EXPLICIT Version DEFAULT v1,
        signatureAlgorithm              AlgorithmIdentifier,
        responseData                    ResponseData,
        signature                       BIT STRING
}

ResponseData            ::=     SEQUENCE {
        responses                       SEQUENCE OF SingleResponse,
        responseExtensions      [0]     EXPLICIT Extensions OPTIONAL
}

SingleResponse          ::=     SEQUENCE {
        request                         Request,
        certStatus                      CertStatus,
        producedAt                      GeneralizedTime,
        validUntil              [0]     EXPLICIT GeneralizedTime OPTIONAL,
        eventTime               [1]     EXPLICIT GeneralizedTime OPTIONAL,
        singleExtensions        [2]     EXPLICIT Extensions OPTIONAL
}

CertStatus              ::=     CHOICE {
        certStatusType          [0]    EXPLICIT CertStatusType
                                        (notRevoked | onHold),
        statusWithTime          [1]    EXPLICIT StatusWithTime
}

StatusWithTime          ::=     SEQUENCE {
        certStatusType                  CertStatusType (revoked),
        time                            GeneralizedTime
}

CertStatusType          ::=     ENUMERATED {
        notRevoked              (0),    --This serial number is not revoked--
        revoked                 (1),    --Serial number was revoked--
        onHold                  (2),    --Cert is on hold--
}

The semantics of time in StatusWithTime are:
- for revoked, time is the time of revocation

The producedAt and validUntil fields define a validity interval. This
interval corresponds to the {thisUpdate, nextUpdate} CRL validity
interval. Responses whose validUntil value is earlier than the local
system time value SHOULD be considered unreliable. Responses where the
validUntil value is not set are equivalant to a CRL with no time for
nextUpdate.

4.3 Mandatory and Optional Cryptographic Algorithms

Clients that request OCSP services SHALL be capable of processing
responses signed used DSA keys identified by the DSA sig-alg-oid
specified in section 7.2.2 of PKIX Part 1. Clients SHOULD also be
capable of processing RSA signatures as specified in section 7.2.1 of
PKIX Part 1. OCSP responders SHALL support the SHA1 hash algorithm.

4.4 Extensions

This section defines the way to support some commonly requested
tasks. Support for all extensions is OPTIONAL.

4.4.1 Nonce

The nonce cryptographically binds a request and response, to prevent
replay attacks. The nonce is included as one of the requestExtensions,
in requests, while in response it would be included as one of the
responseExtensions.  In both the request and the response, the nonce
will be identified by the object identifier id-pkix-ocsp-nonce, while
the extnValue is the value of the nonce.

id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }

4.4.2 Signed Requests

This extension allows the requestor to sign the request. The
requestor includes an extension that has the signatureIdentifier, the
actual bits of the signature and a sequence of certificates to allow
the OCSP responder to verify the signature. The data to be
signed is just the basic request (none of the extensions). The OCSP
Responder can verify the signature, potentially using certificates
that have been included with the extension. The signature on a request
will be identified by id-pkix-ocsp-signature, while the value will
be SignatureData, where:

id-pkix-ocsp-signature OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }
SignatureData           ::=     SEQUENCE {
        signatureAlgorithm      AlgorithmIdentifier,
        signature               BIT STRING,
        certs           [0]     EXPLICIT SEQUENCE OF Certificate OPTIONAL
}

4.4.3 CRL References

It MAY be desirable for the OCSP responder to indicate the CRL on which
a revoked or held certificate is found. This can be useful where OCSP
is used between repositories, and also as an auditing mechanism. The
CRL may be specified by a URL (the URL at which the CRL is available),
a number (CRL number) or a time (the time at which the relevant CRL
was created). These extensions will be specified as singleExtensions.
The identifier for this extension will be id-pkix-ocsp-crl, while the value
will be CrlID.

id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp ? }
CrlID           ::=     SEQUENCE {
        crlUrl          [0]     EXPLICIT IA5String OPTIONAL,
        crlNum          [1]     EXPLICIT INTEGER OPTIONAL,
        crlTime         [2]     EXPLICIT GeneralizedTime OPTIONAL
}

For the choice crlUrl, the IA5String will specify the URL at which the
CRL is available. For crlNum, the INTEGER will specify the value of the CRL
number extension of the relevant CRL. For crlTime, the GeneralizedTime
will indicate the time at which the relevant CRL was issued.

4.4.4 Other Extensions

CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are also
supported as singleExtensions.

5. Security Considerations

For this service to be effective, systems using certificates must
connect to the certificate status service provider. In the event such
a connection cannot be obtained, these systems could implement CRL
processing logic as a fall-back position.

If a CA authorizes another public key to sign OCSP responses,
compromise of that key is as serious as the compromise of the CA's key
as long as the authorization is valid.

A denial of service vulnerability is evident with respect to a flood
of queries constructed to produce error responses. The production of a
cryptographic signature significantly affects response generation
cycle time, thereby exacerbating the situation. Unsigned error
responses provide a reasonable tradeoff against this particular
attack.

Unsigned error responses open up the protocol to a denial of
service attack, where the attacker sends false error responses.

The use of precomputed responses may allow replay attacks in which
an old (notRevoked) response is replayed prior to its expiration but after
the certificate has been revoked.

This data is information which may conceivably be used to enforce
legal contracts, resolve disputes or transfer financial risk from one
party to another. The design of software that processes this type
should be trustworthy in its design and operations.

6. References

[HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee,
       R. Fielding & H. Frystyk, RFC 1945, May 1996.

[MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels,
 S. Bradner, RFC 2119, March 1997.

[URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter,
M.  McCahill, RFC 1738, December 1994.

7. Author's Address

Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019
[email-masked]

Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA  20151
[email-masked]

Ambarish Malpani
ValiCert, Inc.
3160 W. Bayshore Drive
Palo Alto, CA 94303
[email-masked]

Appendix A

A.1 OCSP over HTTP

This section describes the formatting that will be done to the request and
response to support HTTP.

A.1.1 Request

An OCSP request is an HTTP 1.0 POST method. The Content-Type header
has the value "application/ocsp-request", while the body of the
message is the DER encoding of the OCSPRequest.

A.1.2 Response

An HTTP-based OCSP response is composed of the appropriate HTTP headers,
followed by the DER encoding of the OCSPResponse. The Content-Type
header has the value "application/ocsp-response". The Content-Length
header SHOULD specify the length of the response. Other HTTP headers
MAY be present and MAY be ignored if not understood by the requestor.

Published specification: This document.

--------------C02ED1D918D2DB363986E6E7--

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 9 Mar 1998 20:11:19 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

>If I understand correctly, there is a scenario for cross-certification
>whereby I retrieve your public key from a directory (where it may be
>stored as a key, or it may be sealed into a certificate) and then I
>issue a certificate containing your public key signed by me.
>
>If this is accurate, it follows that there will be many certificates
>extant containing the same public key.
>
>Another issue: any ambiguity which may proceed from the intentional
>issuance of two different certs against one key pair, will also apply
>whenever random processes or operational errors produce identical key
>pairs for different users. Although we can prefer that this not happen
>we cannot prevent it by mandate, therefore the infrastructure must be
>sufficiently robust that it not fail when this condition is encountered.
>
>-Dwight

Both valid points, and among the reasons why I didn't say "never".

Bob

Approved-By:  Michael Leahy <[email-masked]>
Date:         Mon, 9 Mar 1998 16:13:58 UT
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: Michael Leahy <[email-masked]>
Subject:      [IETF-PKIX] registering company object identifiers
To: [email-masked]

Hi

To register an object identifier for a company I assume you contact (if in the USA)
http://www.ansi.org but who is the appropriate organization for Europe ?

Also the URL http://www.ansi.org  appears to be down at the moment - have ANSI moved there Web site or what's up ?

Regards
Michael Leahy
ISOCOR

Approved-By:  Dwight Arthur <[email-masked]>
Date:         Mon, 9 Mar 1998 17:12:56 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dwight Arthur <[email-masked]>
Subject:      [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

If I understand correctly, there is a scenario for cross-certification
whereby I retrieve your public key from a directory (where it may be
stored as a key, or it may be sealed into a certificate) and then I
issue a certificate containing your public key signed by me.

If this is accurate, it follows that there will be many certificates
extant containing the same public key.

Another issue: any ambiguity which may proceed from the intentional
issuance of two different certs against one key pair, will also apply
whenever random processes or operational errors produce identical key
pairs for different users. Although we can prefer that this not happen
we cannot prevent it by mandate, therefore the infrastructure must be
sufficiently robust that it not fail when this condition is encountered.

-Dwight

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 9 Mar 1998 15:11:42 -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] Multiple certificates for same key?
Comments: cc: [email-masked]
To: [email-masked]

David,

You posted a VERY important E-mail last week and I am bringing my
support to it.

> The X.509 "SIGNED" macro might not have been designed with the intent
> of supporting this purpose, and so may be excused for not including
> a method of binding a certificate to the signed data.
>
> However, the IETF CMS specification (aka PKCS#7) was designed for
> precisely this purpose (providing non-repudiation grade signatures over
> generic content), yet it still does not provide a clean method of
> binding the signer's certificate to the content.

True.

> The CMS definition of SignedData includes {content, certs, crls,
> signerInfos}, and some other fields.  There may be multiple signatures
> applied to the content, each represented by a SignerInfo.  Each
> SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
> Because the issuerAndSerialNumber field, which uniquely identifies the
> certificate used by the signer, is not covered by the signature, it is
> not bound to the content.  I'm not sure why PKCS#7 was designed that
> way, but it was, and so is CMS.

I believe that at the time, PKCS#7 was written, the authors had not
non-repudiation in mind, but simply using a digital signature for
authenticating a message in real time. For that purpose, the format was
fine.

> It would have been preferable to define an issuerAndSerialNumber
> attribute, which could have been included either in
> authenticateAttributes to bind it with the signature, or in
> unauthenticatedAttributes if the current semantics of not binding the
> signer's cert to the signed content is desired.

As the CMS standard is being rewritten in the smime working group,
(draft-ietf-smime-cms-03.txt) and since the editor is Russ Housley also
a member of the PKIX working group I think it is the perfect time to
suggest to make changes. What do you think Russ ?

> Perhaps defining a redundant copy of issuerAndSerialNumber, to be
> included in authenticatedAttributes, could address the requirement
> without breaking backward compatibility.  (It only covers the signer's
> cert, not the full path, but it's a start.)

Yes. Without breaking compatibility we could also support a SEQUENCE OF
issuerAndSerialNumber. The simple change that is needed is to add this
attribute in the section 11 (Useful Attributes) from the CMS document.
In addition we should mandate the support of such an attribute, if the
signed data is to be used in a non-repudiation process.

> The uglier alternative is  is to double-sign everything, encapsulating a
> signedData within another signedData for each parallel signature.
>
> Since CMS is intended to be a generic security encapsulation mechanism,
> not just an S/MIME-specific structure, those who feel that this
> requirement is important (to address either multiple certification of
> keys or proof-of-possession) should discuss it in the S/MIME working
> group.  (A SigningTime attribute is already defined in CMS, but a
> "location" attribute is not.)

Unfortunately I am not yet on this mailing list, so why I respond here.

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Fri, 6 Mar 1998 17:22:19 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: cc: Stephen Kent <[email-masked]>
To: [email-masked]

Stephen,

At 12:07 PM 3/6/98 -0500, you wrote:
>Dan,
>
>>Let's get this straight -- the key is the identity,
>>your name is a handle.  If liberty means anything, you
>>can call yourself what you want hence identity-to-handle
>>mapping will be many to many.  The tradeoff is your
>>complexity eval of managing O(10**2) keys versus your
>>exposure eval of published cross correlation of the key
>>sharing amongst certs.
>
>Wrong mailing list.  What you said above is the SPKI notion, but it's not
>the PKIX notion, of the semantics of the subject name field in a
>certificate.
>
>Steve

I agree with your characterization of subject name SPKI vis-a-vis PKIX.

Dan makes a secondary point, in that the cost of carrying different keys
for every usage (identification or authorization, I suppose) be weighed
against the potential privacy concern of having one key (especially in
the case of an identity role) employed so widely that tracking usage on
the one key produces a virtual dossier on the owner.

Being primarily a theoretic type, I imagine infinite cpu, storage and
bandwidth are available now, or will be next Tuesday, so I tend to ignore
spacetime considerations at my peril.

P.S.  Hope to hear you speak in Reston at the FPKI thing.

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Russ Housley <[email-masked]>
Date:         Thu, 5 Mar 1998 18:50:27 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

At 06:32 PM 3/5/98 +0200, Mark Shuttleworth wrote:
>> Let's get this straight -- the key is the identity,
>> your name is a handle.  If liberty means anything, you
>> can call yourself what you want hence identity-to-handle
>> mapping will be many to many.  The tradeoff is your
>> complexity eval of managing O(10**2) keys versus your
>> exposure eval of published cross correlation of the key
>> sharing amongst certs.
>
>Gotta disagree.  The name is your identity (and potentially your
>authority).  The key is merely a way to tie an action (signature) to that
>identity.  The problem is tht one-key-many-certs can mean that an action
>is tied to multiple identities.  It's not a huge problem.
>
If a certificate includes more than one AltSubjectName, then action is tied
to multiple identities using one certificate.  Why is it a problem that the
same thing can be accomplished with more than one certificate.

Russ

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Fri, 6 Mar 1998 15:06:27 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

All,

Please note that in the scenarios I have given regarding government
requirements for crypto key recovery, I intend this meaning to apply
to PKI keys *used* by government for government business, and not
necessarily for recovery of private-use crypto keys.  My personal
feelings are that key recovery should be a "local policy" issue.

Regarding David Kemp's response to Paul Koning, I think that we can
all agree that two identical strings of bits are the *same* key,
regardless of how disparately generated.  I am sure Paul meant as
much.  The "second" certification of a key, contrary in use to a
policy specified in the first certification, represents a "null-
policy-intersection" for the use of that key.  In other words, the
key cannot be used without the user being in violation of policy.

Government wants to know how to deter and/or detect such violation.

Where a policy-intersection is non-null, use should be valid where
such usage lies properly in this intersection.  Else again there is
a violation of some policy.

I am sure that Paul did not mean to imply that a key separately
certified was a "different key" and that "null-intersection" meant
freedom to use each key according to (effectively) the union of the
usage policies.

___TONY___

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Paul Koning <[email-masked]>
Date:         Fri, 6 Mar 1998 17:48: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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

...
 David> More realistically, if one CA's Certification Practices
 David> Statement says that subscribers will be required to keep their
 David> private keys in a FIPS-140 rated module, and another CA allows
 David> subscribers to keep them in unencrypted hard disk files, then
 David> if I happen to request certification of two keys which happen
 David> to have the same bit pattern from the two CAs, one of the CA's
 David> policies may have been violated.
 >>  That doesn't follow at all.  You only get into trouble if the
 >> intersection of the requirements of the various CAs is null.

 David> That's a contrived example - requiring the subscriber to adopt
 David> the Clintonesque attitude that there are really two keys.
 David> (The two keys just happen to have the same bits.)  They are
 David> two different pieces of data stored in two different
 David> locations.  If key B is stored in the clear, that doesn't
 David> technically violate CA A's restriction.  But if key A and key
 David> B happen to have the same value, the adverse effect on
 David> security is the same as if key A were stored in the clear,
 David> violating CA A's restriction.

I must be missing something very basic here.

You seem to be saying that I would store the *private* key in two
places because I have two certificates for that same key.

That doesn't compute.  Clearly I would store the private key only
once.  That after all was the reason I wanted it to be one key and not
two...  And furthermore, given that I'm a good responsible person :-)
I'll store it in conformance with the strictest rules for protecting
secret keys that apply to me.

In the example, that would mean using a FIPS-140 module, which will
satisfy the requirements of both CAs.

        paul

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Fri, 6 Mar 1998 14:31:19 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
Comments: cc: Paul Koning <[email-masked]>
To: [email-masked]

At 04:10 PM 3/6/98 -0500, responding to David Kemp, Paul Koning wrote, in
part:

> David> More realistically, if one CA's Certification Practices
> David> Statement says that subscribers will be required to keep their
> David> private keys in a FIPS-140 rated module, and another CA allows
> David> subscribers to keep them in unencrypted hard disk files, then
> David> if I happen to request certification of two keys which happen
> David> to have the same bit pattern from the two CAs, one of the CA's
> David> policies may have been violated.
>
>That doesn't follow at all.  You only get into trouble if the
>intersection of the requirements of the various CAs is null.
>
>In the example you quoted, all that's needed is that the private key
>has to be in a rated module, since one of the CAs requires that.  So
>long as the other CA doesn't have a policy *forbidding* the use of a
>rated module, you're all set.

I tend to agree.  More interesting, however, is the case given by David
that you did not explicitly address.  This is where the two certs demand
crypto-only and signature-only usage, respectively.  Granted, as such
the usage intersection should prove to be null, but this intersection
(as in the previous storage example) occurs in execution of policy, and
not in code.  Consider as well these two scenarios:

1.  Government usage for crypto will demand provision for key recovery.
Suppose they are silent on recovery of signature key usage.  In such case,
one would be conforming only if key recovery is available in both usages.
Not a great idea.  (Actually, a very bad idea.)

2.  Government usage for crypto demands provision for key recovery, but
also mandates strict guarantees against the possibility of key recovery
for signature keys (we should all demand this in my personal opinion.)
Such a demand precludes the use of a key for both purposes, and any
such dual-certification should produce the "empty intersection" that
you spoke of previously.  The question becomes one of enforcement.
Under such circumstances, it should be impossible to use the key, or
to have the second use certified.  At the very least, government should
demand that attempted dual use be detectable.

But how is software to know what other certifications a key may have?

>Using certificates to describe authorization means of course that I
>won't just check whether there exists a certificate that validates a
>signature -- I'd also check that the certificate is one that grants
>the kind of authorization I'm interested in.  For example, to
>validate, say, a dialup access attempt, I might look for a certificate
>issued by my company.

This principle I agree with as well.

>        paul
>

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 6 Mar 1998 17:10:35 -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] Multiple Certificates
To: [email-masked]

>  David> If some other person gets a copy of my private key, that is a
>  David> key compromise.  If I have a keypair certified for one
>  David> purpose, and I take that private key and request that it be
>  David> certified for a different purpose, that is a key compromise
>  David> from one of my schizophrenic personalities to another :-).
>
> I don't see the issue.
>
> If your private key is compromised, your private key is compromised,
> and the validity of all signatures made by that key is thrown in
> doubt.  Whether the corresponding public key is attested by one or by
> a million certificates makes no difference.

Let me try to put it another way, make a different analogy that
might help, or might just confuse.

I like using Unix because it has multiple users.  If I administer
a machine (say my own personal machine at home), I know the root
password and the passwords for any number of users.  But I only
log in using the root password infrequently to do important stuff.
Most of the time I use my normal user account.  And when I want
to do something especially dangerous, like running a program picked
up off the Internet, I log in as a different user with minimal privileges
so it can't read or write my normal files.
Do you agree that this is prudent?

Now say I have three certs, one for doing important stuff (signing
contracts), one for doing regular stuff (signing email), and one for
testing.  I keep the important private key in a token that isn't normally
plugged in to the machine.  I keep the normal key in a disk file, encrypted.
And the test key is kept in whatever form is most useful for testing
software, unencrypted.

If all three keys have the same value, then anyone who gets onto the
machine and gets a copy of the test key now has a copy of the key I am
very careful to store on a token.
Do you agree that this is a bad situation?

Do you agree that if I have a million certs, each with a different
key, then compromising one of them leaves the other 999,999 unaffected?

>  David> More realistically, if one CA's Certification Practices
>  David> Statement says that subscribers will be required to keep their
>  David> private keys in a FIPS-140 rated module, and another CA allows
>  David> subscribers to keep them in unencrypted hard disk files, then
>  David> if I happen to request certification of two keys which happen
>  David> to have the same bit pattern from the two CAs, one of the CA's
>  David> policies may have been violated.
>
> That doesn't follow at all.  You only get into trouble if the
> intersection of the requirements of the various CAs is null.

That's a contrived example - requiring the subscriber to adopt the
Clintonesque attitude that there are really two keys.  (The two
keys just happen to have the same bits.)  They are two different
pieces of data stored in two different locations.  If key B is stored
in the clear, that doesn't technically violate CA A's restriction.  But
if key A and key B happen to have the same value, the adverse effect
on security is the same as if key A were stored in the clear, violating
CA A's restriction.

> It seems to me that, given that many people view certificates as
> things that describe authority (roles) and not identity, you're going
> to have a pile of them.  And if you do, there are good reasons to want
> to minimize the number of private keys.

What is one good reason to minimize the number of private keys?

You aren't going to save much money by skimping on memory to store
private keys.  And you aren't going to gain any convenience; when you
pick a cert you get the private key that goes with it, whether that
is the same value or a different value than the keys for your other
certs.

> To apply one of the standard analogies again: while I have one
> identity, I have a lot of different authorizations (roles), and lots
> of different pieces of plastic and paper attesting to these.  But my
> signature on all of them is the same scribble.

This is a meaningless analogy.  If your digital signature was always
the same electronic scribble, it wouldn't be very hard for anyone
to forge your signature, would it.

Approved-By:  "Arsenault, Al W." <[email-masked]>
Date:         Fri, 6 Mar 1998 16:56: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: "Arsenault, Al W." <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

Sorry to jump in late, but I've been away at other jobs for a while, and
I'm just catching up :-)

>From one of Dave Kemp's messages:

>> What is the foundation or context for this discussion: WHAT ATTACKS ARE
>> WE CONCERNED ABOUT?
>
>
>Key compromise.
>
>If some other person gets a copy of my private key, that is a key compromise.
>If I have a keypair certified for one purpose, and I take that private key
>and request that it be certified for a different purpose, that is a key
>compromise from one of my schizophrenic personalities to another :-).

AWA comment:  it's only a "compromise" if it's unauthorized - against
the rules established by one or more CAs.
>
>More realistically, if one CA's Certification Practices Statement says
>that subscribers will be required to keep their private keys in a
>FIPS-140 rated module, and another CA allows subscribers to keep them
>in unencrypted hard disk files, then if I happen to request certification
>of two keys which happen to have the same bit pattern from the two CAs,
>one of the CA's policies may have been violated.

AWA comment:  if you the user do this intentionally, then you the user
are at fault for violating the CA's requirements.  (Danger: analogy
ahead)  If you the user give your hardware token and the PIN to it to
another carbon-based life form, and that carbon-based life form signs
something as you, you have likely also vioated the CA's requirements.
Same thing if you let another carbon-based life form log in to your
computer as you.  The CA can't ensure everything, which is why all CAs I
know of make users sign agreements stipulating the user
responsibilities.  If you violate your responsibilities, the CA
disclaims any liability for your actions.

(If the dual certification of the same key happens by
incredibly-unlikely random chance (your key generator generated the same
key pair twice), then there's nothing any system can do about it.)

>That is an extreme example, but it applies anytime there are differences
>in the purposes for which a certificate is issued. To be less extreme,
>say the FPKI profile says that certs shall not contain keyUsage bits
>set which allow both signature and encryption.  If the same key is certified
>twice, once for each purpose, then both certs are compliant with the
>policy but the end result is not.

AWA comment:  again, if the user does this intentionally to evade the
rules, the fault lies with the user vice the CA.

>It is impossible to analyze the interactions of all possible combinations
>of certification practices and certificate attributes to determine whether
>any two pairs result in unintended consequences.  Therefore, the safe
>thing to do is to not multiply-certify a single key unless you have
>analyzed and understand the results.
>
>
>> For the life of me, I am unable to identify any attacks that result from
>> replacing certificates other than denial of service.
>>
>> For example, suppose I sign and send a message and someone replaces my
>> certificate with one they dynamically generate that contains "do not
>> trust this certificate", the recipient will surely not trust my message.
>> I, the sender, will still be able to resend my original message via
>> other means.
>>
>> No one has identified an attack that warrants changing the existing
>> standard to not allow multiple certificates per public key (which is
>> most probably not enforcable anyway).
>>
>> Unless someone can identify an attack that warrants changing the
>> standard, the standard should not be changed.
>
>
>I don't think anyone has proposed modifying any standard to prohibit
>multiple certification.  We're just pointing out security considerations
>that should lead to the Generally Accepted Practice of not doing it.

AWA comment:  I agree with what Mark Shuttleworth, Steve Kent, and a
couple of others have said:

        - certifying the same key in multiple certificates is a matter of
individual CA policy.  There are valid reasons for doing it.

        - it should not be deprecated in the PKIX documents, although it
wouldn't hurt to mention some of the dangers associated with it.

I would also point out the unwritten assumption here:  we're talking
about signature keys, only.  There are plenty of good reasons for
putting the same key-exchange/key-agreement key in multiple
certificates, and few if any of the authenticity problems that arise
with signature keys.

                Al Arsenault

-- speaking only for myself.  My views do not necessarily represent
those of my employer.

Approved-By:  Paul Koning <[email-masked]>
Date:         Fri, 6 Mar 1998 16:10: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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

 >> What is the foundation or context for this discussion: WHAT
 >> ATTACKS ARE WE CONCERNED ABOUT?

 David> Key compromise.

 David> If some other person gets a copy of my private key, that is a
 David> key compromise.  If I have a keypair certified for one
 David> purpose, and I take that private key and request that it be
 David> certified for a different purpose, that is a key compromise
 David> from one of my schizophrenic personalities to another :-).

I don't see the issue.

If your private key is compromised, your private key is compromised,
and the validity of all signatures made by that key is thrown in
doubt.  Whether the corresponding public key is attested by one or by
a million certificates makes no difference.

 David> More realistically, if one CA's Certification Practices
 David> Statement says that subscribers will be required to keep their
 David> private keys in a FIPS-140 rated module, and another CA allows
 David> subscribers to keep them in unencrypted hard disk files, then
 David> if I happen to request certification of two keys which happen
 David> to have the same bit pattern from the two CAs, one of the CA's
 David> policies may have been violated.

That doesn't follow at all.  You only get into trouble if the
intersection of the requirements of the various CAs is null.

In the example you quoted, all that's needed is that the private key
has to be in a rated module, since one of the CAs requires that.  So
long as the other CA doesn't have a policy *forbidding* the use of a
rated module, you're all set.

---
It seems to me that, given that many people view certificates as
things that describe authority (roles) and not identity, you're going
to have a pile of them.  And if you do, there are good reasons to want
to minimize the number of private keys.

To apply one of the standard analogies again: while I have one
identity, I have a lot of different authorizations (roles), and lots
of different pieces of plastic and paper attesting to these.  But my
signature on all of them is the same scribble.

Using certificates to describe authorization means of course that I
won't just check whether there exists a certificate that validates a
signature -- I'd also check that the certificate is one that grants
the kind of authorization I'm interested in.  For example, to
validate, say, a dialup access attempt, I might look for a certificate
issued by my company.

        paul

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 6 Mar 1998 15:20: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple Certificates
To: [email-masked]

I have permission from the author to post the following private message:

> From: "Balluffi, Frank" <[email-masked]>
>
> David,
>
> It seems to me that this whole multiple certificates per public key
> dicussion is moving in the direction of technology for technology's
> sake.

Funny, that's what I think about proposals to have multiple certificates
with a single key :-).  Existing technology (Netscape or MSIE pointed
at VeriSign) results in a new key for every cert requested, except in
the case of cross-certification, as pointed out previously.  You
have to go out of your way to make up cert requests with a shared
key.

> What is the foundation or context for this discussion: WHAT ATTACKS ARE
> WE CONCERNED ABOUT?

Key compromise.

If some other person gets a copy of my private key, that is a key compromise.
If I have a keypair certified for one purpose, and I take that private key
and request that it be certified for a different purpose, that is a key
compromise from one of my schizophrenic personalities to another :-).

More realistically, if one CA's Certification Practices Statement says
that subscribers will be required to keep their private keys in a
FIPS-140 rated module, and another CA allows subscribers to keep them
in unencrypted hard disk files, then if I happen to request certification
of two keys which happen to have the same bit pattern from the two CAs,
one of the CA's policies may have been violated.

That is an extreme example, but it applies anytime there are differences
in the purposes for which a certificate is issued. To be less extreme,
say the FPKI profile says that certs shall not contain keyUsage bits
set which allow both signature and encryption.  If the same key is certified
twice, once for each purpose, then both certs are compliant with the
policy but the end result is not.

It is impossible to analyze the interactions of all possible combinations
of certification practices and certificate attributes to determine whether
any two pairs result in unintended consequences.  Therefore, the safe
thing to do is to not multiply-certify a single key unless you have
analyzed and understand the results.

> For the life of me, I am unable to identify any attacks that result from
> replacing certificates other than denial of service.
>
> For example, suppose I sign and send a message and someone replaces my
> certificate with one they dynamically generate that contains "do not
> trust this certificate", the recipient will surely not trust my message.
> I, the sender, will still be able to resend my original message via
> other means.
>
> No one has identified an attack that warrants changing the existing
> standard to not allow multiple certificates per public key (which is
> most probably not enforcable anyway).
>
> Unless someone can identify an attack that warrants changing the
> standard, the standard should not be changed.

I don't think anyone has proposed modifying any standard to prohibit
multiple certification.  We're just pointing out security considerations
that should lead to the Generally Accepted Practice of not doing it.

Approved-By:  "Pawluk, Jean" <[email-masked]>
Date:         Fri, 6 Mar 1998 14:07:32 -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: "Pawluk, Jean" <[email-masked]>
Subject:      [IETF-PKIX] Recall: [IETF-PKIX] Deletes 3/6
To: [email-masked]

Pawluk, Jean would like to recall the message, "[IETF-PKIX] Deletes
3/6".

Approved-By:  "Pawluk, Jean" <[email-masked]>
Date:         Fri, 6 Mar 1998 12:02:33 -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: "Pawluk, Jean" <[email-masked]>
Subject:      [IETF-PKIX] Deletes 3/6
To: [email-masked]

delete IETF-PKIX [email-masked]
delete IETF-PKIX [email-masked]
delete IETF-PKIX [email-masked]
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  FNS/FNS054A1/tanakamnb IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX
delete  [email-masked] IETF-PKIX

Approved-By:  Stephen Kent <[email-masked]>
Date:         Fri, 6 Mar 1998 12:07:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Dan,

>Let's get this straight -- the key is the identity,
>your name is a handle.  If liberty means anything, you
>can call yourself what you want hence identity-to-handle
>mapping will be many to many.  The tradeoff is your
>complexity eval of managing O(10**2) keys versus your
>exposure eval of published cross correlation of the key
>sharing amongst certs.

Wrong mailing list.  What you said above is the SPKI notion, but it's not
the PKIX notion, of the semantics of the subject name field in a
certificate.

Steve

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 5 Mar 1998 22:50:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      [IETF-PKIX] Cryptographic binding of certificates to signatures
To: [email-masked]

(My apologies if a copy of this message with a different
subject is received. Our e-mail, and apparently that of
some other people, has been acting very strangely recently.
I don't know what is going on, but some incoming
messages are showing up a week late, and some
messages on other lists apparently aren't getting through at all.)

David,

If we were able to somehow add cryptographic binding of
the digital signature to the specific certificate that is s
supposed to be used to validate it, virtually all of my objections
to issuing more than one certificate per key would disappear,
and we would be left with some of the positive virtues of that
approach that others have mentioned.

However, I do NOT think that we should insist that each and
every protocol reinvent the wheel. Some will do it wrong (as per
your examples), and some just won't do it at all.

Unfortunately, the SIGNED macro doesn't include a version
indicator (will we _never_ learn?), so we can't do the version 3
trick that we pulled when we found that the X.509 certificate
wasn't adequate for our new extended purpose.

However, I think there is a way out, although from a purist
architectural standpoint it is an ugly hack. But hey, MISSI did
it, and what's good enough for the US Government ought to be
good enough for the rest of us, right?

What I'm proposing is that we define a new series of digital signature
algorithm OIDs, which would include the additional information that
is needed as part of the COMPONENTS.

We can debate the precise information that we might like to include later,
along with the optimum syntax, but this is the approach that as I
recall MISSI took to include clearance information and other parameters
that they had no place to put in the old V1 certificate format. Like I said,
an ugly, but noble hack.

One potential problem is that although currently in-vogue RSA and
DSA key lengths (1024 and 2048 bits) would probably be long enough
to directly include most of what we might like, the 512 bit lengths allowed
by US export (and some import) regulations might be pretty tight, and
would be extremely tight for elliptic curves.

One approach to solving this problem would be to use two message digests,
one for the ToBeSigned, and the other for the ancillary signature data (someone
has to think of a snappy attribute name ¯ I refuse to be blamed for "ancillarySignatureData"), and then include both message digests
within the signature.  This would work for algorithms of up to 320 bits
in length, which might still be tight for some elliptic curve algorithms.

The other approach, which could be extended to arbitrarily long
information, would be to effectively append the existing ToBeSigned
information (normally a message digest) to the ancillary information, and
then compute a super message digest over the entire collection. That
super message digest, plus any additional randomized padding (we
ought to fix that problem while we are at it) would then be the input
to the actual signing operation. This would support signature algorithms
and key lengths which only allow as little as 160 bits of input (or even
128 bits, for MD5)).

The second approach is obviously superior to the first, assuming
that the time for a second hash is considered negligible. But can
anyone think of an even better method?

The benefit of this scheme is that by simply implementing one
or more new enhanced signature algorithms (e.g., "RSA with
SHA-1 and ancillary data") within the underlying toolkits,
virtually all applications would benefit, with virtually no effort at all.

And if we do it right, we might even be able to achieve some degree of
backward compatibility by some sort of slight of hand involving
mapping the algorithm OIDs to existing algorithms
in such a way as to ignore the added information if the code doesn't yet
support it. Maybe some ASN.1 genius can think of a slick trick.

Let me let this sink in before I start talking about all of the stuff I
would like to see included. Hopefully this time we would do it right,
probably by defining the information to be included in ASN.1 with
strong typing, so that we additional information is proposed to be
added it will be simple to do. But that is tomorrow's homework
assignment.

At a minimum, however, it would have to include some form of
unique identification of the certificate to be used to validate the
signature, either issuerName and serial, authorityKeyId, or at
the very least a hash of the certificate contents (although that
wold cause some problems of circular definition if used within
the certificate itself.)  Certainly a URL or some other kind of hint
as to where to actually find the certificate would be a nice touch,
but we can discuss that independently of the primary issue.

Whaddaya think about the basic concept?

Bob

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

--------

>>> "David P. Kemp" <[email-masked]> 3/5/98 13:03:16 >>>
> From: Bob Jueneman <[email-masked]>
>
> The problem, to the extent that there is one, is that the X.509
> definition of the "sign" macro does not provide any means of defining
> precisely which certificate in particular should be used to validate a
> particular signature, and thereby associate a particular set of
> name/rights attributes with that signature.
>
> (That's what often happens when a standard that was intended for one
> purpose is appropriated for another, entirely different purpose. We,
> the digital signature community, probably should have rethought that
> particular issue before adopting the X.509 definition of signature.
> Some other information, such as the date/time and signing and the
> identity of the platform ("location") on which the signature took place
> would have been handy, also.)

Bob,

The X.509 "SIGNED" macro might not have been designed with the intent
of supporting this purpose, and so may be excused for not including
a method of binding a certificate to the signed data.

However, the IETF CMS specification (aka PKCS#7) was designed for
precisely this purpose (providing non-repudiation grade signatures over
generic content), yet it still does not provide a clean method of
binding the signer's certificate to the content.

The CMS definition of SignedData includes {content, certs, crls,
signerInfos}, and some other fields.  There may be multiple signatures
applied to the content, each represented by a SignerInfo.  Each
SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
Because the issuerAndSerialNumber field, which uniquely identifies the
certificate used by the signer, is not covered by the signature, it is
not bound to the content.  I'm not sure why PKCS#7 was designed that
way, but it was, and so is CMS.

It would have been preferable to define an issuerAndSerialNumber
attribute, which could have been included either in
authenticateAttributes to bind it with the signature, or in
unauthenticatedAttributes if the current semantics of not binding the
signer's cert to the signed content is desired.

Perhaps defining a redundant copy of issuerAndSerialNumber, to be
included in authenticatedAttributes, could address the requirement
without breaking backward compatibility.  (It only covers the signer's
cert, not the full path, but it's a start.)
The uglier alternative is  is to double-sign everything, encapsulating a
signedData within another signedData for each parallel signature.

Since CMS is intended to be a generic security encapsulation mechanism,
not just an S/MIME-specific structure, those who feel that this
requirement is important (to address either multiple certification of
keys or proof-of-possession) should discuss it in the S/MIME working
group.  (A SigningTime attribute is already defined in CMS, but a
"location" attribute is not.)

Dave Kemp

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 5 Mar 1998 22:16:12 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

David,

If we were able to somehow add cryptographic binding of
the digital signature to the specific certificate that is s
supposed to be used to validate it, virtually all of my objections
to issuing more than one certificate per key would disappear,
and we would be left with some of the positive virtues of that
approach that others have mentioned.

However, I do NOT think that we should insist that each and
every protocol reinvent the wheel. Some will do it wrong (as per
your examples), and some just won't do it at all.

Unfortunately, the SIGNED macro doesn't include a version
indicator (will we _never_ learn?), so we can't do the version 3
trick that we pulled when we found that the X.509 certificate
wasn't adequate for our new extended purpose.

However, I think there is a way out, although from a purist
architectural standpoint it is an ugly hack. But hey, MISSI did
it, and what's good enough for the US Government ought to be
good enough for the rest of us, right?

What I'm proposing is that we define a new series of digital signature
algorithm OIDs, which would include the additional information that
is needed as part of the COMPONENTS.

We can debate the precise information that we might like to include later,
along with the optimum syntax, but this is the approach that as I
recall MISSI took to include clearance information and other parameters
that they had no place to put in the old V1 certificate format. Like I said,
an ugly, but noble hack.

One potential problem is that although currently in-vogue RSA and
DSA key lengths (1024 and 2048 bits) would probably be long enough
to directly include most of what we might like, the 512 bit lengths allowed
by US export (and some import) regulations might be pretty tight, and
would be extremely tight for elliptic curves.

One approach to solving this problem would be to use two message digests,
one for the ToBeSigned, and the other for the ancillary signature data (someone
has to think of a snappy attribute name ¯ I refuse to be blamed for "ancillarySignatureData"), and then include both message digests
within the signature.  This would work for algorithms of up to 320 bits
in length, which might still be tight for some elliptic curve algorithms.

The other approach, which could be extended to arbitrarily long
information, would be to effectively append the existing ToBeSigned
information (normally a message digest) to the ancillary information, and
then compute a super message digest over the entire collection. That
super message digest, plus any additional randomized padding (we
ought to fix that problem while we are at it) would then be the input
to the actual signing operation. This would support signature algorithms
and key lengths which only allow as little as 160 bits of input (or even
128 bits, for MD5)).

The second approach is obviously superior to the first, assuming
that the time for a second hash is considered negligible. But can
anyone think of an even better method?

The benefit of this scheme is that by simply implementing one
or more new enhanced signature algorithms (e.g., "RSA with
SHA-1 and ancillary data") within the underlying toolkits,
virtually all applications would benefit, with virtually no effort at all.

And if we do it right, we might even be able to achieve some degree of
backward compatibility by some sort of slight of hand involving
mapping the algorithm OIDs to existing algorithms
in such a way as to ignore the added information if the code doesn't yet
support it. Maybe some ASN.1 genius can think of a slick trick.

Let me let this sink in before I start talking about all of the stuff I
would like to see included. Hopefully this time we would do it right,
probably by defining the information to be included in ASN.1 with
strong typing, so that we additional information is proposed to be
added it will be simple to do. But that is tomorrow's homework
assignment.

At a minimum, however, it would have to include some form of
unique identification of the certificate to be used to validate the
signature, either issuerName and serial, authorityKeyId, or at
the very least a hash of the certificate contents (although that
wold cause some problems of circular definition if used within
the certificate itself.)  Certainly a URL or some other kind of hint
as to where to actually find the certificate would be a nice touch,
but we can discuss that independently of the primary issue.

Whaddaya think about the basic concept?

Bob

----

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

>>> "David P. Kemp" <[email-masked]> 3/5/98 13:03:16 >>>
> From: Bob Jueneman <[email-masked]>
>
> The problem, to the extent that there is one, is that the X.509
> definition of the "sign" macro does not provide any means of defining
> precisely which certificate in particular should be used to validate a
> particular signature, and thereby associate a particular set of
> name/rights attributes with that signature.
>
> (That's what often happens when a standard that was intended for one
> purpose is appropriated for another, entirely different purpose. We,
> the digital signature community, probably should have rethought that
> particular issue before adopting the X.509 definition of signature.
> Some other information, such as the date/time and signing and the
> identity of the platform ("location") on which the signature took place
> would have been handy, also.)

Bob,

The X.509 "SIGNED" macro might not have been designed with the intent
of supporting this purpose, and so may be excused for not including
a method of binding a certificate to the signed data.

However, the IETF CMS specification (aka PKCS#7) was designed for
precisely this purpose (providing non-repudiation grade signatures over
generic content), yet it still does not provide a clean method of
binding the signer's certificate to the content.

The CMS definition of SignedData includes {content, certs, crls,
signerInfos}, and some other fields.  There may be multiple signatures
applied to the content, each represented by a SignerInfo.  Each
SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
Because the issuerAndSerialNumber field, which uniquely identifies the
certificate used by the signer, is not covered by the signature, it is
not bound to the content.  I'm not sure why PKCS#7 was designed that
way, but it was, and so is CMS.

It would have been preferable to define an issuerAndSerialNumber
attribute, which could have been included either in
authenticateAttributes to bind it with the signature, or in
unauthenticatedAttributes if the current semantics of not binding the
signer's cert to the signed content is desired.

Perhaps defining a redundant copy of issuerAndSerialNumber, to be
included in authenticatedAttributes, could address the requirement
without breaking backward compatibility.  (It only covers the signer's
cert, not the full path, but it's a start.)
The uglier alternative is  is to double-sign everything, encapsulating a
signedData within another signedData for each parallel signature.

Since CMS is intended to be a generic security encapsulation mechanism,
not just an S/MIME-specific structure, those who feel that this
requirement is important (to address either multiple certification of
keys or proof-of-possession) should discuss it in the S/MIME working
group.  (A SigningTime attribute is already defined in CMS, but a
"location" attribute is not.)

Dave Kemp

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 5 Mar 1998 16:31:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> From: Bill Burr <[email-masked]>
>
> I can leave my certificates stored on a directory somewhere and access them
> over the net when I want them.  I can have my file of certificates on the
> disk of my machine at work, on my machine at home, on my laptop, carry it
> around on a floppy disk, paste them on the wall, put them on my web site,
> and so on. I can have 100 copies and leave them anywhere I want.
>
> But, the key or keys I must protect.  I may want to carry them around on a
> chip card in my wallet.  It may be more important to use that silicon to do
> digital signatures and key agreement on the chip, so that the private key
> never leaves the chip, than to store a large number of certificates and
> separate keys.

Certainly certificates don't need to be carried in protected storage,
and keys do.  But the question is: does your token carry one private
key, period, or one private key per role.

The number of roles you want to manage is probably limited by
ergonomics; if all your certs are stored on floppies or directories, or
web servers, you still have to pick the cert to use for a particular
transaction.  I have trouble leafing through the 20 cards in my wallet
(drivers lic, MasterCard, AMEX, library, Red Cross, health insurance,
warehouse club memberships, etc).  In an electronic transaction,
selecting from 20 or 50 bookmarked URLs, desktop icons, address-book
entries, etc. to pull the cert to use may be practical; selecting from
1000 certs probably is not.

So if a token has the storage capacity for 20 or 50 or 100 private keys,
it probably meets the needs and organizational capabilities of most
human users.  100 private keys (12.8 KBytes) is not an outrageous number
to expect a token to support.  How much cheaper is a 128 byte token than
a 16 KB token?

And if you have application software that can handle pulling public
certificates from a directory/web server/floppy while pulling private
keys from a token, then it is unrealistic to expect that the software
would not be capable of correlating private keys with certs. Managing
100 certs with 100 keys is no more difficult for the user than managing
100 certs with 1 key.

> I don't accept that the pin on my token is analogous to a handwritten
> signature.  The AMEX card is analogous to the certificate, and my selecting
> a particular certificate for use in a protocol, is apanages to picking my
> AMEX rather than my VISA.  But, when I sign my transaction slip, I don't
> sign differently for Amex than for Visa.  It's the same signature.

The actions that the user must perform are analogous: open your wallet,
pick a card, sign a transaction slip.  Unlock your token with a PIN,
pick a personality (cert), click on the Go button.  The user authentication
happens at step 3 in the physical process and step 1 in the electronic
process, but so what?  (If you really want to emulate the physical
world, the app could wait until step 3 before asking for the PIN or
database password).

Why are you concerned whether the signature computed as a result of
clicking the Go button comes from the same private key or different
private keys for different certs?  Even if you always use the same
private key, the signature will be totally different every time if
you're using DSS.  And even if you use the same private key and a
deterministic signature algorithm (RSA), every signature will be
different if the content being signed is different.  It's not the same
signature, regardless of whether you have 1 private key or 100.

That's the danger of reasoning by analogy - you can't look too deep
or things fall apart.

Regards,
Dave Kemp

Approved-By: [email-masked]
Date:         Thu, 5 Mar 1998 10:27: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: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

At 03:20 PM 3/4/98 -0700, you wrote:
>Bill, I've already done my mea culpa's for the "signed by a certificate"
>imprecise usage. Rather than reiterate the argument yet again, I
>would be interested in your reaction to my recent reply to
>Tony Bartoletti.
>
>Havin' fun stirring up the hornets,
>
>Bob
>
>
>>>> Bill Burr <[email-masked]> 03/04 2:27 PM >>>
>Bob,
>
>But do we sign with a certificate, or with a key?  I don't think that key
>and certificate are synonymous.  If the context of the certificate matters
>to the signature, then I should include the certificate in the signed
>message.
> [snip]
>
>

Bob,

Sorry that I hadn't read your response to Tony.  The moderation of this
list seems to induce some delay in the loop.

I think that you may be right to suggest that a signature should be
cryptographically bound to a particular certificate.  But I don't see how a
one certificate per key rule does that, because there isn't any strong way
to enforce that rule.

It seems to me that, if it's important when I sign a message, that I'm
signing as Bill Burr, of NIST, as opposed to Bill Burr, a member of the
garden club, that my message had probably better make that clear, possibly
by including the certificate in the signed part of the message.

If I don't do that, and I have many certificates for a key, then I probably
must accept that a relying party can reasonably choose any of those
certificates, with whatever consequences that brings.

Moreover NIST might well choose to insist that I not use a key it
certified, in any other certificate.

The most serious problem that multiple certificates per key brings, it
seems to me, is revocation, for the particular case of key compromise.
But, at the moment, I'm not sure that today we have an accepted general
answer to revocation.  I think that one model, which would more or less
work today, is for a CA to issue certificates with short validity periods
(hours or a few days), and dispense entirely with CRLs, OCSP, etc.  The CA
could, for example, sign a new certificate every day, with, say, a two day
validity period.  If I, or a relying party need my cert. today, we go get
it from the repository, perhaps for a small charge. I think that this means
more than one certificate per key.

This doesn't solve the key compromise problem, if I have a lot of different
certificates for that key, but it may be a reasonable way to avoid the
problems of CRLs or on-line status protocols, with their baggage.

I'm just reluctant to embrace the one key, one certificate principle, until
we have a little more experience with what actually works.
Regards,

Bill Burr

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 5 Mar 1998 15:03: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> From: Bob Jueneman <[email-masked]>
>
> The problem, to the extent that there is one, is that the X.509
> definition of the "sign" macro does not provide any means of defining
> precisely which certificate in particular should be used to validate a
> particular signature, and thereby associate a particular set of
> name/rights attributes with that signature.
>
> (That's what often happens when a standard that was intended for one
> purpose is appropriated for another, entirely different purpose. We,
> the digital signature community, probably should have rethought that
> particular issue before adopting the X.509 definition of signature.
> Some other information, such as the date/time and signing and the
> identity of the platform ("location") on which the signature took place
> would have been handy, also.)

Bob,

The X.509 "SIGNED" macro might not have been designed with the intent
of supporting this purpose, and so may be excused for not including
a method of binding a certificate to the signed data.

However, the IETF CMS specification (aka PKCS#7) was designed for
precisely this purpose (providing non-repudiation grade signatures over
generic content), yet it still does not provide a clean method of
binding the signer's certificate to the content.

The CMS definition of SignedData includes {content, certs, crls,
signerInfos}, and some other fields.  There may be multiple signatures
applied to the content, each represented by a SignerInfo.  Each
SignerInfo includes {issuerAndSerialNumber, attributes, signature}.
Because the issuerAndSerialNumber field, which uniquely identifies the
certificate used by the signer, is not covered by the signature, it is
not bound to the content.  I'm not sure why PKCS#7 was designed that
way, but it was, and so is CMS.

It would have been preferable to define an issuerAndSerialNumber
attribute, which could have been included either in
authenticateAttributes to bind it with the signature, or in
unauthenticatedAttributes if the current semantics of not binding the
signer's cert to the signed content is desired.

Perhaps defining a redundant copy of issuerAndSerialNumber, to be
included in authenticatedAttributes, could address the requirement
without breaking backward compatibility.  (It only covers the signer's
cert, not the full path, but it's a start.)
The uglier alternative is  is to double-sign everything, encapsulating a
signedData within another signedData for each parallel signature.

Since CMS is intended to be a generic security encapsulation mechanism,
not just an S/MIME-specific structure, those who feel that this
requirement is important (to address either multiple certification of
keys or proof-of-possession) should discuss it in the S/MIME working
group.  (A SigningTime attribute is already defined in CMS, but a
"location" attribute is not.)

Dave Kemp

Approved-By: [email-masked]
Date:         Thu, 5 Mar 1998 09:59: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: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

At 04:45 PM 3/4/98 -0500, you wrote:
>> From: Bill Burr <[email-masked]>
>>
>> If I have 50 or 100 certificates, each with some particular attributes
>> bound with my keys, one for the auto club, one for the New York Times
>> on-line, one for every pay site I subscribe to, etc., and I want to carry
>> them around on my token and use them at home and at work, etc., maybe I've
>> got a problem.
>>
>> Is does seem to me to simplify my life to use one key to sign everything;
>> after all, I don't sign my name differently when I use my AMEX card than
>> when I use my Visa.   This makes sense if we separate attributes from
>> identity and use X9 style attribute certificates, that don't contain a key.
>>  I'm far from convinced that such attribute certificates are practical.
>
>I believe the analogy is flawed.  When you use your AMEX card, the
>information extracted from the magstripe is different than the
>information on your Visa magstripe.  You use the same handwritten
>signature to authorize both cards, just as you use the same PIN to
>activate your token.
>
>I always cringe when people use the word "certificate" to mean both a
>public key certificate and the associated private data, but from an
>ergonomic point of view, there isn't much difference.  When you select
>an X.509 certificate in your web browser to sign a message, the browser
>automatically uses the private key associated with that certificate.
>If you have 50 or 100 certificates to choose from, you have to choose
>once, but you don't have to choose again to get the proper private key;
>that part is automatic.
>
>And if a token can store n certificates of 1K-2K bytes each, adding an
>additional 128-256 bytes of private key for each certificate doesn't
>significantly change the number of certs that can be carried on
>the token.
>
>Dave Kemp
>
>

I can leave my certificates stored on a directory somewhere and access them
over the net when I want them.  I can have my file of certificates on the
disk of my machine at work, on my machine at home, on my laptop, carry it
around on a floppy disk, paste them on the wall, put them on my web site,
and so on. I can have 100 copies and leave them anywhere I want.

But, the key or keys I must protect.  I may want to carry them around on a
chip card in my wallet.  It may be more important to use that silicon to do
digital signatures and key agreement on the chip, so that the private key
never leaves the chip, than to store a large number of certificates and
separate keys.

I don't accept that the pin on my token is analogous to a handwritten
signature.  The AMEX card is analogous to the certificate, and my selecting
a particular certificate for use in a protocol, is apanages to picking my
AMEX rather than my VISA.  But, when I sign my transaction slip, I don't
sign differently for Amex than for Visa.  It's the same signature.

There may be, as bob Juneman suggests, a flaw in the definition of a
signature, which perhaps should be cryptographically bound to a particular
certificate.  But trying to do that by making an unenforceable rule of a
different key per certificate seems to me the wrong way to fix the problem.
Regards,

Bill Burr

Approved-By: [email-masked]
Date:         Thu, 5 Mar 1998 18:32:24 +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: Mark Shuttleworth <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> Let's get this straight -- the key is the identity,
> your name is a handle.  If liberty means anything, you
> can call yourself what you want hence identity-to-handle
> mapping will be many to many.  The tradeoff is your
> complexity eval of managing O(10**2) keys versus your
> exposure eval of published cross correlation of the key
> sharing amongst certs.

Gotta disagree.  The name is your identity (and potentially your
authority).  The key is merely a way to tie an action (signature) to that
identity.  The problem is tht one-key-many-certs can mean that an action
is tied to multiple identities.  It's not a huge problem.

--
Mark Shuttleworth
Thawte Consulting

Approved-By: [email-masked]
Date:         Thu, 5 Mar 1998 11:01:32 +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: Mark Shuttleworth <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> The problem, to the extent that there is one, is that the X.509 definition of the
> "sign" macro does not provide any means of defining precisely which
> certificate in particular should be used to validate a particular signature,
> and thereby associate a particular set of name/rights attributes with that
> signature.

Fortunately, the authorityKeyIdentifier extension let's us do just that ;)

--
Mark Shuttleworth
Thawte Consulting

Approved-By: [email-masked]
Date:         Thu, 5 Mar 1998 11:04: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: [email-masked]
Subject:      [IETF-PKIX] OCSP draft 2
To: [email-masked]

another area that i'm really interested in is the possibility of extending
ocsp into online digital signature status ... (in contrast to
online certificate status). This relates to account authority
digital signature model ... where the relying party on the digital
signature isn't the account authority ... but still needs indication
regarding the validity of the digital signature.

in aads, certificates were removed from financial transactions ... in part
to provide end-to-end digital signature integrity for financial
transactions that had to transit legacy financial networks.  It turned
out that the removal of certificates from the operation also eliminated
systemic risks to the financial infrastructure (that are associated
with common CA infrastructures).

The embodiment of aads is in ANSI X9.59 electronic retail payment
protocol ... which has also been presented as electronic payment
convergenece (also has an acronym GUPI ... grand unified payment
initiative) ... and is targeted for international ISO fast-tracking.

The opportunity in AADS is to leverage a likely robust and pervasive
digital signature infrastructure for operations other than end-to-end,
high integrity financial transactions.

The no-brainer is for an AADS to also issue certificates. However,
the certificates and the account authority financial transactions then
operate at almost the opposite ends of the high-integrity spectrum.
The opportunity is to then to provide higher-integrity PKI that
is closer to the financial transaction end of the spectrum ... but
doesn't happen to be real financial transactions.

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Thu, 5 Mar 1998 10:17:28 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: "Charles W. Gardiner" <[email-masked]>
To: [email-masked]

At 10:16 AM 3/5/98 -0500, Charles W. Gardiner wrote:
>    Surely the document you signed as Purchasing Manager of BigCorp contained
>the name of BigCorp and your title.  The relying party should, therefore,
have
>looked up that certificate, not your chess club certificate.  You probably
>sent the classy cert. when you first placed a purchase order with XYX Corp.
>That's much the way the world works pre-digitally.  Digital signatures
will very
>likely follow in the same groove, well established by custom.
>
>Charlie Gardiner

I would hope so.  However, the comments in this thread imply otherwise.
You assume, I believe, that a human will be in the loop to read the purchase
order, and use this information to look up a certificate manually.  Perhaps
my purchase order example was not the best.  Please consider the comments of
Bob Jueneman, which I include (indented) below:

  The problem, to the extent that there is one, is that the X.509 definition
  of the "sign" macro does not provide any means of defining precisely which
  certificate in particular should be used to validate a particular signature,
  and thereby associate a particular set of name/rights attributes with that
  signature.

  (That's what often happens when a standard that was intended for one
purpose
  is appropriated for another, entirely different purpose. We, the digital
  signature community, probably should have rethought that particular issue
  before adopting the X.509 definition of signature. Some other information,
  such as the date/time and signing and the identity of the platform
  ("location") on which the signature took place would have been handy, also.)

  But that's water over the dam by now, and so all of the various
applications
  which might ever want to use a digital signature have to solve the problem
  themselves.

  Unfortunately, several of those applications further compounded the original
  error by not incorporating an unambiguous reference to the certificate
which
  is to be used to validate the signature within the signed document itself,
  but rather appended the reference to the certificate, or the certificate
  itself, to the document in an insecure manner. One way around that problem
  would be to recite the contents of the certificate itself, but that is both
  awkward, and not likely to be easily machine processable, since no
particular
  convention has been established for such a process.

  Since the certificate reference is not securely bound to the document in
  question, another certificate could easily be substituted. If it were not
for
  the private key proof-of-possession requirement, this would even allow some
  other person to claim authorship of the document, which might be quite
useful
  in some circumstances.  And it certainly allows an individual who possesses
  the key but is wearing different hats (roles) to play some games if it would
  be to his advantage.

(Thanks again Bob, for the explanation.)  Although I read most of the postings
to the PKI mailing lists, I find there is rarely a presentation, high
level, of
what each automated protocol needs or expects in order to perform its
function.
Not long ago, there was debate about whether the relying party was responsible
for gathering the chain of certs to validate a transaction, ot whether it was
the duty of the supplicant (transaction submitter) to supply these, or at
least
their links, to the relying party.

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Dan Geer <[email-masked]>
Date:         Thu, 5 Mar 1998 11:07:14 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dan Geer <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Let's get this straight -- the key is the identity,
your name is a handle.  If liberty means anything, you
can call yourself what you want hence identity-to-handle
mapping will be many to many.  The tradeoff is your
complexity eval of managing O(10**2) keys versus your
exposure eval of published cross correlation of the key
sharing amongst certs.

--dan

Approved-By:  "Charles W. Gardiner" <[email-masked]>
Date:         Thu, 5 Mar 1998 10:16: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: "Charles W. Gardiner" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

    Surely the document you signed as Purchasing Manager of BigCorp contained
the name of BigCorp and your title.  The relying party should, therefore, have
looked up that certificate, not your chess club certificate.  You probably
sent the classy cert. when you first placed a purchase order with XYX Corp.
That's much the way the world works pre-digitally.  Digital signatures will very
likely follow in the same groove, well established by custom.

Charlie Gardiner

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 3 Mar 1998 19:54:59 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]

Peter,

PKIX Part 1 identifies one means of identifying the validation point using
the AuthorityInfoAccess extension.  Beyond that I would expect it to be a
matter of local configuration similar to identifying one's nameserver.

Mike

-----Original Message-----
From: Peter Sylvester <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, March 03, 1998 11:14 AM
Subject: Re: [IETF-PKIX] OCSP Current Status

>I am not whether the following has been discussed or not for OCSP:
>
>Question: Is the protocol just intended to specify the communication
between
>a client and the well-known validation point, or is there something
>to about how to find that point.
>
>I image a possible response from the server saying, no, don't do this
>here, go elsewhere, here's the 'connection info' (URL or whatever).
>
>Peter Sylvester
>EdelWeb
>

Approved-By:  Michael Myers <[email-masked]>
Date:         Wed, 4 Mar 1998 05:33:32 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP draft 2
To: [email-masked]

Marc,

A very thorough review and much appreciated.

Mike

-----Original Message-----
From: Marc Branchaud <[email-masked]>
>
>(1) There's very little "online" about this protocol.  It's basically a
>mechanism for server-based CRL processing, with specific reference to the
>validation logic in PKIX1.
>
>There's nothing wrong with that.  It allows for thin clients that don't
have
>to bother with CRLs, which I think is great.  But because of this I don't
>think that words such as "timely" belong in the draft, because there's
>nothing that ensures the timeliness of a response any more than if CRLs
were
>used directly.  Indeed, calling it "OCSP" at all goes against my (probably
>skewed) pre-conceived notions of what an online status protocol should do,
>which is get status information as straight from the CA's mouth as
possible.

I'm having trouble understanding this line of reasoning.  OCSP exists
specifically to address timelineness issues.  True, the specification
enables one to take advantage of caching, but it doesn't mandate that you do
so.  If you have customers who need a real-time production of a
certificate's status, this is what OCSP is for.  I know I do.  One the other
hand, that same mechanism can be relaxed for CA key pairs that represent
customers with less stringent timeliness needs.

>The current proposal does no such thing.  In fact it's "caching" mechanism
>isn't really about a cache of responses from other OCSP servers or CAs, but
>is instead a way to preserve the results of certificate chain processing
>(incurred when the certificate's status is first determined).  For these
>reasons I propose that the draft be renamed "Server Based CRL Processing"
or
>some such thing.  On the other hand, Carlisle's right that there's nothing
>here that can't be done within the Notary Protocol draft.

As I said, the specification does not require one to implement caching.  You
can certainly take advantage of it if meets the needs of your customers or
market.  One way I've heard proposed is to acquire a certificate's status
through an LDAP directory.

I'm beginning to wonder though if the value-added variations of the proposed
Notary Protocol may have less to do with PKI (or PKIX) than with other fora
where such contexts are well defined.  Where, for example, is the boundary
between PKI and electronic rights management?  A bank's management of its
customer's accounts?  The validity of an electronic stock trade request?
The up-to-the minute validity of pre-established IPSEC Security
Associations?  How does the notary protocol help me revoke a signed object
distributed throughout an enterprise?

I first need a simple, workable, imlementable, deployable alternative to
CRLs.  This is OCSP.

>
>(2) There's been some call for the protocol to use ASN.1.  I agree with
those
>comments, and I would even attempt to propose some actual ASN.1 to get
things
>started were it not for some confusion I have about various parts of the
>draft (I'll get to those below).

I believe we've fairly well resolved this issue.  ASN.1 for ASN.1's sake is
an endless debate.

>
>(3) Let me restate my opinion that this protocol should not be tied to
HTTP.
>Although HTTP, particularly 1.1, may be well suited for the protocol, it
also
>makes sense to allow it to be implemented using CMP or SMTP or whatever
other
>P people might fancy.  Note, too, that the richness of HTTP 1.1's cache
>control is hardly needed with this protocol's notion of "caching" anyway.

Early readers of the OCSP drafts will recall that it was cast into a
transport-independant framework, which was subsequently judged to be
overkill for the scope of the problem.

If you or someone else wishes to produce an I-D that details transport of
OCSP request and response in, say, SMTP, then we would have the basis to
consider a multi-draft approach to the specification.  Until then, there
needs to be at least one transport to ensure interoperability among those
who choose to implement OCSP.

I would however debate the validity of the claim that CMP is a transport
mechanism in the same sense that HTTP, SMTP, FTP or LDAP are transports.

>
>(4) The draft says that definitive response messages SHALL be digitally
>signed.  This is good for providing some degree of non-repudiation, but I
>would suggest that signed responses be optional (or be "SHOULD" at most) to
>allow for SSL-authenticated connections when non-repudiation isn't a
>requirement.  Granted, for individual requests there isn't much benefit as
>the crypto would get done somewhere anyway, but a single SSL connection
could
>support several requests, which would make things a lot faster.

This is a good point that's been brought up earlier.  It would be useful to
detail out how SSL would be used in this context.  May I ask that you
provide some text that I could drop into the draft?

>
>(5) In the middle of page 6 there's mention of the "value '2' for the
>version field" but there is no definition of a "version" field.

I should have deleted that sentence in view of the simplification
of the top-level specification of a request which reads:

OCSP-request     =      url "/ocsp/ver/1/" target [extensions]

I would hope that the presence of "/ver/1" requires no further explanation.

>
>(6) On page 7 it says that the requester's signature is computed over { url
>request target extensions sig-fields } but "request" isn't defined
anywhere.

Good catch.  The syntactic definition of "request" was absorbed into the
definition of "OCSP-request".

Given the specification of:

OCSP-request     =      url "/ocsp/ver/1/" target [extensions]
[signature] [extensions]

The signature should be calculated over the first four elements.

>
>(7) Just below that, it says that the responder "verifies the signature,
>using the public key identified by key-id and the requester certificate
>extension defined below."  Shouldn't that "and" be an "or" since extensions
>are optional?

Yes.  I'll amend the text to reflect the optional inclusion of extensions in
this context.

>
>(8) Section 4.3 describes the cryptographic algorithm requirements of
>clients, but makes no mention of responders.

Yes, responders would be required to implement according to these
requirements as well.

>
>(9) The Requester Certificate extension (section 4.4.2) specifies the use
of
>MD5 for producing the reqid.  Shouldn't SHA1 be used here as it is
everywhere
>else?

Yes, this has been brought to my attention by others.  It should be SHA1
throughout.

>Also, a note in this section suggests that several certificates may
>need to be passed to the OCSP responder.  Wouldn't this be better served by
>POSTing them?  Taking that idea further, it seems to me that these extended
>request strings are getting awfully long and that the whole protocol would
be
>better served by using POST exclusively instead of GET.

>
>(10) The "/ocsp/ver/1/" defined in section 4.1 doesn't match the "/status/
>check/ver/1/" used in the examples from section 4.6.

Done.

>While we're on it,
>what's the advantage of using "/ver/1/" instead of "/ver1/" or just "/v1/"?

The latter point is intended to align the more general syntatic concept
of {name, value} so that in implementation the code structure would
be more uniform.

>
>(11) Finally, the distinction between minimal and definitive error
responses,
>and between error and definitive responses, is fairly muddled and needs to
be
>made more explicit earlier in the draft.

OK.

>
>
>To sum up, I think the basic idea behind this draft -- to offload CRL
>processing from client applications -- is good.  But I also think that the
>draft's title is misleading.  What's more, it could be specified as a
profile
>of the Notary protocol, but I don't mind it remaining a stand-alone
document.
>Either way, it needs substantial changes before going to last call.

Appreciate the review.  It will help in tightening it up and moving OCSP
forward.

As for the larger issue of just how far we can legitimately extend
PKIX protocols into what might arguably be considered non-PKI realms,
I'll leave that debate to the list.

>
>                Marc

Approved-By: [email-masked]
Date:         Wed, 4 Mar 1998 16:27:04 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

Bob,

But do we sign with a certificate, or with a key?  I don't think that key
and certificate are synonymous.  If the context of the certificate matters
to the signature, then I should include the certificate in the signed
message.

I would argue that a relying party needs to decide which one certificate it
is that he relying on, and check the status of that certificate before
relying on the signature.  Why do other certificates, whatever their key,
and whatever their status, matter?  And, if the Relying party is trying to
hold a CA or a signer responsible for damages, then why does he need to
worry about any other certificate than the one he relied upon?  If there
are other certificates for that key, and if some of them have been revoked,
why should it mater?

Of course, A CA might decide that it is prudent to contractually require
that a user not use a key that the CA certifies in other certificates.

I also hope that we're not creating some theory that says that I, as a
keyholder, can disclaim responsibility for my signature, because I used a
key it certified in a way that violated the CP under which a certificate
for that key was issued.

Has anyone observed in this discussion, that CAs themselves will probably
have dozens of certificates for the same key, if they cross-certify
broadly?  Surely someone must have.  Why is it OK for CAs but not
end-entities?

At 01:16 PM 3/4/98 -0700, you wrote:
>Hi, Blake,
>
>The original discussion included the more general question of issuing two
certificates containing the same key but including different attributes --
different DN, etc. Given the difficulty of distinguishing between two
certificates if they both contain the same key and therefore either could have
>been used to sign a document, I believe there may very well be subtle
legal issues that need to be considered, as I indicated.
>
>In addition to the risk management issue from the perspective of the
subscriber or the CA, there is also the question of the relying party's
risk with respect to CRLs, which is why I believe the subject needs to be
addressed within the CPS and perhaps the CA Accreditation Guidelines.
>
>But I probably play pretend-lawyer too much, so I'll defer to the real
experts.
>
>Bob
>
>>>> Blake Greenlee <[email-masked]> 03/04 12:14 PM >>>
>Dear Bob et al:
>
>To re-issue a public key in a new certificate or not is a risk management
issue, not a legal issue. Doing this shouldn't be any more constrained than
to point out that fact.
>
>It is probably not much more of a risk to re-issue a public key in a new
certificate than to send out new CA public keys in a message signed by the
old CA private key. (That is, given algorithms of appropriate key lengths).
>
>Blake
>
>
>
>-----Original Message-----
>From:  Bob Jueneman [SMTP:[email-masked]]
>Sent:  Wednesday, March 04, 1998 2:00 PM
>To:    [email-masked]
>Cc:    [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; Michael Baum;
[email-masked]
>Subject:       Fwd: Re: [IETF-PKIX] Multiple certificates for same key?
>
>There has been some discussion recently on the IETF-PKIX list
>regarding the wisdom of a CA reissuing a new certificate containing an old
public
>key -- in other words, issuing two certificates which contain the same key.
>
>I believe that this significantly complicates issues of certificate
revocation and
>nonrepudiation, and might have other legal consequences involving choice
of law issues
>and other considerations that are far from being immediately obvious.
>
>The subject arose originally in a discussion of the German digital
signature legislation.
>Although I haven't checked it, it might contain language that would
prohibit this
>practice -- I don't know.
>
>In any case, I think the issue is worth addressing from a legal and
legislative
>standpoint. In addition, as I said in the attached message to Steve Kent,
>I believe that the matter needs to be addressed in a CA's Certification
Practice
>Statement in order to provide a warning to a relying party, and it
probably ought
>to be addressed in the CA Accreditation Guidelines that are being
developed within
>the ABA Information Security Committee.
>
>Warwick Ford and Santosh Chokani, as the authors of the CPS Framework, and
the
>Federal PKI working group might also want to weigh in on this issue.
>
>I would be quite interested in any comments or feedback.
>
>Bob
>
>
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.
>Network Products Group
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>[email-masked]
>
>"If you are trying to get to the moon, climbing a tree,
>although a step in the right direction, will not prove
>to be very helpful."
>
>"The most dangerous strategy is to cross a chasm in two jumps."
>
> << Message: Re: [IETF-PKIX] Multiple certificates for same key? >>  <<
Message: Re: [IETF-PKIX] Multiple certificates for same key? >>
>
>
Regards,

Bill Burr

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 15:56:09 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Tony,

As you can imagine, I have had difficulty reading and responding to all
of the hornets at once, as well, so some of our mail has crossed.
I too hope the bandwidth expended has been worth it.

I think the point that I have been trying to make is that although
hashing the public key and saying "yes, SOME certificate exists and is valid
that matches that key" would establish the fact that the possessor of the
private key signed a document, there are inevitably, I argue, various
roles or other kinds of at least implied attributes that may have to be taken into
consideration, especially by the relying party.

The root problem is that the specific certificate which is intended to be used
to validate a digital signature is not crypotographically bound to the digitally
signed text, making it cryptographically ambiguous which certificate cum attributes
was intended to be validated.  In a sense, that is a fundamental flaw in the ASN.1
definition of a digital signature. It could be fixed, of course, and probably much
more easily repairing all of the various protocols that will ever use the Signed
macro, but I suspect that even though we are still at the dawn of this new era
and could fix it rather easily, we won't do that. "You can pay me now, or you
can pay me later." Sigh.

Anyway, thanks (blame?) to Stephan Kelm for raising this thread.
Every so often, we need to revisit our original assumptions and make sure
they are still valid.

Bob

>>> Tony Bartoletti <[email-masked]> 03/04 2:53 PM >>>
Bob,

Thanks for considering my comments.  I didn't see them until after sending
_yet_another_ diatribe on the issue.

While I am concerned about privacy issues, the real thrust of my exploration
was to ferret out, by way of implication, what cert-chain mechanisms folks
expect to exist.  The comments of some lead me to believe that an OSCP-type
responder could simply be submitted a public key (or its hash) and then it
would respond, boolean-wise, with "Yes, there IS a valid cert of some form for
that public key" or not.  That is, as if there would be no provision for the
(e.g., OCSP) user to specify a cert, or a set of attributes that must be
present to indicate the key is suitable for their purposes. Such a system
could only work if there were exactly one cert-per-key, so *the one* cert
(hence *the one* key) is either valid or not.

I hope all of this is of value to someone;)

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 15:39:57 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Paul, although I generally hate to respond point by point, I both
agree and disagree with you, so I guess I have to:>
>
>>>> Paul Koning <[email-masked]> 03/04 2:33 PM >>>
>I'll skip quoting previous messages because it's hard to tell anymore
>who said what....
>
>One analogy presented was that several certificates for the same key
>is similar to having several credit cards in your wallet.
>
>It occurs to me that some of what's going on in this discussion is the
>age-old problem of mixing up authentication with authorization.  As in
>"am I dealing with G. Paul Koning, that guy with the bushy beard,
>passport number foo...?" vs. "given that I believe I'm dealing with
>G. Paul Koning, is he entitled to charge $N to account number bar?"
>
>It seems pretty clear that a pile of certificates all attesting to the
>same key are certifying the same identity, i.e., authenticate the same
>entity.  But because they have different attributes, they may be
>driving different authorization decisions.

Quite correct.  If the identity is "you", you signed it, and "you" are liable.
But there is quite a difference between signing something in your
personal capacity vs. singing something as an authorized agent for
someone else, even though it is "you" who signed it in both cases.

Ask your corporate attorney what it means for your CEO to order
car and sign it "Bill Smith" vs. William A. Smith, President, XYZ Corp.
In the second case it is XYZ who is liable, not Bill personally.

>
>In other words, it looks like the question is: are certificates
>supposed to be authentication tools, or also authorization tools?

My point is that whether explicitly or implicitly, attributes other than the user's
common name imply, or at least tend to imply, some degree of authorization,
willy nilly.

>
>If only authentication tools, then that seems to leave only the case
>of recertifying an existing key as a meaningful scenario for multiple
>certificates.

And even that raises potential issues about CRLs.
>
>If also authentication tools, then clearly there can be many
>certificates since any individual is allowed to do many things, and
>those permissions are granted by many independent organizations.
>
>In the latter case, while it may be possible to have many different
>key pairs for those many authorizing certificates, I agree with Bill
>Burr that this is a bad idea.  The more bits of secret I have, the
>harder it is to protect those bits.

This is where I would take exactly the opposite view. if you cannot
tell which certificate is supposed to be used for what purpose, then
you don't know whether a particular authorization was valid or not.

(BTW, from an information theory standpoint, and particularly
from a covert channel analysis, the more bits of a secret
you have, the EASIER it is to protect it.  If you wrap up all of
your secretsin one short crypto key, it becomes extrarodinarily
difficult to protect it from a covert channel attack. but that's a
different issue. Of course covert channels, like Tempest attacks,
are not considered feasible, said the ostrich with his
head firmly in the sand.)

>
>Another point: if certificates are authorizing tools, you aren't
>actually going through the two step process of first authenticating
>then authorizing.  So it isn't functionally necessary to be able to
>prove that each of my authorizing certificates "belongs to" the same
>identity.  On the other hand, it seems to be very useful to be able to
>do this -- which is what you get by having them all tied to the same
>key.
>
>Finally, a thought that may not work... if there are many certificates
>sharing a key, it would make sense for revocation to revoke the key,
>not each certificate one by one.

Well, of course Carl Ellison and the SPKI crowd would agree with such
a key-centric view, but that would tend to further compound the problem of
blurring attributes associated with a particular key.
>
>        paul

Bob

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 4 Mar 1998 14:27:26 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

At 04:33 PM 3/4/98 -0500, Paul Koning wrote, in part:

>If only authentication tools, then that seems to leave only the case
>of recertifying an existing key as a meaningful scenario for multiple
>certificates.

As Bob Jueneman pointed out, in the absence of globally unique names,
how is such authentication to work?  Here at LLNL, there are several
Dave Browns and Bob Smiths, so even an additional company qualifier
fails to disambiguate.

Where the identity is unambiguous, then the "multiple certs" should
really be for authorizations, as you point out.  Multiple "identity"
certs may still differ in "class" or the degree of assurance given
to the binding by the CA.  So the RP application may need to know
which certificate, not to ascertain "role or attribute of holder" but
to determine assurance level appropriate to usage.

You make a very good point in alluding to a protocol that would state
"public key Z is revoked" rather than "cert Z is evoked" in the case
of revocation due to key compromise.  The difficulty:  In the latter
case, it is the cert issuer that governs a revocation status.  Who
would want the job of independently announcing the revocation status
of a key (perhaps wrongly) that has been certified by disparate parties?

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 15:20: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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Bill, I've already done my mea culpa's for the "signed by a certificate"
imprecise usage. Rather than reiterate the argument yet again, I
would be interested in your reaction to my recent reply to
Tony Bartoletti.

Havin' fun stirring up the hornets,

Bob

>>> Bill Burr <[email-masked]> 03/04 2:27 PM >>>
Bob,

But do we sign with a certificate, or with a key?  I don't think that key
and certificate are synonymous.  If the context of the certificate matters
to the signature, then I should include the certificate in the signed
message.
 [snip]

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 15:13:16 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Tony, I didn't go back to check, but I may have been guilty of the less
than precise usage implied by "which certificate was used to sign".
Obviously you are correct -- private keys sign documents, not certificates,
so the more correct usage would be "which certificate should be used to
validate a document that was signed by a private key which is mathematically
bound to a public key, which is in turn bound to some collection of attributes
and/or names in the certificate by the Certification Authority, based on
representations made by the subscriber and verified (more or less, as
spelled out in the CPS) by the CA." Sorry if I skipped a few steps in the terminology.

(What is the ASN.1 for "do what I mean, not what I say"?)

The problem, to the extent that there is one, is that the X.509 definition of the
"sign" macro does not provide any means of defining precisely which
certificate in particular should be used to validate a particular signature,
and thereby associate a particular set of name/rights attributes with that
signature.

(That's what often happens when a standard that was intended for one purpose
is appropriated for another, entirely different purpose. We, the digital signature
community, probably should have rethought that particular issue before adopting
the X.509 definition of signature. Some other information, such as the date/time and
signing and the identity of the platform ("location") on which the signature took
place would have been handy, also.)

But that's water over the dam by now, and so all of the various applications
which might ever want to use a digital signature have to solve the problem themselves.

Unfortunately, several of those applications further compounded the
original error by not incorporating an unambiguous reference to the certificate which
is to be used to validate the signature within the signed document itself, but rather
appended the reference to the certificate, or the certificate itself, to the document
in an insecure manner. One way around that problem would be to recite the
contents of the certificate itself, but that is both awkward, and not likely to be easily
machine processable, since no particular convention has been established for such a
process.

Since the certificate reference is not securely bound to the document in question,
another certificate could easily be substituted. If it were not for the private key
proof-of-possession requirement, this would even allow some other person to
claim authorship of the document, which might be quite useful in some circumstances.
And it certainly allows an individual who possesses the key but is wearing different
hats (roles) to play some games if it would be to his advantage.

To address your concerns, therefore, I submit that it matters a great deal to the
relying party whether the certificate that is used to validate a digitally signed document is
the Classy Certificate which identifies you as the purchasing agent for your company,
vs. the one which identifies you as the secretary of your bowling team, vs. the one for
you in your private citizen capacity, all of which had a common public key.

Although from a legal standpoint, it is "you" that signed the document in each case,
and hence "you" may be personally liable if your signature was not duly authorized
for that type of transaction, from the standpoint of the relying party "you" in your
private capacity may not have sufficient funds to pay for the nuclear reactor that
you just ordered in your capacity as an agent of Lawrence Livermore.

To put a different spin on it, suppose that you work for Unscrupulous Employer, Inc.
as an officer, director, or agent. You order 1 million blue widgets in the name of
your company in good faith. Unfortunately, by the time they arrive, the bottom
has dropped out of the blue widget market, and now everyone wants red ones.
Your employer is facing bankruptcy if they have to pay for the blue widgets, so some
way or another they manage to remove the company certificate from the signed
document and substitute your own personal certificate which contains the same key,
leaving you twisting slowly in the wind. Since widgets cost $10 apiece, the widget
manufacturer sues you for $10 million. He won't collect more than a few hundred
thousand after he sells your house, so both of you will be pretty upset.

You will both argue that it wasn't your private capacity certificate that was intended to
be referenced, but rather the company's Classy Certificate, and offer "proof" in the form of
the original document as received, but the Unscrupulous Employer can argue that you
change the document after it arrived, and that his copy was the correct one. At least
from a cryptographic standpoint it is indeterminate whose certificate was supposed
to have been used to validate the signature.

I suppose that once this problem is adequately recognized attorneys will advise the
clients not to rely solely on the certificate to establish authorship, but to include
a claim of authorship in the document itself, and to insist on such a reference
being in any signed transaction that is to be accepted, but as a technologist
I would prefer a technical solution.

Bob
>
>
>
>>>> Tony Bartoletti <[email-masked]> 03/04 1:18 PM >>>
>Pardon, please, my pedantic revisitation of this topic, but some of the
>comments that have been made imply (to me) a peculiar stance on the
>relationship between keys, certificates, end-entities (EE) and relying
>parties (RP).
>
>More than once, I have seen expressed "which certificate was used to sign"
>a document or transaction.  I thought that a "private key" was used, and is
>not a component of any certificate directly.  I think of a private key as
>having (potentially) a life of its own, possibly independent of any
>certificate (albeit not of great use where not certified in some capacity.)
>
>Where does the following example "fall down"? :
>
>In my hypothetical role as Purchase Officer for BigCorp, I obtain a classy,
>expensive certificate for a key, attesting to my identity and role, and
>obligating me to protect such key to the level of assurance indicated by
>the certificate.  I also have this key certified by Certs-R-Us as belonging
>to me in the capacity "member of chess club in good standing" (with a very
>low degree of assurance provided, and so a low cost.)
>
>I sign a purchase order on behalf of BigCorp.  The relying party must verify
>this signature, and so must obtain a some certificate by some means.  Simply
>verifying that some arbitrary public key verifies the signature is not
>enough.  It must be a *suitably certified* key.  If I point the RP to my
>"chess club" cert, the signature may verify, but the transaction should not
>proceed.  How could it?
>
>Also, how could my act of obtaining a "cheap cert" on the same key weaken
>in any way the relationship this key has to me in my BigCorp role, or my
>obligations to protect said key in accord with the provisions indicated in
>the classy, expensive certificate?
>
>Finally, I say all of this, not to advocate multiple certification of a key,
>(keys will NOT be a scarce commodity) but to understand the "liability issues"
>alluded to by some in this discussion.  I even wonder if there is a fear that
>"cheap CAs" might leverage the strong (pre-existing) certification on a key
>to issue additional certifications, attesting to whatever the owner-in-common
>would like, in essense conditioning the validity of their new binding on the
>continued validity of the "classy certificate."
>
>___TONY___
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 4 Mar 1998 13:53:22 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

Bob,

Thanks for considering my comments.  I didn't see them until after sending
_yet_another_ diatribe on the issue.

While I am concerned about privacy issues, the real thrust of my exploration
was to ferret out, by way of implication, what cert-chain mechanisms folks
expect to exist.  The comments of some lead me to believe that an OSCP-type
responder could simply be submitted a public key (or its hash) and then it
would respond, boolean-wise, with "Yes, there IS a valid cert of some form for
that public key" or not.  That is, as if there would be no provision for the
(e.g., OCSP) user to specify a cert, or a set of attributes that must be
present to indicate the key is suitable for their purposes. Such a system
could only work if there were exactly one cert-per-key, so *the one* cert
(hence *the one* key) is either valid or not.

I hope all of this is of value to someone;)

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 4 Mar 1998 16:45:54 -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] Multiple certificates for same key?
To: [email-masked]

> From: Bill Burr <[email-masked]>
>
> If I have 50 or 100 certificates, each with some particular attributes
> bound with my keys, one for the auto club, one for the New York Times
> on-line, one for every pay site I subscribe to, etc., and I want to carry
> them around on my token and use them at home and at work, etc., maybe I've
> got a problem.
>
> Is does seem to me to simplify my life to use one key to sign everything;
> after all, I don't sign my name differently when I use my AMEX card than
> when I use my Visa.   This makes sense if we separate attributes from
> identity and use X9 style attribute certificates, that don't contain a key.
>  I'm far from convinced that such attribute certificates are practical.

I believe the analogy is flawed.  When you use your AMEX card, the
information extracted from the magstripe is different than the
information on your Visa magstripe.  You use the same handwritten
signature to authorize both cards, just as you use the same PIN to
activate your token.

I always cringe when people use the word "certificate" to mean both a
public key certificate and the associated private data, but from an
ergonomic point of view, there isn't much difference.  When you select
an X.509 certificate in your web browser to sign a message, the browser
automatically uses the private key associated with that certificate.
If you have 50 or 100 certificates to choose from, you have to choose
once, but you don't have to choose again to get the proper private key;
that part is automatic.

And if a token can store n certificates of 1K-2K bytes each, adding an
additional 128-256 bytes of private key for each certificate doesn't
significantly change the number of certs that can be carried on
the token.

Dave Kemp

Approved-By:  Paul Koning <[email-masked]>
Date:         Wed, 4 Mar 1998 16:33:00 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

I'll skip quoting previous messages because it's hard to tell anymore
who said what....

One analogy presented was that several certificates for the same key
is similar to having several credit cards in your wallet.

It occurs to me that some of what's going on in this discussion is the
age-old problem of mixing up authentication with authorization.  As in
"am I dealing with G. Paul Koning, that guy with the bushy beard,
passport number foo...?" vs. "given that I believe I'm dealing with
G. Paul Koning, is he entitled to charge $N to account number bar?"

It seems pretty clear that a pile of certificates all attesting to the
same key are certifying the same identity, i.e., authenticate the same
entity.  But because they have different attributes, they may be
driving different authorization decisions.

In other words, it looks like the question is: are certificates
supposed to be authentication tools, or also authorization tools?

If only authentication tools, then that seems to leave only the case
of recertifying an existing key as a meaningful scenario for multiple
certificates.

If also authentication tools, then clearly there can be many
certificates since any individual is allowed to do many things, and
those permissions are granted by many independent organizations.

In the latter case, while it may be possible to have many different
key pairs for those many authorizing certificates, I agree with Bill
Burr that this is a bad idea.  The more bits of secret I have, the
harder it is to protect those bits.

Another point: if certificates are authorizing tools, you aren't
actually going through the two step process of first authenticating
then authorizing.  So it isn't functionally necessary to be able to
prove that each of my authorizing certificates "belongs to" the same
identity.  On the other hand, it seems to be very useful to be able to
do this -- which is what you get by having them all tied to the same
key.

Finally, a thought that may not work... if there are many certificates
sharing a key, it would make sense for revocation to revoke the key,
not each certificate one by one.

        paul

Approved-By:  "Balluffi, Frank" <[email-masked]>
Date:         Wed, 4 Mar 1998 16:23:51 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Balluffi, Frank" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

        I agree with Mark Shuttleworth:

>   2. If the signed package does not include the certs, or references
> to
>      the certs (like the issuer+serial form of authorityKeyIdentifier)
>      then the validating technology should examine each of the options
>      to see if an appropriate chain of authority can be found before
>      crying foul.  This is really the case where the reference is of
> the
>      "hash of key" form, which could in theory point to multiple certs
>      all containning the same key.
>
> What I'm trying to say is, we should come up with rules that the
> software
> should follow that allow for multiple certs containing the same key,
> rather than saying "hardly ever do this".  The market will determine
> how
> often we do it, and the implementation should support the market,
> rather
> than dictate.  Whew, better get off this pedestal before people start
> throwing fruit ;)
>
        I think the word "rules" is a bit strong. Perhaps the potential
problems associated with multiple certificates per public key should be
identified and accompanied by some suggestions. For example:

*       applications (and protocols) may uniquely identify a certificate
by issuer and serialNumber
*       policy qualifiers may be embedded into certificates

        It's hard to imagine an SSL client being confused by a
certificate containing the policy qualifier "only for use by protocol
number 9".

        As a consumer, I would like to be able to purchase an
inexpensive cryptographic token capable of storing one key pair and hold
multiple certificates, one for each application (or protocol).

        Frank Balluffi
        CertCo LLC
        [email-masked]

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 4 Mar 1998 12:18:27 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Pardon, please, my pedantic revisitation of this topic, but some of the
comments that have been made imply (to me) a peculiar stance on the
relationship between keys, certificates, end-entities (EE) and relying
parties (RP).

More than once, I have seen expressed "which certificate was used to sign"
a document or transaction.  I thought that a "private key" was used, and is
not a component of any certificate directly.  I think of a private key as
having (potentially) a life of its own, possibly independent of any
certificate (albeit not of great use where not certified in some capacity.)

Where does the following example "fall down"? :

In my hypothetical role as Purchase Officer for BigCorp, I obtain a classy,
expensive certificate for a key, attesting to my identity and role, and
obligating me to protect such key to the level of assurance indicated by
the certificate.  I also have this key certified by Certs-R-Us as belonging
to me in the capacity "member of chess club in good standing" (with a very
low degree of assurance provided, and so a low cost.)

I sign a purchase order on behalf of BigCorp.  The relying party must verify
this signature, and so must obtain a some certificate by some means.  Simply
verifying that some arbitrary public key verifies the signature is not
enough.  It must be a *suitably certified* key.  If I point the RP to my
"chess club" cert, the signature may verify, but the transaction should not
proceed.  How could it?

Also, how could my act of obtaining a "cheap cert" on the same key weaken
in any way the relationship this key has to me in my BigCorp role, or my
obligations to protect said key in accord with the provisions indicated in
the classy, expensive certificate?

Finally, I say all of this, not to advocate multiple certification of a key,
(keys will NOT be a scarce commodity) but to understand the "liability issues"
alluded to by some in this discussion.  I even wonder if there is a fear that
"cheap CAs" might leverage the strong (pre-existing) certification on a key
to issue additional certifications, attesting to whatever the owner-in-common
would like, in essense conditioning the validity of their new binding on the
continued validity of the "classy certificate."

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By: [email-masked]
Date:         Wed, 4 Mar 1998 11:37:33 +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: Mark Shuttleworth <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Hiya

I think that saying "OK, but only rarely" is dangerous, because it leads
to implementations which break when they see a signle key in multiple
certs.

How about this:

  1. Most "signing" technologies like S/MIME and PKCS#7 include the
     signing certificate along with the signed data.  So parsing
     applications only have to validate the presented or attached certs.

  2. If the signed package does not include the certs, or references to
     the certs (like the issuer+serial form of authorityKeyIdentifier)
     then the validating technology should examine each of the options
     to see if an appropriate chain of authority can be found before
     crying foul.  This is really the case where the reference is of the
     "hash of key" form, which could in theory point to multiple certs
     all containning the same key.

What I'm trying to say is, we should come up with rules that the software
should follow that allow for multiple certs containing the same key,
rather than saying "hardly ever do this".  The market will determine how
often we do it, and the implementation should support the market, rather
than dictate.  Whew, better get off this pedestal before people start
throwing fruit ;)

--
Mark Shuttleworth
Thawte Consulting

Approved-By: [email-masked]
Date:         Wed, 4 Mar 1998 12:50:04 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

At 09:42 AM 3/4/98 -0500, you wrote:
>> From: Tony Bartoletti <[email-masked]>
>>
>> The arguments put forth in deprecating multiple (independent) certification
>> of a single keypair are reasonable, but I point out that they belie the
>> purported nature of X.509 certificates as "identity certificates" (that is,
>> to bind the key simply to a warm body able to appear court.)
>
>I don't think X.509 certificates were ever purported to be "identity
>certificates" with the meaning you suggest.  That is an interpretation
>formulated by proponents of an alternative certificate format :-).
>
>The original purpose of X.509 was to provide strong (as opposed to
>password-based) authentication to X.500 directory servers.  Although
>X.509 v1 did bind just an "identity" to a key, the meaning of "identity"
>was concerned more with the privileges possessed by a warm body than
>by the warm body itself.  If Joe Smith @ foo.com had a certificate and
>the matching private key, he could get access to the directory if he
>was on the access list.  It doesn't really matter if Joe got his job
>under an assumed name to avoid child support, or how many Joe Smiths
>there are in the world, it only matters that there is one person with
>that userid at that company, and that that person is entitled to access.
>
>MISSI expanded the use of X.509v1 certificates by cleverly stuffing
>additional attributes (privileges, clearances, etc) into the
>subjectPublicKeyInfo field, since there was nowhere else to put them.
>Now that X.509v3 has extensions, privilege attributes can be included
>in a more proper location.  But the role of X.509 certificates is still
>the binding of privileges to keys, not the binding of warm bodies to keys.
>
>For the purpose of electronic filing of tax returns, or getting access
>to social security records, it would be convenient to have a "name"
>(i.e. SSN) that attempted to be uniquely tied to a particular warm body.
>But privacy advocates don't like that idea, so the binding between
>identities and warm bodies is deliberately left vague.  That is a
>political limitation, not a technical one.
>
>
>
>> Allowing independent certifications on a single key can be compared to the
>> use of both a "Diner's Club" card, and an "Auto Club" card.  If stranded
>> in a broken car, the tow truck operator will be uninterested in my Diner's
>> Club card, whether valid or not.  They want my Auto Club card, and want to
>> be assured that it is considered to be in effect at the time of
transaction.
>
>This presumes that keypairs are somehow a scarce commodity.  What
>possible benefit is there to having your Diners Club and Auto Club
>certificates share the same key?  They're just bits; billions and
>billions of combinations of them (apologies to the late A******
>Astronomer :-).  Just use a new keypair for each distinct purpose
>unless, as Bob Jueneman points out, there's a Very Good Reason not to.
>
>
Dave,

Keypairs may not exactly be a scarce commodity, but perhaps the protected
storage for private keys is.  If you think that you should keep your
private keys in a hardware token, you may not be able to have dozens of
private keys.

If I have 50 or 100 certificates, each with some particular attributes
bound with my keys, one for the auto club, one for the New York Times
on-line, one for every pay site I subscribe to, etc., and I want to carry
them around on my token and use them at home and at work, etc., maybe I've
got a problem.

Is does seem to me to simplify my life to use one key to sign everything;
after all, I don't sign my name differently when I use my AMEX card than
when I use my Visa.   This makes sense if we separate attributes from
identity and use X9 style attribute certificates, that don't contain a key.
 I'm far from convinced that such attribute certificates are practical.

But if, as you -I think correctly- suggest, we're actually binding a lot of
attributes into X.509 certificates, then I suspect that we're each
individually going wind up with a lot of x.509 public key certificates.  If
each of them has a different private key, then we've got a lot of private
keys to store, manage and protect.  I think that the fewer private keys I
have to manage, store and protect, the better.
Regards,

Bill Burr

Approved-By: [email-masked]
Date:         Wed, 4 Mar 1998 13:06:38 +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: Michael Warner <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Are you trying to solve too large a problem here ?   It seems as though you
are trying to have a fully automated equivalent of the entire legal system,
by trying to tightly link roles and responsibilities to the certificates.
It almost sounds like SPKI....

Surely the purpose of the certificate is to bind the public key with an
identity (or set of attributes) of a physical person.   The fact that I have
multiple names (or roles or other attributes) doesn't mean I'm actually
multiple people, or that I change my (handwritten) signature.

It is the application space which will be concerned about my various
attributes (including my name).   The fact that I have other attributes
(including my name) in one application space should not impact my attributes
in a second.   If the attributes have meaning in multiple application spaces
then they should not conflict.   If they do, it means they have been
incorrectly defined, assigned or interpreted.

If a signed message in one application space is so ambiguous in nature as to
have meaning in a different application space there would seem to be a
problem with the definition of the message structures of the applications -
not the certificates.

Cheers,

Michael

-----Original Message-----
From: Bob Jueneman <[email-masked]>

>The issue, of course, is that if there are two certificates which both
contain the same public key, then  the binding from the private key (which
signed the document) to the public key to the identity and other attributes
which are associated with the public/private key become indeterminate.
>
>It might be argued that if it is indeed the same entity, the no harm no
foul rule should apply. But I would argue that unless the ENTIRE contents of
the two certificates are precisely identical (in which case why bother),
then different is not the same.

>
>To go further would require an extensive analysis of exactly what the
differences were, and whether they might matter, even in some obscure
context that would be difficult to envision.  For example, a difference in
validity period might have some difference down the line in terms of
nonrepudiation, especially if one certificate was revoked because of a
compromise and the other was not.
>
>In the case of differences in the common name, address, etc., even though
it is the same person using either her married or personal name (Mrs. John
Smith vs. Lucy Smith), there might be some obscure legal difference due to
community property laws or whatnot -- who knows.
>
>Likewise, two different certificates -- one listing my primary residence
and the other my summer cabin -- might have slightly different connotations
in a legal context, since there might be differences in the laws of the two
different jurisdictions, and in the absence of any other indication of the
locus of the transaction, the locality of the user as expressed in the
certificate might govern.
>
>At one time I took the hard and fast position that said that the same
public key should NEVER be used in two different certificates, but someone
convinced me that sometimes corporations change their name (Esso to Exxon,
United States Steel to USX, etc.), other times they are acquired by another
company. forcing a drastic change of all of the subordinate names might
screw up name subordination and other mechanisms, and shouldn't be done
hastily, even if the organization whose name is changing is a CA.  So I
guess I can't say that public keys should _never_ be reused.
>
>How about HARDLY EVER, ALMOST NEVER, ONLY IF THE SUN DOESN'T RISE, AND THEN
ONLY IF YOU STOP AND THINK REAL HARD?
>
>On the other hand, having multiple certificates, all with the same entity
information but with different keys, whether because of different key
usages, algorithms, or just your whim, is perfectly acceptable. Maybe you
can get the CA to give you a volume discount.  (Seriously, why not, since
most of what they are doing is the due diligence of confirming who you are?)
>
>Bob
>
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.
>Network Products Group
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>[email-masked]
>
>"If you are trying to get to the moon, climbing a tree,
>although a step in the right direction, will not prove
>to be very helpful."
>
>"The most dangerous strategy is to cross a chasm in two jumps."
>
>
>>>> Tony Bartoletti <[email-masked]> 03/02 3:35 PM >>>
>Stefan,
>
>At 06:34 PM 3/2/98 +0100, you wrote:
>>Folks,
>>
>>I haven't had the time to browse through all the different latest drafts,
I'm
>>afraid. Having had some discussions concerning the German digital
signature
>>law, however, a question occured to me: Is a CA allowed to issue two (or
>>more) certificates for a single end-entity's public key? If yes, this
could
>>lead to big problems, especially in terms of liability of the CA. If
>>not, shouldn't this be specified somewhere?
>
>Could you expand on the liability issues you mention regarding the issuance
of
>differing certificates for the same public key?  From a layman's point of
>view,
>of course a CA could get into trouble issuing arbitrary certificates on a
>given
>end-user's public key.  But, for the sake of argument, if I want the same
key
>to be certified by a CA in two distinct certificates, both of which contain
>data that identifies me (in different ways, for different reasons,) then it
>seems to be up to the relying party to check if there is a valid
certificate
>for that key, suitable for their purposes of identification.  (Apologies
for
>naive view and tortured sentence structure.)
>
>Here is a related question (and perhaps more likely desired) : Can I ask a
CA
>to certify 10 keys, in 10 certificates, all of which attest to identical
info?
>(modulo certificate id, or course.)  My thought is, I want to use my keys
very
>sparingly, cycling through them so to thwart marketeers attempting to trace
my
>habits.  This presupposes that I, the cert-owner, control the cert that I
>point
>the relying party to use.
>
>Thoughts?
>
>
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: [email-masked]   phone: 510-422-3881             LLLLLLLL
>

Approved-By: [email-masked]
Date:         Wed, 4 Mar 1998 10:36:53 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      Re: [IETF-PKIX] Re patent 5699431 & PKIX
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msA259957B314729DBF867807C
Content-Type: multipart/mixed; boundary="------------749BDBCE2BA6267C9E2CAD72"

This is a multi-part message in MIME format.
--------------749BDBCE2BA6267C9E2CAD72
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul,
I think that David is right but there may be a larger issue at hand here...

It is my understanding that  since a company or private entity could file for a
patent against a technology up to  one year after public disclosure, that it
would be possible to enact a standard in the IETF/IESG and then patent it if you
could complete the standardization process in less than the obligatory year.
With this in mind perhaps a revision of the IETF charter text with regard to
patent issues is in order.

By the way - The actual text of the Intellectual property's notice (as taken
from the bottom of http://www.ietf.org.ipr.htm) reads something like:

(C) Where the IESG knows of rights, or claimed rights under (A), the IETF
Executive Director shall attempt to obtain from the claimant of such rights, a
written assurance that upon approval by the IESG of the relevant Internet
standards track specification(s), any party will be able to obtain the right to
implement, use and distribute the technology or works when implementing, using
or distributing technology based upon the specific specification(s) under openly
specified, reasonable, non-discriminatory terms. The Working Group proposing the
use of the technology with respect to which the proprietary rights are claimed
may assist the IETF Executive Director in this effort. The results of this
procedure shall not affect advancement of a specification along the standards
track, except that the IESG may defer approval where a delay may facilitate the
obtaining of such assurances. The results will, however, be recorded by the IETF
Executive Director, and made available. The IESG may also direct that a summary
of the results be included in any RFC published containing
the specification.

for further clarification of patented technologies in Internet Standards, see
section 4.1.2  and section 10.3.2 of RFC2026 - The Internet Standards Process
v3.

In my mind there is a bigger question as to whether the IETF should set a
standards requirements that makes its standardized technologies free of patent
encumbrance. Personally I think that since the US people are still funding the
bunt of the Internet and its operations that the technologies that we as IETF
members standardize on MUST be freely available to all.

With that in mind, from my viewpoint there are two time based issues with the
patent issues

    1) the text of the existing charter is specific to "patented" technologies,
but doesn't address the timeliness of the disclosure and with the amount of time
it takes to get a submission worked through the US PTMO, sometimes as much as
two (2) years or longer if the claims of a given patent are opened to
prosecution or the like, it seems reasonable that the text of the IETF/IESG
charter could be amended to refer to "technologies or specific implementations
of technologies" that are under way or will be filed for patent protection
within the 1 year filing deadline for US based disclosure. (whew!, sorry bout
the long sentence there!)

With this type of patent-specific text in place, any technologies that are
enacted as standards would not be patentable UNLESS they, the patents
themselves, were put into the public trust or maybe as an alternative "licensed
freely" as though they were in the public trust... Somewhat like the Spread
Spectrum Radio Patents done in the 40's.

I apologize for ranting, but this is an issue that I am particularly sensitive
to!.

Todd

David P. Kemp wrote:

> > From: Paul Hoffman / IMC <[email-masked]>
> > Date:         Thu, 15 Jan 1998 17:55:15 -0800
> >
> > Section 10.3.2 specifies what kind of patent information must be made
> > available before something can move onto standards track. If a company is
> > known to have an applicable patent but has not come up with a patent
> > statement, that company can hold up the process of getting the document on
> > standards track (nudge, nudge).
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
>
> draft-ietf-pkix-ipki3cmp-07.txt does not contain a patent statement, sigh.
> Will we need to wait for draft -08 before going to the IESG?
> (nudge, nudge, nudge).

 No - Lets get this one into IESG for review and action.

--
--------
--  Regards,
--  Todd Glassey

Todd's Latest Rant --
---------------------
"...Plan?, There ain't no plan, I though' you had the plan..."
      The Pig Killer - Mad Max: Beyond Thunderdome

--------------749BDBCE2BA6267C9E2CAD72
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Todd S. Glassey
n:              Glassey;Todd S.
org:            Coastek, Inc.
adr:            5550 Scotts Valley Drive;;Suite 700;Scotts Valley;Ca;95066;USA
email;internet: [email-masked]
title:          Chief Scientist and Principal Founder
tel;work:       408.440.0180
tel;fax:        408.438.2979
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

--------------749BDBCE2BA6267C9E2CAD72--

--------------msA259957B314729DBF867807C
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msA259957B314729DBF867807C--

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Wed, 4 Mar 1998 11:53:05 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      [IETF-PKIX] Examples from PKIX part 1
To: [email-masked]

David Kemp has prepared binary examples of the three certs and the CRL that
are
shown in the back of the PKIX part 1 draft. They are now available at the
S/MIME WG's page at
<<http://www.imc.org/ietf-smime/>http://www.imc.org/ietf-smime/>, near the
bottom of the page.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 12:42:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Tony,

You've raised some good issues, and the question of a pure "identity"
certificate vs. one which contains additional attributes has been hotly
debated, especially on the SPKI list.

Since a common name is not sufficient to identify an individual in a globally
unambiguous way (something that is at least thought to be desirable in order to
facilitate global electronic commerce), some form of additional name
qualification is required.

Whether that involves the use of an organization name or a residential address,
I would argue that there are at least subtle implications of "rights" that may be
involved, whether we in the technical community intended that or not.

For example, although it might not be reasonable to assume that someone who
is issued a certificate containing the name of corporation XYZ is an agent (e.g.,
a purchasing agent) for that company, at least in the US there is a doctrine of
implied agency. That is, if it walks like a duck, quacks like a duck, and is ordering
duck food, it probably is a purchasing agent -- or at least the relying party may be
entitled to believe so. Obviously if someone has a certificate issued by XYZ Corp.
and is requesting a dozen pencils to be shipped to XYZ, they are more likely to be
believe than if the pencils were to be shipped to ABC Corp.

Likewise, there are subtle implications that may be associated with someone's
residential address. For example, if I am going to send out (spam) invitations to
visit my off-shore or Indian reservation gambling casino, I might not want to send
it to residents of states which ban such gambling. And likewise, if I were inclined
to make available for downloading from my web site in SanFrancisco certain
pictures that shall we say might be in questionable taste, I probably wouldn't
want to allow residents of states such as Utah and Tennessee to access such
images, for people have been convicted for violating those state's local standards
as to what constitutes pornography or indecent material.

Without getting metaphysical about it, the point is that the only available "attributes"
that can reasonably be used to differentiate between two individuals with the
same name also have other societal implications that may be both inescapable
and difficult to predict in advance, as it may in fact depend on the whim of some local
legislatures, rather than any bright-line legal principles.

In other words, as a bumper sticker on a water treatment truck I saw recently
said, "E coli happens."

Bob

>
>>>> Tony Bartoletti <[email-masked]> 03/03 8:10 PM >>>
>I am not a lawyer, and I don't claim to appreciate fully the legal issues
>surrounding a CA and their obligations, in either general or specific cases.
>
>The arguments put forth in deprecating multiple (independent) certification
>of a single keypair are reasonable, but I point out that they belie the
>purported nature of X.509 certificates as "identity certificates" (that is,
>to bind the key simply to a warm body able to appear court.)  Rather, they
>become attribute certificates, attesting to (say) primary residence, not so
>much for distinguishing among similarly named individuals but now assuming
>a free standing legal significance.  The certificate no longer attests only
>that a given document was signed by me, it can now be used as evidence that
>I reside at location X, *independent* of my use of the key at all.  While I
>can appreciate the utility of such usage, I question where the boundaries lie.
>
>Allowing independent certifications on a single key can be compared to the
>use of both a "Diner's Club" card, and an "Auto Club" card.  If stranded
>in a broken car, the tow truck operator will be uninterested in my Diner's
>Club card, whether valid or not.  They want my Auto Club card, and want to
>be assured that it is considered to be in effect at the time of transaction.
>
>True, a key compromise on one should affect all certificates over that key.
>If one certificate is not revoked, but should have been, it could just as
>easily be the certificate appropriate to the transaction as the one not.
>
>I wonder if the central issue is primarily one of protocol.  The RP must
>(somehow) obtain not just *any* certificate validating my ownership of the
>key in question, but the certificate indicating I satisfy the role that the
>relying party expects for a signatory to the given transaction.  (In pure
>"Identity Cert" principle, any such cert should just identify "me" to a
>given degree of assurance, and then the relying party should use that fact
>to determine if, within their own domain, this "me" has the required role.)
>
>Again, I am not really advocating such usage, but I wonder if the restriction
>is simply one of cert retrieval complexity, or if such usage would really
>"break X.509".  Has the structure so embedded these legal implications?
>
>___TONY___
>
>
>Tony Bartoletti                                             LL
>SPI-NET GURU                                             LL LL
>Computer Security Technology Center                   LL LL LL
>Lawrence Livermore National Lab                       LL LL LL
>PO Box 808, L - 303                                   LL LL LLLLLLLL
>Livermore, CA 94551-9900                              LL LLLLLLLL
>email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Mar 1998 11:41:37 -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] Multiple certificates for same key?
Comments: To: [email-masked]
To: [email-masked]

Steve,

I already agreed that I was not going to fall on my sword over the issue
of never, ever allowing two certificates to be issued for the same key,
at least in part because I don't know any possible mechanism for enforcing
such a rule if the user goes to two different CAs for the two certificates,
perhaps under two slightly different names or name forms. I suppose that
once we have established the principle, as the saying goes, all that
remains to be argued about is the price,

On the other hand, I am somewhat troubled by your example of deliberately
using a short validity interval to minimize the CRL problem, and re-certifing
the old key with a new certificate.  You may have minimized the CA's storage
space problem, and also minimized the bandwidth required to transmit the CRLs,
and in your new position as CTO for GTE CyberTrust (congratulations/ condolences :-)
I can understand that point of view, but rather than having eased the CRL management
problem I think you have compounded it, at least from the user's standpoint.

As Andreas Berger correctly pointed out, and I certainly should have, unless the
certificate is actually incoporated within the document which is being signed, it is not
deterministic which certificate was actually intended. Certainly in S/MIME (and PEM)
the certificate was carried in an unsigned attachment, and could therefore be
substituted or deleted, if indeed it was transmitted at all. it was this very possibility
that lead us to require proof of possision of the private key, so that someone
couldn't extract someone else's public key and include it in his own certificate,
and thereby claim authoriship for a signed document.

Certainly in the case of software-stored keys, there is no shortage of bits, and
there is very little reason I can think of to use such a re-certification mechanism
instead of a key update/replacement scheme.  Granted, in the case of a
centrally managed hardware token it may be slightly more difficult to
regenerate keys, especially in view of the power requirements for good hardware
key generation that was recently discussed on the cert-talk list in connection with a
Smart Disk, but I am not entirely convinced about that either.

I guess my recommendation would be for PKIX to officially deprecate recertification of a key
as generally undesirable without, as David Kemp says, A Very Good Reason, but not
to prohibit it entirely. Within that overall guidance, CAs and users (and relying parties!)
can make up their own mind what do to.

If as a CA you want a user's and potential relying party's point of view, I personally
wouldn't put a lot of faith in any CA who would countenance such actions, and I
would certainly want to see notice provided in a CA's CPS that would warn me of that
possibility. If a given CA issues multiple certificate for the same key _without_ informing
relying parties, I would be inclined to say that they were being derelict in their duty.

I'm going to bring this issue to the attention of the group within the ABA Information Security Committee that is drafting CA Accreditation Guidelines, so they can consider it further.

Bob

>>>> Stephen Kent <[email-masked]> 03/04 7:21 AM >>>
>Bob,
>
>Ignoring issues of non-repudiation (for which only some certs may be
>employed), it may be reasonable for two certs to hold the same public key.
>For example, A CA may choose to have a short validity interval to ease CRL
>management, but not require users to generate and transmit new key pairs to
>match the interval.  In that case, the CA can merely re-certify the old key
>and reissue a cert with a new serial number and the same name, and probably
>all the other attributes would be the same as well.
>
>Steve

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

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

"The most dangerous strategy is to cross a chasm in two jumps."

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Wed, 4 Mar 1998 10:37:31 -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: Trevor Freeman <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

It is impossible for CA to establish whether a public key has been used in a
certificate elsewhere.
The public key bind the user to the certificate, but the it is the
certificate which hold the CA policy on the use of the certificate which is
equally important part of the process.
It is impossible to resolve this issue within the PKI alone. We should
recommend that when generating a signature for non-repudiation purposes
applications must ensure that the identity of the certificate used to sign
is part of the data protected by the signature.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 4 Mar 1998 11:56:32 -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] Re patent 5699431 & PKIX
To: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> Date:         Thu, 15 Jan 1998 17:55:15 -0800
>
> Section 10.3.2 specifies what kind of patent information must be made
> available before something can move onto standards track. If a company is
> known to have an applicable patent but has not come up with a patent
> statement, that company can hold up the process of getting the document on
> standards track (nudge, nudge).
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

draft-ietf-pkix-ipki3cmp-07.txt does not contain a patent statement, sigh.
Will we need to wait for draft -08 before going to the IESG?
(nudge, nudge, nudge).

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Wed, 4 Mar 1998 08:34:43 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

>If we agree that this comment data ought not be verified, then the argument
>is really over the inclusion of non-verified data in certs, which is a long
>standing debate in this community.  Deliverability is not the issue here,
>but rather the opportunity for users to be mislead.

Quite right. I agree with the "allow non-verified data" camp as long as we
put lots of words in the document about what things we know can't be
verified, then let CAs decide what to do with it. It seems like
over-regulation to say "we know better what you shouldn't put into a cert,
so we're going to prohibit it even though you might have done it well." The
comment in RFC 822 names is a very good example of this.

Since the mailing list archive has a huge hole in it, I don't know if this
debate was ever resolved for PKIX.

>Not sure where "DirectoryString" enters into our discussion.  It seems that
>there is a catch 22 here:  you seem to be saying that it's OK to not verify
>this data as a CA, but then suggest that it is important to include because
>of it's user friendliness.

Right.

>  This suggests that the latter quality is

>important for user comsumption, but that user consumption of unverified
>data from what purports to be a secure form of identiofication is OK in
>this context.  That's hard for me to accept.

It isn't for me. How do you know how well the CA verified the 822 address?
Did they send mail to it and get it back? Did they just do a VRFY on it?
Did they ever check it again? At what intervals? Did they check with the
Postmaster at the site to make sure the address was known to her/him and
not a hacker who got a temporary account by fraud? All of these things are
determined by reading the CA's policy before trusting them. Whether or not
they verified the comment part of the name is just one more thing on the
list of things that the CA tells you they verified.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Koning <[email-masked]>
Date:         Wed, 4 Mar 1998 10:23:18 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

...
 David> For the purpose of electronic filing of tax returns, or
 David> getting access to social security records, it would be
 David> convenient to have a "name" (i.e. SSN) that attempted to be
 David> uniquely tied to a particular warm body. ...

Digression alert...  identity to SSN binding is not actually unique,
in two ways: a person can have more than one SSN, and on a few
occasions apparently the same SSN has been issued more than once.

        paul

Approved-By:  "Balluffi, Frank" <[email-masked]>
Date:         Wed, 4 Mar 1998 10:13: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: "Balluffi, Frank" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

There are many reasons to issue multiple certificates per public key
(see example below).

There are also many reasons to only issue one certificate per public
key. For example, suppose a corporation provides a cryptographic token
capable of holding one key pair to each employee and institutes a policy
of only allowing the token to be used for corporate business. One method
of enforcing this policy might be to only permit one certificate to be
issued per public key. This method would disallow the public key to be
bound to the employee's corporate name (e.g., C=US, O=XYZ, CN=John
Smith) and personal name (e.g., C=US, ST=IL, L=Chicago, CN=John Smith).

It seems to me that the question of how many certificates per public key
is a policy question, not a technical question.

Frank Balluffi
CertCo LLC
[email-masked]

> -----Original Message-----
> From: Stephen Kent [SMTP:[email-masked]]
> Sent: Wednesday, March 04, 1998 9:22 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
>
> Bob,
>
> Ignoring issues of non-repudiation (for which only some certs may be
> employed), it may be reasonable for two certs to hold the same public
> key.
> For example, A CA may choose to have a short validity interval to ease
> CRL
> management, but not require users to generate and transmit new key
> pairs to
> match the interval.  In that case, the CA can merely re-certify the
> old key
> and reissue a cert with a new serial number and the same name, and
> probably
> all the other attributes would be the same as well.
>
> Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 4 Mar 1998 09:59:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Andreas,

>> I haven't had the time to browse through all the different latest
>>drafts, I'm
>> afraid. Having had some discussions concerning the German digital signature
>> law, however, a question occured to me: Is a CA allowed to issue two (or
>> more) certificates for a single end-entity's public key? If yes, this could
>> lead to big problems, especially in terms of liability of the CA. If
>> not, shouldn't this be specified somewhere?
>>From a technical point of view, there is no reason why it should be
>defined whether issuing several certificates for a single public key.
>The problem simply is that if you have two certificates with the same
>key available you cannot distinguish which one was used to produce the
>signature. To accomplish that you would have to name the certificate
>inside the document that was signed. This way, you can make sure that
>the signer chose the correct context (certificate) to sign the document.
>
>This whole scheme fails once the secret key is retrieved. Then anybody
>can use any of the two certificates. And what do you do if only one of
>the certificates is revoked, the other is not? Then it is important, why
>the certificate was revoked (a formal reason or a key compromise).
>
You are right that using the same key in two or more certs implies a need
to revoke all of them in the case of a compromise.  You and others are also
right that certain instances of reusing a key have significant adverse
effects, especially with regard to non-repudiation.  However, not all uses
of certs are for NR and there are legitimate circumstances for reuse, thus
I would not expect PKIX to preclude such reuse, though inclusion of a
suitable warning is not unreasonable.

Steve

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 4 Mar 1998 09:48:23 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Paul,

>>I'd like to suggest that we not allow all of these representations of RFC
>>822 names, despite your obeservation that they are all syntactically
>>allowed under RFC 822.  My reasoning is that we ought to not confuse the
>>bounds of what is being certified.  As a CA, I can readily validate a pure
>>user_name@FQDN syntax, but when someone includes a parenthetical comment,
>>it makes the verification harder and subject to errors.
>
>I completely disagree. The RFC 822 syntax is absolutely clear that the
>other stuff is a comment with no relation to the deliverability of the
>address. It doesn't make "the verification harder and subject to errors":
>it is *never verified* because it can't be.

If we agree that this comment data ought not be verified, then the argument
is really over the inclusion of non-verified data in certs, which is a long
standing debate in this community.  Deliverability is not the issue here,
but rather the opportunity for users to be mislead.

>>  A user seeing such
>>a name is likely to pay more attention to a more human-readable part of the
>>name, which may not be verified, while software is almost certain to pay
>>attention to the more tightly constrained synatx that actually supports
>>addressing of the message.
>
>Possibly true. However, a user might also believe that the bare email
>address is valid because the cert is value, when in fact the address was
>only valid for the five minutes in which the CA checked it. Or the user
>might believe that "[email-masked]" means Joe is associated with IBM, even
>though he is no longer. And so on and so on. This is a user interface
>issue, not a reliability issue. And you'll have the same issue with many
>kinds of otherNames, uniformResourceIdentifiers, and iPAddresses (for IPv6).

This is a user interface issue, but it is also a security issue and this is
a security standard.  The user ID in a cert is of greatest concern to me
because of its likely extensive use in secure e-mail, where user's will
often make value judgements, vs. IP addresses and DNS names being processed
by software in IPsec.

>>  Thus a mismatch may occur if a secure e-mail
>>package or IPsec implementation validates based on the more restricted
>>syntax, but the user thinks in terms of the comment part of the name.
>
>Well, they shouldn't do that, should they? A comment in the draft would fix
>that.

We cannot standardize user behavior, but we can avoid obvious pitfalls that
users might encounter.

>You are making the field less friendly for fear of confusing people, but
>there are lots of room for other confusions in DirectoryString. I'd say
>leave it as it is and put a note in the text saying "nothing other than
>the address portion of the name can be verified based on the definition in
>RFC 822" and leave it at that.

Not sure where "DirectoryString" enters into our discussion.  It seems that
there is a catch 22 here:  you seem to be saying that it's OK to not verify
this data as a CA, but then suggest that it is important to include because
of it's user friendliness.  This suggests that the latter quality is
important for user comsumption, but that user consumption of unverified
data from what purports to be a secure form of identiofication is OK in
this context.  That's hard for me to accept.

Steve

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 4 Mar 1998 09:42: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

> From: Tony Bartoletti <[email-masked]>
>
> The arguments put forth in deprecating multiple (independent) certification
> of a single keypair are reasonable, but I point out that they belie the
> purported nature of X.509 certificates as "identity certificates" (that is,
> to bind the key simply to a warm body able to appear court.)

I don't think X.509 certificates were ever purported to be "identity
certificates" with the meaning you suggest.  That is an interpretation
formulated by proponents of an alternative certificate format :-).

The original purpose of X.509 was to provide strong (as opposed to
password-based) authentication to X.500 directory servers.  Although
X.509 v1 did bind just an "identity" to a key, the meaning of "identity"
was concerned more with the privileges possessed by a warm body than
by the warm body itself.  If Joe Smith @ foo.com had a certificate and
the matching private key, he could get access to the directory if he
was on the access list.  It doesn't really matter if Joe got his job
under an assumed name to avoid child support, or how many Joe Smiths
there are in the world, it only matters that there is one person with
that userid at that company, and that that person is entitled to access.

MISSI expanded the use of X.509v1 certificates by cleverly stuffing
additional attributes (privileges, clearances, etc) into the
subjectPublicKeyInfo field, since there was nowhere else to put them.
Now that X.509v3 has extensions, privilege attributes can be included
in a more proper location.  But the role of X.509 certificates is still
the binding of privileges to keys, not the binding of warm bodies to keys.

For the purpose of electronic filing of tax returns, or getting access
to social security records, it would be convenient to have a "name"
(i.e. SSN) that attempted to be uniquely tied to a particular warm body.
But privacy advocates don't like that idea, so the binding between
identities and warm bodies is deliberately left vague.  That is a
political limitation, not a technical one.

> Allowing independent certifications on a single key can be compared to the
> use of both a "Diner's Club" card, and an "Auto Club" card.  If stranded
> in a broken car, the tow truck operator will be uninterested in my Diner's
> Club card, whether valid or not.  They want my Auto Club card, and want to
> be assured that it is considered to be in effect at the time of transaction.

This presumes that keypairs are somehow a scarce commodity.  What
possible benefit is there to having your Diners Club and Auto Club
certificates share the same key?  They're just bits; billions and
billions of combinations of them (apologies to the late A******
Astronomer :-).  Just use a new keypair for each distinct purpose
unless, as Bob Jueneman points out, there's a Very Good Reason not to.

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 4 Mar 1998 09:21: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Bob,

Ignoring issues of non-repudiation (for which only some certs may be
employed), it may be reasonable for two certs to hold the same public key.
For example, A CA may choose to have a short validity interval to ease CRL
management, but not require users to generate and transmit new key pairs to
match the interval.  In that case, the CA can merely re-certify the old key
and reissue a cert with a new serial number and the same name, and probably
all the other attributes would be the same as well.

Steve

Approved-By:  Peter Lipp <[email-masked]>
Date:         Wed, 4 Mar 1998 11:15:55 +0100
Reply-To: Peter Lipp <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Lipp <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0061_01BD475E.E6B01800
Content-Type: multipart/mixed;
        boundary="----=_NextPart_000_005F_01BD475E.E6A9FD80"

------=_NextPart_000_005F_01BD475E.E6A9FD80
Content-Type: text/plain;
        charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

>Does it make things slightly harder to process, or does it actually =
break
>X.509?

>Consider the scenario of a person who wishes to manage different
>"certificate profiles" but not have to worry about different keys.  For
>example, he may want to sign messages as one person within the company,
>using a cert with his Org, OrgUnit and Title, but outside the company =
he
>wants to use a simpler cert that just has his name and email address in
>it.  Why should both of those certs be forced to use different keys?

My image of these processes is a keycentric one.=20

If you get a signature, accepting the signature involves a) the =
cryptographic correctness of the signature and b) my policy accepting =
the certificate given. If one has 2 certificates for one key, the =
decision will not depend on the key only, but also on the certificate =
given. I consider this to be not ok. I would like to be able to use =
protocols that do not need to provide me with a suitable certificate - I =
could have a local cache or so. Carrying certificates around is not so =
great, considering the space such things use to take. Assuming a working =
infrastructure, I could ask some CA-service to deliver a cert if I don't =
have it in my cache. If there would be more than one, leading to =
different trust decisions, this would be a drawback.=20

Peter

------=_NextPart_000_005F_01BD475E.E6A9FD80
Content-Type: text/x-vcard;
        name="Peter Lipp.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
        filename="Peter Lipp.vcf"

BEGIN:VCARD
VERSION:2.1
N:Lipp;Peter;;
FN:Peter Lipp
ORG:Styria;
TITLE:
TEL;WORK;VOICE:+43 316 873 5513
TEL;HOME;VOICE:
TEL;VOICE:Graz
TEL;WORK;FAX:A-8042
ADR;WORK:;;;;;;
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:=0D=0A,  =0D=0A
EMAIL;PREF;INTERNET:[email-masked]
REV:19980304T101555Z
END:VCARD

------=_NextPart_000_005F_01BD475E.E6A9FD80--

------=_NextPart_000_0061_01BD475E.E6B01800
Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="smime.p7s"

------=_NextPart_000_0061_01BD475E.E6B01800--

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Tue, 3 Mar 1998 21:23:25 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

>I'd like to suggest that we not allow all of these representations of RFC
>822 names, despite your obeservation that they are all syntactically
>allowed under RFC 822.  My reasoning is that we ought to not confuse the
>bounds of what is being certified.  As a CA, I can readily validate a pure
>user_name@FQDN syntax, but when someone includes a parenthetical comment,
>it makes the verification harder and subject to errors.

I completely disagree. The RFC 822 syntax is absolutely clear that the
other stuff is a comment with no relation to the deliverability of the
address. It doesn't make "the verification harder and subject to errors":
it is *never verified* because it can't be.

>  A user seeing such
>a name is likely to pay more attention to a more human-readable part of the
>name, which may not be verified, while software is almost certain to pay
>attention to the more tightly constrained synatx that actually supports
>addressing of the message.

Possibly true. However, a user might also believe that the bare email
address is valid because the cert is value, when in fact the address was
only valid for the five minutes in which the CA checked it. Or the user
might believe that "[email-masked]" means Joe is associated with IBM, even
though he is no longer. And so on and so on. This is a user interface
issue, not a reliability issue. And you'll have the same issue with many
kinds of otherNames, uniformResourceIdentifiers, and iPAddresses (for IPv6).

>  Thus a mismatch may occur if a secure e-mail
>package or IPsec implementation validates based on the more restricted
>syntax, but the user thinks in terms of the comment part of the name.

Well, they shouldn't do that, should they? A comment in the draft would fix
that.

You are making the field less friendly for fear of confusing people, but
there are lots of room for other confusions in DirectoryString. I'd say
leave it as it is and put a note in the text saying "nothing other than
the address portion of the name can be verified based on the definition in
RFC 822" and leave it at that.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Tue, 3 Mar 1998 19:10:49 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

I am not a lawyer, and I don't claim to appreciate fully the legal issues
surrounding a CA and their obligations, in either general or specific cases.

The arguments put forth in deprecating multiple (independent) certification
of a single keypair are reasonable, but I point out that they belie the
purported nature of X.509 certificates as "identity certificates" (that is,
to bind the key simply to a warm body able to appear court.)  Rather, they
become attribute certificates, attesting to (say) primary residence, not so
much for distinguishing among similarly named individuals but now assuming
a free standing legal significance.  The certificate no longer attests only
that a given document was signed by me, it can now be used as evidence that
I reside at location X, *independent* of my use of the key at all.  While I
can appreciate the utility of such usage, I question where the boundaries lie.

Allowing independent certifications on a single key can be compared to the
use of both a "Diner's Club" card, and an "Auto Club" card.  If stranded
in a broken car, the tow truck operator will be uninterested in my Diner's
Club card, whether valid or not.  They want my Auto Club card, and want to
be assured that it is considered to be in effect at the time of transaction.

True, a key compromise on one should affect all certificates over that key.
If one certificate is not revoked, but should have been, it could just as
easily be the certificate appropriate to the transaction as the one not.

I wonder if the central issue is primarily one of protocol.  The RP must
(somehow) obtain not just *any* certificate validating my ownership of the
key in question, but the certificate indicating I satisfy the role that the
relying party expects for a signatory to the given transaction.  (In pure
"Identity Cert" principle, any such cert should just identify "me" to a
given degree of assurance, and then the relying party should use that fact
to determine if, within their own domain, this "me" has the required role.)

Again, I am not really advocating such usage, but I wonder if the restriction
is simply one of cert retrieval complexity, or if such usage would really
"break X.509".  Has the structure so embedded these legal implications?

___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 3 Mar 1998 13:20: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other   extensions
Comments: To: [email-masked]
To: [email-masked]

Hoyt,

We agree exactly on the comment part of an RFC 822 name.  Now if nobody
disagrees, we can kill this part!

Sorry I can't make Snomass; our only skiing so far this year has been 3
days at Killington, but it was nice.  The CTO job is keeping me very busy,
and I get to keep my other jobs too ...

Steve

Approved-By:  Peter Sylvester <[email-masked]>
Date:         Tue, 3 Mar 1998 18:56:09 +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: Peter Sylvester <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]

I am not whether the following has been discussed or not for OCSP:

Question: Is the protocol just intended to specify the communication between
a client and the well-known validation point, or is there something
to about how to find that point.

I image a possible response from the server saying, no, don't do this
here, go elsewhere, here's the 'connection info' (URL or whatever).

Peter Sylvester
EdelWeb

Approved-By:  Peter Lipp <[email-masked]>
Date:         Tue, 3 Mar 1998 17:44:53 +0100
Reply-To: Peter Lipp <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Lipp <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00D0_01BD46CC.139B75F0
Content-Type: multipart/mixed;
        boundary="----=_NextPart_000_00CE_01BD46CC.13709560"

------=_NextPart_000_00CE_01BD46CC.13709560
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>What do others think?

I agree. One exception might be argueable: if the string in CN is =
<exactly> the same as the one between the <> or () pairs, then I =
wouldn't see any problem.

Peter

Dr. Peter Lipp
Institute for Applied Information Processing and Communications
Graz, University of Technology

------=_NextPart_000_00CE_01BD46CC.13709560
Content-Type: text/x-vcard;
        name="Peter Lipp.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
        filename="Peter Lipp.vcf"

BEGIN:VCARD
VERSION:2.1
N:Lipp;Peter;;
FN:Peter Lipp
ORG:Styria;
TITLE:
TEL;WORK;VOICE:+43 316 873 5513
TEL;HOME;VOICE:
TEL;VOICE:Graz
TEL;WORK;FAX:A-8042
ADR;WORK:;;;;;;
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:=0D=0A,  =0D=0A
EMAIL;PREF;INTERNET:[email-masked]
REV:19980303T164452Z
END:VCARD

------=_NextPart_000_00CE_01BD46CC.13709560--

------=_NextPart_000_00D0_01BD46CC.139B75F0
Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="smime.p7s"

------=_NextPart_000_00D0_01BD46CC.139B75F0--

Approved-By:  Stephen Kent <[email-masked]>
Date:         Tue, 3 Mar 1998 10:59:03 -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] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

Paul,

I'd like to suggest that we not allow all of these representations of RFC
822 names, despite your obeservation that they are all syntactically
allowed under RFC 822.  My reasoning is that we ought to not confuse the
bounds of what is being certified.  As a CA, I can readily validate a pure
user_name@FQDN syntax, but when someone includes a parenthetical comment,
it makes the verification harder and subject to errors.  A user seeing such
a name is likely to pay more attention to a more human-readable part of the
name, which may not be verified, while software is almost certain to pay
attention to the more tightly constrained synatx that actually supports
addressing of the message.  Thus a mismatch may occur if a secure e-mail
package or IPsec implementation validates based on the more restricted
syntax, but the user thinks in terms of the comment part of the name.  I'd
like to urge more of a WISWYG approach here, even though it means
restricting the syntax to a subset of what can be expressed in 822.

What do others think?

Steve

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Tue, 3 Mar 1998 14: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: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] CMP question.
To: [email-masked]

'Certificate Management Protocols' feb. '98, says that

    'Certification may only be requested for one locally
    generated public key (for more, use separate PKIMessages)'

But the body structure

CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {
    certReq   CertRequest,
    ... }

CertRequest ::= SEQUENCE {
   ...
    certTemplate  CertTemplate,
   ... }

CertTemplate ::= SEQUENCE {
  ...
    publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
  ...}

seems to allow multiple requests for key certifications in the same
PKIMessage.

Could someone explain this to me?

- Jakob

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Tue, 3 Mar 1998 11:04:45 +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: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] caPubs-field in CertRepMessage
To: [email-masked]

to the list,

Can anyone tell me, what the intention of the field 'caPubs'
in CertRepMessage is?

  CertRepMessage ::= SEQUENCE {
      caPubs          [1] SEQUENCE SIZE (1..MAX) OF Certificate
OPTIONAL,
      response            SEQUENCE OF CertResponse
  }

- Jakob

Approved-By:  Peter Lipp <[email-masked]>
Date:         Tue, 3 Mar 1998 10:08:42 +0100
Reply-To: Peter Lipp <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Lipp <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0065_01BD468C.587C9F90
Content-Type: multipart/mixed;
        boundary="----=_NextPart_000_0063_01BD468C.586742D0"

------=_NextPart_000_0063_01BD468C.586742D0
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>Can I ask a CA to certify 10 keys, in 10 certificates, all of which =
attest=20
>to identical info? (modulo certificate id, or course.) =20

Any commercial CA would be more than happy to have you as a customer :-)

>Thoughts?

If no other privacy measures are available, this is a legitmate option.=20

Peter

------=_NextPart_000_0063_01BD468C.586742D0
Content-Type: text/x-vcard;
        name="Peter Lipp.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
        filename="Peter Lipp.vcf"

BEGIN:VCARD
VERSION:2.1
N:Lipp;Peter;;
FN:Peter Lipp
ORG:Styria;
TITLE:
TEL;WORK;VOICE:+43 316 873 5513
TEL;HOME;VOICE:
TEL;VOICE:Graz
TEL;WORK;FAX:A-8042
ADR;WORK:;;;;;;
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:=0D=0A,  =0D=0A
EMAIL;PREF;INTERNET:[email-masked]
REV:19980303T090841Z
END:VCARD

------=_NextPart_000_0063_01BD468C.586742D0--

------=_NextPart_000_0065_01BD468C.587C9F90
Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="smime.p7s"

------=_NextPart_000_0065_01BD468C.587C9F90--

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Tue, 3 Mar 1998 10:02:24 +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: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] CMP, feb, 1998
To: [email-masked]

To the list,

Having obtained 'Certificate Management Protocols' for february 1998
I find the following ASN.1 comment strange (a value of -1 to be ...):

CertResponse ::= SEQUENCE {
      certReqId           INTEGER,
      -- to match this response with corresponding request (a value
      -- of -1 is to be used if certReqId is not specified in the
      -- corresponding request)

well, the corresponding request has ASN.1 structure:

CertRequest ::= SEQUENCE {
    certReqId     INTEGER,
    certTemplate  CertTemplate,
    controls      Controls OPTIONAL }

where certReqId is NOT optional. Did I miss something?

- Jakob

Approved-By:  David Hemsath <[email-masked]>
Date:         Mon, 2 Mar 1998 18:19: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: David Hemsath <[email-masked]>
Subject:      [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki3cmp-07.txt
To: [email-masked]

                   Status Distribution March 02, 1998 14:46:48

The message regarding "[IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki3cmp-07.txt" sent on March 02, 1998 14:46:48 was sent by

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

Recipients

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

Status          769
Explanation     Invalid recipient

X.400 Status    769
Explanation     Error transferring to D01HUBM1/01/H/IBM mail.box; Server error: File does not exist

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Mon, 2 Mar 1998 14:35:50 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
Comments: To: Stefan Kelm <[email-masked]>
To: [email-masked]

Stefan,

At 06:34 PM 3/2/98 +0100, you wrote:
>Folks,
>
>I haven't had the time to browse through all the different latest drafts, I'm
>afraid. Having had some discussions concerning the German digital signature
>law, however, a question occured to me: Is a CA allowed to issue two (or
>more) certificates for a single end-entity's public key? If yes, this could
>lead to big problems, especially in terms of liability of the CA. If
>not, shouldn't this be specified somewhere?

Could you expand on the liability issues you mention regarding the issuance of
differing certificates for the same public key?  From a layman's point of
view,
of course a CA could get into trouble issuing arbitrary certificates on a
given
end-user's public key.  But, for the sake of argument, if I want the same key
to be certified by a CA in two distinct certificates, both of which contain
data that identifies me (in different ways, for different reasons,) then it
seems to be up to the relying party to check if there is a valid certificate
for that key, suitable for their purposes of identification.  (Apologies for
naive view and tortured sentence structure.)

Here is a related question (and perhaps more likely desired) : Can I ask a CA
to certify 10 keys, in 10 certificates, all of which attest to identical info?
(modulo certificate id, or course.)  My thought is, I want to use my keys very
sparingly, cycling through them so to thwart marketeers attempting to trace my
habits.  This presupposes that I, the cert-owner, control the cert that I
point
the relying party to use.

Thoughts?

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Stephen Kent <[email-masked]>
Date:         Mon, 2 Mar 1998 16:25: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Stefan,

I don't think we have any prohibitions against issuing multiple certs
against the same public key.  In fact, if the certs represent renewal
certs, I'm sure we would not preclude such actions.  Since two certs can
differ in terms of extensions, validity intervals, etc., not just in terms
of subject names, this would seem an unduly restrictive prohibition in the
general case.  Thus I suscept this is more of a policy matter for a given
CA context.

Steve

Approved-By:  Russ Housley <[email-masked]>
Date:         Sat, 28 Feb 1998 13:42:11 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

I also think OCSP should be defined in a transport independent fashion.  I
do not think it will be hard to remove the http dependencies.

Russ

At 11:50 AM 2/24/98 +0100, Peter Sylvester wrote:
>A little nit-picking:
>
>- There is a need for an 'pretty online' service to find out the
>  status of certificates. One might consider to define this service
>  without referencing to http, and then selecting http
>  as 'use of lower layers'.
>  In the actual text these things seems to be tied together.
>
>- The mentioned keyword/value pairs might be given as such
>  (using whatever textual means to describe it) but not in
>  the rather implicit way through its encoding in an http request.
>
>- The text should be written in ASCII or ISO-latin-1 (not with
>  quotes coming from some well known word-processing-$ware.)
>
>- In the description of a request, there is a definition of
>  'time' which is not used anywhere?
>
>Peter Sylvester -- EdelWeb France
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 2 Mar 1998 15:23:51 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] CMP Progression
To: [email-masked]

> From: Warwick Ford <[email-masked]>
>
> These documents will now be submitted back to the IESG with a
> recommendation for publication as RFCs specifying Proposed Standards.
>
> Congratulations to the editors for their relentless efforts to resolve the
> issues surrounding these documents!

As a member of the team that produced one of the documents, let me say
that no one is as pleased as we are to see them moving forward.

I am aware of only one remaining open issue with the CRMF document.
The registration info field defines two methods for carrying certificate
content between a Registration Agent and the CA; call them methods A and B.
CRMF currently contains no conformance requirements, thus support for
both A and B is optional.

The IESG may insist, as they have in other working groups, on minimum
conformance requirements which ensure interoperability between
PKIX-conformant clients and servers.  In the case of CRMF, such
requirements would designate either A or B (or both) as
mandatory-to-implement.

This Working Group may wish to consider whether conformance requirements
should be included in the CRMF specification, included in some other
IETF specification, or left up to community-specific profiles.  I expect
that the question will be raised by the IESG; if we wish to progress the
specification, we should have an answer ready.

Approved-By: [email-masked]
Date:         Mon, 2 Mar 1998 12:51:26 -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-07.txt
Comments: To: [email-masked]
To: [email-masked]

--NextPart

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 X.509 Public Key Infrastructure
                          Certificate Management Protocols
        Author(s)       : C. Adams, S. Farrell
        Filename        : draft-ietf-pkix-ipki3cmp-07.txt
        Pages           : 67
        Date            : 26-Feb-98

This document describes 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-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki3cmp-07.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-07.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID:     <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki3cmp-07.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ipki3cmp-07.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--OtherAccess--

--NextPart--

Approved-By: [email-masked]
Date:         Mon, 2 Mar 1998 18:34:22 +0100
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stefan Kelm <[email-masked]>
Subject:      [IETF-PKIX] Multiple certificates for same key?
To: [email-masked]

Folks,

I haven't had the time to browse through all the different latest drafts, I'm
afraid. Having had some discussions concerning the German digital signature
law, however, a question occured to me: Is a CA allowed to issue two (or
more) certificates for a single end-entity's public key? If yes, this could
lead to big problems, especially in terms of liability of the CA. If
not, shouldn't this be specified somewhere?

Sorry if this topic already has been discussed.

Cheers,

        Stefan.

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

Approved-By:  Russ Housley <[email-masked]>
Date:         Sat, 28 Feb 1998 13:42:11 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]

I also think OCSP should be defined in a transport independent fashion.  I
do not think it will be hard to remove the http dependencies.

Russ

At 11:50 AM 2/24/98 +0100, Peter Sylvester wrote:
>A little nit-picking:
>
>- There is a need for an 'pretty online' service to find out the
>  status of certificates. One might consider to define this service
>  without referencing to http, and then selecting http
>  as 'use of lower layers'.
>  In the actual text these things seems to be tied together.
>
>- The mentioned keyword/value pairs might be given as such
>  (using whatever textual means to describe it) but not in
>  the rather implicit way through its encoding in an http request.
>
>- The text should be written in ASCII or ISO-latin-1 (not with
>  quotes coming from some well known word-processing-$ware.)
>
>- In the description of a request, there is a definition of
>  'time' which is not used anywhere?
>
>Peter Sylvester -- EdelWeb France
>

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Sun, 1 Mar 1998 11:28:11 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

At 09:16 PM 2/28/98 -0800, you wrote:
>> When an RFC822 name is encoded in SubjectAltName (or one of its
>> equivalents), is a display name allowed as well as the base address?
>> So can I encode "Jim Schaad [[email-masked]]", or can I just
>> encode [email-masked]?

Note that your example should be:
     Jim Schaad <[email-masked]>
With <> instead of [].

Since the rfc822Namein SubjectAltName is expressed as an IA5String, I would
hope that any mailbox syntax that used only the IA5String character set
would be acceptable. And, since all valid 822 addresses must be in the
ASCII character set, this should include all three acceptable formats:
     [email-masked]
     Jim Schaad <[email-masked]>
     [email-masked] (Jim Schaad)

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By: [email-masked]
Date:         Sat, 28 Feb 1998 21:16:56 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] RFC 822 names in SubjectAltName and other extensions
To: [email-masked]

> A question was recently asked of me which I though I knew the answer
> for but cannot find any backup on this information.
>
> When an RFC822 name is encoded in SubjectAltName (or one of its
> equivalents), is a display name allowed as well as the base address?
> So can I encode "Jim Schaad [[email-masked]]", or can I just
> encode [email-masked]?   I have always assumed until I was asked
> that only the latter was permitted.
>
> jim schaad
>
>