Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
From: Paul Hoffman / IMC <[email-masked]>
To: Michael Myers <[email-masked]>, Marc Branchaud <[email-masked]>
Cc: [email-masked]
Date: Thu, 30 Apr 1998 16:10:38 -0700

At 03:34 PM 4/30/98 -0700, Michael Myers wrote:
>For these reasons, I would agree with the proposed text with the first
>three lines deleted.  There is no way for anyone to implement a client that
>would enforce them.

I agree with Mike. The source of the data is not important here, and trying
to force heuristics on it seems inappropriate.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 30 Apr 1998 15:34:54 -0700
To: Marc Branchaud <[email-masked]>, Paul Hoffman / IMC <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt 
Cc: [email-masked]
Sender: [email-masked]

Marc, 

How can it be shown whether or not the responder is working directly off a
certificate database or not?  Or off a digitially signed image of a
database for that matter?  Furthermore, the site or sites receiving a
request may front a database with a periodically produced CRL for a variety
of reasons.  Lastly, there may very well exist refresh latency at sites or
on servers that do have a certifiate database.  Consider the case of a cron
job on a cert server that periodically sweeps it certificate database,
produces pre-signed responses and includes in them the next time at which
this event is expected to occur.

For these reasons, I would agree with the proposed text with the first
three lines deleted.  There is no way for anyone to implement a client that
would enforce them.

Mike

At 01:09 PM 4/30/98 -0700, Marc Branchaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Content-Type: text/plain; charset=us-ascii
>
>
>Paul Hoffman / IMC <[email-masked]> scrawled:
>> 
>> At 02:24 PM 4/29/98 -0700, Ambarish Malpani wrote:
>> >I would like to have nextUpdate be allowed. For cases where the OCSP
>> >responder is working off a CRL, it should reflect the value of
>> >nextUpdate
>> >in the CRL. However, for cases where the responder is working off the
>> >CAs database (which could be updated at any instant), I would like to
>> >have nextUpdate be optional, which means that this response was valid
>> >only at the thisUpdate time and can change even in the next second.
>> 
>> This works for me as long as the semantics of nextUpdate are clear and
>> mandatory. "If the nextUpdate field is included, it MUST be [[[insert exact
>> words from PKIX part 1]]]. If it not included, the recipient cannot infer
>> any information about how long the OCSP response will be valid."
>> 
>
>I would like nextUpdate to be removed entirely, but I guess I can live with
>it being optional.  I would like Paul's suggested wording to go even further,
>though.  Although referencing part 1 looks like an easy way out, part 1's
>description of nextUpdate is really sparse.  Here's what I suggest:
>
>   The nextUpdate field MAY be included if the responder derives the response
>   from a CRL.  In that case, the value of nextUpdate in the response MUST
>   match the value of nextUpdate in the CRL.  The nextUpdate field SHOULD NOT
>   be included if the responder has direct access to the CA's revocation
>   database (i.e. it can obtain revocation information in real time).  When
>   it is included, the nextUpdate field SHOULD be interpreted to mean that
>   fresh revocation information should be available no later than
>   nextUpdate's time, and may be available sooner.  In general, nextUpdate is
>   not a guarantee of the lifetime of a response's validity.  Clients SHOULD
>   use their own local policies to determine how long they believe a response
>   to be valid, regardless of the presence of the nextUpdate field in the
>   response.
>
>		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
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNUjahFrdFXNdDxPlAQH8JgMAlcl12gaRmUpdYM8dPzAelLtAFkYRSjIA
>kN7WIe9F/V2Nv0GHw9+H+pD9AGY6ohEWnn7yoc76JbXh6XBMY/OziyjfELPpICBg
>A4MvDxlTRovSIRXsrGazlzgXIWsmrFY7
>=Vcae
>-----END PGP SIGNATURE-----
>
>

To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt 
Date: Thu, 30 Apr 1998 13:09:41 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

Paul Hoffman / IMC <[email-masked]> scrawled:
> 
> At 02:24 PM 4/29/98 -0700, Ambarish Malpani wrote:
> >I would like to have nextUpdate be allowed. For cases where the OCSP
> >responder is working off a CRL, it should reflect the value of
> >nextUpdate
> >in the CRL. However, for cases where the responder is working off the
> >CAs database (which could be updated at any instant), I would like to
> >have nextUpdate be optional, which means that this response was valid
> >only at the thisUpdate time and can change even in the next second.
> 
> This works for me as long as the semantics of nextUpdate are clear and
> mandatory. "If the nextUpdate field is included, it MUST be [[[insert exact
> words from PKIX part 1]]]. If it not included, the recipient cannot infer
> any information about how long the OCSP response will be valid."
> 

I would like nextUpdate to be removed entirely, but I guess I can live with
it being optional.  I would like Paul's suggested wording to go even further,
though.  Although referencing part 1 looks like an easy way out, part 1's
description of nextUpdate is really sparse.  Here's what I suggest:

   The nextUpdate field MAY be included if the responder derives the response
   from a CRL.  In that case, the value of nextUpdate in the response MUST
   match the value of nextUpdate in the CRL.  The nextUpdate field SHOULD NOT
   be included if the responder has direct access to the CA's revocation
   database (i.e. it can obtain revocation information in real time).  When
   it is included, the nextUpdate field SHOULD be interpreted to mean that
   fresh revocation information should be available no later than
   nextUpdate's time, and may be available sooner.  In general, nextUpdate is
   not a guarantee of the lifetime of a response's validity.  Clients SHOULD
   use their own local policies to determine how long they believe a response
   to be valid, regardless of the presence of the nextUpdate field in the
   response.

		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

Date: Thu, 30 Apr 1998 11:14:03 -0700
To: Stephen Samson <[email-masked]>, [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: Entrust Technologies Announces License Terms for CRL Distribution Points Patent
Cc: Jeff Schiller <[email-masked]>, Steve Kent <[email-masked]>, Tim Polk <[email-masked]>, Warwick Ford <[email-masked]>
Sender: [email-masked]

Stephen,

It appears the text is not yet posted at this URL.  On reference, I receive
a page that states:

"Our Apologies

This link is either outdated or missing at this time. Please refer yourself
to our homepage or feel free to use the sitemap."

Mike

At 01:26 PM 4/30/98 -0400, Stephen Samson wrote:
>Members of the IETF Community;
>
>Entrust Technologies is very pleased to provide details of its previously
>announced royalty-free license for the CRL Distribution Points Patent.
>
>By following the link:  http://www.entrust.com/products/patent.htm to our
>website, you will be able to read a summary of the license terms. In the
>spirit of open Standards, Entrust has fashioned the license in fair,
>reasonable and equitable terms that should appeal to all interested parties.
>
>A party interested in taking a license should contact the author directly,
>so that appropriate license documentation can be drafted. Please direct any
>questions to:
>
>Steve Samson
>
>Entrust Technologies Inc.
>750 Heron Rd.,  8th Floor
>Ottawa, Ontario, Canada, K1V 1A7
>
>voice:			613-247-3725
>fax:			613-247-3412
>email:			[email-masked]
>Entrust Validation String:	SCKM-HQDL-X75G
>
>

From: Stephen Samson <[email-masked]>
To: [email-masked]
Cc: Jeff Schiller <[email-masked]>, Steve Kent <[email-masked]>, Tim Polk <[email-masked]>, Warwick Ford <[email-masked]>
Subject: Entrust Technologies Announces License Terms for CRL Distribution Points Patent
Date: Thu, 30 Apr 1998 13:26:06 -0400
Sender: [email-masked]

Members of the IETF Community;

Entrust Technologies is very pleased to provide details of its previously
announced royalty-free license for the CRL Distribution Points Patent.

By following the link:  http://www.entrust.com/products/patent.htm to our
website, you will be able to read a summary of the license terms. In the
spirit of open Standards, Entrust has fashioned the license in fair,
reasonable and equitable terms that should appeal to all interested parties.

A party interested in taking a license should contact the author directly,
so that appropriate license documentation can be drafted. Please direct any
questions to:

Steve Samson

Entrust Technologies Inc.
750 Heron Rd.,  8th Floor
Ottawa, Ontario, Canada, K1V 1A7

voice:			613-247-3725
fax:			613-247-3412
email:			[email-masked]
Entrust Validation String:	SCKM-HQDL-X75G

To: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates 
Date: Thu, 30 Apr 1998 10:18:44 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

Ambarish Malpani <[email-masked]> scrawled:
> 
> So, here are the options:
> 
> 1. Hash(IssuerDN and IssuerPublicKey) and CertSerialNumber
> 2. Hash(IssuerDN), Hash(IssuerPublicKey) and CertSerialNumber
> 3. IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber
> 

I prefer option 3.  The OCSP server needs to know which CA issued the cert, 
but using a hash of the IssuerDN just adds an unneeded layer of indirection.

		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

Date: Thu, 30 Apr 1998 10:14:50 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

> From: Ambarish Malpani <[email-masked]>
> 
> So, here are the options:
> 
> 1. Hash(IssuerDN and IssuerPublicKey) and CertSerialNumber
> 2. Hash(IssuerDN), Hash(IssuerPublicKey) and CertSerialNumber
> 3. IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber
> 
> What are the opinions of the group? I would like to have a quick
> flurry of opinions before we decide to go one way or the other.
      ...

> > The second issue is a relatively simple one - how important is it to
> > save bytes in the query - sending the hash of the issuer's DN is much
> > smaller than sending the full DN. However, if we just send the hash of
> > the DN, the responder may not be able to reconstruct the full DN, so
> > querying a database that is indexed by anything other than the hash
> > of the DN might be impossible.

I am worried about hashing the DN for the sole purpose of saving
bytes in the query.  Even if the canonicalization issue is solved, there
remains the problem stated here: given the hash, the responder cannot
(not "may not be able to"!) reconstruct the DN, so that forces
all implementations to index by hash of the canonicalized DN.  That
is an unnecessary constraint on implementors.

It precludes meaningful error messages "can't find cert for issuer=xyz
serial=123" which may be helpful when customers ask why their queries
aren't working.

And it adds a translation step, which I tend to resist on philosophical
grounds: if you have "x", then you shouldn't used a transformed
version "f(x)" in protocols unless there are compelling reasons to do
so.  I don't regard the potential byte savings as compelling.
The example in PKIX part 1 "C=US, O=gov, OU=nist" encodes to 42
octets, vs. 22 octets for SHA(DN).  Longer DNs would offer somewhat
greater savings.

OTOH, hashing SubjectPublicKeyInfo saves enough space to be worthwhile
- with parameters (which should always be included with the public key
even if they are not present in the Issuer's certificate) the example
public key encodes to 436 octets.  22 is more than an order of
magnitude smaller.  And the public key doesn't have as much "meaning"
to be obliterated by hashing as the DN has.

So I vote for option 3: IssuerDN, SerialNumber, Hash(IssuerPublicKey)

Dave Kemp

Date: Thu, 30 Apr 1998 11:12:25 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Ambarish Malpani <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Ambarish Malpani wrote:
 
> Hi All,
>     Would like to get closure on the method of identifying
> certificates. I think nobody has any objections to including the
> issuer's public key in the information that is used to identify the
> issuer. The main point of contention is whether to send the whole
> DN or the hash of the DN.
> 
> Tim, hopefully your issue with sending over the hash of the DN can
> be addressed by canonicalizing the issuer's DN before hashing it
> (are there any such canonicalization rules)?
> 
> So, here are the options:
> 
> 1. Hash(IssuerDN and IssuerPublicKey) and CertSerialNumber
> 2. Hash(IssuerDN), Hash(IssuerPublicKey) and CertSerialNumber
> 3. IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber

>From the option that are proposed, option 3 is the only one that is
working for all environments. 

The argument is that neither Hash(IssuerDN) nor Hash(IssuerDN and
IssuerPublicKey) can be used to find which CA has issued a certificate
unless you get an hint by some other means.

In the option 3, we should allow either IssuerDN or alternate name to be
used, since I do not think it is appropriate to mandate DNs for CAs (no
argument has been given on the list up to now to explain why DNs would
work better that alternate names as long as the latter are unique).

Regards,

Denis

> What are the opinions of the group? I would like to have a quick
> flurry of opinions before we decide to go one way or the other.
> 
> Regards,
> Ambarish

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

Date: Wed, 29 Apr 1998 17:05:43 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
Sender: [email-masked]

At 02:24 PM 4/29/98 -0700, Ambarish Malpani wrote:
>I would like to have nextUpdate be allowed. For cases where the OCSP
>responder is working off a CRL, it should reflect the value of
>nextUpdate
>in the CRL. However, for cases where the responder is working off the
>CAs database (which could be updated at any instant), I would like to
>have nextUpdate be optional, which means that this response was valid
>only at the thisUpdate time and can change even in the next second.

This works for me as long as the semantics of nextUpdate are clear and
mandatory. "If the nextUpdate field is included, it MUST be [[[insert exact
words from PKIX part 1]]]. If it not included, the recipient cannot infer
any information about how long the OCSP response will be valid."

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 29 Apr 1998 14:24:59 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
Sender: [email-masked]

Hi All,
    Again, would like to close on this issue: I think thisUpdate and
producedAt are non-controversial. The main issue is should nextUpdate
be allowed and if it is allowed, should it be optional or not.

I would like to have nextUpdate be allowed. For cases where the OCSP
responder is working off a CRL, it should reflect the value of
nextUpdate
in the CRL. However, for cases where the responder is working off the
CAs database (which could be updated at any instant), I would like to
have nextUpdate be optional, which means that this response was valid
only at the thisUpdate time and can change even in the next second.

Marc, can you live with this specification or do you violently disagree?

Again, would like a quick flurry of activity on this topic so that we
can close it ASAP.

Regards,
Ambarish

Ambarish Malpani wrote:
> 
> We are proposing that OCSP responses have the following fields:
> 
>     producedAt - a GeneralizedTime that indicates the time at which this
>         response was produced/signed. There is only one producedAt time
>         in the response (irrespective of how many certs are included in
>         the response)
>     thisUpdate - a GeneralizedTime, which specifies the time at which the
>         response was known to be current - basically the time at which
>         the CA's database was looked up. It may or may not have the same
>         value as producedAt. There is a thisUpdate field with every cert
>         whose status is known. Corresponds to the thisUpdate in a CRL.
>     nextUpdate - a GeneralizedTime, which specifies when newer information
>         will be available from this CA. Has the same semantics as the
>         nextUpdate time in CRLs. There is a nextUpdate field with every
>         cert whose status is known. There is no guarantee that revocation
>         information will not be updated before nextUpdate (just as there is
>         no guarantee that a CRL will not be issued before nextUpdate).
> 
...Deleted...
> 
> Comments?
> 
> Ambarish
> 

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Wed, 29 Apr 1998 14:11:09 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Hi All,
    Would like to get closure on the method of identifying
certificates. I think nobody has any objections to including the
issuer's public key in the information that is used to identify the
issuer. The main point of contention is whether to send the whole
DN or the hash of the DN.

Tim, hopefully your issue with sending over the hash of the DN can
be addressed by canonicalizing the issuer's DN before hashing it
(are there any such canonicalization rules)?

So, here are the options:

1. Hash(IssuerDN and IssuerPublicKey) and CertSerialNumber
2. Hash(IssuerDN), Hash(IssuerPublicKey) and CertSerialNumber
3. IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber

What are the opinions of the group? I would like to have a quick
flurry of opinions before we decide to go one way or the other.

Regards,
Ambarish

Ambarish Malpani wrote:
> 
> There have been three proposals for identifying certificates:
> 
>     1. Hash(Issuer's DN) and the certificate's serial number
>     2. Hash(Issuer's DN and Issuer's Public Key) and the certificate's
>         serial number
>     3. Issuer's DN, Hash(Issuer's Public Key) and the certificate's
> serial
>         number
> 
>     There are two main issues here:
>     a. Does the query need to include information about the issuer's
> public
>         key?
>     b. Should we send the whole Issuer DN, or just it's hash?
> 
>     The second issue is a relatively simple one - how important is it to
> save bytes in the query - sending the hash of the issuer's DN is much
> smaller than sending the full DN. However, if we just send the hash of
> the
> DN, the responder may not be able to reconstruct the full DN, so
> querying
> a database that is indexed by anything other than the hash of the DN
> might
> be impossible.
> 
>     The first issue is more interesting: I contend that there is not way
> to enforce uniqueness of DN's across the whole world. However, public
> keys
> better be unique (otherwise you have broken the basic premise of public
> key cryptography).
>     Consider the following (slightly long winded) story:
> 
>     Once upon a time, there was a country X, which has a famous CA,
> CA of X. One year, it had a revolution, which resulted in the country
> being divided into East X and West X. The U.S. supported West X, while
> China supported East X. Ofcourse, both nations wanted to retain the name
> CA of X, since it was well known across the world. Neither of them
> continued to use the same public key (since both sides knew the
> corresponding
> private key), but both wanted to use the original DN.
>     The issue of who would be allowed to retain the original DN was
> taken
> to the International Court in the Hague, but in the meantime,
> Switzerland,
> which was running a global OCSP responder, needed to figure out which
> country's CA of X it would support.
> 
>     Fortunately, there is an easy way out of this problem - if we
> include
> the hash of the issuer's public key as a means of identifying the CA,
> clashes of DNs don't affect OCSP. Also, given that the
> AuthorityKeyIdentifier
> is going to be mandatory in PKIX, client's don't even need to do an
> additional hashing operation to provide this information.
> 
>     Some people have argued that if DNs clash, everything in PKIX
> breaks. I
> would like to make the following points:
>     - Just because something else breaks, you shouldn't design your
>         protocols with the same weaknesses.
>     - In most of PKIX, along with a name, you also have a signature.
> This
>         signature implicitly identifies the public key associated with that
>         name.
>     - It is quite possible that even if issuer DNs clash, most domains
>         will never see that clash, because they only trust one of the issuers
>         with that DN. The only person who sees that clash might be an OCSP
>         responder that tries to collect revocation data from all issuers.
> 
>     Enough from me. What is the feeling on this issue in this group?
> Should
> we include the hash of the issuer's public key to uniquely identify the
> issuer?
> 
> Ambarish
> 

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

From: John Everson <[email-masked]>
Date: Wed, 29 Apr 1998 15:03:11 -0500
Subject: RE: OCSP status tally
TO: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

--openmail-part-098dd9db-00000001
Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.RTF"

I think the key is to allow for maximum flexibility without excess.
Either method provides the basic functionality, however Slava's optional
components provide flexibility. I'm afraid the flexibility will produce
too many variations if they are implemented at all. I still prefer:

CertStatusType ::= ENUMERATED {
    unknown              (-2),
    notRevoked           (-1),
    revoked (unspecified) (0),
    keyCompromise         (1),
    cACompromise          (2),
    affiliationChanged    (3),
    superseded            (4),
    cessationOfOperation  (5),
    certificateHold       (6) }

but would be happy with either one considering the alternative:

CertStatusType ::= ENUMERATED {
    notRevoked     (0),
    revoked        (1),
    unknown        (2) }

Which provides too little flexibility.

John Everson
Sprint

-----Original Message-----
From: mmyers [mailto:[email-masked]]
Sent: Wednesday, April 29, 1998 12:13 PM
To: John.Everson; dpkemp; ietf-pkix
Cc: mmyers
Subject: RE: OCSP status tally

John,

Would the revocationReason construct in Slava's recent proposal meet
your
needs?  Recall that he had proposed:

RevocationStatus ::= CHOICE {         
      unknown      [0] IMPLICIT UnknownInfo,
       notRevoked   [1] IMPLICIT NULL,
       revoked      [2] IMPLICIT RevokedInfo }

UnknownInfo ::= NULL -- this can be replaced with an enumeration
                     -- for various specific reasons such as
                     -- doNotKnowAboutCA etc.

RevokedInfo ::= SEQUENCE {
      revocationTime GeneralizedTime,
      revocationReason RevocationReason OPTIONAL -- this could include
                                                  -- "onHold" }

Mike

At 09:00 AM 4/29/98 -0500, John Everson wrote:
>
>It seems a shame to provide less functionality. I prefer going with all
>the defined codes from CRLReason:
>
>CertStatusType ::= ENUMERATED {
>    unknown              (-2),
>    notRevoked           (-1),
>    revoked (unspecified) (0),
>    keyCompromise         (1),
>    cACompromise          (2),
>    affiliationChanged    (3),
>    superseded            (4),
>    cessationOfOperation  (5),
>    certificateHold       (6) }
>
>John Everson
>Sprint
>
>-----Original Message-----
>From: dpkemp [mailto:[email-masked]]
>Sent: Tuesday, April 28, 1998 4:13 PM
>To: ietf-pkix
>Cc: dpkemp
>Subject: Re: OCSP status tally
>
>
>> From: Michael Myers <[email-masked]>
>>   
>> I would like to propose we move forward with the following simplified
>> construction:
>>   
>> CertStatusType ::= ENUMERATED {
>>     notRevoked     (0),
>>     revoked        (1),
>>     onHold         (2),
>>     unknownCA      (3),
>>     unknownCert    (4) }
>
>
>It seems unusual to include a specific status code for "onHold", but
>not for any of the other X.509-defined reason codes.  And it seems
>unusual to have two codes which mean "unknown" but for different
>reasons; is there any business requirement for RPs to make a
>distinction between unknownCA and unknownCert?
>
>Might I suggest:
>
>CertStatusType ::= ENUMERATED {
>    notRevoked     (0),
>    revoked        (1),
>    unknown        (2) }
>
>
>or less enthusiastically, include all the defined codes from CRLReason:
>
>CertStatusType ::= ENUMERATED {
>    unknown              (-2),
>    notRevoked           (-1),
>    revoked (unspecified) (0),
>    keyCompromise         (1),
>    cACompromise          (2),
>    affiliationChanged    (3),
>    superseded            (4),
>    cessationOfOperation  (5),
>    certificateHold       (6) }
>
>
>
>
>> From: Andreas Berger <[email-masked]>
>>
>> Sorry that I bring that up again: the answer about knowing about a CA
>> but not about the referenced certificate would be a good one for use
>of
>> OCSP in the German Signature Law, where such a service is required.
>
>Without knowing both "the law" and the text of this specific law, it's
>impossible to be 100% sure of it's intent.  However, I'm 99.98% sure
:-)
>that "knowing about a CA" means that the RP possesses the certificate
>of the CA as part of the cert path being validated, or that the CA's
>cert can be validated or is a trust point, or that the RP has some
>out-of-band reason to believe that the CA exists.
>
>I have a hard time believing that the law's intent is to require the
>use of OCSP-like technology with status codes enabling the OCSP
>responder to claim "I know / don't-know about this CA".  The RP's
>knowledge is what's important, not a repository/responder's knowledge.
>
>
>Dave Kemp
>
>
>

--openmail-part-098dd9db-00000001--

Date: Wed, 29 Apr 1998 10:12:48 -0700
To: John Everson <[email-masked]>, [email-masked], [email-masked]
From: Michael Myers <[email-masked]>
Subject: RE: OCSP status tally
Sender: [email-masked]

John,

Would the revocationReason construct in Slava's recent proposal meet your
needs?  Recall that he had proposed:

RevocationStatus ::= CHOICE {        
	unknown      [0] IMPLICIT UnknownInfo,
       notRevoked   [1] IMPLICIT NULL,
       revoked      [2] IMPLICIT RevokedInfo }

UnknownInfo ::= NULL -- this can be replaced with an enumeration
                     -- for various specific reasons such as
                     -- doNotKnowAboutCA etc.

RevokedInfo ::= SEQUENCE {
	revocationTime GeneralizedTime,
	revocationReason RevocationReason OPTIONAL -- this could include
                                                  -- "onHold" }

Mike

At 09:00 AM 4/29/98 -0500, John Everson wrote:
>
>It seems a shame to provide less functionality. I prefer going with all
>the defined codes from CRLReason:
>
>CertStatusType ::= ENUMERATED {
>    unknown              (-2),
>    notRevoked           (-1),
>    revoked (unspecified) (0),
>    keyCompromise         (1),
>    cACompromise          (2),
>    affiliationChanged    (3),
>    superseded            (4),
>    cessationOfOperation  (5),
>    certificateHold       (6) }
>
>John Everson
>Sprint
>
>-----Original Message-----
>From: dpkemp [mailto:[email-masked]]
>Sent: Tuesday, April 28, 1998 4:13 PM
>To: ietf-pkix
>Cc: dpkemp
>Subject: Re: OCSP status tally
>
>
>> From: Michael Myers <[email-masked]>
>>  
>> I would like to propose we move forward with the following simplified
>> construction:
>>  
>> CertStatusType ::= ENUMERATED {
>>     notRevoked     (0),
>>     revoked        (1),
>>     onHold         (2),
>>     unknownCA      (3),
>>     unknownCert    (4) }
>
>
>It seems unusual to include a specific status code for "onHold", but
>not for any of the other X.509-defined reason codes.  And it seems
>unusual to have two codes which mean "unknown" but for different
>reasons; is there any business requirement for RPs to make a
>distinction between unknownCA and unknownCert?
>
>Might I suggest:
>
>CertStatusType ::= ENUMERATED {
>    notRevoked     (0),
>    revoked        (1),
>    unknown        (2) }
>
>
>or less enthusiastically, include all the defined codes from CRLReason:
>
>CertStatusType ::= ENUMERATED {
>    unknown              (-2),
>    notRevoked           (-1),
>    revoked (unspecified) (0),
>    keyCompromise         (1),
>    cACompromise          (2),
>    affiliationChanged    (3),
>    superseded            (4),
>    cessationOfOperation  (5),
>    certificateHold       (6) }
>
>
>
>
>> From: Andreas Berger <[email-masked]>
>>
>> Sorry that I bring that up again: the answer about knowing about a CA
>> but not about the referenced certificate would be a good one for use
>of
>> OCSP in the German Signature Law, where such a service is required.
>
>Without knowing both "the law" and the text of this specific law, it's
>impossible to be 100% sure of it's intent.  However, I'm 99.98% sure :-)
>that "knowing about a CA" means that the RP possesses the certificate
>of the CA as part of the cert path being validated, or that the CA's
>cert can be validated or is a trust point, or that the RP has some
>out-of-band reason to believe that the CA exists.
>
>I have a hard time believing that the law's intent is to require the
>use of OCSP-like technology with status codes enabling the OCSP
>responder to claim "I know / don't-know about this CA".  The RP's
>knowledge is what's important, not a repository/responder's knowledge.
>
>
>Dave Kemp
>
>
>

Date: Wed, 29 Apr 1998 08:10:33 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: OCSP status tally
Sender: [email-masked]

Denis,

I'm looking for a label on the value that addresses the case when the OCSP
server specifically does not have or have access to information on a given
certificate, even though the OCSP server may otherwise recognize the
certificate's issuer (and hence unknownCA is inappropriate). As I had noted
previously, this situation could easily occur for some uses of CRL
Distribution Points, CRLLists or other delegation mechanism.  If you feel
that unknownCert is an inappropriate label, what would you propose we
otherwise use to label this value?

Mike

At 10:35 AM 4/29/98 -0700, Denis Pinkas wrote:
>
>However " unknownCert    (4)" implies that the cert is accessible by the
>OCSP server and would conflict with "notRevoked" when the cert is *not*
>accessible by the OCSP server.
>
>Unless there is a further indication that states whether the cert is or
>is not accessible, the proposal does not work.
>
>Denis

Date: Wed, 29 Apr 1998 08:08:44 -0700
To: [email-masked], Michael Myers <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: OCSP status tally
Cc: [email-masked]
Sender: [email-masked]

Denis,

I'm looking for a label on the value that addresses the case when the OCSP
server specifically does not have or have access to information on a given
certificate, even though the OCSP server may otherwise recognize the
certificate's issuer (and hence unknownCA is inappropriate). As I had noted
previously, this situation could easily occur for some uses of CRL
Distribution Points, CRLLists or other delegation mechanism.  If you feel
that unknownCert is an inappropriate label, what would you propose we
otherwise use to label this value?

Mike

At 10:35 AM 4/29/98 -0700, Denis Pinkas wrote:
>
>However " unknownCert    (4)" implies that the cert is accessible by the
>OCSP server and would conflict with "notRevoked" when the cert is *not*
>accessible by the OCSP server.
>
>Unless there is a further indication that states whether the cert is or
>is not accessible, the proposal does not work.
>
>Denis

From: John Everson <[email-masked]>
Date: Wed, 29 Apr 1998 09:00:30 -0500
Subject: RE: OCSP status tally
TO: [email-masked], [email-masked]
Sender: [email-masked]

--openmail-part-0987991b-00000001
Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.RTF"

It seems a shame to provide less functionality. I prefer going with all
the defined codes from CRLReason:

CertStatusType ::= ENUMERATED {
    unknown              (-2),
    notRevoked           (-1),
    revoked (unspecified) (0),
    keyCompromise         (1),
    cACompromise          (2),
    affiliationChanged    (3),
    superseded            (4),
    cessationOfOperation  (5),
    certificateHold       (6) }

John Everson
Sprint

-----Original Message-----
From: dpkemp [mailto:[email-masked]]
Sent: Tuesday, April 28, 1998 4:13 PM
To: ietf-pkix
Cc: dpkemp
Subject: Re: OCSP status tally

> From: Michael Myers <[email-masked]>
>  
> I would like to propose we move forward with the following simplified
> construction:
>  
> CertStatusType ::= ENUMERATED {
>     notRevoked     (0),
>     revoked        (1),
>     onHold         (2),
>     unknownCA      (3),
>     unknownCert    (4) }

It seems unusual to include a specific status code for "onHold", but
not for any of the other X.509-defined reason codes.  And it seems
unusual to have two codes which mean "unknown" but for different
reasons; is there any business requirement for RPs to make a
distinction between unknownCA and unknownCert?

Might I suggest:

CertStatusType ::= ENUMERATED {
    notRevoked     (0),
    revoked        (1),
    unknown        (2) }

or less enthusiastically, include all the defined codes from CRLReason:

CertStatusType ::= ENUMERATED {
    unknown              (-2),
    notRevoked           (-1),
    revoked (unspecified) (0),
    keyCompromise         (1),
    cACompromise          (2),
    affiliationChanged    (3),
    superseded            (4),
    cessationOfOperation  (5),
    certificateHold       (6) }

> From: Andreas Berger <[email-masked]>
>
> Sorry that I bring that up again: the answer about knowing about a CA
> but not about the referenced certificate would be a good one for use
of
> OCSP in the German Signature Law, where such a service is required.

Without knowing both "the law" and the text of this specific law, it's
impossible to be 100% sure of it's intent.  However, I'm 99.98% sure :-)
that "knowing about a CA" means that the RP possesses the certificate
of the CA as part of the cert path being validated, or that the CA's
cert can be validated or is a trust point, or that the RP has some
out-of-band reason to believe that the CA exists.

I have a hard time believing that the law's intent is to require the
use of OCSP-like technology with status codes enabling the OCSP
responder to claim "I know / don't-know about this CA".  The RP's
knowledge is what's important, not a repository/responder's knowledge.

Dave Kemp

--openmail-part-0987991b-00000001--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part4-03.txt
Date: Wed, 29 Apr 1998 10:01:33 -0400
Sender: [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 
                          Certificate Policy and Certification Practices Framework
	Author(s)	: W. Ford, S. Chokhani
	Filename	: draft-ietf-pkix-ipki-part4-03.txt
	Pages		: 45
	Date		: 28-Apr-98
	
   This  document  presents  a  framework  to  assist  the  writers   of
   certificate   policies   or  certification  practice  statements  for
   certification  authorities  and  public  key   infrastructures.    In
   particular,  the  framework  provides  a comprehensive list of topics
   that potentially (at the writer's discretion) need to be covered in a
   certificate  policy definition or a certification practice statement.
   This document is being submitted to the RFC Editor with a request for
   publication as an Informational RFC.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-part4-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part4-03.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: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-part4-03.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-ipki-part4-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-part4-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 29 Apr 1998 10:35:00 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

> Marc, All:
> 
> I would like to propose we move forward with the following simplified
> construction:
> 
> CertStatusType ::= ENUMERATED {
>     notRevoked     (0),
>     revoked        (1),
>     onHold         (2),
>     unknownCA      (3),
>     unknownCert    (4) }

Mike,

It seems that you are continuing your own track without looking to the
other E-mails.
I have advocated mandatory and optional status and you have not
commented on it.

The following structure would be fine:

CertStatusType ::= ENUMERATED {
   notRevoked     (0),
   revoked        (1),
   onHold         (2),
   unknownCA      (3) }

However " unknownCert    (4)" implies that the cert is accessible by the
OCSP server and would conflict with "notRevoked" when the cert is *not*
accessible by the OCSP server.

Unless there is a further indication that states whether the cert is or
is not accessible, the proposal does not work.

Denis

> In the unknownCA case, a repository may not have acquired information
> necessary to produce any other assertion.  The unknownCert value addresses
> all other states not explicitly address by notRevoked or revoked.  In
> particular, it may be the case that a certain repositories can be proven to
> have only received a subset of a CA's information via mechanisms such as
> CRL Distribution Points, CRLList or other means of delegating authority.
> 
> Mike

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

Date: Tue, 28 Apr 1998 23:53:51 -0400 (EDT)
From: Rich Salz <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

Perhaps "indeterminant" instead of "unknowncert", if it really is intended
to be the catch-all choice.

Date: Tue, 28 Apr 1998 18:26:23 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: OCSP status tally
Sender: [email-masked]

Slava,

Looks like our messages crossed each other on the way to the list where I
had asked for opinions on {revoked, notRevoked, unknown}.  Your proposal
certainly has merit.  It better addresses inclusion of a time value than
the current ASN.1 does and links a generic "revoked" statment more closely
to reasons for the revocation state.  At this point I'd be interested in
hearing what others may think.

Mike

At 05:17 PM 4/28/98 -0700, you wrote:
>
>May I reintroduce my original suggestion to have the following
>RevocationStauts definition with small variations (hoping that after
>numerous discussions we had the intent here will be a little clearer
>this time):
>
>RevocationStatus ::= CHOICE {        
>	unknown      [0] IMPLICIT UnknownInfo,
>        notRevoked   [1] IMPLICIT NULL,
>        revoked      [2] IMPLICIT RevokedInfo,
>
>}
>
>UnknownInfo ::= NULL -- this can be replaced with an enumeration
>                     -- for various specific reasons such as
>doNotKnowAboutCA etc.
>
>RevokedInfo ::= SEQUENCE {
>	revocationTime GeneralizedTime,
>	revocationReason RevocationReason OPTIONAL -- this could include
>"onHold"
>}

Date: Tue, 28 Apr 1998 17:17:17 -0700
From: Slava Galperin <[email-masked]>
Organization: Teknowledge Corporation
To: Michael Myers <[email-masked]>
CC: Marc Branchaud <[email-masked]>, [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

Michael Myers wrote:
> 
> Marc, All:
> 
> I would like to propose we move forward with the following simplified
> construction:
> 
> CertStatusType ::= ENUMERATED {
>     notRevoked     (0),
>     revoked        (1),
>     onHold         (2),
>     unknownCA      (3),
>     unknownCert    (4) }
> 
> In the unknownCA case, a repository may not have acquired information
> necessary to produce any other assertion.  The unknownCert value addresses
> all other states not explicitly address by notRevoked or revoked.  In
> particular, it may be the case that a certain repositories can be proven to
> have only received a subset of a CA's information via mechanisms such as
> CRL Distribution Points, CRLList or other means of delegating authority.
> 

I think it might be reasonable to include revocation reason or
revocation date when sending "revoked" status (and in this case it may
be combined with "onHold" case).
Also various "do not know"s can be folded into single "unknown" response
since it seems unlikely that OCSP requester cares about the difference.

May I reintroduce my original suggestion to have the following
RevocationStauts definition with small variations (hoping that after
numerous discussions we had the intent here will be a little clearer
this time):

RevocationStatus ::= CHOICE {        
	unknown      [0] IMPLICIT UnknownInfo,
        notRevoked   [1] IMPLICIT NULL,
        revoked      [2] IMPLICIT RevokedInfo,

}

UnknownInfo ::= NULL -- this can be replaced with an enumeration
                     -- for various specific reasons such as
doNotKnowAboutCA etc.

RevokedInfo ::= SEQUENCE {
	revocationTime GeneralizedTime,
	revocationReason RevocationReason OPTIONAL -- this could include
"onHold"
}

I would like to stress that if OCSP requester does not care about the
details attached to specific status it can stop after parsing the CHOICE
tag and is not required to parse CHOICE inner content. Therefore for
less sophisticated OCSP requresters this definitions is just as simple
as ENUMERATED whereas more sophisticated ones can take advantage of the
information associated with a particular status code.

--

Slava

Date: Tue, 28 Apr 1998 16:09:57 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: OCSP status tally
Sender: [email-masked]

Dave,

Someone else may wish to argue for onHold independant of other revocation
reasons, but I'm all for simplicity.  In addition, I wholeheartedly support
your proposed consolidation of unknownCA and unknownCert.  My prior
proposal reflected what I had heard from others on their needs.

So, all:  pending any further debate on the matter, the next rev of OCSP
will specify the following response value structure and content:

At 05:12 PM 4/28/98 -0400, you wrote:
>Might I suggest:
>
>CertStatusType ::= ENUMERATED {
>    notRevoked     (0),
>    revoked        (1),
>    unknown        (2) }
>

Mike

Date: Tue, 28 Apr 1998 16:09:35 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP at IETF
Sender: [email-masked]

Hi All,
    I would like to get closure on all the open issues about OCSP. I
would like to summarize what I felt the group/people were saying about
each of these topics. If you disagree or feel strongly about the
proposed solution, please let me know.

Results under each topic below:

Ambarish Malpani wrote:
> 
> Hi All,
>      Great meeting a whole bunch of you at IETF.
> 
>      I am going to post a set of emails about the issues raised about
> OCSP, to start a set of threads on topics in OCSP.
> 
> Here is a summary of the topics that will be covered in the mails to
> follow:
>
 
>     - OCSP Usage Scenarios (as requested by Steve Kent)
Nothing needed to be resolved.

>     - Status Information on a Certificate
As Mike/Dave suggested, we will allow of the following states:
    notRevoked, revoked, unknown
Syntax to be decided.
There will *not* be an issued/notIssued state.
Right now, I don't think we should include an expired state (Dave?)
Andreas/Alexei, do you think your concerns have been addressed?

>     - Types of OCSP Responders
We will allow all three types of OCSP responders:
    - CA responding
    - Somebody the OCSP querrier decides to trust by out of band means
    - Somebody designated by the CA to issue OCSP responses on its
        behalf. The CA will designate another entity as a
        designated responder by issuing it a certificate with an
        special extension.

>     - Method of identifying certs
Am raising this topic again in a separate mail.

>     - Semantics of thisUpdate, nextUpdate, producedAt
Am raising this topic again in a separate mail.

>     - Extended error states in responses
Don't think we need the extended error responses, other than one
that says the server is busy right now (come back later)

>     - Caching
Am raising this topic again in a separate mail.

> 
> If you have input on any of these topics, please do the the mailing
> list know, so that we can address those concerns ASAP, reach a
> concensus about OCSP and finish up this project.
> 
> Thanks,
> Ambarish
-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Tue, 28 Apr 1998 16:02:41 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: [Fwd: [IETF-PKIX] OCSP Status Information on a Certificate]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------062C0D6D7EAC0041641869B6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry, I thought this was going out to the list.

Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303
--------------062C0D6D7EAC0041641869B6
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <[email-masked]>
Date: Tue, 28 Apr 1998 13:04:07 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
MIME-Version: 1.0
To: "David P. Kemp" <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
X-Priority: 3 (Normal)
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Dave,
    Did think about the expired issue for some time - however, if
you don't have a time that you trust on your local machine, how do
you know to trust the time on the OCSP response (the thisUpdate,
nextUpdate, producedAt times).

Regards,
Ambarish

David P. Kemp wrote:
> 
> > From: Marc Branchaud <[email-masked]>
> >
> > So I guess (unless I've forgotten someone) that the tally now stands at:
> >
> >       Issued / Revoked / Expired == 1
> >       Revoked only == 0
> >       Abstain == 1
> >
> 
> Add one for Revoked only, or add a new category Revoked / Expired.
> 
> As before, I don't see any rationale for Issued.
> 
> Expired could be useful if one assumes that the client does not have
> a reliable clock, that the responder does have access to a trusted
> time source, and that the RP uses OCSP for every verification.
> 
> Last month my wife's PC started dating files sometime in 2003 for no
> apparent reason.  The lithium battery was fine, the clock has been
> fine since we reset it, and the machine doesn't have a modem installed
> so it's never been exposed to hackers on the net.  Gamma rays, I guess.
> Anyway, OCSP Expired status may be useful.

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

--------------062C0D6D7EAC0041641869B6--

Date: Tue, 28 Apr 1998 17:12:52 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

> From: Michael Myers <[email-masked]>
> 
> I would like to propose we move forward with the following simplified
> construction:
> 
> CertStatusType ::= ENUMERATED {
>     notRevoked     (0),
>     revoked        (1),
>     onHold         (2),
>     unknownCA      (3),
>     unknownCert    (4) }

It seems unusual to include a specific status code for "onHold", but
not for any of the other X.509-defined reason codes.  And it seems
unusual to have two codes which mean "unknown" but for different
reasons; is there any business requirement for RPs to make a
distinction between unknownCA and unknownCert?

Might I suggest:

CertStatusType ::= ENUMERATED {
    notRevoked     (0),
    revoked        (1),
    unknown        (2) }

or less enthusiastically, include all the defined codes from CRLReason:

CertStatusType ::= ENUMERATED {
    unknown              (-2),
    notRevoked           (-1),
    revoked (unspecified) (0),
    keyCompromise         (1),
    cACompromise          (2),
    affiliationChanged    (3),
    superseded            (4),
    cessationOfOperation  (5),
    certificateHold       (6) }

> From: Andreas Berger <[email-masked]>
>
> Sorry that I bring that up again: the answer about knowing about a CA
> but not about the referenced certificate would be a good one for use of
> OCSP in the German Signature Law, where such a service is required.

Without knowing both "the law" and the text of this specific law, it's
impossible to be 100% sure of it's intent.  However, I'm 99.98% sure :-)
that "knowing about a CA" means that the RP possesses the certificate
of the CA as part of the cert path being validated, or that the CA's
cert can be validated or is a trust point, or that the RP has some
out-of-band reason to believe that the CA exists.

I have a hard time believing that the law's intent is to require the
use of OCSP-like technology with status codes enabling the OCSP
responder to claim "I know / don't-know about this CA".  The RP's
knowledge is what's important, not a repository/responder's knowledge.

Dave Kemp

To: [email-masked]
Subject: Re: OCSP status tally 
Date: Tue, 28 Apr 1998 12:57:18 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

Sounds good to me.

		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

Michael Myers <[email-masked]> scrawled:
> 
> Marc, All:
> 
> I would like to propose we move forward with the following simplified
> construction:
> 
> CertStatusType ::= ENUMERATED {
>     notRevoked     (0),
>     revoked        (1),
>     onHold         (2),
>     unknownCA      (3),
>     unknownCert    (4) }
> 
> In the unknownCA case, a repository may not have acquired information
> necessary to produce any other assertion.  The unknownCert value addresses
> all other states not explicitly address by notRevoked or revoked.  In
> particular, it may be the case that a certain repositories can be proven to
> have only received a subset of a CA's information via mechanisms such as
> CRL Distribution Points, CRLList or other means of delegating authority.
> 
> Mike
> 

Date: Tue, 28 Apr 1998 12:53:45 -0700
To: Marc Branchaud <[email-masked]>, [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: OCSP status tally
Sender: [email-masked]

Marc, All:

I would like to propose we move forward with the following simplified
construction:

CertStatusType ::= ENUMERATED {
    notRevoked     (0),
    revoked        (1),
    onHold         (2),
    unknownCA      (3),
    unknownCert    (4) }

In the unknownCA case, a repository may not have acquired information
necessary to produce any other assertion.  The unknownCert value addresses
all other states not explicitly address by notRevoked or revoked.  In
particular, it may be the case that a certain repositories can be proven to
have only received a subset of a CA's information via mechanisms such as
CRL Distribution Points, CRLList or other means of delegating authority.

Mike

At 11:51 AM 4/28/98 -0700, Marc Branchaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Content-Type: text/plain; charset=us-ascii
>
>
>Ambarish has reminded me of several other "votes" in favour of OCSP 
>returning revocation status only.  So the current tally is:
>
>	Revoked only == 5
>	Issued / Revoked / Expired == 1
>	Abstain == 1
>
>		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
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNUYlRFrdFXNdDxPlAQES7wMAkgJ65JuIh1A8dc3KcWpvW9uw+OcHvP2Y
>G7F1Rryl7c91L+vGDVTk83cbhHjjC3p9tT0JPdPrSntEkmYQOhJTUFTd/BtcEoh/
>AyPuPaetlBJgKHA2F2vSQxb0RGqF2TJm
>=fwGW
>-----END PGP SIGNATURE-----
>
>

Date: Tue, 28 Apr 1998 15:32:13 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
Sender: [email-masked]

> From: Marc Branchaud <[email-masked]>
> 
> So I guess (unless I've forgotten someone) that the tally now stands at:
> 
> 	Issued / Revoked / Expired == 1
> 	Revoked only == 0
> 	Abstain == 1
> 

Add one for Revoked only, or add a new category Revoked / Expired.

As before, I don't see any rationale for Issued.

Expired could be useful if one assumes that the client does not have
a reliable clock, that the responder does have access to a trusted
time source, and that the RP uses OCSP for every verification.

Last month my wife's PC started dating files sometime in 2003 for no
apparent reason.  The lithium battery was fine, the clock has been
fine since we reset it, and the machine doesn't have a modem installed
so it's never been exposed to hackers on the net.  Gamma rays, I guess.
Anyway, OCSP Expired status may be useful.

To: [email-masked]
Subject: OCSP status tally
Date: Tue, 28 Apr 1998 11:51:49 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

Ambarish has reminded me of several other "votes" in favour of OCSP 
returning revocation status only.  So the current tally is:

	Revoked only == 5
	Issued / Revoked / Expired == 1
	Abstain == 1

		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

To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate 
Date: Tue, 28 Apr 1998 10:53:38 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

"Alexei V. Vopilov" <[email-masked]> scrawled:
> 
> Marc, here are my comments.
> Basically I'm voting for all three (Revoked/Expired/Issued),
> not because of possible clients fatness, but because I can free
> a client from need to have the whole public certificate prior
> to issue OCSP request on it.
> 

That seems a strange requirement to me.  What benefit is there to knowing 
the status of a certificate that you don't have?  The whole reason for 
needing a certificate's status is to be able to trust the public key 
therein.  Without the certificate, you don't have the public key, so what's 
the point?

> Also, I don't think that OSCP must be only online CRL facility.
> Although, the name OSCP claims to deliver something more than
> a 'revoked' status the draft statements declare it _is_ for
> checking a certificate when no proper CRL is available on client
> side. At the same time other draft statements propose to provide
> more information returned for a requestor.
> 

I agree that OCSP has the potential to be more than just a CRL proxy server. 
As for the draft, I can't speak for the authors but I believe that any 
wording about different status types will be changed to reflect the 
discussions on the list.

> Finally, it would be a good idea (IMO) to support in OCSP protocol
> the case when a requestor will elect to _not_ use certificate until
> OCSP responder returns all the statuses as per standard verification
> procedure. Thus, regardless of certificate contents it is considered
> as invalid presumably.
> 

This is Pat's inverted OCSP semantics argument (see the CDP Alternative 
Proposal thread).

> more comments follow...
> 
> -----Original Message-----
> From: Marc Branchaud <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: 16 ai?aey 1998 a. 21:06
> Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
> 
> [ . . .]
> 
> :> Revocation =  "NotAvailable" // cannot access to CRL information
> :>               "UnknownCA"    // cannot access to unknown CA database
> :
> :Well, setting aside the issue of whether multi-valued responses are a good
> :idea or not, I would argue that the above two cases are equivalent.
> :
> :If the responder can't access the proper CRL information, it's because it
> :hasn't collected the CRLs from the CA and so it basically doesn't recognize
> :the CA.  The same argument applies to responders with direct access to a
> :CA's database.
> 
> ALX: Thus, you eliminate _any_ need for OSCP if a party has CRL, containing
> ALX: "next_update" value < present time, right?
> 

No, not at all.  The point is that the "NotAvailable" and "UnknownCA"
revocation status responses are the same.  Your question is about something
else entirely, and I don't agree with it.  If an entity has an expired CRL
(next_update < present_time) then it had better at least attempt some kind of
operation to get fresher revocation information, either through OCSP or a
"traditional" CRL retrieval.

> :Come to think of it, there could be a situation where a responder holds an
> :expired CRL for which it has yet to receive a replacement.  One might argue
> :that a "NotAvailable" response would be OK, but I think it would be better
> :to provide a response based on the expired CRL, perhaps accompanied by some
> :kind of warning.
> 
> ALX: Ok, make the response of bitmask type might work.
> ALX: Unknown CA   = 0
> ALX: Revoked      = 1
> ALX: NotRevoked     = 2
> ALX: NotAvaliable = Revoked|NotRevoked
> ALX: It is the way to provide 'some kind of warning'
> 

I'm interpreting your | to mean logical-OR, in which case your NotAvailable
field is always 1 and doesn't help.  A more appropriate bit would be a
"stale" bit that got set if the responder was forced to use expired
revocation information.

Even better would be a warning that had an indication of just how stale the 
information is, so that the client can better decide whether to accept it.

> :> Expiration =  "NotAvailable" // cannot access to known CA database
> :> _contents_
> :>               "UnknownCA"    // cannot access to unknown CA database
> :
> :Expiration is independent of the contents of a CA's database or even the
> :recognition of the CA by the responder.  The only time the responder would
> :reply with an "unknown" expiration value is if it doesn't actually perform
> :the expiration calculation.  This calculation can be performed for _any_
> :certificate, so whether an unknown response is made is really just a matter
> :of how the responder is configured.
> :So, once again, I think a single kind of "unknown" response is adequate
> :here.
> 
> ALX: IMO, if an entry in CA database is the body of certificate for
> ALX: requested status on, the _almost only_ way to check expiration
> ALX: status is to have access to CA database entry (call it 'contents').
> ALX: NOTE that OCSP v3 does not require for certificate body  be
> ALX: present in the request and  even be available on the requestor side.
> 

I disagree.  I think OCSP assumes that the requestor has the certificate to 
begin with.  Like I said above, I can't imagine why anyone would want to 
know the status of a certificate they don't posess.

> :> Issued     =  "NotAvailable" // cannot access to known CA database
> :> _directory_
> :>               "UnknownCA"    // cannot access to unknown CA database
> :>
> :
> :This is where complexity is justified, because a responder using only CRLs
> :can not know if an unrevoked certificate has ever been issued (revoked
> :certs, on the other hand, are known to have been issued).  So I agree that
> :these two kinds of "unknown" responses are a good thing.  The "NotAvailable"
> :response would be given by responders that only have CRL information (for
> :the given CA).  A responder with direct access to the CA's database
> :shouldn't normally use the "NotAvailable" response.
> 
> ALX: Suppose, Responder has access to CA database. He _is_ able to
> ALX: navigate using serial number and issuer info, but cannot grab the
> ALX: certificate body. In that case it would specify
> ALX: Expired = NotAvailable
> ALX: Issued  = Issued
> 

Again, the need for Expired is based on your assumption that OCSP clients 
might not have the certificate they're querying about.  I don't agree with 
that assumption.

> :> Having this a Responder implementation can support only part of
> :> specification without interoperability problems.
> :> Note there is the difference between "NotAvailable" semantic for
> :> Expiration and Issued statuses.
> :>
> :> Note also that nothing (according to spec design)
> :> prevents implementing an OCSP Responder by extending CRLs
> :> issued by a CA (or by just ignoring them at all).
> :>
> :
> :I'm not sure what you mean by this.  Could you elaborate?
> 
> ALX: OK, suppose my employees are using certificates from VeriXXX
> ALX: issued in country XXX to complete transactions both
> ALX: in XXX and my country (let it be YYY ;-). But 'good days' are
> ALX: over and country XXX want to put all transactions in YYY down by
> ALX: forcing VeriXXX to revoke all it YYY certificates.
> ALX: But my business will not stop while I rely on OCSP that will just
> ALX: ignore bother CRLs from VeriXXX.
> 

I don't see a problem with this scenario.  Your business can also keep going
if it just decides to ignore revocation altogether.  If you're willing to
trust an OCSP responder that ignores CRLs, that's your choice.  IF the
responder is malicious, there's not much you can do anyway.  And if you're
willing to continue to do business with YYY behind XXX's back, that's also
your choice.  A PKI isn't a policing mechanism.

> :As for the bigger picture, I'm still not convinced either way about whether
> :or not OCSP should have multi-valued responses.  I think the extra
> :complexity is manageable, but I also see the appeal of a simpler protocol.
> :It really depends on what people want to do with OCSP.  Are the issued/
> :unissued and expired/unexpired values needed?
> 
> ALX: How many lines of code it would require for supporting all the
> ALX: statuses, assuming an OSCP responder process _more_ than just
> ALX: information from CRLs, i.e. direct CA database access?
> ALX: IMO, 50% Requestors need status to be just "good/bad"
> ALX: while other 50% need to know "why bad"? The second group
> ALX: of requestors tends to be expanded by those from first one
> ALX: who got "unknown" status.
> ALX: If so, the support of just Revoked/NotRevoked/Unknown statuses
> ALX: will (optimistically) serve probably 1% of requestors grabbed
> ALX:  from both groups.
> 

So I guess (unless I've forgotten someone) that the tally now stands at:

	Issued / Revoked / Expired == 1
	Revoked only == 0
	Abstain == 1

		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

From: "Mullar Tim" <[email-masked]>
To: [email-masked]
Subject: OCSP
Date: Tue, 28 Apr 1998 09:45:47 PDT
Sender: [email-masked]

exist an implementation of OCSP Protocol??

Thank you in advance

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From: "Todd Glassey" <[email-masked]>
To: "Stephen P. Wilson" <[email-masked]>, "Warwick Ford" <[email-masked]>
Cc: "Tim Polk" <[email-masked]>, <[email-masked]>, "Stephen Samson" <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for   CRL Distribution Points Patent
Date: Tue, 28 Apr 1998 07:38:49 -0700
Sender: [email-masked]

Yeah Entrust... But there is the bigger issue of the overall ISOC/IESG
Intellectual Properties Policy implemented through the IETF.

The bottom line is that until the IP language is reworded in RFC's 2026 and
2028, this type of occurrence is still possible and this will continue to
cast F.U.D. on our standards.

Todd

-----Original Message-----
From: Stephen P. Wilson <[email-masked]>
To: Warwick Ford <[email-masked]>
Cc: Tim Polk <[email-masked]>; [email-masked] <[email-masked]>;
Stephen Samson <[email-masked]>
Date: Friday, April 24, 1998 1:41 AM
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL
Distribution Points Patent

>Warwick Ford wrote:
>>
>> I also am very pleased to see this move by Entrust.  When can we see
>> the full statement of licensing terms?  Royalty-free is good, but we
>> need to be sure that there are no other problematic terms or
>> conditions associated with the license.
>
>Excuse my ignorance, it's quite possible I'm misunderstanding this (it
>is somewhat confusing to me...) - but, just because they are saying now
>that it's going to be royalty free, doesn't mean that it's always going
>to be royalty free, does it?
>
>Didn't something similar happen with .GIF files? - whereby, after being
>freely "use-able" for a long time, the company with the patent decided
>that anyone using the format should have to pay them royalties.
>
>I'm no legal expert (far from it in fact) - so perhaps I'm making some
>huge assumptions - could someone clarify this for me?
>
>Stephen.
>
>--
>Stephen Wilson. BSc (hons), AMIEE.          [email-masked]
>The views and statements contained in this message are entirely those
>of the author and should not be considered as the opinion or policy
>of any other person or organisation.
>

From: "Linn, John" <[email-masked]>
To: [email-masked], [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: Padding Requirements for RSA signatures
Date: Tue, 28 Apr 1998 09:22:03 -0400
Sender: [email-masked]

Peter wrote, excerpting:

> PKCS #1 already handles OAEP from the SET work (rsaOAEPEncryptionSET, 1 2
> 840
> 113549 1 1 6, according to a different source within RSA this OID was once
> ripemd160WithRsaEncryption), but because there haven't been any updates
> released for several years this isn't generally known (perhaps one of the
> list
> members involved in SET, or someone from RSADSI, could comment on this).
>  
I've now checked the situation with others within RSA Labs who are involved
with PKCS #1, and understand the following:  While the SET work includes
OAEP support, the definition there is somewhat SET-specific.  More
generalized work on OAEP specification is underway (and considered likely
stable) within P1363; it's RSA Labs' intent to issue an update to PKCS #1
later this year including P1363-based OAEP. 

--John Linn, RSA Labs/East.

To: [email-masked]
Subject: Proposed change to OpenCDP proposal.
Date: Mon, 27 Apr 1998 17:36:42 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

Setting aside the "inverted OCSP semantics" debate for a second, as far as 
CRLs go I think OpenCDP is pretty good.

I think section 6 [the Revocation Issuer (RI) extension] needs to have some
text that emphasizes the need for a strong link between the entity named in
the extension and its key.  I proposed to Phill in a private message that the
following text be appended to the section:

  If the original signing key is not used to sign the CRL the client MUST
  ascertain that the signer (i.e. the RI) is trustable for that purpose.
  Clients MAY do this via some out-of-band process, or the CA MAY issue a
  certificate for the RI's key.  In the latter case, the RI SHOULD (MUST?)
  include its certificate in the CRL (using a TBD CRL extension) to prove
  that it has the authority to sign the CRL.

He thought the text was OK, and now we're bringing the dicussion to the list 
so everyone can have a kick at it.

The TBD CRL extension mentioned in the proposed text would simply contain the
certificate for the CRL signer:

	cRLSignerCertificate EXTENSION ::= {
		SYNTAX CRLSignerCertificate
		IDENTIFIED BY id-ce-cRLSignerCertificate
	}

	id-ce-cRLSignerCertificate OBJECT IDENTIFIER ::= {TBD}

	CRLSignerCertificate ::= Certificate

Thoughts?

		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

From: Yang Su Mi <[email-masked]>
Subject: ocsp implementation
To: [email-masked]
Date: Tue, 28 Apr 1998 09:26:34 +0900 (KST)
Sender: [email-masked]

Are any ocsp implementations available?

Thank you very much.
Yang, Soomi

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Mon, 27 Apr 1998 10:27:25 -0700
Subject: Re: CDP Alternative Proposal
Sender: [email-masked]

given that status of certificate is being checked ... then
all that is needed is the certificate id ... and ask whether
that certificate id is still acceptable (the CA signature
on the certificate should be sufficient regarding the
validity of the certificate). then status coming back
is a signed, time-stamped yes/no.

in aads, next step is validation of signed transaction ... where
there isn't a certificate ....  authority validates the
signature, signature status, transaction, and transaction
status (&/or approval).

in business world, hybrids may be possible ... relying party
may have account that provides authority ... but still wants an outside
service to maintain key status (i.e. certificate gives status
at time of manufacter ... as well as some binding between
key-pair and something(?) ... also at time of manufacter ...
question is what are the possible timeliness issues/status
required at time of use.

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Padding Requirements for RSA signatures
From: EKR <[email-masked]>
Date: 27 Apr 1998 08:55:11 -0700
Lines: 13
Sender: [email-masked]

[email-masked] (Peter Gutmann) writes:
> [Speaking of OAEP, has anyone benchmarked the overhead of the padding vs the
>  simpler PKCS #1 padding?  With all the hashing and mangling involved, it looks
>  like the padding could take about as long as the public-key operation]
It's insignificant. In my implementation, less than 2% of the overall
time to do an RSA public key encryption. (And correspondingly much
less of the decryption.)

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Mon, 27 Apr 1998 11:08:46 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: CDP Alternative Proposal
Sender: [email-masked]

> From: "Phillip M Hallam-Baker" <[email-masked]>
> 
> >P.S. The notion of 'inverted OCSP semantics' was/is well understood by
> >parties other than those involved in the CDP draft, just in case we may
> >have to obtain future royalty-free licenses on this 'original research'.
> 
> Oh I think you are quite right. I think we all understood that a CRL 
> would be used to verify the validity of a cert but somehow I had also
> framed this mental model of the relying parties processing CRLs
> to compile a blacklist and checking to see that the certificate
> was not on it. I had not progressed from the idea that a positive
> assertion was what was required to the idea that a positive
> assertion was something  the CRL could and should express.

Traditionally certificates exist to allow offline verification of
public keys/identities/privileges.  CRLs exist to allow certificates to
be constrained (i.e.  revoked) subsequent to their issuance, still
offline.

If one is going to do online verification of public keys ('inverted
OCSP semantics'), what is the point of OCSP in the first place?
It's just another layer of overhead for the poor thin client to
process.
Instead, one should just have the online server return a certificate
signed by the responder which is valid for the intended duration of the
response.  This is not an "Online Certificate Status Protocol", it is
online certification.

A new OCSP status format isn't needed, just use the online-generated
Certificate as the status.

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Padding Requirements for RSA signatures
Date: Mon, 27 Apr 1998 10:01:58 -0400
Sender: [email-masked]

>While there have been improed padding techniques proposed, I am unaware of
>any attacks against PKCS#1 signatures.  They are widely used and
implemented.

Sorry, what I was attempting to explain was the reason why
PKCS#1 is specified the was it is with constants in the
signature field. The substitution attack is an RSA issue that
PKCS#1 addresses not a feasible attack against PKCS#1 RSA.

Regardless this is not an area I think PKIX should venture.
If there is a serious vulnerability discovered then it would
make sense to deprecate an algorithm or packaging format
but the IETF is not in general a good place to develop
cryptographic mechanisms.

        Phill

Date: Sun, 26 Apr 1998 15:01:38 -0400
To: "Phillip M Hallam-Baker" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Padding Requirements for RSA signatures
Cc: [email-masked]
Sender: [email-masked]

While there have been improed padding techniques proposed, I am unaware of
any attacks against PKCS#1 signatures.  They are widely used and implemented.

Russ

At 01:37 PM 4/24/98 -0400, Phillip M Hallam-Baker wrote:
>This is from memory but I think the argument goes as follows.
>
>For signatures one important attack that has to be considered 
>is the substitution attack. Consider the case in which I might be 
>able to induce someone to sign a bit sequence which contained
>random bits that in one context were simply ignored but in another
>context might carry some semantic info.
>
>There is also the problem of using the same associative 
>properties Chaum uses to create blind cash to transform one
>signed message into another. Unless the unused bits have 
>some determinate value there is the risk that someone 
>would induce another to sign a value which when unblinded
>authenticated another document.
>
>
>There are better packaging formats than the PKCS#1 in 
>current use. Phil Rogaway has made a number of proposals
>in this area. I am not up to date on where they have reached
>although I remember commenting on them a year or two ago 
>when they were reviewed at MIT.
>
>I don't think we should attempt to develop cryptographic
>packaging in PKIX. That is an area where I think we need
>to leave it to other groups. In the specific case of RSA I
>think this is something we can reasonably expect RSA
>labs to take the lead noting of course that their work
>is subject to peer review through the academic litterature,
>discussion lists, conferences etc.
>
>It is a good point and the list should generally be aware 
>that the PKCS#1 standard may well be upgraded in
>the near future. But implementations still need to be 
>aware of the format currently in use.
>
>        Phill
>
>-----Original Message-----
>From: Andreas Berger <[email-masked]>
>To: pkix <[email-masked]>
>Date: Friday, April 24, 1998 9:13 AM
>Subject: Padding Requirements for RSA signatures
>
>
>>Hi,
>>
>>in Section 7.2.1 in the first part of PKIX the padding is fixed to the
>>methods stated in PKCS#1:
>>
>>"Padding conventions described in PKCS #1, section 8.1, must be used."
>>
>>Since fixed padding seems to have disadvantages when used in SmartCards
>>(i.e. Bellcore attack), a random component in the padding is usually
>>proposed for digital signature applications. German DIN (standards
>>organization) proposes exactly this for the cryptographic devices that
>>are to be supported with the German Signature Law. PKCS#1 is supported
>>as long as the Smartcards perform a double check before giving a reply
>>with the signature.
>>
>>Interesting enough, a random component is proposed in PKCS#1 for
>>encryption (in my understanding of 8.1).
>>
>>So my question is: is this requirement of the PKCS#1 style fixed padding
>>for signatures specifically intended? Is this gorup open to, let's say
>>one or two, other padding formats?
>>
>>Andreas
>>-- 
>>Erst kommt das Fressen, dann kommt die Moral
>> -- Bertolt Brecht
>>
> 

From: "Alexei V. Vopilov" <[email-masked]>
To: <[email-masked]>
Subject: Repost:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
Date: Mon, 27 Apr 1998 02:04:43 +0400
Sender: [email-masked]

Marc, here are my comments.
Basically I'm voting for all three (Revoked/Expired/Issued),
not because of possible clients fatness, but because I can free
a client from need to have the whole public certificate prior
to issue OCSP request on it.

Also, I don't think that OSCP must be only online CRL facility.
Although, the name OSCP claims to deliver something more than
a 'revoked' status the draft statements declare it _is_ for
checking a certificate when no proper CRL is available on client
side. At the same time other draft statements propose to provide
more information returned for a requestor.

Finally, it would be a good idea (IMO) to support in OCSP protocol
the case when a requestor will elect to _not_ use certificate until
OCSP responder returns all the statuses as per standard verification
procedure. Thus, regardless of certificate contents it is considered
as invalid presumably.

more comments follow...

-----Original Message-----
From: Marc Branchaud <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 16 ai?aey 1998 a. 21:06
Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate

[ . . .]

:> Revocation =  "NotAvailable" // cannot access to CRL information
:>               "UnknownCA"    // cannot access to unknown CA database
:
:Well, setting aside the issue of whether multi-valued responses are a good
:idea or not, I would argue that the above two cases are equivalent.
:
:If the responder can't access the proper CRL information, it's because it
:hasn't collected the CRLs from the CA and so it basically doesn't recognize
:the CA.  The same argument applies to responders with direct access to a
:CA's database.

ALX: Thus, you eliminate _any_ need for OSCP if a party has CRL, containing
ALX: "next_update" value < present time, right?

:Come to think of it, there could be a situation where a responder holds an
:expired CRL for which it has yet to receive a replacement.  One might argue
:that a "NotAvailable" response would be OK, but I think it would be better
:to provide a response based on the expired CRL, perhaps accompanied by some
:kind of warning.

ALX: Ok, make the response of bitmask type might work.
ALX: Unknown CA   = 0
ALX: Revoked      = 1
ALX: NotRevoked     = 2
ALX: NotAvaliable = Revoked|NotRevoked
ALX: It is the way to provide 'some kind of warning'

:> Expiration =  "NotAvailable" // cannot access to known CA database _contents_
:>               "UnknownCA"    // cannot access to unknown CA database
:
:Expiration is independent of the contents of a CA's database or even the
:recognition of the CA by the responder.  The only time the responder would
:reply with an "unknown" expiration value is if it doesn't actually perform
:the expiration calculation.  This calculation can be performed for _any_
:certificate, so whether an unknown response is made is really just a matter
:of how the responder is configured.
:So, once again, I think a single kind of "unknown" response is adequate
:here.

ALX: IMO, if an entry in CA database is the body of certificate for
ALX: requested status on, the _almost only_ way to check expiration
ALX: status is to have access to CA database entry (call it 'contents').
ALX: NOTE that OCSP v3 does not require for certificate body  be
ALX: present in the request and  even be available on the requestor side.

:> Issued     =  "NotAvailable" // cannot access to known CA database
_directory_
:>               "UnknownCA"    // cannot access to unknown CA database
:>
:
:This is where complexity is justified, because a responder using only CRLs
:can not know if an unrevoked certificate has ever been issued (revoked
:certs, on the other hand, are known to have been issued).  So I agree that
:these two kinds of "unknown" responses are a good thing.  The "NotAvailable"
:response would be given by responders that only have CRL information (for
:the given CA).  A responder with direct access to the CA's database shouldn't
:normally use the "NotAvailable" response.

ALX: Suppose, Responder has access to CA database. He _is_ able to
ALX: navigate using serial number and issuer info, but cannot grab the
ALX: certificate body. In that case it would specify
ALX: Expired = NotAvailable
ALX: Issued  = Issued

:> Having this a Responder implementation can support only part of
:> specification without interoperability problems.
:> Note there is the difference between "NotAvailable" semantic for
:> Expiration and Issued statuses.
:>
:> Note also that nothing (according to spec design)
:> prevents implementing an OCSP Responder by extending CRLs
:> issued by a CA (or by just ignoring them at all).
:>
:
:I'm not sure what you mean by this.  Could you elaborate?

ALX: OK, suppose my employees are using certificates from VeriXXX
ALX: issued in country XXX to complete transactions both
ALX: in XXX and my country (let it be YYY ;-). But 'good days' are
ALX: over and country XXX want to put all transactions in YYY down by
ALX: forcing VeriXXX to revoke all it YYY certificates.
ALX: But my business will not stop while I rely on OCSP that will just
ALX: ignore bother CRLs from VeriXXX.

:As for the bigger picture, I'm still not convinced either way about whether
:or not OCSP should have multi-valued responses.  I think the extra
:complexity is manageable, but I also see the appeal of a simpler protocol.
:It really depends on what people want to do with OCSP.  Are the issued/
:unissued and expired/unexpired values needed?

ALX: How many lines of code it would require for supporting all the
ALX: statuses, assuming an OSCP responder process _more_ than just
ALX: information from CRLs, i.e. direct CA database access?
ALX: IMO, 50% Requestors need status to be just "good/bad"
ALX: while other 50% need to know "why bad"? The second group
ALX: of requestors tends to be expanded by those from first one
ALX: who got "unknown" status.
ALX: If so, the support of just Revoked/NotRevoked/Unknown statuses
ALX: will (optimistically) serve probably 1% of requestors grabbed
ALX:  from both groups.

:I do think they're more marginal.  If the cert's signature verifies, then
:it's a good bet that the cert was issued.  As for expiration, a client would
:have to be pretty thin to not have a clock.

ALX: I would say yes, but the question is does Expiration and Issuing
ALX: Certificate Status protocols will never be the scope of PKIX?
ALX: If not, can OSCP manage the complexity to integrate this stuff in?
:Marc
regards,
--Alexei

Date: Sun, 26 Apr 1998 14:30:06 -0400
To: Stephen Samson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL Distribution Points Patent
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

I applaud this action.

This action obviously removes all of the issues associated with the CRL
Distribution Point extension.  However, the press release text does not
answer the question that I posted to the IETF-PKIX list in January. It is
not completely clear (at least to me) if this statement applies to all of
the Internet private extensions that were included in draft versions of
PKIX Part 1 while Warwick was employeed at Entrust.

Can we please be provided with a complete list of certificate extensions
that are covered by the patent and are now available royalty-free?  I would
like to see this list included in the Patent Statement from Nortel/Entrust
at the end of PKIX Part 1.

Russ

At 11:28 AM 4/23/98 -0400, Stephen Samson wrote:
>Members of the IETF community;
>
>In response to your concerns, Entrust Technologies is pleased to announce
>that rights in its US Patent 5,699,431 will be licensed on a royalty-free
>basis. The entire announcement can be found on the Entrust Technologies
>website, by following the attached link:
>
>http://www.entrust.com/news/1998/04_23_98.htm
>
>For more information, contact
>
>Steve Samson
>
>Entrust Technologies Inc.
>750 Heron Rd.,  8th Floor
>Ottawa, Ontario, Canada, K1V 1A7
>
>voice:			613-247-3725
>fax:			613-247-3412
>email:			[email-masked]
>Entrust Validation String:	SCKM-HQDL-X75G
> 

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>, IETF-PXIX <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Key identifiers
Date: Fri, 24 Apr 1998 21:47:04 -0400
Sender: [email-masked]

I have two comments on Denis and Dave's interactions:

1.  The use of authority key identifier extension where the key idenfier
is a bit string (as opposed to DN(authority parent), serial number) will
NOT lead to a false rejection of a valid path.  Denis is incorrect in
that.

2.  We do have a full path development algorithm.  It works very well
for the hierarchies in terms of computational complexity).  It works
well (as optimized as can be with my knowledge of today's technology)
for network environment in terms of computational complexity.  It does
not have a great deal of software complexity.  In summer, to answer Dave
Kemp's question, we do have a certificate path development algorithm.

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[email-masked]]
> Sent:	Thursday, April 23, 1998 7:14 PM
> To:	IETF-PXIX
> Subject:	Re: Key identifiers
> 
> > > = Denis Pinkas 
> >   = David P. Kemp
> 
> > > The reality is that for discovering a path, you might have to walk
> up
> > > and down, but the verification should only be done "walking down".
> This
> > > means that no digital signature verification should be done before
> > > getting one or more candidate paths down.
> > 
> > Part 1 Section 6 states that conforming implementations must perform
> > path validation in a manner which achieves identical results to the
> > given procedure, which takes as input a full cert path and works
> > from top to bottom.
> > 
> > But I don't see how following this procedure saves on signature
> > computations:  for every point at which there is a choice of
> issuers,
> > you need a disambiguator.  That is either a signature verification
> or
> > something which gives a shortcut answer without ever giving a false
> > reject.  Heuristics such as validity checking (against the target
> date
> > only, NOT for issuer-subject validity nesting!) might help in a very
> > few cases.
> 
> In most cases you will have the saving. The only case where you will
> not
> have the saving is when two CAs will have the same name (whether that
> name is a DN or an alternate name). This case should be very seldom
> but
> might exist. For that very seldom case, I do not think that we need
> additional mandatory parameters that every CA shall support and that
> takes some space in the certificate.  
> 
> >           AuthorityKeyIdentifier will allow you to reject all
> > inappropriate candidates, but it takes up space in the certs, as you
> > say.  Another, more radical, approach would be to define new
> > AlgorithmOIDs which include a one octet checkword in the signature
> > value, which could be compared against a specific high-entropy octet
> of
> > the authority public key.  This would eliminate 255/256 of the
> > unnecessary signature verifications.  NB: I'm not advocating this
> > approach, just using it as an illustration of a hack which could
> > improve pathbuilding efficiency without costing much space.
> > 
> > > > I have one problem with this approach: The verification path is
> not
> > > > fixed. Let us assume a CA gets certified by a set of other CAs.
> Some
> > > > users trust one of them, others some other CAs (which is why the
> CA
> > > > probably got this multiple certificates). When a user
> certificate
> > > > contains a reference to a single other CA, a user which does not
> trust a
> > > > specific CA will fail to verify the certificate, although there
> might be
> > > > a another path which would lead to a successful verification.
> > >
> > > I support this comment. This means that placing the key identifier
> will
> > > create failures in cases where successful verification could have
> be
> > > done applying a different approach.
> > 
> > I don't understand this comment.  If an entity has a certificate
> signed
> > by a particular issuer, that certificate will have the identifier of
> that
> > issuer's key.  A certificate from a different issuer will have a
> different
> > key identifier.  In what case will a key identifier cause a reject
> where
> > the signature would otherwise have verified correctly?
> 
> The problem is that the link is pointing *back* to a particular cert
> of
> a CA. A CA may have its signing public key signed by more than one CA.
> In that case the end-entity will point to only one of these certs
> which
> may end up to an intrusted point for the receiver. Using a different
> cert for the key of the CA could end up to a trusted point for the
> receiver. This is why you may end up with a reject.
> 
> > > > One question: Do we have an algorithm for a complete
> verification? There
> > > > is one that describes how to verify an existing FC path, but do
> we have
> > > > an algorithm on how to construct a path?
> > >
> > > We currently don't and we probably should define one.
> > 
> > Yes.  Santosh?
> > 
> > Dave Kemp
> 
> 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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Padding Requirements for RSA signatures
Reply-To: [email-masked]
Date: Sat, 25 Apr 1998 13:03:01 (NZST)
Sender: [email-masked]

>On the yea side is the argument that if the spec does not allow for a block
>padding format which gives the DIN a "warm fuzzy feeling", then there are
>potential problems reconciling PKIX with German Signature Law. On the nay side
>is the argument that it is outside the scope of the PKIX charter to define its
>own encryption block formats, and that people concerned with the quality of
>DIN's emotional experiences should lobby RSA Labs to include something similar
>to OAEP which should protect against low exponent attacks made popular by
>Coppersmith. (Of course, my personal opinion on this one is that PKCS#1 is
>fine, and if you're using a public exponent of 3, you get what you deserve.)
 
PKCS #1 already handles OAEP from the SET work (rsaOAEPEncryptionSET, 1 2 840
113549 1 1 6, according to a different source within RSA this OID was once
ripemd160WithRsaEncryption), but because there haven't been any updates
released for several years this isn't generally known (perhaps one of the list
members involved in SET, or someone from RSADSI, could comment on this).
 
At the moment there are three main padding choices:
 
1. PKCS #1 (signature or encryption).
2. ISO 9796 (signature).
3. OAEP (encryption).
 
The problem with moving away from PKCS #1 is that nothing of any significance
supports any of the alternatives, and unless you can persuade a large number of
vendors to add support for something which they may or may not perceive as
adding any value, changing the block padding will mean your certs fail to
verify with most software.
 
If either 9796 or OAEP are added, it'd be nice to have some fairly complete
test vectors for both available somewhere, with the complexity involved in
these padding types it's likely there'll be all sorts of interesting 
interpretations of the standard around once multiple vendors get into the act.
 
[Speaking of OAEP, has anyone benchmarked the overhead of the padding vs the
 simpler PKCS #1 padding?  With all the hashing and mangling involved, it looks
 like the padding could take about as long as the public-key operation]
 
Peter.

Date: Fri, 24 Apr 1998 15:24:08 -0700 (PDT)
From: Number Twenty-Three <[email-masked]>
Subject: Re: Padding Requirements for RSA signatures
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

<PRE>
At the risk of flogging a dead horse, let me add  my two cents to this
thread. It seems  to  me that  the  question is, "should PKIX  specify
encryption block formats?" On the yea side is the argument that if the
spec does not allow  for a block padding  format which gives the DIN a
"warm  fuzzy feeling", then  there  are potential problems reconciling
PKIX with  German Signature Law. On the  nay side is the argument that
it  is  outside  the  scope of  the PKIX  charter   to define  its own
encryption block formats, and  that people concerned with the  quality
of DIN's  emotional   experiences should  lobby RSA  Labs  to  include
something similar  to OAEP which  should protect  against low exponent
attacks  made popular by Coppersmith. (Of  course, my personal opinion
on  this  one is that PKCS#1   is fine, and  if  you're using a public
exponent of 3, you get what you deserve.)

I  would   propose that  somewhere in  the  family  of PKIX  drafts is
included a list   of "acceptable" block   formats. We  might even  say
something    like: "compliant   implementations  MUST  support  PKCS#1
formats,  and they  SHOULD (or  MAY)  support  OAEP."  I imagine  that
VeriSign's concern  is  that if the   standard mandates something like
OAEP, they (and  most likely GTE, Thawte,   [fill in the  name of your
favorite commercial CA  here], et al) will have  a bit of  recoding to
do. A concern that I can certainly understand.

I agree  with Phill  that DEFINING  new  block padding formats  may be
outside   the scope of    the PKIX charter.   However,  I  am somewhat
sympathetic to Andreas' concerns. I don't think it's outside the scope
of PKIX to list "acceptable" block padding formats.  Some might have a
problem with "acceptable",  in which  case the  word "known" might  be
substituted.

I propose   that buried  somewhere  in  one of  the  drafts  a list be
maintained similar to:

  * You MUST support PKCS#1 block type 1. (See PKCS#1)
  * You SHOULD support OAEP. (See X9.44, P1363, or SET)
  * You MAY support PKCS#1 block type 0. (See PKCS#1)

In  this way, the   standard addresses the concerns   of the DIN,  and
allows  those of us who can  live with PKCS#1 block  types to live our
lives in a state  of bliss, not having to  immediately add support for
OAEP to our products. Should someone wish  to implement a system which
is compatible with German signature law, they can include support OAEP
in thier application profile.

In the future, when RSA Labs includes OAEP, or something like OAEP
into PKCS#1, the spec can be ammended to include:

  * You SHOULD support PKCS#1 block type 3

Assuming that  block type 3 is  the OAEPish thing we're discussing. If
Labs is really working on this, then  the worst that  can happen is we
get  two definitions that overlap. If  they're not working on it, then
our friends in Germany get to use OAEP or  an OAEP-like padding scheme
that gives them a "warm fuzzy feeling" sometime this millenium.

The  next  question is where  are the  OIDs  for these things defined?
PKCS#1 block  format 1 is implied  in  the RSAWithMD5, RSAWithMD2, and
RSAWithSHA  OIDs defined   in the  RSA  OID  space. I'm  assuming that
there's an OAEP OID  lurking out there  somewhere, just waiting to  be
used. Or, if we're really masochistic, we could apply to IANA(?) for a
branch in OID space reserved for PKIX. This would, of course, probably
break every known current implementation, so maybe it's not THAT great
of an idea...

-- Alzo spracht Phillip M Hallam-Baker <[email-masked]>:
] This is from memory but I think the argument goes as follows.
] For signatures one important attack that has to be considered 
] is the substitution attack. Consider the case in which I might be 
] able to induce someone to sign a bit sequence which contained
] random bits that in one context were simply ignored but in another
] context might carry some semantic info.
] 
] There is also the problem of using the same associative 
] properties Chaum uses to create blind cash to transform one
] signed message into another. Unless the unused bits have 
] some determinate value there is the risk that someone 
] would induce another to sign a value which when unblinded
] authenticated another document.
] 
] 
] There are better packaging formats than the PKCS#1 in 
] current use. Phil Rogaway has made a number of proposals
] in this area. I am not up to date on where they have reached
] although I remember commenting on them a year or two ago 
] when they were reviewed at MIT.
] 
] I don't think we should attempt to develop cryptographic
] packaging in PKIX. That is an area where I think we need
] to leave it to other groups. In the specific case of RSA I
] think this is something we can reasonably expect RSA
] labs to take the lead noting of course that their work
] is subject to peer review through the academic litterature,
] discussion lists, conferences etc.
] 
] It is a good point and the list should generally be aware 
] that the PKCS#1 standard may well be upgraded in
] the near future. But implementations still need to be 
] aware of the format currently in use.
] 
]         Phill
] 
] -----Original Message-----
] From: Andreas Berger <[email-masked]>
] To: pkix <[email-masked]>
] Date: Friday, April 24, 1998 9:13 AM
] Subject: Padding Requirements for RSA signatures
] 
] 
] >Hi,
] >
] >in Section 7.2.1 in the first part of PKIX the padding is fixed to the
] >methods stated in PKCS#1:
] >
] >"Padding conventions described in PKCS #1, section 8.1, must be used."
] >
] >Since fixed padding seems to have disadvantages when used in SmartCards
] >(i.e. Bellcore attack), a random component in the padding is usually
] >proposed for digital signature applications. German DIN (standards
] >organization) proposes exactly this for the cryptographic devices that
] >are to be supported with the German Signature Law. PKCS#1 is supported
] >as long as the Smartcards perform a double check before giving a reply
] >with the signature.
] >
] >Interesting enough, a random component is proposed in PKCS#1 for
] >encryption (in my understanding of 8.1).
] >
] >So my question is: is this requirement of the PKCS#1 style fixed padding
] >for signatures specifically intended? Is this gorup open to, let's say
] >one or two, other padding formats?
] >
] >Andreas
] >-- 
] >Erst kommt das Fressen, dann kommt die Moral
] > -- Bertolt Brecht
] >
</PRE>

<br><HR SIZE=1><TABLE BORDER=0><TR><TD><IMG SRC="http://www.woc.org/public/Matthew-Hamrick/images/matt/matthumb.jpg" HEIGHT=160 WIDTH=120 ALT="[Matt]" LOWSRC="http://www.woc.org/public/Matthew-Hamrick/images/matt/matthumblo.gif" ALIGN="top"></TD><TD VALIGN=top><A HREF="http://www.woc.org/public/Matthew-Hamrick/index.html"><FONT SIZE=4><I>Matthew S. Hamrick</I></FONT></A><BR><FONT SIZE=2>[email-masked]</FONT><BR><FONT SIZE="1">Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.<BR>Iä! Shub-Niggurath! Narrathoth! Narrathoth! Narrathoth!</FONT></TD></TABLE>

<hr size=1><b>DO YOU YAHOO!?</b><br>Get your free @yahoo.com address at <a href="http://mail.yahoo.com">Yahoo! Mail</a>.<br>

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Pat Richard" <[email-masked]>
Cc: "Flanigan, Bill" <[email-masked]>, <[email-masked]>
Subject: Re: CDP Alternative Proposal
Date: Fri, 24 Apr 1998 16:13:31 -0400
Sender: [email-masked]

>P.S. The notion of 'inverted OCSP semantics' was/is well understood by
>parties other than those involved in the CDP draft, just in case we may
>have to obtain future royalty-free licenses on this 'original research'.
>
>:-)) 
>
>(okay, I admit that last paragraph was a bit harsh, but what am I
>supposed to beleive anymore ?)

Oh I think you are quite right. I think we all understood that a CRL 
would be used to verify the validity of a cert but somehow I had also
framed this mental model of the relying parties processing CRLs
to compile a blacklist and checking to see that the certificate
was not on it. I had not progressed from the idea that a positive
assertion was what was required to the idea that a positive
assertion was something  the CRL could and should express.

In other words the 'realisation' was that I personally had been 
thinking about the problem in the wrong way entirely. The 
realisation was PHB getting unwedged. I certainly did not
want to imply that everyone else was wedged in the first place.

I now think that the idea of putting the scope into the CRL is 
something that is actually quite fundamental. If we had sat
down to design X.509 from scratch when Phil Zimmerman
unwedged us from the strict hierarchy with the UN secretary
general as root type mindset I think scoping is something
we would have put in as entirely obvious.

Although my attention had been directed to the problem
by certain CDP issues I don't think that there is in fact a 
conflict. I see them as being complimentary, CDPs provide
the location of a CRL, scopes allow dynamic control of the 
CRL size.

The current draft was written before we knew the Entrust
patent might be available on acceptable terms and so there
are parts which are specifically drafted to avoid patent 
infringement. That was not the principle point of the draft 
however (although I admit it was sort of the point of the title).

I agree that we need to have another look at OCSP. But
even here I think the need for a local distribution point 
for status info in addition to CRLs has not been understood.

Think of OCSP as an Intranet resource along with the DNS 
server. The scoped CRL model means that it is quite
realistic to have a local OCSP responder pulling CRLs
from a distribution center as needed. Under the old
model OCSP still had the problem of being forced to be 
a pre-push system rather than a DNS-like on demand pull.

            Phill

Date: Fri, 24 Apr 1998 12:23:00 -0700
From: Pat Richard <[email-masked]>
To: Sharon Boeyen <[email-masked]>
CC: [email-masked], Jeff Schiller <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL D istribution Points Patent
Sender: [email-masked]

I guess I mean "more optional", as in "not in the draft going to last
call"...

:-))

There are alternatives to using distribution points - if their
functionality is critical to the system then we should work to define
alternative structures - and if it is not then we should remove it. I
thought we had all spent a lot of brainpower thinking about how to get
on without them....

-Pat

Sharon Boeyen wrote:
> 
> Pat, this  was an optional element in PKIX prior to L.A. as it also is in
> the base X.509 standard.
>

From: Sharon Boeyen <[email-masked]>
To: [email-masked], "'Pat Richard'" <[email-masked]>
Cc: Jeff Schiller <[email-masked]>
Subject: RE: Entrust Technologies Announces Royalty-free License for CRL D istribution Points Patent
Date: Fri, 24 Apr 1998 14:51:13 -0400
Sender: [email-masked]

Pat, this  was an optional element in PKIX prior to L.A. as it also is in
the base X.509 standard. 

> ----------
> From: 	Pat Richard[SMTP:[email-masked]]
> Sent: 	April 24, 1998 2:11 PM
> To: 	[email-masked]
> Cc: 	Jeff Schiller
> Subject: 	Re: Entrust Technologies Announces Royalty-free License for
> CRL Distribution Points Patent
> 
> Tim Polk wrote:
> ...
> >   As the patent encumbrances have been removed, I now
> > intend to leave these extensions in the specification.
> 
> 
> While I wholeheartedly champion the un-emcumbrance of the technology
> (which we all agreed to remove from the all the drafts at the LA
> meeting), I shudder that anyone wishing to comply with an RFC document
> will have to be an Entrust "licensee". This brings other questions to
> mind - even if you disregard the idea that you may want to not be an
> Entrust licensee - like what protection is there from a legal
> perspective surrounding protection from possible Entrust policy changes
> in the future (even if the license is "perpetual") ?
> 
> I suggest that since we have scoped the effort required to take it out,
> and some have already taken it out of their drafts, that we continue to
> do so, and make the use of distribution points completely and entirely
> optional.
> 
> 
> > Thanks,
> > 
> > Tim Polk
> 
> 

Date: Fri, 24 Apr 1998 11:21:41 -0700
From: Pat Richard <[email-masked]>
To: "Phillip M. Hallam-Baker" <[email-masked]>
CC: "Flanigan, Bill" <[email-masked]>, [email-masked]
Subject: Re: CDP Alternative Proposal
Sender: [email-masked]

Phillip M. Hallam-Baker wrote:
> ...
> 
> This is an Internet draft based on original research by Warwick and
> myself.
> 
> ...
> Last week we realised that the problem with CRLs was not
> issuing the revocation info but the implicit assertion each CRL contains
> that all other certificates are valid. 
> ....

To re-phrase the 'realization', the default assertion in the current
OCSP model is one of validity, or that certs are 'valid
unless proven invalid' (which is what the previous drafts implied,
perhaps not by intent, but implied).

In any case, IMHO a lot of the 'kludges' currently ongoing in the OCSP
space are relative to the initial intent of making the OCSP model an
online 'replica' (so to speak) of CRLs (perhaps by virtue of existing
CRL expertise), which, by nature, are inherently late and inherently
flawed (by the implicit assumption of status).

To get more to the point, at the LA IETF I specifically questioned the
interpretation of certificate validity in the OCSP model (where we
assume a cert is valid until provn invalid) and I suggested an inversion
in the default semantics of an OCSP response, which is to assume invalid
until proven valid (and we can control participation in either CRL
(pro-valid) or online (pro-invalid) models by policy - that when using a
CRL use the old semantics, that when using OCSP, use inverted
semantics).

In addition, the notion of 'invalid unless proven valid' has merit when
there is an ongoing dispute. In other words (as experienced by other
real-world protocol implementors)
in the case of a disputed response, where one responder to a query
returns true, and another of equal weight returns false, what is the
correct value? For implementors to follow the most basic, indirect,
non-policy burdened logic: In the 'valid unless proven invalid model',
TRUE is accepted. In the 'invalid unless proven valid' model, FALSE is
accepted. 

Where is the text that addresses this most basic issue ? We seem to keep
issuing more and more kludges to work around the most basic flaw in the
CRL model. Invert the semantics. Why not implement it properly from the
ground up ?

P.S. The notion of 'inverted OCSP semantics' was/is well understood by
parties other than those involved in the CDP draft, just in case we may
have to obtain future royalty-free licenses on this 'original research'.

:-)) 

(okay, I admit that last paragraph was a bit harsh, but what am I
supposed to beleive anymore ?)

-Pat

> 
> A simple solution to CRL partitioning therefore is to embed a
> statement in each CRL specifying the CRL population it relates to.
> The issuer is not bound to chose a particular partitioning scheme
> in advance. Indeed the issuer could decide to issue CRLs of a
> particular length, say 100 certificates and chose the scoping
> constraints accordingly.
> 
> We think this is a better approach than hardwiring distribution points
> into certificates as per the Entrust patent claims.
> 
> Given that the area director has told us to jettison the encumbered
> technology so that part 1 can go to the IESG I don't think there is any
> dispute about the importance of this issue.
> 
>         Phill

Date: Fri, 24 Apr 1998 11:11:32 -0700
From: Pat Richard <[email-masked]>
To: [email-masked]
CC: Jeff Schiller <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL Distribution Points Patent
Sender: [email-masked]

Tim Polk wrote:
...
>   As the patent encumbrances have been removed, I now
> intend to leave these extensions in the specification.

While I wholeheartedly champion the un-emcumbrance of the technology
(which we all agreed to remove from the all the drafts at the LA
meeting), I shudder that anyone wishing to comply with an RFC document
will have to be an Entrust "licensee". This brings other questions to
mind - even if you disregard the idea that you may want to not be an
Entrust licensee - like what protection is there from a legal
perspective surrounding protection from possible Entrust policy changes
in the future (even if the license is "perpetual") ?

I suggest that since we have scoped the effort required to take it out,
and some have already taken it out of their drafts, that we continue to
do so, and make the use of distribution points completely and entirely
optional.

> Thanks,
> 
> Tim Polk

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Andreas Berger" <[email-masked]>, "pkix" <[email-masked]>
Subject: Re: Padding Requirements for RSA signatures
Date: Fri, 24 Apr 1998 13:37:08 -0400
Sender: [email-masked]

This is from memory but I think the argument goes as follows.

For signatures one important attack that has to be considered 
is the substitution attack. Consider the case in which I might be 
able to induce someone to sign a bit sequence which contained
random bits that in one context were simply ignored but in another
context might carry some semantic info.

There is also the problem of using the same associative 
properties Chaum uses to create blind cash to transform one
signed message into another. Unless the unused bits have 
some determinate value there is the risk that someone 
would induce another to sign a value which when unblinded
authenticated another document.

There are better packaging formats than the PKCS#1 in 
current use. Phil Rogaway has made a number of proposals
in this area. I am not up to date on where they have reached
although I remember commenting on them a year or two ago 
when they were reviewed at MIT.

I don't think we should attempt to develop cryptographic
packaging in PKIX. That is an area where I think we need
to leave it to other groups. In the specific case of RSA I
think this is something we can reasonably expect RSA
labs to take the lead noting of course that their work
is subject to peer review through the academic litterature,
discussion lists, conferences etc.

It is a good point and the list should generally be aware 
that the PKCS#1 standard may well be upgraded in
the near future. But implementations still need to be 
aware of the format currently in use.

        Phill

-----Original Message-----
From: Andreas Berger <[email-masked]>
To: pkix <[email-masked]>
Date: Friday, April 24, 1998 9:13 AM
Subject: Padding Requirements for RSA signatures

>Hi,
>
>in Section 7.2.1 in the first part of PKIX the padding is fixed to the
>methods stated in PKCS#1:
>
>"Padding conventions described in PKCS #1, section 8.1, must be used."
>
>Since fixed padding seems to have disadvantages when used in SmartCards
>(i.e. Bellcore attack), a random component in the padding is usually
>proposed for digital signature applications. German DIN (standards
>organization) proposes exactly this for the cryptographic devices that
>are to be supported with the German Signature Law. PKCS#1 is supported
>as long as the Smartcards perform a double check before giving a reply
>with the signature.
>
>Interesting enough, a random component is proposed in PKCS#1 for
>encryption (in my understanding of 8.1).
>
>So my question is: is this requirement of the PKCS#1 style fixed padding
>for signatures specifically intended? Is this gorup open to, let's say
>one or two, other padding formats?
>
>Andreas
>-- 
>Erst kommt das Fressen, dann kommt die Moral
> -- Bertolt Brecht
>

Date: Fri, 24 Apr 1998 11:53:10 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked]
Subject: Re: Comment on PKIX-1 - cRLSign
Sender: [email-masked]

> From: "Simonetti David" <[email-masked]>
> 
> Section 4.2.1.3, Key Usage, includes a paragraph on page 25 describing
> the cRLSign bit, "This bit may only be asserted in CA certificates."
>
>   ...
> 
> I suggest the statement on page 25 be removed.

I agree that this sentence should be removed from the description of
the cRLSign bit, because it is desirable to allow revocation
authorities to be separate from certificate authorities, or to allow a
CA to use different keys to sign certificates (perhaps offline) and
revocation information (which happens more frequently, and presumably
online).

In addition, I hesitate to suggest a modification to the first sentence
if it would delay the publication of Part 1, but we may wish to
change:

  "The cRLSign bit is asserted when the subject public key is used for
   verifying a signature on CRLs."

to:
 
  "...
   verifying a signature on revocation information."

which would extend the use of this bit to enable signed OCSP responses
in addition to CRLs.

Date: Fri, 24 Apr 1998 10:41:01 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IETF-PKIX] Comments on pkix-ipki-part1
Sender: [email-masked]

>>>>> "Peter" == Peter Gutmann <[email-masked]> writes:
>...
 Peter> There's no need to actually drop T61String.  All you need to
 Peter> do is say something like the following:
 
 Peter> "Where T61String is used it shall be restricted to contain
 Peter> only printable 8859-1 characters.  Shift and escape sequences
 Peter> and control codes shall not be used".

Sounds good.
 
 Peter> (it may be necessary to define "printable character" to "the
 Peter> range 0x20-0x7E and 0xA1-0xFE").

Yes, it's a good idea to define it -- but 0xFF is also a printable
character in 8859-1.

	paul

Date: Fri, 24 Apr 1998 09:13:16 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

> From: [email-masked]
> 
> You can't really avoid doing it.  If a CA issues CRL[n] which expires at
> time T, when is it supposed to issue CRL[n+1]?  At time T?  If so, then end
> systems won't have any valid revocation lists from time T until after
> whatever propagation delay the CRL distribution mechanism imposes (which
> may be dependent on directory replication schedules, HTTP proxy caching
> policy or any number of other things, many of which are outside the control
> of either the CA or the end-system).  So a CA really is forced to issue
> CRL[n+1] at some time before the previous CRL is set to expire.  So during
> that period, an end-system will have some uncertainty as to whether it has
> the absolute latest CRL.  But this is only a problem if verifiers have
> unrealistic expectations regarding what CRLs offer.

I agree with this analysis and the conclusion that CAs must routinely
issue CRL[n+1] at some time before nextUpdate of CRL[n].

I just wanted to point out that it is undesirable to base a system
on the assumption that CRLs can have long validity periods (say one
month) and may also support timely revocation (say 8 hours) by
issuing CRLs[n+1], [n+2], ... [n+k] while CRL[n] is still valid.

If the business requirement is for 8 hour freshness, then the CA's
policy should be something like issue CRLs with 8 hour validity every
4 hours.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Stephen P. Wilson" <[email-masked]>, "Warwick Ford" <[email-masked]>
Cc: "Tim Polk" <[email-masked]>, <[email-masked]>, "Stephen Samson" <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for   CRL Distribution Points Patent
Date: Fri, 24 Apr 1998 09:20:33 -0400
Sender: [email-masked]

>Excuse my ignorance, it's quite possible I'm misunderstanding this (it
>is somewhat confusing to me...) - but, just because they are saying now
>that it's going to be royalty free, doesn't mean that it's always going
>to be royalty free, does it?
>
>Didn't something similar happen with .GIF files? - whereby, after being
>freely "use-able" for a long time, the company with the patent decided
>that anyone using the format should have to pay them royalties.
>
>I'm no legal expert (far from it in fact) - so perhaps I'm making some
>huge assumptions - could someone clarify this for me?

That is a very good point. Moreover there is an issue of precedent
here as well as the specifics of this claim. This issue is not whether
or not Entrust is trustworthy but whether a precedent is set which
might be raised by a more malicious party.

I am just reading through a patent application which has on the
'Inventor' list an MIT professor. The patent essentially claims the
core technologies of Lotus Notes replication system, Kerberos
and proxy gateway and has a filing date of 1995.

The assignee of that particular patent has recently been issue 
other patents with similarly broad claims. Now forgive me if
I am a tired old cynic but I for one would not be willing to accept
license terms which forced me to license all my technology 
in return for access to the patents already issued. If I were say
IBM and I did so I would have unilaterally disarmed and would 
have no recourse were the other patent to be issued.

Fortunately International patents have to be published before
they are issued and I for one will be informing the alledged
inventors of a substantial quantity of prior art. 

The Entrust situation is very different, but even so the question 
the IESG is likely to consider as most important is precedence.

This is not really the place to have a general discussion of
the inequities of the US patent system however. Until the
Entrust terms are known there is not much usefull discussion
to be had on the subject.

        Phill

Date: Fri, 24 Apr 1998 15:02:25 +0200
From: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
To: pkix <[email-masked]>
Subject: Padding Requirements for RSA signatures
Sender: [email-masked]

Hi,

in Section 7.2.1 in the first part of PKIX the padding is fixed to the
methods stated in PKCS#1:

"Padding conventions described in PKCS #1, section 8.1, must be used."

Since fixed padding seems to have disadvantages when used in SmartCards
(i.e. Bellcore attack), a random component in the padding is usually
proposed for digital signature applications. German DIN (standards
organization) proposes exactly this for the cryptographic devices that
are to be supported with the German Signature Law. PKCS#1 is supported
as long as the Smartcards perform a double check before giving a reply
with the signature.

Interesting enough, a random component is proposed in PKCS#1 for
encryption (in my understanding of 8.1).

So my question is: is this requirement of the PKCS#1 style fixed padding
for signatures specifically intended? Is this gorup open to, let's say
one or two, other padding formats?

Andreas
-- 
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Date: Fri, 24 Apr 1998 09:41:25 +0100
From: "Stephen P. Wilson" <[email-masked]>
Organization: Defence Evaluation & Research Agency.
To: Warwick Ford <[email-masked]>
CC: Tim Polk <[email-masked]>, [email-masked], Stephen Samson <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for  CRL Distribution Points Patent
Sender: [email-masked]

Warwick Ford wrote:
> 
> I also am very pleased to see this move by Entrust.  When can we see 
> the full statement of licensing terms?  Royalty-free is good, but we 
> need to be sure that there are no other problematic terms or 
> conditions associated with the license.

Excuse my ignorance, it's quite possible I'm misunderstanding this (it
is somewhat confusing to me...) - but, just because they are saying now
that it's going to be royalty free, doesn't mean that it's always going
to be royalty free, does it?

Didn't something similar happen with .GIF files? - whereby, after being
freely "use-able" for a long time, the company with the patent decided
that anyone using the format should have to pay them royalties.

I'm no legal expert (far from it in fact) - so perhaps I'm making some
huge assumptions - could someone clarify this for me?

Stephen.

-- 
Stephen Wilson. BSc (hons), AMIEE.          [email-masked] 
The views and statements contained in this message are entirely those 
of the author and should not be considered as the opinion or policy 
of any other person or organisation.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: [IETF-PKIX] Comments on pkix-ipki-part1
Reply-To: [email-masked]
Date: Fri, 24 Apr 1998 16:25:08 (NZST)
Sender: [email-masked]

[This is a collection of several messages into one]
 
>Peter Gutmann wrote:
>>4.2.1.2.
>>
>>This gives the subject key identifier as the hash of the
>>subjectPublicKeyInfo *without* the tag and length.
>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.
 
I think Nada Cicovic summed up the point I was trying to make very well:
 
>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.
 
The public key is already encoded as an ASN.1 structure (usually a sequence), 
so all that removing the tag + length from the start does is create an awkward 
special-case requirement and add complexity to the spec.
 
[The RFC 2247 issue]
 
>Since we have a rfc which deals with using internet domain names within a
>distinguished name, it would seem rather strange that a subsequent IETF
>standard would exclude the use of this rfc on the grounds of what names the
>ITU support. From my simple perspective all we have to do is add domain
>component to the list of supported attributes in a general name.
 
I've seen an equal balance of messages either way, so I'll add my own $0.02 to 
try and tip the balance against DN components.  Since there's already a 
mechanism for encoding any type of Internet-related name (a GeneralName), 
there's no need for DN components, because all they are is a means of stuffing 
what's normally contained in a UR{I|L} into a DN.  GeneralNames provide the 
ability to encode more than just a DNS name, don't require breaking it up into 
components, and don't pollute the DN.  The only argument I can see for DN 
components is when you're being forced to use X.509v1 which doesn't support 
extensions with GeneralNames.
 
[And now the big one...]
 
>The TeletexString and UniversalString are included for backward compatibility,
>and should not be used for certificates for new subjects.
 
I think deprecating T61String entirely (presumably based on my long "it 
doesn't work" posting of a few weeks back) is throwing out the baby with the 
bathwater. You can make it work provided you constrain the way it's used.  
There are several problems with dropping T61String:
 
1. PrintableString has such a severaly crippled character set that even many
   normal ASCII strings (this sentence, for example) can't be encoded in it.
   By dropping T61String, a lot of ASCII strings are unnecessarily blown out to
   two-byte BMPStrings.
 
2. Most of Europe will be negatively affected by this change, since killing
   T61String means they're virtually forced to use BMPString in all their
   certs, even though it's not really necessary.
 
   (A chorus of harrumphing from European list members would be appropriate
    here).
 
3. By forcing people to BMPString, you might end up causing more problems than
   you solve.  Everything on earth (even DOS, with the right codepage) supports
   8859-1.  Support for BMPString/Unicode is still very patchy, will never
   happen for a great many OS's which are still widely used but no longer
   supported by vendors (Windows 3.x, any older version of Unix, etc), and
   apparently has uncertain support in HTML and HTML tools (how would you
   display a BMPString from a cert on a web page?).
 
There's no need to actually drop T61String.  All you need to do is say
something like the following:
 
"Where T61String is used it shall be restricted to contain only printable
 8859-1 characters.  Shift and escape sequences and control codes shall not be
 used".
 
(it may be necessary to define "printable character" to "the range 0x20-0x7E
and 0xA1-0xFE").
 
This means you can automatically assume that a T61String is 8859-1, which gets 
you automatic support in pretty much any OS, all web browsers, and most other 
situations where it's likely to be useful.  Detecting non-conformance is also 
relatively easy, just check for anything funny which falls outside the 
acceptable range.
 
Peter.

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: FW: [IETF-PKIX] Subject/Issuer Name Population
Date: Thu, 23 Apr 1998 18:41:57 -0700
Sender: [email-masked]

My apologies -- I sent this to the wrong list.  That'll teach me to just
do a "reply" during mailing list transitions.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

> -----Original Message-----
> From:	Blake Ramsdell 
> Sent:	Thursday, April 23, 1998 6:13 PM
> To:	'IETF X.509-based public key infrastructure mailing list'
> Subject:	RE: [IETF-PKIX] Subject/Issuer Name Population
> 
> On Friday, April 17, 1998 7:42 AM, Tim Polk [SMTP:[email-masked]]
> wrote:
> > Please take the time to review the text.
> 
> I may have missed something in this, so I apologize if this is a dumb
> question.
> 
> The encoding rules for DirectoryString from 4.1.2.4 in your proposed
> text are:
> 
> >      (a) if the character set is sufficient, the string will be
> >      represented as a PrintableString;
> >
> >      (b) failing (a), if the BMPString character set is sufficient
> the
> >      string shall be represented as a BMPString; and
> >
> >      (c) failing (a) and (b), the string shall be represented as a
> >      UTF8String.
> 
> Is the assumption that a PKIX application is more likely to understand
> BMPString before UTF8String?  It seems like a waste to have to go to
> BMPString just because you want to encode something outside of
> PrintableString, but if it's for compatibility then I can understand
> the rationale.
> 
> If it's not for compatibility, then I suggest that we go ahead with
> UTF8String unless I missed something.
> 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> 

From: "Todd Glassey" <[email-masked]>
To: "Warwick Ford" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>, "Stephen Samson" <[email-masked]>, "Robert Moskowitz" <[email-masked]>
Cc: "poised WG" <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for   CRL Distribution Points Patent
Date: Thu, 23 Apr 1998 15:52:12 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

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

This effort is very commendable and addresses this specific issue but not
the policy that is the root cause of the problem.  While this is a clear
statement from Entrust that they want to play by the verbally agreed rules
it does not inhibit or eliminate the potential problem.

If the IETF is to continue being what it has been, that is a standards
agency that promotes leading edge-rather vision than lagging-edge
implementations and PKIX in particular), like some of the other major
standards bodies, this issue of IP management needs to be addressed. The
IETF (Through the Poised WG) needs to have a specific and exact policy for
dealing with IP issues, a policy that is much less ambiguous to current IP
laws and Processes. It, this updated policy, needs to be publicly stated and
agreed upon by all developers submitting to the IETF for comments or
standardization.

I would actually suggest that the submitters of drafts, rfc's or standards
proposals, by submitting them convey a limited power of attorney in the
matter of the technology and maybe we create a new class of standards to
appease the corporate "parents". I personally believe that this
arms-distance approach is necessary to further cement and solidify the
ISOC's position through the efforts of its disconnected children, the IESG
and its IETF. IMHO - A statement from the IETF regarding its vision and the
need for a policy like this to indemnify the ISOC/IESG/IETF itself are very
much in order

Todd

-----Original Message-----
From: Robert Moskowitz <[email-masked]>
To: Warwick Ford <[email-masked]>; Tim Polk <[email-masked]>;
[email-masked] <[email-masked]>; Stephen Samson
<[email-masked]>
Date: Thursday, April 23, 1998 11:04 AM
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL
Distribution Points Patent

>At 01:04 PM 4/23/98 -0700, Warwick Ford wrote:
>
>I spoke with John Ryan about this directly yesterday.  I don't think we
>will need much to get the exact wording of terms out.  I am right now
>testing out a few IPsec products that specifically care about this, so stay
>tuned...
>
>>I also am very pleased to see this move by Entrust.  When can we see the
>>full statement of licensing terms?  Royalty-free is good, but we need to
be
>>sure that there are no other problematic terms or conditions associated
>>with the license.
>>
>>Assuming that turns out all clear, then the profile can certainly proceed
>>immediately to Proposed Standard with CDPs and the other extensions and
>>policy qualifiers reinstated.
>>
>>We would also like to continue study of OpenCDP on the ietf-pkix list --
>>there are some features here that look very valuable and that we may want
>>to include in a follow-up standard.
>>
>>Warwick
>>
>>
>>At 11:57 AM 4/23/98 -0400, Tim Polk wrote:
>>>
>>>I was delighted to see Steve's email.  Perhaps we can put patents and
>>>politics behind us and move on to building and deploying security
>>>solutions.  In that light:
>>>
>>>At the LA meeting, I proposed to remove two certificate extensions (crl
>>>distribution points and authority info access) and two crl extensions
>>>(issuing distribution point and certificate issuer) from the profile
>>>forwarded to the IESG.  This decision was based entirely on IP issues,
not
>>>technical merit.  As the patent encumbrances have been removed, I now
>>>intend to leave these extensions in the specification.
>>>
>>>Thanks,
>>>
>>>Tim Polk
>>>
>>>At 11:28 AM 4/23/98 -0400, you wrote:
>>>>Members of the IETF community;
>>>>
>>>>In response to your concerns, Entrust Technologies is pleased to
announce
>>>>that rights in its US Patent 5,699,431 will be licensed on a
royalty-free
>>>>basis. The entire announcement can be found on the Entrust Technologies
>>>>website, by following the attached link:
>>>>
>>>>http://www.entrust.com/news/1998/04_23_98.htm
>>>>
>>>>For more information, contact
>>>>
>>>>Steve Samson
>>>>
>>>>Entrust Technologies Inc.
>>>>750 Heron Rd.,  8th Floor
>>>>Ottawa, Ontario, Canada, K1V 1A7
>>>>
>>>>voice: 613-247-3725
>>>>fax: 613-247-3412
>>>>email: [email-masked]
>>>>Entrust Validation String: SCKM-HQDL-X75G
>>>>
>>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>>[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>>---------------------------------------------------------------------
>>
>>
>Robert Moskowitz
>ICSA
>Security Interest EMail: [email-masked]
>

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

------=_NextPart_000_013D_01BD6ECF.C811FE70--

Date: Thu, 23 Apr 1998 12:04:00 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: [IETF-PKIX] Subject/Issuer Name Population
Sender: [email-masked]

At 09:20 AM 4/23/98 -0400, [email-masked] wrote:
>i)  This may invalidate certificates that are currently deployed.
>Since printableString is such a limited character set (a..z,
>A..Z, 0..9 plus a few punctuation characters, not including
>"@", "!" or "_"), many deployed certificates will currently
>use either teletexString or universalString, but since X.520
>matching rules are supposed to be in effect, there is no
>reason to suppose that equivalent names in existing
>certificates will match under a binary comparison.

I haven't looked at the X.520 matching rules, but I wonder how they could
cover universalString. The character set for universalString is ISO 10646
in UCS-4 mode (4 bytes per character). I don't believe that ISO 10646
defines case-matching rules, nor does it have a list of spacing characters,
so doing case-folding and space stripping would have to use local rules,
meaning lack of interoperability. Note that case mapping and spaces are
defined in Unicode, but only in non-normative tables, so we can't even look
there for guidance.

>ii)  The preferred ordering of printableString, bmpString and
>utf8String is problematic.  Since almost anything that might
>ever appear in a name attribute is going to reside within the
>BMP character-set, utf8String will hardly ever be used, so this
>really comes down to a choice between printableString and
>bmpString; utf8String will never actually be used if this
>ordering is used.  This is a pity, since utf8String is
>actually a very implementation-friendly codeset, in that
>it's identical to 7-bit ASCII for characters that can be
>represented in 7-bit ASCII, it doesn't use embedded null
>octets, so code can use regular null-terminated C-strings to
>store and manipulate it, it is designed so that it won't
>break 8-bit clean code that scans for 7-bit ASCII values,
>and it's efficient in terms of the number of octets used
>to encode a given string.

I agree fully, except for that last part. UTF8String is not efficient for
all characters; in specific, it takes 3 bytes to encode all Indic and Asian
scripts, which can be encoded in 2 bytes in BMPString. On the whole,
however, I also support UTF8String over BMPString for the other factors you
list.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Stephen Samson <[email-masked]>
To: [email-masked]
Subject: FW: Entrust Technologies Announces Royalty-free License for  CRL  Distribution Points Patent
Date: Thu, 23 Apr 1998 14:38:38 -0400
Sender: [email-masked]

Details of non-financial license terms will be made public next week.

> ----------
> From: 	Warwick Ford[SMTP:[email-masked]]
> Sent: 	23 April, 1998 4:04 PM
> To: 	Tim Polk; [email-masked]; Stephen Samson
> Subject: 	Re: Entrust Technologies Announces Royalty-free License for
> CRL Distribution Points Patent
> 
> I also am very pleased to see this move by Entrust.  When can we see the
> full statement of licensing terms?  Royalty-free is good, but we need to
> be
> sure that there are no other problematic terms or conditions associated
> with the license.
> 
> Assuming that turns out all clear, then the profile can certainly proceed
> immediately to Proposed Standard with CDPs and the other extensions and
> policy qualifiers reinstated.
> 
> We would also like to continue study of OpenCDP on the ietf-pkix list --
> there are some features here that look very valuable and that we may want
> to include in a follow-up standard.
> 
> Warwick
> 
> 
> At 11:57 AM 4/23/98 -0400, Tim Polk wrote:
> >
> >I was delighted to see Steve's email.  Perhaps we can put patents and
> >politics behind us and move on to building and deploying security
> >solutions.  In that light:
> > 
> >At the LA meeting, I proposed to remove two certificate extensions (crl
> >distribution points and authority info access) and two crl extensions
> >(issuing distribution point and certificate issuer) from the profile
> >forwarded to the IESG.  This decision was based entirely on IP issues,
> not
> >technical merit.  As the patent encumbrances have been removed, I now
> >intend to leave these extensions in the specification.
> >
> >Thanks,
> >
> >Tim Polk
> >
> >At 11:28 AM 4/23/98 -0400, you wrote:
> >>Members of the IETF community;
> >>
> >>In response to your concerns, Entrust Technologies is pleased to
> announce
> >>that rights in its US Patent 5,699,431 will be licensed on a
> royalty-free
> >>basis. The entire announcement can be found on the Entrust Technologies
> >>website, by following the attached link:
> >>
> >>http://www.entrust.com/news/1998/04_23_98.htm
> >>
> >>For more information, contact
> >>
> >>Steve Samson
> >>
> >>Entrust Technologies Inc.
> >>750 Heron Rd.,  8th Floor
> >>Ottawa, Ontario, Canada, K1V 1A7
> >>
> >>voice:			613-247-3725
> >>fax:			613-247-3412
> >>email:			[email-masked]
> >>Entrust Validation String:	SCKM-HQDL-X75G
> >>
> >>
> >
> >
> 
> ---------------------------------------------------------------------
> Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
> [email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
> ---------------------------------------------------------------------
>  
> 

Date: Thu, 23 Apr 1998 13:59:28 -0400
To: Warwick Ford <[email-masked]>, Tim Polk <[email-masked]>, [email-masked], Stephen Samson <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for   CRL Distribution Points Patent
Sender: [email-masked]

At 01:04 PM 4/23/98 -0700, Warwick Ford wrote:

I spoke with John Ryan about this directly yesterday.  I don't think we
will need much to get the exact wording of terms out.  I am right now
testing out a few IPsec products that specifically care about this, so stay
tuned...

>I also am very pleased to see this move by Entrust.  When can we see the
>full statement of licensing terms?  Royalty-free is good, but we need to be
>sure that there are no other problematic terms or conditions associated
>with the license.
>
>Assuming that turns out all clear, then the profile can certainly proceed
>immediately to Proposed Standard with CDPs and the other extensions and
>policy qualifiers reinstated.
>
>We would also like to continue study of OpenCDP on the ietf-pkix list --
>there are some features here that look very valuable and that we may want
>to include in a follow-up standard.
>
>Warwick
>
>
>At 11:57 AM 4/23/98 -0400, Tim Polk wrote:
>>
>>I was delighted to see Steve's email.  Perhaps we can put patents and
>>politics behind us and move on to building and deploying security
>>solutions.  In that light:
>> 
>>At the LA meeting, I proposed to remove two certificate extensions (crl
>>distribution points and authority info access) and two crl extensions
>>(issuing distribution point and certificate issuer) from the profile
>>forwarded to the IESG.  This decision was based entirely on IP issues, not
>>technical merit.  As the patent encumbrances have been removed, I now
>>intend to leave these extensions in the specification.
>>
>>Thanks,
>>
>>Tim Polk
>>
>>At 11:28 AM 4/23/98 -0400, you wrote:
>>>Members of the IETF community;
>>>
>>>In response to your concerns, Entrust Technologies is pleased to announce
>>>that rights in its US Patent 5,699,431 will be licensed on a royalty-free
>>>basis. The entire announcement can be found on the Entrust Technologies
>>>website, by following the attached link:
>>>
>>>http://www.entrust.com/news/1998/04_23_98.htm
>>>
>>>For more information, contact
>>>
>>>Steve Samson
>>>
>>>Entrust Technologies Inc.
>>>750 Heron Rd.,  8th Floor
>>>Ottawa, Ontario, Canada, K1V 1A7
>>>
>>>voice:			613-247-3725
>>>fax:			613-247-3412
>>>email:			[email-masked]
>>>Entrust Validation String:	SCKM-HQDL-X75G
>>>
>>>
>>
>>
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>---------------------------------------------------------------------
> 
>
Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Date: Thu, 23 Apr 1998 13:04:39 -0700
To: Tim Polk <[email-masked]>, [email-masked], Stephen Samson <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for  CRL Distribution Points Patent
Sender: [email-masked]

I also am very pleased to see this move by Entrust.  When can we see the
full statement of licensing terms?  Royalty-free is good, but we need to be
sure that there are no other problematic terms or conditions associated
with the license.

Assuming that turns out all clear, then the profile can certainly proceed
immediately to Proposed Standard with CDPs and the other extensions and
policy qualifiers reinstated.

We would also like to continue study of OpenCDP on the ietf-pkix list --
there are some features here that look very valuable and that we may want
to include in a follow-up standard.

Warwick

At 11:57 AM 4/23/98 -0400, Tim Polk wrote:
>
>I was delighted to see Steve's email.  Perhaps we can put patents and
>politics behind us and move on to building and deploying security
>solutions.  In that light:
> 
>At the LA meeting, I proposed to remove two certificate extensions (crl
>distribution points and authority info access) and two crl extensions
>(issuing distribution point and certificate issuer) from the profile
>forwarded to the IESG.  This decision was based entirely on IP issues, not
>technical merit.  As the patent encumbrances have been removed, I now
>intend to leave these extensions in the specification.
>
>Thanks,
>
>Tim Polk
>
>At 11:28 AM 4/23/98 -0400, you wrote:
>>Members of the IETF community;
>>
>>In response to your concerns, Entrust Technologies is pleased to announce
>>that rights in its US Patent 5,699,431 will be licensed on a royalty-free
>>basis. The entire announcement can be found on the Entrust Technologies
>>website, by following the attached link:
>>
>>http://www.entrust.com/news/1998/04_23_98.htm
>>
>>For more information, contact
>>
>>Steve Samson
>>
>>Entrust Technologies Inc.
>>750 Heron Rd.,  8th Floor
>>Ottawa, Ontario, Canada, K1V 1A7
>>
>>voice:			613-247-3725
>>fax:			613-247-3412
>>email:			[email-masked]
>>Entrust Validation String:	SCKM-HQDL-X75G
>>
>>
>
>

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

Date: Thu, 23 Apr 1998 12:35:16 -0400
From: "Simonetti David" <[email-masked]>
Organization: BAH
To: Tim Polk <[email-masked]>, IETF-PKIX <[email-masked]>
Subject: Comment on PKIX-1 - cRLSign
Sender: [email-masked]

Section 4.2.1.3, Key Usage, includes a paragraph on page 25 describing
the cRLSign bit, "This bit may only be asserted in CA certificates."

The draft OpenCDP includes an extension, REVOCATION ISSUER EXTENSION,
used by a CA to indicate that it has delegated authority to one or more
other entities to issue and sign CRLs or sign OCSP responses on its
behalf.  Additionally, the ill-fated issuingDistributionPoint extension
allowed a CRL issuer other than a CA.

I suggest the statement on page 25 be removed.
-- 
David Simonetti, Booz·Allen & Hamilton Inc.

Date: Thu, 23 Apr 1998 11:57:29 -0400
To: [email-masked], Stephen Samson <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL Distribution Points Patent
Cc: Jeff Schiller <[email-masked]>, Steve Kent <[email-masked]>, Warwick Ford <[email-masked]>, [email-masked], "Housley, Russ" <[email-masked]>
Sender: [email-masked]

I was delighted to see Steve's email.  Perhaps we can put patents and
politics behind us and move on to building and deploying security
solutions.  In that light:
 
At the LA meeting, I proposed to remove two certificate extensions (crl
distribution points and authority info access) and two crl extensions
(issuing distribution point and certificate issuer) from the profile
forwarded to the IESG.  This decision was based entirely on IP issues, not
technical merit.  As the patent encumbrances have been removed, I now
intend to leave these extensions in the specification.

Thanks,

Tim Polk

At 11:28 AM 4/23/98 -0400, you wrote:
>Members of the IETF community;
>
>In response to your concerns, Entrust Technologies is pleased to announce
>that rights in its US Patent 5,699,431 will be licensed on a royalty-free
>basis. The entire announcement can be found on the Entrust Technologies
>website, by following the attached link:
>
>http://www.entrust.com/news/1998/04_23_98.htm
>
>For more information, contact
>
>Steve Samson
>
>Entrust Technologies Inc.
>750 Heron Rd.,  8th Floor
>Ottawa, Ontario, Canada, K1V 1A7
>
>voice:			613-247-3725
>fax:			613-247-3412
>email:			[email-masked]
>Entrust Validation String:	SCKM-HQDL-X75G
>
>

From: Stephen Samson <[email-masked]>
To: [email-masked]
Cc: Jeff Schiller <[email-masked]>, Steve Kent <[email-masked]>, Tim Polk <[email-masked]>, Warwick Ford <[email-masked]>
Subject: Entrust Technologies Announces Royalty-free License for CRL Distr ibution Points Patent
Date: Thu, 23 Apr 1998 11:28:12 -0400
Sender: [email-masked]

Members of the IETF community;

In response to your concerns, Entrust Technologies is pleased to announce
that rights in its US Patent 5,699,431 will be licensed on a royalty-free
basis. The entire announcement can be found on the Entrust Technologies
website, by following the attached link:

http://www.entrust.com/news/1998/04_23_98.htm

For more information, contact

Steve Samson

Entrust Technologies Inc.
750 Heron Rd.,  8th Floor
Ottawa, Ontario, Canada, K1V 1A7

voice:			613-247-3725
fax:			613-247-3412
email:			[email-masked]
Entrust Validation String:	SCKM-HQDL-X75G

Date: Thu, 23 Apr 1998 11:24:24 -0400
From: "Simonetti David" <[email-masked]>
Organization: BAH
To: IETF-PKIX <[email-masked]>
Subject: Entrust® Technologies Offers Free License of Patented Technology
Sender: [email-masked]

Does this have an affect on the current efforts on Part 1?

Press release at http://www.entrust.com/news/1998/04_23_98.htm

-- 
David Simonetti, Booz·Allen & Hamilton Inc.

From: [email-masked]
To: [email-masked]
Date: Thu, 23 Apr 1998 10:50:14 -0400
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

[email-masked] (David P. Kemp) wrote:

>Carl Ellison has a colorful description of CRLs which are not
>required by the verifier: wandering anti-matter which may or
>may not happen to collide with the revoked certificates in
>time to prevent them from being used.  PKIX should not
>encourage the "statistical revocation" approach, and should
>point out the dangers of using it, as Paul has done in his
>Security Considerations text.

>Mike left out the obvious solution to the problem: just don't do it.
>PKIX does not prohibit CAs from issuing CRLs before the nextUpdate of a
>prior CRL, but the policy of individual CAs should take into account
>the trustworthiness and reliability of the distribution mechanism when
>deciding how to set nextUpdate and whether to ever issue interim CRLs.
>The no-brainer approach is to assume that revocation distribution is
>completely untrustworthy and expire the revocation information often
>enough that there is no motivation to issue interim information.

You can't really avoid doing it.  If a CA issues CRL[n] which expires at
time T, when is it supposed to issue CRL[n+1]?  At time T?  If so, then end
systems won't have any valid revocation lists from time T until after
whatever propagation delay the CRL distribution mechanism imposes (which
may be dependent on directory replication schedules, HTTP proxy caching
policy or any number of other things, many of which are outside the control
of either the CA or the end-system).  So a CA really is forced to issue
CRL[n+1] at some time before the previous CRL is set to expire.  So during
that period, an end-system will have some uncertainty as to whether it has
the absolute latest CRL.  But this is only a problem if verifiers have
unrealistic expectations regarding what CRLs offer.

The thisUpdate and nextUpdate fields should be viewed as a policy statement
by the CA that certificates revoked after the thisUpdate time may still be
verifiable by some end systems until nextUpdate.  That doesn't prohibit the
CA from issuing an updated CRL earlier, particularly if it knows that a
compromise has occurred (indeed, I would expect a CA to do so - it
corresponds to the real world concept of making a good-faith attempt to
notify subscribers to the CA of the compromise).  It simply means that it
can't provide any assurance that the new revocation list will supersede the
current one for all end-systems until after the current CRL's nextUpdate.

John

Date: Thu, 23 Apr 1998 16:40:06 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Andreas Berger <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: [IETF-PKIX] Subject/Issuer Name Population
Sender: [email-masked]

Andreas Berger wrote:

> Tim Polk wrote:

> > I have attached proposed text for the issuer and subject name sections.
> >
> > Highlights:
> >
> > (1) issuer name is required (that is, may not be an empty SEQUENCE).

> Do we need this or can we loosen it a little? I am thinking of CAs that
> just have DNS name (which is also hierarchical and unique and thus
> similar to a DN)? Should we say that the name should be globally unique
> and that only on alternative name should be present if the DN is empty?

I support this approach.

> > (2) subject name is required for CA certs.  (This means you never chain off
> > altnames!)

> see above.

The same.

(further text deleted)

Regards,

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

From: [email-masked]
To: [email-masked]
Date: Thu, 23 Apr 1998 09:20:18 -0400
Subject: Re: [IETF-PKIX] Subject/Issuer Name Population
Sender: [email-masked]

---------------------- Forwarded by John Wray/Iris on 04/23/98 09:17 AM
---------------------------

John Wray
04/22/98 10:43 AM

To:   "IETF X.509-based public key infrastructure mailing list"
      <[email-masked]>
cc:
Subject:  Re: [IETF-PKIX] Subject/Issuer Name Population  (Document link
      not converted)

Tim Polk <[email-masked]> on 04/17/98 10:42:00 AM,  wrote:

>I have attached proposed text for the issuer and subject name sections.
>
>Highlights:
>
>(1) issuer name is required (that is, may not be an empty SEQUENCE).
>(2) subject name is required for CA certs.  (This means you never chain
off
>altnames!)
>(3) Name comparison rules are greatly relaxed from the X.520 text.  Binary
>comparison of attribute values is permitted for everything except
>PrintableString. That is, no white space compression or case conversion in
>BMP or UTF8.
>
>(Rationale for PrintableString:  It has already been implemented, and is
>used in practically all certificates.  Upper and lowercase country codes,
>etc. will break if we don't support it.)

(1) and (2) above are fine.  However, the proposed text for (3) has
several problems.

Restatement of the proposal:

   A DirectoryString is now permitted to be a choice of printableString,
   teletexString, universalString, utf8String and bmpString, and PKIX
   implementations have to be able to understand certificates whose
   names use any of these syntaxes.   When generating certificates,
   use printableString if the string to be encoded fits in the
   printableString character-set, otherwise use bmpString if the
   string fits in the bmpString charset, otherwise use utf8String.

   Also, instead of X.520 matching rules (which depend on the attribute
   type, not the string syntax chosen, although for almost all reasonable
   attributes they turn out to be caseIgnoreString), define new matching
   rules based on the string syntax, such that attribute values encoded
   using printableString shall use caseIgnoreString matching rules, whereas
   attribute values using any other string syntax shall use binary
   matching.
   Attribute values that use different string syntaxes shall never match,
   regardless of their contents.

I have several issues with this.

i)  This may invalidate certificates that are currently deployed.
Since printableString is such a limited character set (a..z,
A..Z, 0..9 plus a few punctuation characters, not including
"@", "!" or "_"), many deployed certificates will currently
use either teletexString or universalString, but since X.520
matching rules are supposed to be in effect, there is no
reason to suppose that equivalent names in existing
certificates will match under a binary comparison.  This
will be even worse if we decide to throw out strings that would
otherwise match, simply because two CAs chose to use different
stringSyntaxes for encoding a given name.  I know of at least
one CA implementation that, if a name won't fit into the
printableString character-set, goes straight to universalString.
Certificates issued by this implementation will not be useful
in a PKIX infrastructure if the proposed text is adopted (or at
least, such certificates cannot appear in the same certificate
chain as PKIX-compliant certificates).

ii)  The preferred ordering of printableString, bmpString and
utf8String is problematic.  Since almost anything that might
ever appear in a name attribute is going to reside within the
BMP character-set, utf8String will hardly ever be used, so this
really comes down to a choice between printableString and
bmpString; utf8String will never actually be used if this
ordering is used.  This is a pity, since utf8String is
actually a very implementation-friendly codeset, in that
it's identical to 7-bit ASCII for characters that can be
represented in 7-bit ASCII, it doesn't use embedded null
octets, so code can use regular null-terminated C-strings to
store and manipulate it, it is designed so that it won't
break 8-bit clean code that scans for 7-bit ASCII values,
and it's efficient in terms of the number of octets used
to encode a given string.  It is also the standard codeset
for communicating between Java and other languages via the
Java native method interface.  Instead of this codeset, any
string that falls outside the printableString character-set
will be forced by this recommendation to use the 16-bit
bmpString codeset, with all the overhead (and potential
for byte-order bugs) that implies.

iii) If the restriction that attribute values have to use
the same syntax in order to be compared were to be dropped,
the only implication for PKIX implementations would be that
they would have to be able to convert from one string syntax
to another during chain processing.  However, this ability is
already required of a PKIX CA, by the requirement that a PKIX
implementation must choose the most restrictive syntax
that can represent a given attribute, so it's not an
great additional burden to put it in the chain processing
code as well (particularly as it's trivial to do for all the
allowed codesets except for the deprecated teletexString).
However, if an implementation _does_ have the ability to
convert between syntaxes, the rationale for using the most
restrictive syntax really goes away (since if the
implementation can convert, it shouldn't matter what syntax
a name is actually encoded with inside a certificate).
Given this, the PKIX profile should go for simplicity
(which to me as an implementor means removing choice wherever
possible), and simply specify the use of utf8String for all
names.  For the printableString character-set, the encoding
of a utf8String value is identical to the same value encoded
as a printableString - the only effect of using printableString
vs. utf8String is that they have different tags in the BER,
so there's no overhead in terms of code complexity or string
storage size.  The only effect would be to get rid of the
requirement on the implementation to dynamically pick a
preferred code-set by scanning the string;  instead it can
always use utf8.

iv) The specification of binary matching for all codesets
other than printable string doesn't really seem to buy
that much.  Consider an end-system E1, wishing to initiate a
secure communication with another end-system E2.  Assume that
the end-system retrieves certificates from a directory.
To initiate the connection, E1 will want to retrieve E2's
certificate.  Presumably, E2's name will have been provided
to E1 by a user, and it is unlikely that the user will know
the exact capitalization and spacing that E2's CA used when
binding E2's name into its certificate.  Instead, E1 will
likely take whatever name is provided, and use that to do
an directory retrieval.  The directory (which can be assumed
to understand X.520 matching rules) will return E2's
certificate, but before E1 can use the certificate it must
ensure that the subject name in the certificate actually
corresponds to E2 (since the directory isn't trusted).
So E1 has to be able to perform an X.520-style comparison
here, even if we specify binary matching in the certificate
chain processing.  So we haven't actually saved any code by
using binary matching - all we've done is to cause a PKIX
implementation to appear overly fussy about capitalization
and spacing.

In summary, now that the arcane teletexString syntax has
been deprecated, and we have utf8 as a compact universal
codeset that also happens to be ASCII-friendly, much of
the complexity of name comparisons has already been
eliminated.  The proposed PKIX restrictions on syntaxes
and comparisons don't simplify the implemention (and
in some cases they add complexity), while in almost all
cases they reduce functionality.

John

Date: Thu, 23 Apr 1998 16:25:40 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Re: OCSP Status Information on a Certificate
Sender: [email-masked]

Note: I am not sure that this message sent on Monday reached the list.
Sorry if this is a duplicate.
==================================================================

Slava,

Thanks for joining us.

(...)

> >  I fully agree. That's why I'm I don't think that issued/not issued
> >  should be a MAY: I think it has to be a MUST. We can be sure that 
> >  some clients will blow the comparison unless they are always told 
> >  whether or not the cert was even issued.

> Are we talking about fat OCSP client here ?
> Does the OCSP client in this case have full certificate chain ?
> Can we safely assume that fat OCSP client will need to verify signatures
> on the chain first, validity and other X509v3 constraints and only then
> submit OCSP request for status of every certificate in the chain ?

You are asking the right questions. 

> If this is so then, essentially, OCSP client is already in the possession
> of the well-formed certificate signed by the (indirectly or directly) 
> trusted CA key. In these circumstances receiving an anwer "not issued"
> may only mean that CA key is compromised and "unathorized" certificate 
> has been signed. But if someone has the CA key and can sign anything 
> with it (including "unathorized" certificates) then that someone can 
> also make sure that "unathorized" certificate has the same serial number
> as one of "authorized" and as long as we only send serial number to 
> identify a certificate in OCSP request the substitution of the 
> "authorized" cert with "unathorized" one will be unnoticed. This makes 
> "never issued" somewhat useless for fat OCSP clients.

> Is this reasoning wrong ?

The reasoning is correct. However I believe that your reasoning is also
valid for the other cases, i.e. I do not see how it is possible to take
a decision to accept a certificate without having that certificate in
hands, and as you correcly indicate you need anyway to verify signatures
on the chain first, validity and other X509v3 constraints. 

> Also since CA archiving capacity is always finite and we also talking
> about allowing "historical" OCSP queries "never issued" will have 
> to be replaced with "info unavailable" at least in some cases. This 
> further redices the value of "never issued" status.

 ... which is useless.

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

Date: Thu, 23 Apr 1998 16:21:19 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Michael Myers <[email-masked]>
CC: "Pkix List (E-mail)" <[email-masked]>
Subject: Re: OCSP Response Values and Structure
Sender: [email-masked]

Michael Myers wrote:
> 
> In reviewing comments to date so that we can move forward on the OCSP
> editing task,  the rough consensus appears to be as follows regarding OCSP
> response structure:
> 
> revocationStatus     {revoked, notRevoked, . . . }
> expirationStatus     {notYetValid, expired,  . . . }
> issuedStatus         {issued, notIssued, . . . }

Mike,

I do not think that your recap express the rough concensus. Look again
at the thread.

Several people have indicated which status (singular) should be
mandatory and which (plural) might be optional. There have been
questions raised and not answered.

For the optional status no argument has been given about their real
usefulness. In particular there has been no story to say if (and in the
case of if, how) an OCSP requester could make a path validation without
having access to the certificates of the path itself.

Regards,

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

Date: Thu, 23 Apr 1998 16:13:37 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Re: Key identifiers
Sender: [email-masked]

> > = Denis Pinkas 
>   = David P. Kemp

> > The reality is that for discovering a path, you might have to walk up
> > and down, but the verification should only be done "walking down". This
> > means that no digital signature verification should be done before
> > getting one or more candidate paths down.
> 
> Part 1 Section 6 states that conforming implementations must perform
> path validation in a manner which achieves identical results to the
> given procedure, which takes as input a full cert path and works
> from top to bottom.
> 
> But I don't see how following this procedure saves on signature
> computations:  for every point at which there is a choice of issuers,
> you need a disambiguator.  That is either a signature verification or
> something which gives a shortcut answer without ever giving a false
> reject.  Heuristics such as validity checking (against the target date
> only, NOT for issuer-subject validity nesting!) might help in a very
> few cases.

In most cases you will have the saving. The only case where you will not
have the saving is when two CAs will have the same name (whether that
name is a DN or an alternate name). This case should be very seldom but
might exist. For that very seldom case, I do not think that we need
additional mandatory parameters that every CA shall support and that
takes some space in the certificate.  

>           AuthorityKeyIdentifier will allow you to reject all
> inappropriate candidates, but it takes up space in the certs, as you
> say.  Another, more radical, approach would be to define new
> AlgorithmOIDs which include a one octet checkword in the signature
> value, which could be compared against a specific high-entropy octet of
> the authority public key.  This would eliminate 255/256 of the
> unnecessary signature verifications.  NB: I'm not advocating this
> approach, just using it as an illustration of a hack which could
> improve pathbuilding efficiency without costing much space.
> 
> > > I have one problem with this approach: The verification path is not
> > > fixed. Let us assume a CA gets certified by a set of other CAs. Some
> > > users trust one of them, others some other CAs (which is why the CA
> > > probably got this multiple certificates). When a user certificate
> > > contains a reference to a single other CA, a user which does not trust a
> > > specific CA will fail to verify the certificate, although there might be
> > > a another path which would lead to a successful verification.
> >
> > I support this comment. This means that placing the key identifier will
> > create failures in cases where successful verification could have be
> > done applying a different approach.
> 
> I don't understand this comment.  If an entity has a certificate signed
> by a particular issuer, that certificate will have the identifier of that
> issuer's key.  A certificate from a different issuer will have a different
> key identifier.  In what case will a key identifier cause a reject where
> the signature would otherwise have verified correctly?

The problem is that the link is pointing *back* to a particular cert of
a CA. A CA may have its signing public key signed by more than one CA.
In that case the end-entity will point to only one of these certs which
may end up to an intrusted point for the receiver. Using a different
cert for the key of the CA could end up to a trusted point for the
receiver. This is why you may end up with a reject.

> > > One question: Do we have an algorithm for a complete verification? There
> > > is one that describes how to verify an existing FC path, but do we have
> > > an algorithm on how to construct a path?
> >
> > We currently don't and we probably should define one.
> 
> Yes.  Santosh?
> 
> Dave Kemp

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ocdp-00.txt
Date: Thu, 23 Apr 1998 09:54:45 -0400
Sender: [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  
                          OPEN CRL DISTRIBUTION PROCESS (OpenCDP)
	Author(s)	: W. Ford, P. Hallam-Baker
	Filename	: draft-ietf-pkix-ocdp-00.txt
	Pages		: 4
	Date		: 22-Apr-98
	
This Internet Draft specifies mechanisms for determining if a public-key
certificate is valid or revoked, using CRL partitions.  These mechanisms
are considered superior to the CRL Distribution Points (CDP) mechanism
defined in ISO/IEC 9504-8/ITU-T Rec. X.509 for several reasons.
In particular, OpenCDP:

(a) accommodates dynamic partitioning as opposed to fixed partitioning;
(b) better supports use of certificates in multiple environments
    with different CRL stores;
(c) includes a means for improving cachability and timeliness
    characteristics with CRLs;  and
(d) is believed not to be encumbered by the patent claims applying to CDPs.
 
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-ocdp-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocdp-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: ftp.ietf.org
	
	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-ocdp-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-ocdp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocdp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "Flanigan, Bill" <[email-masked]>, <[email-masked]>
Subject: Re: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 16:28:45 -0400
Sender: [email-masked]

>Hello Phillip,
>
> Eminence?  Not an issue, at least not for me.  Prose?  Same.
>Acknowledgements?  Don't see these folks mentioned in the draft (but nice
to
>hear about their contributions).  And, thank you for the background on the
>draft.

The acknowledgements appear immediately after the IETF draft
disclaimer rather than at the end. I think Warwick wanted to make
sure they got noticed rather than tucking them away at the end.

        Phill

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "Phillip M. Hallam-Baker" <[email-masked]>, "Flanigan, Bill" <[email-masked]>, <[email-masked]>
Subject: Re: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 16:14:26 -0400
Sender: [email-masked]

OK, sorry about the sarcasm level in response to Bill's query. Bill probably
didn't intend the insult.

The last time someone suggested adding authors names to one of my drafts was
when Jeff Hostetler and myself propsed digest authentication in HTTP. The
RFC ended up with about 7 names, many of which had been added in the hope
that certain companies would support it (they didn't).

Having worked in particle physics I know all about being on an author list
that takes three pages. I always thought that rather ridiculous.

        Phill

From: "Flanigan, Bill" <[email-masked]>
To: [email-masked]
Subject: RE: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 16:05:03 -0400
Sender: [email-masked]

Hello Phillip,

	Eminence?  Not an issue, at least not for me.  Prose?  Same.
Acknowledgements?  Don't see these folks mentioned in the draft (but nice to
hear about their contributions).  And, thank you for the background on the
draft.

Bill

> -----Original Message-----
> From:	Phillip M. Hallam-Baker [SMTP:[email-masked]]
> Sent:	Wednesday, April 22, 1998 3:08 PM
> To:	Flanigan, Bill; [email-masked]
> Subject:	Re: CDP Alternative Proposal
> 
> >Before I spend any time wading through this much less submitting any 
> >suggested improvements or comments, I would like to see additional 
> >co-authors from other organizations be added.  Comments?
> 
> 
> 
> I am sorry that Bill does not find Warwick and myself sufficiently 
> emminent to make his reading list. Perhaps if we had persuaded
> Frederick Forsythe and Gabbriel Garcia Marquez to run over the
> prose rather than Brian LaMacchia, Barbara Fox and Jeff
> Weinstein we would have stood a better chance.
> 
> 
> This is an Internet draft based on original research by Warwick and
> myself.
> 
> As with all Internet drafts it is an individual submission by the authors.
> Authorship does not imply any endorsement by any organisation nor
> does it necessarily mean that other people did not make substantial
> contributions.
> 
> 
> Last week we realised that the problem with CRLs was not
> issuing the revocation info but the implicit assertion each CRL contains
> that all other certificates are valid. This lead to the idea that the only
> problem of partitioning CRLs was that one could only know a
> certificate was implicitly valid if one had the all the CRLs in which it
> might appear.
> 
> A simple solution to CRL partitioning therefore is to embed a
> statement in each CRL specifying the CRL population it relates to.
> The issuer is not bound to chose a particular partitioning scheme
> in advance. Indeed the issuer could decide to issue CRLs of a
> particular length, say 100 certificates and chose the scoping
> constraints accordingly.
> 
> 
> We think this is a better approach than hardwiring distribution points
> into certificates as per the Entrust patent claims.
> 
> Given that the area director has told us to jettison the encumbered 
> technology so that part 1 can go to the IESG I don't think there is any
> dispute about the importance of this issue. 
> 
> 
>         Phill
> 
> 
> 
> 

From: WHenry <[email-masked]>
To: "'Flanigan, Bill'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 15:38:58 -0400
Sender: [email-masked]

  I see no reason to add a long list of co-authors to the document.

 Bill Henry
 Performance Engineering Corporation
 3949 Pender Drive
 Fairfax, VA 22030
 Internet: [email-masked]

> -----Original Message-----
> From:	Flanigan, Bill [SMTP:[email-masked]]
> Sent:	Wednesday, April 22, 1998 2:16 PM
> To:	[email-masked]
> Subject:	RE: CDP Alternative Proposal
> 
> Before I spend any time wading through this much less submitting any 
> suggested improvements or comments, I would like to see additional 
> co-authors from other organizations be added.  Comments?
> 
> Bill
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> William F. Flanigan, Jr., Ph.D.       Voice:           (703) 735-3305
> Defense Information Systems Agency      DSN:                      653
> Strategic Planning Office (JEBA)        Fax:            (703)735-3255
> 10701 Parkridge Boulevard        Voice Mail:            (703)735-3305 
> Reston, VA 20191-4357              Internet:  <[email-masked]>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
> 
> > -----Original Message-----
> > From:	Warwick Ford [SMTP:[email-masked]]
> > Sent:	Wednesday, April 22, 1998 2:11 AM
> > To:	[email-masked]
> > Subject:	CDP Alternative Proposal
> > 
> > We have today submitted the attached Internet Draft entitled "Open CRL
> > Distribution Process (OpenCDP)" as <draft-ietf-pkix-ocdp-00.txt>.
> > 
> > While this work was initially motivated by the IETF and IESG desire that
> > the PKIX drafts not contain encumbered technology, we believe that the
> > result also has significant technical advantages over the CDP mechanism.
> > 
> > Given interest in this proposal, we suggest that the PKIX Cert and CRL
> > Profile (with CDPs expressly forbidden as per LA) progress to proposed
> > standard as soon as possible, allowing dependent application standards
> > (e.g., CMS) to progress as well.  PKIX may wish to also consider
> adopting
> > the OpenCDP specification as the basis of a follow-up adjunct standard.
> > 
> > Warwick and Phillip
> > 
> > 

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "Flanigan, Bill" <[email-masked]>, <[email-masked]>
Subject: Re: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 15:08:21 -0400
Sender: [email-masked]

>Before I spend any time wading through this much less submitting any 
>suggested improvements or comments, I would like to see additional 
>co-authors from other organizations be added.  Comments?

I am sorry that Bill does not find Warwick and myself sufficiently 
emminent to make his reading list. Perhaps if we had persuaded
Frederick Forsythe and Gabbriel Garcia Marquez to run over the
prose rather than Brian LaMacchia, Barbara Fox and Jeff
Weinstein we would have stood a better chance.

This is an Internet draft based on original research by Warwick and
myself.

As with all Internet drafts it is an individual submission by the authors.
Authorship does not imply any endorsement by any organisation nor
does it necessarily mean that other people did not make substantial
contributions.

Last week we realised that the problem with CRLs was not
issuing the revocation info but the implicit assertion each CRL contains
that all other certificates are valid. This lead to the idea that the only
problem of partitioning CRLs was that one could only know a
certificate was implicitly valid if one had the all the CRLs in which it
might appear.

A simple solution to CRL partitioning therefore is to embed a
statement in each CRL specifying the CRL population it relates to.
The issuer is not bound to chose a particular partitioning scheme
in advance. Indeed the issuer could decide to issue CRLs of a
particular length, say 100 certificates and chose the scoping
constraints accordingly.

We think this is a better approach than hardwiring distribution points
into certificates as per the Entrust patent claims.

Given that the area director has told us to jettison the encumbered 
technology so that part 1 can go to the IESG I don't think there is any
dispute about the importance of this issue. 

        Phill

From: "Flanigan, Bill" <[email-masked]>
To: [email-masked]
Subject: RE: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 14:15:59 -0400
Sender: [email-masked]

Before I spend any time wading through this much less submitting any 
suggested improvements or comments, I would like to see additional 
co-authors from other organizations be added.  Comments?

Bill

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           (703) 735-3305
Defense Information Systems Agency      DSN:                      653
Strategic Planning Office (JEBA)        Fax:            (703)735-3255
10701 Parkridge Boulevard        Voice Mail:            (703)735-3305 
Reston, VA 20191-4357              Internet:  <[email-masked]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	Warwick Ford [SMTP:[email-masked]]
> Sent:	Wednesday, April 22, 1998 2:11 AM
> To:	[email-masked]
> Subject:	CDP Alternative Proposal
> 
> We have today submitted the attached Internet Draft entitled "Open CRL
> Distribution Process (OpenCDP)" as <draft-ietf-pkix-ocdp-00.txt>.
> 
> While this work was initially motivated by the IETF and IESG desire that
> the PKIX drafts not contain encumbered technology, we believe that the
> result also has significant technical advantages over the CDP mechanism.
> 
> Given interest in this proposal, we suggest that the PKIX Cert and CRL
> Profile (with CDPs expressly forbidden as per LA) progress to proposed
> standard as soon as possible, allowing dependent application standards
> (e.g., CMS) to progress as well.  PKIX may wish to also consider adopting
> the OpenCDP specification as the basis of a follow-up adjunct standard.
> 
> Warwick and Phillip
> 
> 

Date: Wed, 22 Apr 1998 10:52:38 +0300
From: Moshe Litvin <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 11:26 AM 4/21/98 +0300, Moshe Litvin wrote:
> >The problem you describe is inherent to CRL and not to the distribution
> >method.
> 
> I disagree. If I send a request to a CA for the latest CRL, and I might get
> an old response if I use HTTP but am sure to get a current response if I
> use FTP, then the problem is in the distribution method.
> 

But this can happen also in FTP and LDAP:

1. Someone can write the old CRL back in place of the newer CRL in the
LDAP directory or the FTP server.

2. The LDAP directory could be a replicating one and the replication
hasn't occurred yet.

Do you have some sort of CRL distribution method that is immune to this
problem?

Moshe

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

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

Date: Tue, 21 Apr 1998 23:10:42 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: CDP Alternative Proposal
Sender: [email-masked]

We have today submitted the attached Internet Draft entitled "Open CRL
Distribution Process (OpenCDP)" as <draft-ietf-pkix-ocdp-00.txt>.

While this work was initially motivated by the IETF and IESG desire that
the PKIX drafts not contain encumbered technology, we believe that the
result also has significant technical advantages over the CDP mechanism.

Given interest in this proposal, we suggest that the PKIX Cert and CRL
Profile (with CDPs expressly forbidden as per LA) progress to proposed
standard as soon as possible, allowing dependent application standards
(e.g., CMS) to progress as well.  PKIX may wish to also consider adopting
the OpenCDP specification as the basis of a follow-up adjunct standard.

Warwick and Phillip
-----------------------------------------

PKIX Working Group                            P. Hallam-Baker (VeriSign)
Internet Draft                                        W. Ford (VeriSign)
                                                           
expires in six months                                     April 21, 1998

                Internet X.509 Public Key Infrastructure

                 OPEN CRL DISTRIBUTION PROCESS (OpenCDP)

                     <draft-ietf-pkix-ocdp-00.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).

   Copyright (C) The Internet Society (date). All Rights Reserved.

Abstract

This Internet Draft specifies mechanisms for determining if a public-key
certificate is valid or revoked, using CRL partitions.  These mechanisms
are considered superior to the CRL Distribution Points (CDP) mechanism
defined in ISO/IEC 9504-8/ITU-T Rec. X.509 for several reasons.  In
particular, OpenCDP:
(a) accommodates dynamic partitioning as opposed to fixed partitioning;
(b) better supports use of certificates in multiple environments with
different CRL stores;
(c) includes a means for improving cachability and timeliness
characteristics with CRLs;  and
(d) is believed not to be encumbered by the patent claims applying to CDPs.

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

Acknowledgments

The following individuals made significant contributions to the development
of this proposal:  Arn Schaeffer, Mahi de Silva, Michael Myers, and Alex
Deacon of VeriSign, Brian LaMacchia and Barbara Fox of Microsoft, and Jeff
Weinstein of Netscape.

1. PRINCIPLES

A certification authority may issue distinct CRLs for different subsets of
its certificate population.  The partitioning may be based on various
requirements, such as the need to partition evenly for pure performance
purposes, the need to produce separate CRLs on the basis of revocation
reason, or the need to group together revocation information for related
entities, e.g., all the servers or clients of one organization.

CRL partitioning involves two functions:

(a)  a CRL location function, which allows for a certificate-using system
to find a CRL applicable to a given certificate;
(b)  a certificate-CRL validation function, which provides for the
certificate-using system to confirm that a CRL to hand is indeed an
applicable CRL for the certificate under consideration.

The CDP mechanism merged these two functions into one mechanism.  In
contrast, the OpenCDP mechanism separates these two functions and thereby
achieves various benefits.  

First, the location function becomes a non-security-critical function, in
that location information does not need to be embedded into a certificate
and signed by the CA.  Among other benefits, this helps reduce certificate
sizes.

Second, the certificate-CRL validation function can be made a dynamic
mapping relationship, as opposed to the static relationship afforded by
CDPs.  For example, this function can be based on such certificate
population characteristics as subject name structures, certificate serial
number ranges, or date ranges.  Such CRL partition definitional criteria
can be changed dynamically by the CA if needed, without affecting the
issued certificate base.

Third, because the location information is not in the certificate, it is
possible to change that information for use of the certificate in different
environments, e.g., change it to point to a different CRL store when
traversing a firewall.

Fourth, given the provision of an attribute external to a certificate for
conveying CRL location information, the same attribute can convey other
useful revocation information such as a pointer to an OCSP server.

The OpenCDP mechanism employs a single X.509 CRL extension and two
attribute types for use in directories or in protocol construction.  No
certificate extensions are needed except that, if indirectCRLs are to be
implemented, there is a need for a new revocationIssuer extension to
implement the function of the cRLIssuer element of the
cRLDistributionPoints extension (which is no longer used in PKIX) - see
later section on Revocation Issuer Extension.

2. CRL LOCATION FUNCTION

A certificate-using system that uses partitioned CRLs needs to locate an
appropriate CRL for a given certificate.  Information on CRL location does
not need to be inside a certificate. Furthermore, it can be advantageous
not to have such information within certificates, in order to allow for
changing of the partition configuration or storage locations after
certificates are issued.  Therefore, OpenCDP explicitly forbids the
inclusion of location information within certificates.

CRL location will not always require standardized protocol features, since
it can often be handled by local logic, e.g., a CRL "map" (or pointer
thereto) for an enterprise, based on user names, might be incorporated into
a configuration file in end-user products of that enterprise.  

However, it is advantageous to have a standard format for specifying such
information, for use in protocols and directory entries.  This
specification therefore defines a standard attribute type for holding
revocation information, including CRL location information.  This attribute
type and typical ways of using it are described below under Revocation
Information Attribute.

This specification also defines another mechanism for locating CRLs.  This
involves a list of CRLs stored in the CA's directory entry.  This mechanism
is described below under the CRL List Attribute.

3. CERTIFICATE-CRL VALIDATION FUNCTION

The scope of a CRL partition can be defined by specifying ranges on any of
the fields in a certificate.  For Internet (PKIX) purposes, it is proposed
that the scoping be limited to the following criteria or any combination
thereof:

(a)  A certificate serial number range;
(b)  A subject key identifier range;
(c)  One or more subject name subtrees;
(d)  A time range for certificate issuance (more precisely, for the
notBefore time in the certificate);
(e)  End-user certificate vs CA-certificate.

Examples of CRL partition scopes are:

(1)  All of the certificates of a CA with serial numbers between 10,000 and
19,999 inclusive.
(2)  All of the certificates of a CA with subject names commencing: "C=US,
O=foobar, ..."
(3)  All of the certificates of a CA with subject DNS names
"<anything>.foobar.com".
(4)  All of the certificates of a CA for the subject "C=US, O=foo, OU=bar,
CN=myname".
(5)  All of the certificates of a CA with a notBefore date in April, 1998.

The scope of a CRL is indicated within that CRL using the following CRL
extension:

cRLScope EXTENSION ::= {
        SYNTAX  CRLScopeSyntax
        IDENTIFIED BY   { <oid tbd> } }

CRLScopeSyntax ::= SEQUENCE {
        serialNumberRange       [0] NumberRange OPTIONAL,
        subjectKeyIdRange       [1] NumberRange OPTIONAL,
        nameSubtrees            [2] GeneralNames OPTIONAL,
        notBeforeRange          [3] NotBeforeRange OPTIONAL,
        onlyContainsUserCerts   [4] BOOLEAN DEFAULT FALSE,
        onlyContainsCACerts     [5] BOOLEAN DEFAULT FALSE,
        onlySomeReasons         [6] ReasonFlags OPTIONAL,
        indirectCRL             [7] BOOLEAN DEFAULT FALSE }

NumberRange ::= SEQUENCE {
        startingNumber          INTEGER,
        endingNumber            INTEGER,
        modulus                 INTEGER OPTIONAL }

notBeforeRange ::= SEQUENCE {
        startingNotBeforeTime   GeneralizedTime,
        endingNotBeforeTime     GeneralizedTime }

The serialNumberRange element, if present, is used as follows.  When a
modulus value is present, the serial number is reduced modulo the given
value before checking for presence in the range.  Then, certificates with a
(reduced) serial number equal to or greater than startingNumber and less
than endingNumber are considered to be within scope of the CRL.

The subjectKeyId range element, if present, is interpreted the same as
serialNumberRange, except that the number used is the value in the
certificate's subjectKeyIdentifier extension, interpreted as an unsigned
integer.

Conventions for the nameSubtrees option are the same as for the Name
Constraints extension.  

If the notBeforeRange element is present, certificates with a notBefore
time equal to or greater than startingNotBeforeTime and less than
endingNotBeforeTime are considered to be within scope of the CRL.

The fields onlyContainsUserCerts, onlyContainsCACerts, onlySomeReasons and
indirectCRL are used as described for the X.509 issuingDistributionPoint
extension.  (Note that the issuingDistributionPoint extension and cRLScope
extension conflict with each other -- the issuingDistributionPoint
extension is not permitted in a CRL which contains a cRLScope extension.)

When a certificate-using system uses a CRL to check status of a
certificate, it should check that the CRL scope includes the certificate,
as follows:

(a)  If the CRL contains an issuingDistributionPoint extension, then such
CRL is inconsistent with PKIX and should not be used.
(b)  If the CRL contains a cRLScope extension, then the certificate-using
system must check that the certificate falls within the scope indicated by
the intersection of the serialNumberRange, subjectKeyIdRange, nameSubtrees,
and notBeforeRange scopes, and is consistent with onlyContainsUserCerts and
onlyContainsCACerts if present.
(c)  If the CRL contains neither an issuingDistributionPoint nor cRLScope
extension, then the scope is the entire scope of the CA, and the CRL may be
used for any certificate from that CA.

4.  REVOCATION INFORMATION ATTRIBUTE

Attributes of this type are used to hold CRL location information or other
information pertaining to revocation status of a certificate.  Ways of
using this attribute type include the following:

(a)  In a directory entry that holds a certificate.  The revocation
information is stored in an attribute accompanying the certificate
attribute and when anyone retrieves a certificate they can also retrieve
the revocation information. [Note: This attribute type needs to be included
in the PKIX LDAP schema.]

(b)  When a certificate is transported by CMS (or any other PKCS#7-based
protocol), the corresponding revocation information can be conveyed in an
unauthenticated attribute.

(c)  When a certificate is transported by ISAKMP, the corresponding
revocation information can be conveyed as an ISAKMP payload.

(d)  When a certificate is transported as part of a TLS/HTTP exchange, the
corresponding revocation information can be conveyed in a HTTP header.

(e)  When a certificate is issued using CRMF or PKCSReq (see [CRMF] or
[CMMF] respectively), the corresponding revocation information can be
conveyed as an unauthenticated attribute in the "response" field of a
CertRep message body (see [CMMF] for details on CertRep syntax.)

As new IETF protocols are defined, it is anticipated that the protocols
will make explicit provision for conveying revocation information along
with certificates.

Note that there may be circumstances in which an intermediary (e.g.,
firewall) may change revocation information, such as CRL location pointers,
in transit.

Following is the definition of the Revocation Information attribute type:

revocInfo ATTRIBUTE ::= {
  	WITH SYNTAX RevocInfo
  	ID <oid tbd> }

RevocInfo ::= SEQUENCE {
     certIssuer              GeneralNames,
     certSerialNumber        INTEGER,
     infoLocations           [0] SEQUENCE SIZE (1..MAX) OF InfoLocation
                             OPTIONAL,
     extensions              [1] SEQUENCE OF INSTANCE OF 
                             TYPE-IDENTIFIER OPTIONAL }

InfoLocation ::= SEQUENCE {
     locator                 GeneralNames,
     infoType                InfoType DEFAULT crl,
     reasons                 ReasonFlags OPTIONAL }

InfoType ::= ENUMERATED {
     crl                     (0),
     oCSPServer              (1) }

ReasonFlags ::= BIT STRING {
     unused                  (0),
     keyCompromise           (1),
     cACompromise            (2),
     affiliationChanged      (3),
     superseded              (4),
     cessationOfOperation    (5),
     certificateHold         (6) }

For the semantics of the reasons field, see the definition of the CRL
Distribution Points certificate extension in X.509.

Certification authorities that are conformant to OpenCDP must not insert a
revocation information attribute within a certificate.

5. CRL LIST ATTRIBUTE

This optional attribute type is for use by a CA in presenting a list of
available CRLs to certificate-users.  This list can be stored in the CA's
directory entry.  (That entry can be determined from issuer name or an
issuerAltName value.)

The list is signed and there is provision for inclusion of a last-update
time/date for every CRL.  A CA is able to use this mechanism as follows.  A
new CRL list is reissued periodically, typically with a relatively high
reissue frequency (in comparison with CRL reissue frequencies).  A
certificate user, on obtaining this list, can quickly determine if cached
copies of CRLs are still up-to-date.  This eliminates much unnecessary
retrieval of CRLs.  Furthermore, by using this mechanism, certificate users
become aware of CRLs issued by the CA between its usual update cycle,
thereby improving the timeliness of the CRL system.

Following is the definition of the CRL List attribute type:

cRLList ATTRIBUTE ::= {
  	WITH SYNTAX CRLList
  	ID <oid tbd> }

CRLList ::= SIGNED { SEQUENCE {
     signature               AlgorithmIdentifier,
     issuer                  GeneralNames,
     thisUpdate              GeneralizedTime,
     nextUpdate              GeneralizedTime  OPTIONAL,
     cRLLocators             CRLLocators }}

CRLLocators ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE  {
     locator                 GeneralName,
     cRLScope                CRLScopeSyntax,
     lastUpdate              GeneralizedTime OPTIONAL }

The signature, issuer, thisUpdate, and nextUpdate fields are interpreted
similarly as to in a CRL.  The lastUpdate field is the value of the
thisUpdate field in the most-recently issued referenced CRL.

6.  REVOCATION ISSUER EXTENSION

This noncritical certificate extension is used by a CA to indicate that it
has delegated authority to one or more other entities to issue and sign
CRLs or sign OCSP responses on its behalf.

revocationIssuer EXTENSION ::= {
        SYNTAX  GeneralNames
        IDENTIFIED BY   { <oid tbd> } }

7.  INTELLECTUAL PROPERTY STATEMENT

The authors have no knowledge of any pending or granted patents covering
the techniques described.  

Author Addresses:

   Phillip Hallam-Baker
   VeriSign, Inc.
   301 Edgewater Place, Suite 210
   Wakefield, MA 01880
   USA
   [email-masked]

   Warwick Ford
   VeriSign, Inc.
   301 Edgewater Place, Suite 210
   Wakefield, MA 01880
   USA
   [email-masked]

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

Date: Tue, 21 Apr 1998 14:35:28 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

After talking to David Kemp, I'd like to propose an additional paragraph to
the one I had already proposed for the security section:

If a CA issues one or more CRLs before the nextUpdate time
of a previous CRL, a requestor has no way of ensuring that a CRL
received from that CA is the most current one available.  Caching,
repository updating, and man-in-the-middle attacks may all result in
a valid but outdated CRL being accepted by the requestor without the
requestor knowing that a newer CRL is available.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 21 Apr 1998 13:12:17 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

> From: Mike Smith <[email-masked]>
> 
> Isn't the off-schedule CRL considered a delta-CRL (even if it
> contains the complete set of records)?  If so, then doesn't the reply
> also have to include the last "full" CRL produced in its response as
> well?

Nope and nope.  A delta CRL will have the deltaCRLIndicator extension
present.  The extension contains the BaseCRLNumber to which the delta
applies.  A CRL without the extension is not a delta CRL.

If a full base CRL had to be transmitted along with every delta CRL,
then there would be no reason to use delta CRLs.  The assumption is
that the verifier already has a locally-cached copy of the base CRL,
or is responsible for fetching it separately.

To: [email-masked]
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http 
Date: Tue, 21 Apr 1998 09:55:47 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

"Bob Jueneman" <[email-masked]> scrawled:
> 
> Michael, I'm not entirely sure I agree with your semantics. 
> Maybe I've missed something, but I always interpreted 
> the traditional CRL nextUpdate semantics to mean "if you 
> haven't gotten an new CRL by this time, you are potentially 
> missing something", not "I'm not going to have another 
> word to say on this subject until this time, even if the world 
> is about to come to an end."
> 
> In other words, I believe that a CA (at least some CAs) 
> would feel that they are allowed, and perhaps even 
> compelled, to issue a CRL PRIOR to the time of the 
> nextUpdate, especially in the event of a known key 
> compromise. Certainly I would take my business elsewhere 
> if a CA or repository would not provide me that service.
> 
> I haven't followed the OCSP discussion that closely, 
> I'm afraid, but surely the semantics haven't changed
> all that much?
>
> bob
> 

I'd say that the semantics have never been too clear.  I even find the way
you've described them a bit confusing.  You say that a CRL's nextUpdate means
that "if you haven't gotten an new CRL by this time, you are potentially
missing something" but you also say that a CA should be allowed to issue a 
CRL prior to nextUpdate.

So, basically, regardless of whether nextUpdate has passed or not, an RP may 
potentially be missing something.  nextUpdate doesn't really tell the RP 
anything.

The best interpretation of nextUpdate I've seen is something I inferred from
a post David Kemp put up about a week ago.  He said that a CA needs a certain
amount of time to process a revocation, and it needs a way to relay that
revocation-lag information to RPs.

That kind of information is far more useful to RPs than some guesstimate 
about the frequency of CRL publishing.  nextUpdate might be used to carry 
that information.  It makes sense within OCSP to say "Here is the 
cartificate's status NOW, and if a revocation were to occur NOW it would 
take X seconds for it be processed."  So if an RP waited X seconds and did 
another check, it would know the cert's status at NOW.  Another way to think 
of it is "this was the cert's status X seconds ago."

For CRLs, though, making nextUpdate adopt these semantics only makes sense if
the CRLs are published at most every X seconds (and never sooner).  That is,
there would be no CRLs published until nextUpdate.  This is because the CRL
would be saying "These are the revoked certificates as of NOW and since it
takes me (the CA) X seconds to process a revocation there will be _no_
updates to this list until NOW + X."  That is, nextUpdate = NOW + X.

I think this is a new spin on CRLs.  If not, it certainly hasn't been clear
to me until now (and so I'd say that the standards have inadequately 
explained the issue).  The implication is that if a CA wants to be able to 
boast of a fast revocation response time, say 10 seconds, then it has to 
publish a CRL every 10 seconds (or use OCSP).

                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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-webcap-00.txt
Date: Tue, 21 Apr 1998 12:55:18 -0400
Sender: [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		: WEB based Certificate Access Protocol-- WebCAP/1.0
	Author(s)	: S. Reddy
	Filename	: draft-ietf-pkix-webcap-00.txt
	Pages		: 26
	Date		: 20-Apr-98
	
   This document describes the Internet X.509 Public Key Infrastructure
   (PKI) Certificate Access 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].
 
   This document specifies a set of methods, headers, and content-types
   ancillary to HTTP/1.1 to publish, retrieve X.509 certificates and
   Certificate Revocation Lists. This protocol also facilitates
   determining current status of a digital certificate without the use
   of CRLs.  This protocol defines new methods, request and response
   bodies, error codes to HTTP/1.1 protocol for securely publishing,
   retrieving, and validation certificates across a firewalls.

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-webcap-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-webcap-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: ftp.ietf.org
	
	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-webcap-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-webcap-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-webcap-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 21 Apr 1998 12:42:38 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> 
> At 11:26 AM 4/21/98 +0300, Moshe Litvin wrote:
> >The problem you describe is inherent to CRL and not to the distribution
> >method.
> 
> I disagree. If I send a request to a CA for the latest CRL, and I might get
> an old response if I use HTTP but am sure to get a current response if I
> use FTP, then the problem is in the distribution method.

I agree completely with Mike on this one.  The CA signature on a CRL
(or OCSP response) allows the use of unreliable repositories.  FTP is
no more or less reliable a protocol than HTTP, it's just that the
use of caching proxies is more prevalent with HTTP (caching FTP
proxies do exist).  In addition to inadvertent errors due to caching,
one must also consider deliberate manipulation of repository contents,
which could result in a superceded-but-still-valid CRL being used.

Mike left out the obvious solution to the problem: just don't do it.
PKIX does not prohibit CAs from issuing CRLs before the nextUpdate of a
prior CRL, but the policy of individual CAs should take into account
the trustworthiness and reliability of the distribution mechanism when
deciding how to set nextUpdate and whether to ever issue interim CRLs.
The no-brainer approach is to assume that revocation distribution is
completely untrustworthy and expire the revocation information often
enough that there is no motivation to issue interim information.

Carl Ellison has a colorful description of CRLs which are not required
by the verifier: wandering anti-matter which may or may not happen to
collide with the revoked certificates in time to prevent them from being
used.  PKIX should not encourage the "statistical revocation" approach,
and should point out the dangers of using it, as Paul has done in his
Security Considerations text.

  Dave Kemp

Date: Tue, 21 Apr 1998 09:01:50 -0700
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Bob,

Semantics of nextUpdate in OCSP and in CRLs are identical.  Implementors
should support an update to a CRL prior to expiration of nextUpdate on a
current CRL.

Mike

At 07:21 PM 4/20/98 -0600, Bob Jueneman wrote:
>Michael, I'm not entirely sure I agree with your semantics. 
>Maybe I've missed something, but I always interpreted 
>the traditional CRL nextUpdate semantics to mean "if you 
>haven't gotten an new CRL by this time, you are potentially 
>missing something", not "I'm not going to have another 
>word to say on this subject until this time, even if the world 
>is about to come to an end."
>
>In other words, I believe that a CA (at least some CAs) 
>would feel that they are allowed, and perhaps even 
>compelled, to issue a CRL PRIOR to the time of the 
>nextUpdate, especially in the event of a known key 
>compromise. Certainly I would take my business elsewhere 
>if a CA or repository would not provide me that service.
>
>I haven't followed the OCSP discussion that closely, 
>I'm afraid, but surely the semantics haven't changed
>all that much?
>
>bob
>
>>>> "Michael Myers" <[email-masked]> 04/20 5:36 PM >>>
>Paul,
>
>One the primary reasons a CRL is signed in the first place is to relieve any
>repository containing them of security requirements.  A certificate
>processing system determines that a CRL is expired by examining nextUpdate.
>This value is protected by CA signature, not by presumptions of the
>functional correctness or assurances provided by the security architecture
>of the repository.
>
>If a repository provides an old CRL instead of a new CRL, then one of two
>cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
>with respect to the current system time of the certificate processing
>software or it isn't.  If it is, an exception condition should be raised.
>If not, the information in the old CRL is still reliable.
>
>Mike
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On Behalf
>> Of Paul Hoffman / IMC
>> Sent: Monday, April 20, 1998 3:11 PM
>> To: [email-masked] 
>> Subject: Security section of draft-ietf-pkix-opp-ftp-http
>>
>>
>> Russ' "how to get certs and CRLs over FTP and HTTP" draft seems fine, but
>> the Security section is incomplete. Specifically, it doesn't mention the
>> hidden security problems that HTTP proxy caches can introduce. I propose
>> that the following be added to the Security section:
>>
>> The HTTP 1.1 protocol specifically allows HTTP proxies to cache responses
>> for repeated requests for URLs. Although RFC 2068 carefully specifies how
>> HTTP proxies should work, there are many non-conformant proxies in use on
>> the Internet. A non-conformant HTTP proxy can have serious security
>> implications for requesting CRLs. If a new CRL is issued before the
>> nextUpdate time in a CRL, but an HTTP proxy incorrectly gives the
>> requestor
>> an older CRL, the requestor will get wrong revocation information and will
>> have no way of knowing that the information is out of date. CRL
>> distributors following this specification have no way of forcing
>> the latest
>> CRL through to a requestor.
>>
>>
>> --Paul Hoffman, Director
>> --Internet Mail Consortium
>>
>
>
>
>

Date: Tue, 21 Apr 1998 08:53:36 -0700
To: Marc Branchaud <[email-masked]>, "Pkix List (E-mail)" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: OCSP Response Values and Structure 
Sender: [email-masked]

Other values relevant to a given category, e.g. onHold and unknownCA for
revocationStatus.

At 06:29 PM 4/20/98 -0700, Marc Branchaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Content-Type: text/plain; charset=us-ascii
>
>
>"Michael Myers" <[email-masked]> scrawled:
>> 
>> In reviewing comments to date so that we can move forward on the OCSP
>> editing task,  the rough consensus appears to be as follows regarding OCSP
>> response structure:
>> 
>> revocationStatus     {revoked, notRevoked, . . . }
>> expirationStatus     {notYetValid, expired,  . . . }
>> issuedStatus         {issued, notIssued, . . . }
>> 
>
>What do the ellipses stand for?
>
>                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
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNTv2llrdFXNdDxPlAQF7GQMAjz+3rEbpbtnVkcCsz9BjjHvpPgEzjQRw
>bl2Nrco6xrbg3cH/dfRyCJhoNuzhBieqmgmZ+9itUpoJpPJ8aihLXF/B904YAQZ9
>F9Z5Qt1L3Nh5HeoFLPtBTYVhRWEvEl3/
>=x9Az
>-----END PGP SIGNATURE-----
>
>

Date: Tue, 21 Apr 1998 07:58:58 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

At 11:26 AM 4/21/98 +0300, Moshe Litvin wrote:
>The problem you describe is inherent to CRL and not to the distribution
>method.

I disagree. If I send a request to a CA for the latest CRL, and I might get
an old response if I use HTTP but am sure to get a current response if I
use FTP, then the problem is in the distribution method.

>If a CA issues a CRL before the nextUpdate there is no way it
>can make sure that all the relying parties will use it.

Correct.

>It can be
>because of a non-conformant HTTP proxy, a malicious HTTP proxy,  someone
>who managed to put write the old CRL back in the directory, or someone
>who managed to block the communication between the CA and the directory
>at the relevant time to the distribution of the new CRL.

All true, and they show the problem I'm addressing. If we have a protocol
for asking for a CRL (or OCSP response), and that protocol might return
out-of-date information, and the user has no way to know if it is out of
date, it is a security problem that needs to be discussed in the security
section of the relevant document. For protocols for which this won't
happen, we don't need to bring it up.

>It is a genuine problem but it's place is in PKIX part 1.

I don't think so. It only appears after a request from a user for the CRL,
and only appears in one protocol, HTTP (and only appears in broken
implementations of it, of which there are many). That is, the problem does
not appear until a requestor asks a CA for the latest CRL and gets
something different.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 21 Apr 1998 08:32:50 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

One assumption was that a CA acting as its own responder for OCSP would be able to give spontaneous certificate status even if that status was not yet reflected on a published CRL - kind of searching its pre-CRL building store or a database where status was linked to each cert.  In a case of a CA supporting OCSP-only, CRLs were not even necessary, since the status could be tied to each cert, for real-time responses and no need for ZCRL processing at all.  I do not know the status of that model.

Michael

>>> <[email-masked]> 04/21/98 02:41AM >>>
I get the feeling that we're somehow going in circles with this issue.

In order to solve the inherent problems with CRLs (off-line distribution),
OCSP was introduced. Now the relying party could check the status
of a certificate at any time by a direct question to the CA.

Why then bother with issuing of new CRLs before the old one has
expired? It doesn't sound wise to me. What legal implications will
that have given the situation where a relying party have accepted
a certificate on the basis of a current (but old) CRL? I would say that
this is also a policy issue.

And on top of this, I've also noted a new draft on how to cache OCSP
messages...

Will the circle (ever) be unbroken?

I'm afraid that we'll end up in a situation where every single information
exchanged on the Internet needs a time stamp.

Lars Johansson
Sweden Post

----------
[email-masked] wrote:
>
> At 04:36 PM 4/20/98 -0700, Michael Myers wrote:
> >One the primary reasons a CRL is signed in the first place is to relieve any
> >repository containing them of security requirements.  A certificate
> >processing system determines that a CRL is expired by examining nextUpdate.
> >This value is protected by CA signature, not by presumptions of the
> >functional correctness or assurances provided by the security architecture
> >of the repository.
>
> Absolutely true. And completely unrelated to the security issue I brought up.
>
> >If a repository provides an old CRL instead of a new CRL, then one of two
> >cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
> >with respect to the current system time of the certificate processing
> >software or it isn't.  If it is, an exception condition should be raised.
> >If not, the information in the old CRL is still reliable.
>
> Reliable, but probably incomplete. There are three cases, not just the two
> you describe. The third case, which I describe in my suggested wording for
> the draft, is that a CA has issued a new CRL at a time before the
> nextUpdate of the previous CRL. If the CA issued a new CRL before the
> nextUpdate time of the previous one, it is probably due to additions to the
> list. That is expressly allowed by PKIX part 1.
>
> Let me try this graphically:
>
> CRL(cRLNumber=42, thisUpdate=5/10/98, nextUpdate=6/10/98) has 300 
names on it.
> CRL(cRLNumber=43, thisUpdate=5/15/98, nextUpdate=6/10/98) has 310 
names on it.
>
> A bad HTTP proxy that has a request for the CRL has cached CRL 42. On
> 5/20/98, a request for the CRL comes in, and the proxy sends back CRL 42
> without checking with the main server. The requestor doesn't find the
> desired cert on the list and assumes it hasn't been revoked. However, that
> cert is among the 10 new certs on the list. The nextUpdate is in the
> future, so they have no reason to think that this CRL is stale.
>
> This situation has the same result as the requestor saying "hmm, since the
> nextUpdate on the CRL is in the future, I must have the current CRL," which
> is the wrong interpretation of nextUpdate, as we all know. It won't happen
> if the proxy cache does the right thing, or if there is no proxy cache, but
> if a bad proxy cache does this, there is absolutely no way for the
> requestor to find out about it. Thus, the security warning.
>
> And, yes, this is the same problem with OCSP responses in a bad proxy cache.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

Date: Tue, 21 Apr 1998 08:24:51 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Bob:

Isn't the off-schedule CRL considered a delta-CRL (even if it contains the complete set of records)?  If so, then doesn't the reply also have to include the last "full" CRL produced in its response as well?

If the "nextUpdate" can not be relied on for the next update, then its meaning is not to be relied on.

Michael

>>> "Bob Jueneman" <[email-masked]> 04/20/98 07:21PM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************

Date: Tue, 21 Apr 1998 12:14:42 +0200
From: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
To: pkix <[email-masked]>
Subject: Re: [IETF-PKIX] Subject/Issuer Name Population
Sender: [email-masked]

Tim Polk wrote:
> 
> I have attached proposed text for the issuer and subject name sections.
> 
> Highlights:
> 
> (1) issuer name is required (that is, may not be an empty SEQUENCE).
Do we need this or can we loosen it a little? I am thinking of CAs that
just have DNS name (which is also hierarchical and unique and thus
similar to a DN)? Should we say that the name should be globally unique
and that only on alternative name should be present if the DN is empty?

> (2) subject name is required for CA certs.  (This means you never chain off
> altnames!)
see above.

> (3) Name comparison rules are greatly relaxed from the X.520 text.  Binary
> comparison of attribute values is permitted for everything except
> PrintableString. That is, no white space compression or case conversion in
> BMP or UTF8.
> 
> (Rationale for PrintableString:  It has already been implemented, and is
> used in practically all certificates.  Upper and lowercase country codes,
> etc. will break if we don't support it.)
> 
> Please take the time to review the text.
Regarding the subject name in end entity certificates:

   Where it is non-null, the subject name field shall contain an X.500
   distinguished name (DN). The DN must be unique for each subject
   entity certified by the one CA as defined by the issuer name field.
   (A CA may issue more than one certificate with the same DN to the
   same subject entity.)

I think we should not make requirements for the DN stored in the subject
field, since too many implementations out there use the DN
(subject/issuer) with any kind of semantic they want.

Question:

Isn't the alternative name field "directoryName" the right place to
state that "This is a Distinguished Name in the X.500 sense, additional
information about the subject can be found here".

A different question:

Has anybody "real world" solutions for identifying subject of
certificate (i.e. end-entities). I am thinking of the following cases:

- a person with a company affiliation (most of X.500 seems to be fixed
on this).
Problems: Name ambiguities, do we give people a number...?

- a person with no company affiliation, but with place and date of
birth. While the generic attributes of DNames can be (somewhat hard)
pressed to store this kind of information, I do not think this is a
satisfactory solution

- a person with an address. Same problems as above.

- a person with an address and an addtional qualifier (such as medical
doctor).

The lowest common denominator between implementations usually is the
subject name (display to the user) and hopefully the PKIX alternative
names. So when specific application domains want to be compatible with
the generic PKIX structure, most of the information probably needs to go
into the subject name. So it is (other than in closed user groups) not
advisable to extend the alternative name construct to contain important
information.

Example:

We are working on a specification for certificates that are to be used
with the German Signature Law. The X.509 profile for this application
should be compatible with PKIX requirements (we are trying to do this).
This would allow people to use their Signature certificate with all
applications, especially electronic mail. This implies that PKIX
implementations should be able to verify signatures associated with SigG
(Signature Law) certificates.

Our solution so far is to give examples of how to construct the subject
Distinguished Name to contain the necessary attributes. The goal here is
that the information about the subject is similar to information used in
the physical world (i.e. street address). This information is - in the
technical sense - not unique (cannot be used as a DN in X.500). But for
all practical purposes, it is.

Andreas
-- 
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Date: Tue, 21 Apr 1998 11:40:54 +0200
From: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
To: pkix <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 08:48 AM 4/17/98 -0700, you wrote:
> >And in the event a client receives {is revoked, not issued}, which
> >dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
> >is no problem.
> 
> To the client, "not issued" is always more important than revoked or not
> revoked. We can put that in the OCSP spec.
> 
> >As soon as OCSP clients are out there in any volume, there
> >are those who will seek to determine the client's behavior in fringe cases.
> 
> I fully agree. That's why I'm I don't think that issued/not issued should
> be a MAY: I think it has to be a MUST. We can be sure that some clients
> will blow the comparison unless they are always told whether or not the
> cert was even issued.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
Paul, I disagree.

The issued/not issued flag can only be answered by a small set of OCSP
responders. Let's take - for example - a company that operates an OCSP
responder of some of the most frequently used CAs in the world. It load
their CRLs to reduce communication cost and offers these "CRLs on-line"
to the internal client software (thus lowering the maintainance cost to
distribute CRLs to all clients). Given a specific certificate, such an
OCSP responder can only answer the question of revocation (revoked/not
revoked) on the basis of the CRL (so revoked is: on the list, not
revoked is: not on the list).

So probably we need some kind of "don't know" of the OCSP responder.

Regarding the question above: when a certificate was "not issued" this
is a no-go for the verification process. I think that we could drop any
other answers if the certificate was never issued. This is different for
"issued: don't know" and "issued: yes".

Andreas
-- 
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

From: [email-masked]
Date: Tue, 21 Apr 1998 10:41:42 +0200
Subject: RE: Security section of draft-ietf-pkix-opp-ftp-http
TO: [email-masked], [email-masked]
Sender: [email-masked]

I get the feeling that we're somehow going in circles with this issue.

In order to solve the inherent problems with CRLs (off-line distribution),
OCSP was introduced. Now the relying party could check the status
of a certificate at any time by a direct question to the CA.

Why then bother with issuing of new CRLs before the old one has
expired? It doesn't sound wise to me. What legal implications will
that have given the situation where a relying party have accepted
a certificate on the basis of a current (but old) CRL? I would say that
this is also a policy issue.

And on top of this, I've also noted a new draft on how to cache OCSP
messages...

Will the circle (ever) be unbroken?

I'm afraid that we'll end up in a situation where every single information
exchanged on the Internet needs a time stamp.

Lars Johansson
Sweden Post

----------
[email-masked] wrote:
>
> At 04:36 PM 4/20/98 -0700, Michael Myers wrote:
> >One the primary reasons a CRL is signed in the first place is to relieve any
> >repository containing them of security requirements.  A certificate
> >processing system determines that a CRL is expired by examining nextUpdate.
> >This value is protected by CA signature, not by presumptions of the
> >functional correctness or assurances provided by the security architecture
> >of the repository.
>
> Absolutely true. And completely unrelated to the security issue I brought up.
>
> >If a repository provides an old CRL instead of a new CRL, then one of two
> >cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
> >with respect to the current system time of the certificate processing
> >software or it isn't.  If it is, an exception condition should be raised.
> >If not, the information in the old CRL is still reliable.
>
> Reliable, but probably incomplete. There are three cases, not just the two
> you describe. The third case, which I describe in my suggested wording for
> the draft, is that a CA has issued a new CRL at a time before the
> nextUpdate of the previous CRL. If the CA issued a new CRL before the
> nextUpdate time of the previous one, it is probably due to additions to the
> list. That is expressly allowed by PKIX part 1.
>
> Let me try this graphically:
>
> CRL(cRLNumber=42, thisUpdate=5/10/98, nextUpdate=6/10/98) has 300 
names on it.
> CRL(cRLNumber=43, thisUpdate=5/15/98, nextUpdate=6/10/98) has 310 
names on it.
>
> A bad HTTP proxy that has a request for the CRL has cached CRL 42. On
> 5/20/98, a request for the CRL comes in, and the proxy sends back CRL 42
> without checking with the main server. The requestor doesn't find the
> desired cert on the list and assumes it hasn't been revoked. However, that
> cert is among the 10 new certs on the list. The nextUpdate is in the
> future, so they have no reason to think that this CRL is stale.
>
> This situation has the same result as the requestor saying "hmm, since the
> nextUpdate on the CRL is in the future, I must have the current CRL," which
> is the wrong interpretation of nextUpdate, as we all know. It won't happen
> if the proxy cache does the right thing, or if there is no proxy cache, but
> if a bad proxy cache does this, there is absolutely no way for the
> requestor to find out about it. Thus, the security warning.
>
> And, yes, this is the same problem with OCSP responses in a bad proxy cache.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

Date: Tue, 21 Apr 1998 11:26:32 +0300
From: Moshe Litvin <[email-masked]>
To: [email-masked]
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Paul,

The problem you describe is inherent to CRL and not to the distribution
method. If a CA issues a CRL before the nextUpdate there is no way it
can make sure that all the relying parties will use it. It can be
because of a non-conformant HTTP proxy, a malicious HTTP proxy,  someone
who managed to put write the old CRL back in the directory, or someone
who managed to block the communication between the CA and the directory
at the relevant time to the distribution of the new CRL.

It is a genuine problem but it's place is in PKIX part 1.

Moshe

Paul Hoffman / IMC wrote:
> 
> Russ' "how to get certs and CRLs over FTP and HTTP" draft seems fine, but
> the Security section is incomplete. Specifically, it doesn't mention the
> hidden security problems that HTTP proxy caches can introduce. I propose
> that the following be added to the Security section:
> 
> The HTTP 1.1 protocol specifically allows HTTP proxies to cache responses
> for repeated requests for URLs. Although RFC 2068 carefully specifies how
> HTTP proxies should work, there are many non-conformant proxies in use on
> the Internet. A non-conformant HTTP proxy can have serious security
> implications for requesting CRLs. If a new CRL is issued before the
> nextUpdate time in a CRL, but an HTTP proxy incorrectly gives the requestor
> an older CRL, the requestor will get wrong revocation information and will
> have no way of knowing that the information is out of date. CRL
> distributors following this specification have no way of forcing the latest
> CRL through to a requestor.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

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

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

Date: Tue, 21 Apr 1998 10:03:21 +0300
From: Moshe Litvin <[email-masked]>
To: Ian Roberts <[email-masked]>
CC: [email-masked]
Subject: Re: [IETF-PKIX] Key Identifiers
Sender: [email-masked]

Robert,

A little math: Assume that we are talking about 512 bits RSA keys, the
number of prime number < n is about n/ln n. So the number of prime
number of 256 bits is about 2^256/ln 256 > 2^248. Even if we take only
the primes that are exactly 256 bits it is  > 2^246, which means that
the number of RSA keys of 512 bits is > 2^492. 

Now what are the chances of key collision?

Moshe

Ian Roberts wrote:
> 
> >From: [email-masked]
> >To: Ian Roberts
> >Subject: Re: [IETF-PKIX] Key Identifiers
> >Date: 20 April 1998 15:01
> >
> >>>>>> "Ian" == Ian Roberts <[email-masked]> writes:
> >
> > Ian> The discussion on Key Identifiers lead me down the following
> > Ian> chain of thought;
> >
> > Ian> If the Key Identifier is useful for building a path, then it
> > Ian> would be useful to be able to query a directory server for
> > Ian> certificates containing keys with a given key identifier.
> >
> > Ian> If directory servers become sufficiently large (for example, the
> > Ian> size of the Altavista search engine) then a lookup of a large
> > Ian> number of certificates by Key Identifier should be possible
> > Ian> within a couple of seconds (with many occurring concurrently).
> >
> > Ian> If the directory server contained 200 million certificates, then
> > Ian> a possible attack would be to generate key sets and then query
> > Ian> the directory server for matches.  This would give someone with
> > Ian> a fairly low-spec machine the ability to search several hundred
> > Ian> million keys per second.
> >
> >Ian,
> >
> >It sounds like you're thinking about some sort of attack on
> >something.  But I can't figure out what you're attacking and how.
> >
> >    paul
> >
> >
> 
> Sorry, from where I was standing it looked clear, but then these odd
> thoughts always do :-)
> 
> Conventional key search attacks focus a lot of CPU power toward cracking a
> single key set.  It is the cost of this CPU time that is the deterrent and
> hopefully stops low-budget individuals from using this method.
> 
> However, where someone has access to a large directory server, where
> certificate retrievals can be done by Key Identifier (where the key
> identifier is the SHA-1 hash of the public key), then a low power CPU can be
> use to generate key sets (slowly) and the key identifier, and then use the
> directory server to see if any certificates exist with the same Key
> Identifier - any which are found can then be compared for public key
> equality.  For any match you have then discovered the private key for that
> certificate.
> 
> This technique would not aid anyone in cracking a particular key, but could
> be used in an attempt to crack any key held in a directory.
> 
> For example
> 
> With a single budget PC you could generate a key set, say every 5 seconds,
> they can then use the directory server to see if that key set matches any of
> the (say) 200 million certificates on the server (on a server the size of
> Altavista, in a couple of seconds), thus they can in effect try 40 million
> keys per second, using someone else's CPU power.  The key identifier is not
> unique, but a check for quality of public would soon show if you have
> discovered someone's key set.
> 
> Hope this is clearer,
> 
> Ian Roberts
> 
> --
> Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
> Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
> Website:  http://www.zergo.com

Date: Mon, 20 Apr 1998 22:32:23 -0700 (PDT)
From: Surendra Reddy <[email-masked]>
To: [email-masked]
Subject: Web based Certificate Access Protocol - WebCAP
Sender: [email-masked]

I have submitted "Web based Certificate Access Protocol - WebCAP" as an
I-D. It is now available at 
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-webcap-00.txt. This
is a sketchy version and objective of this draft is to come up with
a single protocol that meets PKIX Certicate Management Protocol
requirements in highly scalable and distributed environment. 

All the work/discussions done on OCSP can be integrated
into this protocol and we can merge OCSP and WebCAP into a single
proposal.

My next version of this document will cover all aspects
of PKIX Certificate Management Protocol. 

- Surendra
.......................................................
Surendra K Reddy		phone:  +1(650) 506 5441
Development Manager		mobile: +1(650) 867 4757
Internet Applications Division  email(oracle): [email-masked]	
Oracle Corporation		email(inet)  : [email-masked]

To: "Pkix List (E-mail)" <[email-masked]>
Subject: Re: OCSP Response Values and Structure 
Date: Mon, 20 Apr 1998 18:29:58 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

"Michael Myers" <[email-masked]> scrawled:
> 
> In reviewing comments to date so that we can move forward on the OCSP
> editing task,  the rough consensus appears to be as follows regarding OCSP
> response structure:
> 
> revocationStatus     {revoked, notRevoked, . . . }
> expirationStatus     {notYetValid, expired,  . . . }
> issuedStatus         {issued, notIssued, . . . }
> 

What do the ellipses stand for?

                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

Date: Mon, 20 Apr 1998 19:21:16 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Michael, I'm not entirely sure I agree with your semantics.=20
Maybe I've missed something, but I always interpreted=20
the traditional CRL nextUpdate semantics to mean "if you=20
haven't gotten an new CRL by this time, you are potentially=20
missing something", not "I'm not going to have another=20
word to say on this subject until this time, even if the world=20
is about to come to an end."

In other words, I believe that a CA (at least some CAs)=20
would feel that they are allowed, and perhaps even=20
compelled, to issue a CRL PRIOR to the time of the=20
nextUpdate, especially in the event of a known key=20
compromise. Certainly I would take my business elsewhere=20
if a CA or repository would not provide me that service.

I haven't followed the OCSP discussion that closely,=20
I'm afraid, but surely the semantics haven't changed
all that much?

bob

>>> "Michael Myers" <[email-masked]> 04/20 5:36 PM >>>
Paul,

One the primary reasons a CRL is signed in the first place is to relieve =
any
repository containing them of security requirements.  A certificate
processing system determines that a CRL is expired by examining nextUpdate.=

This value is protected by CA signature, not by presumptions of the
functional correctness or assurances provided by the security architecture
of the repository.

If a repository provides an old CRL instead of a new CRL, then one of two
cases will occur.  Either the old CRL is expired (as defined by nextUpdate)=

with respect to the current system time of the certificate processing
software or it isn't.  If it is, an exception condition should be raised.
If not, the information in the old CRL is still reliable.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Paul Hoffman / IMC
> Sent: Monday, April 20, 1998 3:11 PM
> To: [email-masked]=20
> Subject: Security section of draft-ietf-pkix-opp-ftp-http
>
>
> Russ' "how to get certs and CRLs over FTP and HTTP" draft seems fine, =
but
> the Security section is incomplete. Specifically, it doesn't mention the
> hidden security problems that HTTP proxy caches can introduce. I propose
> that the following be added to the Security section:
>
> The HTTP 1.1 protocol specifically allows HTTP proxies to cache =
responses
> for repeated requests for URLs. Although RFC 2068 carefully specifies =
how
> HTTP proxies should work, there are many non-conformant proxies in use =
on
> the Internet. A non-conformant HTTP proxy can have serious security
> implications for requesting CRLs. If a new CRL is issued before the
> nextUpdate time in a CRL, but an HTTP proxy incorrectly gives the
> requestor
> an older CRL, the requestor will get wrong revocation information and =
will
> have no way of knowing that the information is out of date. CRL
> distributors following this specification have no way of forcing
> the latest
> CRL through to a requestor.
>
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

Date: Mon, 20 Apr 1998 17:25:51 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

At 04:36 PM 4/20/98 -0700, Michael Myers wrote:
>One the primary reasons a CRL is signed in the first place is to relieve any
>repository containing them of security requirements.  A certificate
>processing system determines that a CRL is expired by examining nextUpdate.
>This value is protected by CA signature, not by presumptions of the
>functional correctness or assurances provided by the security architecture
>of the repository.

Absolutely true. And completely unrelated to the security issue I brought up.

>If a repository provides an old CRL instead of a new CRL, then one of two
>cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
>with respect to the current system time of the certificate processing
>software or it isn't.  If it is, an exception condition should be raised.
>If not, the information in the old CRL is still reliable.

Reliable, but probably incomplete. There are three cases, not just the two
you describe. The third case, which I describe in my suggested wording for
the draft, is that a CA has issued a new CRL at a time before the
nextUpdate of the previous CRL. If the CA issued a new CRL before the
nextUpdate time of the previous one, it is probably due to additions to the
list. That is expressly allowed by PKIX part 1.

Let me try this graphically:

CRL(cRLNumber=42, thisUpdate=5/10/98, nextUpdate=6/10/98) has 300 names on it.
CRL(cRLNumber=43, thisUpdate=5/15/98, nextUpdate=6/10/98) has 310 names on it.

A bad HTTP proxy that has a request for the CRL has cached CRL 42. On
5/20/98, a request for the CRL comes in, and the proxy sends back CRL 42
without checking with the main server. The requestor doesn't find the
desired cert on the list and assumes it hasn't been revoked. However, that
cert is among the 10 new certs on the list. The nextUpdate is in the
future, so they have no reason to think that this CRL is stale.

This situation has the same result as the requestor saying "hmm, since the
nextUpdate on the CRL is in the future, I must have the current CRL," which
is the wrong interpretation of nextUpdate, as we all know. It won't happen
if the proxy cache does the right thing, or if there is no proxy cache, but
if a bad proxy cache does this, there is absolutely no way for the
requestor to find out about it. Thus, the security warning.

And, yes, this is the same problem with OCSP responses in a bad proxy cache.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Michael Myers" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, <[email-masked]>
Subject: RE: Security section of draft-ietf-pkix-opp-ftp-http
Date: Mon, 20 Apr 1998 16:36:12 -0700
Importance: Normal
Sender: [email-masked]

Paul,

One the primary reasons a CRL is signed in the first place is to relieve any
repository containing them of security requirements.  A certificate
processing system determines that a CRL is expired by examining nextUpdate.
This value is protected by CA signature, not by presumptions of the
functional correctness or assurances provided by the security architecture
of the repository.

If a repository provides an old CRL instead of a new CRL, then one of two
cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
with respect to the current system time of the certificate processing
software or it isn't.  If it is, an exception condition should be raised.
If not, the information in the old CRL is still reliable.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Paul Hoffman / IMC
> Sent: Monday, April 20, 1998 3:11 PM
> To: [email-masked]
> Subject: Security section of draft-ietf-pkix-opp-ftp-http
>
>
> Russ' "how to get certs and CRLs over FTP and HTTP" draft seems fine, but
> the Security section is incomplete. Specifically, it doesn't mention the
> hidden security problems that HTTP proxy caches can introduce. I propose
> that the following be added to the Security section:
>
> The HTTP 1.1 protocol specifically allows HTTP proxies to cache responses
> for repeated requests for URLs. Although RFC 2068 carefully specifies how
> HTTP proxies should work, there are many non-conformant proxies in use on
> the Internet. A non-conformant HTTP proxy can have serious security
> implications for requesting CRLs. If a new CRL is issued before the
> nextUpdate time in a CRL, but an HTTP proxy incorrectly gives the
> requestor
> an older CRL, the requestor will get wrong revocation information and will
> have no way of knowing that the information is out of date. CRL
> distributors following this specification have no way of forcing
> the latest
> CRL through to a requestor.
>
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

From: "Michael Myers" <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: OCSP Response Values and Structure
Date: Mon, 20 Apr 1998 16:14:04 -0700
Importance: Normal
Sender: [email-masked]

In reviewing comments to date so that we can move forward on the OCSP
editing task,  the rough consensus appears to be as follows regarding OCSP
response structure:

revocationStatus     {revoked, notRevoked, . . . }
expirationStatus     {notYetValid, expired,  . . . }
issuedStatus         {issued, notIssued, . . . }

Date: Mon, 20 Apr 1998 15:11:04 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Russ' "how to get certs and CRLs over FTP and HTTP" draft seems fine, but
the Security section is incomplete. Specifically, it doesn't mention the
hidden security problems that HTTP proxy caches can introduce. I propose
that the following be added to the Security section:

The HTTP 1.1 protocol specifically allows HTTP proxies to cache responses
for repeated requests for URLs. Although RFC 2068 carefully specifies how
HTTP proxies should work, there are many non-conformant proxies in use on
the Internet. A non-conformant HTTP proxy can have serious security
implications for requesting CRLs. If a new CRL is issued before the
nextUpdate time in a CRL, but an HTTP proxy incorrectly gives the requestor
an older CRL, the requestor will get wrong revocation information and will
have no way of knowing that the information is out of date. CRL
distributors following this specification have no way of forcing the latest
CRL through to a requestor.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject:  pkix subject \ issuer names and RFC2247
Date: Mon, 20 Apr 1998 14:27:35 -0700
Sender: [email-masked]

Dave,
Since we have a rfc which deals with using internet domain names within a
distinguished name, it would seem rather strange that a subsequent IETF
standard would exclude the use of this rfc on the grounds of what names the
ITU support. From my simple perspective all we have to do is add domain
component to the list of supported attributes in a general name.
Trevor

Date: Mon, 20 Apr 1998 13:45:42 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [IETF-PKIX] Key Identifiers
Sender: [email-masked]

Well, 3DES is considered extremely secure against exhaustive search, with =
only 2^128 bits of key. So 2^10124 bits would be one hell of a lot better!

It's more effective as a time waster at the server, unless, of course, a =
flaw in the key geneatin code generates non-random keys.

Bob

>>> Tony Bartoletti <[email-masked]> 04/20 11:59 AM >>>
At 11:02 AM 4/20/98 -0600, Bob Jueneman wrote:
>Ian,
>
>I assume that you are not attacking the public keys directly, but rather
hoping that someone used a poor random number generator in generating =
them?
 Even so, this siounds more like a denial of service attack than a
cryptanalytic attack.
>
>Bob=20

Bob,

I think Ian is saying that if one generates a key-pair, and given a Key-ID
is a hash or otherwise deterministic function of the public key, one could
query the universe of certified keys and perhaps, by chance, come across
a certificate (perhaps your certificate) with matching key-ID and public
key, and thereby deduce that they have your private key.

Personally, I believe (hope?) that the space of possible key-pairs is
so very large that even 200 million is a very minute fraction of the
space, too sparce to hope for a random match.  But then, I haven't done
the math yet.

I don't see the lookup as a denial of service, (it amazes me how search-
engines have done such efficient pre-indexing that they can quickly repond
with "1,254,867 documents matched you query.  Next 10 matches?")

Of course, if I have your private key, it is compromised.  So I could send
a signed "revoke this key" message to the CA.  I suppose that would be a
charitable form of denial of service.

___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

Date: Mon, 20 Apr 1998 10:59:03 -0700
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: [IETF-PKIX] Key Identifiers
Sender: [email-masked]

At 11:02 AM 4/20/98 -0600, Bob Jueneman wrote:
>Ian,
>
>I assume that you are not attacking the public keys directly, but rather
hoping that someone used a poor random number generator in generating them?
 Even so, this siounds more like a denial of service attack than a
cryptanalytic attack.
>
>Bob 

Bob,

I think Ian is saying that if one generates a key-pair, and given a Key-ID
is a hash or otherwise deterministic function of the public key, one could
query the universe of certified keys and perhaps, by chance, come across
a certificate (perhaps your certificate) with matching key-ID and public
key, and thereby deduce that they have your private key.

Personally, I believe (hope?) that the space of possible key-pairs is
so very large that even 200 million is a very minute fraction of the
space, too sparce to hope for a random match.  But then, I haven't done
the math yet.

I don't see the lookup as a denial of service, (it amazes me how search-
engines have done such efficient pre-indexing that they can quickly repond
with "1,254,867 documents matched you query.  Next 10 matches?")

Of course, if I have your private key, it is compromised.  So I could send
a signed "revoke this key" message to the CA.  I suppose that would be a
charitable form of denial of service.

___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

Date: Mon, 20 Apr 1998 11:02:45 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [IETF-PKIX] Key Identifiers
Sender: [email-masked]

Ian,

I assume that you are not attacking the public keys directly, but rather =
hoping that someone used a poor random number generator in generating =
them?  Even so, this siounds more like a denial of service attack than a =
cryptanalytic attack.

Bob=20

>>> Ian Roberts <[email-masked]> 04/20 10:21 AM >>>

>From: [email-masked]=20
>To: Ian Roberts
>Subject: Re: [IETF-PKIX] Key Identifiers
>Date: 20 April 1998 15:01
>
>>>>>> "Ian" =3D=3D Ian Roberts <[email-masked]> writes:
>
> Ian> The discussion on Key Identifiers lead me down the following
> Ian> chain of thought;
>
> Ian> If the Key Identifier is useful for building a path, then it
> Ian> would be useful to be able to query a directory server for
> Ian> certificates containing keys with a given key identifier.
>
> Ian> If directory servers become sufficiently large (for example, the
> Ian> size of the Altavista search engine) then a lookup of a large
> Ian> number of certificates by Key Identifier should be possible
> Ian> within a couple of seconds (with many occurring concurrently).
>
> Ian> If the directory server contained 200 million certificates, then
> Ian> a possible attack would be to generate key sets and then query
> Ian> the directory server for matches.  This would give someone with
> Ian> a fairly low-spec machine the ability to search several hundred
> Ian> million keys per second.
>
>Ian,
>
>It sounds like you're thinking about some sort of attack on
>something.  But I can't figure out what you're attacking and how.
>
>    paul
>
>

Sorry, from where I was standing it looked clear, but then these odd=20
thoughts always do :-)

Conventional key search attacks focus a lot of CPU power toward cracking =
a=20
single key set.  It is the cost of this CPU time that is the deterrent =
and=20
hopefully stops low-budget individuals from using this method.

However, where someone has access to a large directory server, where=20
certificate retrievals can be done by Key Identifier (where the key=20
identifier is the SHA-1 hash of the public key), then a low power CPU can =
be=20
use to generate key sets (slowly) and the key identifier, and then use =
the=20
directory server to see if any certificates exist with the same Key=20
Identifier - any which are found can then be compared for public key=20
equality.  For any match you have then discovered the private key for =
that=20
certificate.

This technique would not aid anyone in cracking a particular key, but =
could=20
be used in an attempt to crack any key held in a directory.

For example

With a single budget PC you could generate a key set, say every 5 =
seconds,=20
they can then use the directory server to see if that key set matches any =
of=20
the (say) 200 million certificates on the server (on a server the size =
of=20
Altavista, in a couple of seconds), thus they can in effect try 40 =
million=20
keys per second, using someone else's CPU power.  The key identifier is =
not=20
unique, but a check for quality of public would soon show if you have=20
discovered someone's key set.

Hope this is clearer,

Ian Roberts

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com=20

From: Ian Roberts <[email-masked]>
Date: Mon, 20 Apr 1998 17:02:09 +0000
To: [email-masked]
Subject: Certificate Paths
Sender: [email-masked]

When attempting to build a certificate path in order to validate a=20
certificate I am looking at the following approach

Given two sets, F, U where the initial state is F is the empty set and U=20
contains the certificate you wish to validate=2E

1) While U is not empty;

2) Select a Certificate, C,  from U=2E  Remove C from U and add to F=2E

3) Fetch all of the certificates belonging to the issuer (set P)

4) Reduce P by removing all certificates from P that are not valid in=20
themselves (date, key usage etc)=2E

5) Reduce P by removing all certificates from P that are already in F=2E

6) Reduce P to contain only those certificates which contain a public key=20
that verifies C=2E

7) Add P to U=2E

8) Wend=2E

If intersection of the set F with the set of explicitly trusted (usually=20
root CA) certificates is not empty then we were able to build one or more=20
validation path(s)=2E

I believe that this will work with cross certification=2E

Following the discussion on Key Identifiers I looked at optimising this=20
using key identifiers=2E

The most obvious solution is to include an additional Reduction of P

5b) If C contains a AuthorityKeyIdentifier, Reduce P by removing all=20
certificates which contain a KeyIdentifier which does not match=2E

This however does not address the comment Denis=2EPinkas@bull=2Enet made

>As said above, no verification of digital signature should be done
>before getting a full path=2E This saves signature checks (as requested by
>Paul Koning) without the need to overload the certificate by additional
>mandatory extensions (that take memory place when the certificate is
>stored in a smart card)=2E

since 6 would still require potentially spurious verifies=2E

All the other solutions I have looked at involve the fetching of=20
certificates which are not required by the solution above since deferring=20
(6) always has the potential to increase the size of P=2E  However,=20
certificate fetches (e=2Eg=2E via LDAP, approx 90ms to our local directory=20
server) may be more expensive than a verify (appox 20ms in our current=20
implementation)=2E

aberger@DARMSTADT=2EGMD=2EDE wrote:
> One question: Do we have an algorithm for a complete verification? There
> is one that describes how to verify an existing FC path, but do we have
> an algorithm on how to construct a path?

I agree that we need such an algorithm, however I think that it should be=20
expressed as simply as possible and optimizations be left to the implemento=
r=20
(they can decide if certificate fetches are more expensive than verifies)=2E

The algorithm above does not build a single path, it collects all=20
certificate from the subject up to all self-signed certificates that could=20
form valid paths (you can work back down from any trusted root certificate=20
in the final intersection  to build a path)=2E

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants=2E RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www=2Ezergo=2Ecom

Date: Mon, 20 Apr 1998 08:45:16 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: I-D ACTION:draft-ietf-pkix-ocsp-caching-00.txt
Sender: [email-masked]

[[It appears that the Internet Drafts editor does not have the right
mailing address
for the mailing list. So, I'm copying it here from the IETF-Announce list.
--Paul Hoffman]]

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ocsp-caching-00.txt
Date: Mon, 20 Apr 1998 09:48:26 -0400
Sender: [email-masked]
:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group 
of the IETF.

	Title		: Internet Public Key Infrastructure Caching the 
                          Online Certificate Status Protocol
	Author(s)	: M. Branchard
	Filename	: draft-ietf-pkix-ocsp-caching-00.txt
	Pages		: 27
	Date		: 17-Apr-98
	
   The Online Certificate Status Protocol [OCSP] specifies how a client
   process may obtain certificate status information online from a
   server.  In order for OCSP to scale beyond small communities of
   users, a method to cache certificate status information at
   intermediary servers is required.
 
   This document describes the requirements of and assumptions behind
   OCSP caching, and defines the mechanisms through which such caching
   can be accomplished.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ocsp-caching-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-caching-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: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ocsp-caching-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.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ocsp-caching-00.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-caching-00.txt>

From: Ian Roberts <[email-masked]>
Date: Mon, 20 Apr 1998 16:21:54 +0000
To: [email-masked]
Subject: Re: [IETF-PKIX] Key Identifiers
Sender: [email-masked]

>From: pkoning@xedia=2Ecom
>To: Ian Roberts
>Subject: Re: [IETF-PKIX] Key Identifiers
>Date: 20 April 1998 15:01
>
>>>>>> "Ian" =3D=3D Ian Roberts <iroberts@ZERGO=2ECOM> writes:
>
> Ian> The discussion on Key Identifiers lead me down the following
> Ian> chain of thought;
>
> Ian> If the Key Identifier is useful for building a path, then it
> Ian> would be useful to be able to query a directory server for
> Ian> certificates containing keys with a given key identifier=2E
>
> Ian> If directory servers become sufficiently large (for example, the
> Ian> size of the Altavista search engine) then a lookup of a large
> Ian> number of certificates by Key Identifier should be possible
> Ian> within a couple of seconds (with many occurring concurrently)=2E
>
> Ian> If the directory server contained 200 million certificates, then
> Ian> a possible attack would be to generate key sets and then query
> Ian> the directory server for matches=2E  This would give someone with
> Ian> a fairly low-spec machine the ability to search several hundred
> Ian> million keys per second=2E
>
>Ian,
>
>It sounds like you're thinking about some sort of attack on
>something=2E  But I can't figure out what you're attacking and how=2E
>
>    paul
>
>

Sorry, from where I was standing it looked clear, but then these odd=20
thoughts always do :-)

Conventional key search attacks focus a lot of CPU power toward cracking a=20
single key set=2E  It is the cost of this CPU time that is the deterrent an=
d=20
hopefully stops low-budget individuals from using this method=2E

However, where someone has access to a large directory server, where=20
certificate retrievals can be done by Key Identifier (where the key=20
identifier is the SHA-1 hash of the public key), then a low power CPU can b=
e=20
use to generate key sets (slowly) and the key identifier, and then use the=20
directory server to see if any certificates exist with the same Key=20
Identifier - any which are found can then be compared for public key=20
equality=2E  For any match you have then discovered the private key for tha=
t=20
certificate=2E

This technique would not aid anyone in cracking a particular key, but could=
=20
be used in an attempt to crack any key held in a directory=2E

For example

With a single budget PC you could generate a key set, say every 5 seconds,=20
they can then use the directory server to see if that key set matches any o=
f=20
the (say) 200 million certificates on the server (on a server the size of=20
Altavista, in a couple of seconds), thus they can in effect try 40 million=20
keys per second, using someone else's CPU power=2E  The key identifier is n=
ot=20
unique, but a check for quality of public would soon show if you have=20
discovered someone's key set=2E

Hope this is clearer,

Ian Roberts

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants=2E RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www=2Ezergo=2Ecom

Date: Mon, 20 Apr 1998 16:31:26 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Re: OCSP Status Information on a Certificate
Sender: [email-masked]

Slava,

Thanks for joining us.

(...)

> >  I fully agree. That's why I'm I don't think that issued/not issued
> >  should be a MAY: I think it has to be a MUST. We can be sure that 
> >  some clients will blow the comparison unless they are always told 
> >  whether or not the cert was even issued.

> Are we talking about fat OCSP client here ?
> Does the OCSP client in this case have full certificate chain ?
> Can we safely assume that fat OCSP client will need to verify signatures
> on the chain first, validity and other X509v3 constraints and only then
> submit OCSP request for status of every certificate in the chain ?

You are asking the right questions. 

> If this is so then, essentially, OCSP client is already in the possession
> of the well-formed certificate signed by the (indirectly or directly) 
> trusted CA key. In these circumstances receiving an anwer "not issued"
> may only mean that CA key is compromised and "unathorized" certificate 
> has been signed. But if someone has the CA key and can sign anything 
> with it (including "unathorized" certificates) then that someone can 
> also make sure that "unathorized" certificate has the same serial number
> as one of "authorized" and as long as we only send serial number to 
> identify a certificate in OCSP request the substitution of the 
> "authorized" cert with "unathorized" one will be unnoticed. This makes 
> "never issued" somewhat useless for fat OCSP clients.

> Is this reasoning wrong ?

The reasoning is correct. However I believe that your reasoning is also
valid for the other cases, i.e. I do not see how it is possible to take
a decision to accept a certificate without having that certificate in
hands, and as you correcly indicate you need anyway to verify signatures
on the chain first, validity and other X509v3 constraints. 

> Also since CA archiving capacity is always finite and we also talking
> about allowing "historical" OCSP queries "never issued" will have 
> to be replaced with "info unavailable" at least in some cases. This 
> further redices the value of "never issued" status.

 ... which is useless.

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

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: OCSP Relay
Date: Sat, 18 Apr 1998 11:25:04 -0700
Importance: Normal
Sender: [email-masked]

The assumption that an OCSP requestor is in possession of the certificate in
question potentially precludes chaining of requests.  Consider that it might
be useful to aggregate OCSP requests at the enterprise boundary.  Some of
those certificates may be internally issued, some externally issued.  In the
case of the latter, the corporate OCSP responder could issue a request to
the external CA to acquire that CA's signed response.

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of SGalperin
> Sent: Friday, April 17, 1998 10:54 AM
> To: [email-masked]
> Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
>
>
> In a message dated 98-04-17 12:31:04 EDT, you write:
>
> >
> >  At 08:48 AM 4/17/98 -0700, you wrote:
> >  >And in the event a client receives {is revoked, not issued}, which
> >  >dominates?  Similarly, {not revoked, not issued}.  I remain
> unconvinced
> > this
> >  >is no problem.
> >
> >  To the client, "not issued" is always more important than
> revoked or not
> >  revoked. We can put that in the OCSP spec.
> >
> >  >As soon as OCSP clients are out there in any volume, there
> >  >are those who will seek to determine the client's behavior in fringe
> cases.
> >
> >  I fully agree. That's why I'm I don't think that issued/not
> issued should
> >  be a MAY: I think it has to be a MUST. We can be sure that some clients
> >  will blow the comparison unless they are always told whether or not the
> >  cert was even issued.
> >
>
> Are we talking about fat OCSP client here ?
> Does the OCSP client in this case have full certificate chain ?
> Can we safely assume that fat OCSP client will need to verify
> signatures on
> the chain first, validity and other X509v3 constraints and only
> then submit
> OCSP request for status of every certificate in the chain ?
>
> If this is so then, essentially, OCSP client is already in the
> possession of
> the well-formed certificate signed by the (indirectly or
> directly) trusted CA
> key. In these circumstances receiving an anwer "not issued" may
> only mean that
> CA key is compromised and "unathorized" certificate has been
> signed. But if
> someone has the CA key and can sign anything with it (including
> "unathorized"
> certificates) then that someone can also make sure that "unathorized"
> certificate has the same serial number as one of "authorized" and
> as long as
> we only send serial number to identify a certificate in OCSP request the
> substitution of the "authorized" cert with "unathorized" one will be
> unnoticed. This makes "never issued" somewhat useless for fat
> OCSP clients.
>
> Is this reasoning wrong ?
>
> Also since CA archiving capacity is always finiteand we also talking about
> allowing "historical" OCSP queries "never issued" will have to be replaced
> with "info
> unavailable" at least in some cases. This further redices the
> value of "never
> issued" status.
>
> --Slava Galperin
>

From: "Pawluk, Jean" <[email-masked]>
To: [email-masked]
Subject: FW: Archives and IETF-PKIX handoff.
Date: Fri, 17 Apr 1998 20:45:42 -0500
Sender: [email-masked]

   Howdy to all,

> Now's my chance to finally say a few things on this about to this list
> besides who owns the strange
> email addresses causing so many list error messages.
> 
> I am happy to pass off ownership of this list to Paul and IMC and go
> on a well deserved combination
> of a business/vacation trip for a couple of weeks.
> 
> I have ALL of the archives for the past 2 years on my personal
> machines but since I'm leaving in
> an hour I ask that you co-operate with Paul and help him get the info
> he needs.If there are problems that take a while to figure out with
> the list to send both of us a message so that we can get any of these
> problems worked out.
> 
> Now that I'm not the list owner expect to hear a lot more from Tandem
> on IETF and PKIX,
> 
> Regards
> 
> Jeanne
> 
>  Jean Pawluk 
>  Manager,  Security and Directory Technology Products
>   
>  Tandem Computers,
>  10501 N. Tantau Avenue , Loc 201-1
>  Cupertino, California 95014-0728
>  
>  office (408) 285-2450    fax  (408) 285-2380  pager (408)699-5940    
>  [email-masked]  
> 
> 

Date: Fri, 17 Apr 1998 20:52:50 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: New location for the mailing list
Sender: [email-masked]

On behalf of the PKIX Co-Chairs and membership, let me take this
opportunity to express our appreciation to Tandem for all their volunteer
efforts over the past 4 years in hosting the ietf-pkix list.  They have
supported us well since the inception of the PKIX WG.  In particular, let
me thank Jeanne Pawluk for her efforts as the most recent list
administrator.  Supporting a list this size, with very limited resources,
is undoubtedly a major challenge and all to often a thankless effort.

At the same time, let me thank IMC and Paul Hoffman for volunteering to now
take over the list administration.  We greatly appreciate this gesture, and
thank Paul, in particular, for managing such a smooth transition.

Warwick

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

Date: Fri, 17 Apr 1998 17:37:04 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: You don't have to resubscribe
Sender: [email-masked]

Sorry for not being clearer in my earlier message: you do *not* need to
resubscribe. The sysadmin at Tandem got me the current list just before he
shut off subscription processing at Tandem. I had to massage the list (a
lot), but do not think I lost anyone. 

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 17 Apr 1998 17:07:04 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Filling in the archives
Sender: [email-masked]

If you've looked on <http://www.imc.org/ietf-pkix/>, you'll see that we
have the old archives kept by Tandem, which end on 9/15/97, and new ones
that were being kept by IMC starting 3/1/98. If you have an archive for all
of the dates between those, and you're quite sure that it is complete,
please send me a message (not on the list). I'd like to fill in the missing
messages and make the archive complete. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 17 Apr 1998 15:57:29 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New location for the mailing list
Sender: [email-masked]

Greetings, PKIX folk. Because of the many problems that the list has been
experiencing, the WG chairs have moved the PKIX mailing list to IMC. The
new address for messages for the mailing list is:
     [email-masked]

To subscribe and unsubscribe, send a message to:
     [email-masked]
with the single word "subscribe" or "unsubscribe" in the body of the
message. The mailing list is being run by Majordomo, if that means anything
to you.

There is a Web page for the mailing list at
<http://www.imc.org/ietf-pkix/>. We'll start working on getting a full
archive available soon.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Fri, 17 Apr 1998 14:01: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

I agree with David Kemp's analysis and take back my suggestion that
wasIssued be mandatory.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 17 Apr 1998 13:23:39 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
Comments: To: [email-masked], [email-masked]
To: [email-masked]

It would be desirable if keyIDs were globally unique, but that
isn't absolutely essential, and the addtional space required for a
full SHA-1 hash might not be worth it. Standard hash (classical sense)
table collision resolution techniques could be used.

Of course, if you are looking things up in a directory, insisting on
a globally uniq keyID would be very nice.

Bob

>>> Rich Ankney <[email-masked]> 04/17 12:28 PM >>>
Key IDs are only guaranteed to be unique within the given subject
name, not globally (see X.509 etc.).  If one uses the SHA-1 hash
of the public key, there's a good chance it's globally unique, but
use of the hash is not a requirement of PKIX.

Regards,
Rich

----------
> From: Ian Roberts <[email-masked]>
> To: [email-masked]
> Subject: Re: [IETF-PKIX] Key Identifiers
> Date: Friday, April 17, 1998 11:45 AM
>
> The discussion on Key Identifiers lead me down the following chain of
> thought;
>
> If the Key Identifier is useful for building a path, then it would be
useful
> to be able to query a directory server for certificates containing keys
with
> a given key identifier.
>
> If directory servers become sufficiently large (for example, the size of
the
> Altavista search engine) then a lookup of a large number of certificates
by
> Key Identifier should be possible within a couple of seconds (with many
> occurring concurrently).
>
> If the directory server contained 200 million certificates, then a
possible
> attack would be to generate key sets and then query the directory server
for
> matches.  This would give someone with a fairly low-spec machine the
ability
> to search several hundred million keys per second.
>
> Ian Roberts
> --
> Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
> Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
> Website:  http://www.zergo.com

Approved-By:  Russ Housley <[email-masked]>
Date:         Fri, 17 Apr 1998 14:40:51 -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: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

Steve:

I must disagree.  I do not think that it is a large burden to mandate the
issuer DN.  Client code is greatly simplified for applications if they are
present.

1.  Certificate path development.  In an environment where there is a
directory, DNs are very useful to obtain the certificates.  Given the
increasing iterest in LDAP, I expect more and more evironments to iclude
directoriy systems.

2.  CRLs.  If issuer DNs are included, the alternative name extension is
not required to determine if a particular certificate is being revoked.  If
DNs are not included, the issuer alt name plus the serial number need to be
checked.

3.  S/MIME v2 and S/MIME v3 both reference certificates by issuered DN plus
serial number.

4.  TLS also reference certificates by issuered DN plus serial number.

Perhaps none of these by itself is sufficient to mandate the presence of
issuer DN, but taken together, Ithik that they offer a strong argument.
Especially since it is not onerous for a CA.

Russ

At 07:02 PM 4/16/98 -0400, Stephen Kent wrote:
>Tim,
>
>>At 12:11 PM -0400 4/9/98, Tim Polk wrote:
>>>For those who weren't in the LA meeting, this proposal was requested by the
>>>S/MIME working group.  An empty issuer name wreaks general havoc with their
>>>protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
>>>an important consideration.
>>
>>I will point out that TLS (née SSL) has a similar requirement, as it uses a
>>list of Distinguished Names to specify supported CAs when requesting client
>>certificates.
>
>
>I think the problem we see here is that some applications have a legitimate
>interest in requiring DNs for issuers, but not all application share this
>need. Thus it may be inappropriate to rerquire that ALL PKIX certs contain
>an Issuer DN, rather than allowing a null Issuer DN if an IssuerAltName is
>present. Even in your example, its not clear that the list of CA names sent
>in SSL/TLS be DNs, other than for historic reasons.  TLS could choose to
>mandate use of GeneralNames for CAs in this context, as another minor
>deviation from SSL that would make it more general.
>
>Denis pointed out that use of the NameConstraints extension is problematic
>when the Issuer and Subject name types differ, although that problem might
>be mitigated.  What if we if we specify that a subjectAltName is validated
>against an IssuerAltName when both are present, and if the Subject name is
>null?  I do worry though that this might lead to confusion since the Issuer
>and IssuerAltName might differ under such circumstances.
>
>Steve
>

Approved-By:  Rich Ankney <[email-masked]>
Date:         Fri, 17 Apr 1998 14:28:43 -0400
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] Key Identifiers
To: [email-masked]

Key IDs are only guaranteed to be unique within the given subject
name, not globally (see X.509 etc.).  If one uses the SHA-1 hash
of the public key, there's a good chance it's globally unique, but
use of the hash is not a requirement of PKIX.

Regards,
Rich

----------
> From: Ian Roberts <[email-masked]>
> To: [email-masked]
> Subject: Re: [IETF-PKIX] Key Identifiers
> Date: Friday, April 17, 1998 11:45 AM
>
> The discussion on Key Identifiers lead me down the following chain of
> thought;
>
> If the Key Identifier is useful for building a path, then it would be
useful
> to be able to query a directory server for certificates containing keys
with
> a given key identifier.
>
> If directory servers become sufficiently large (for example, the size of
the
> Altavista search engine) then a lookup of a large number of certificates
by
> Key Identifier should be possible within a couple of seconds (with many
> occurring concurrently).
>
> If the directory server contained 200 million certificates, then a
possible
> attack would be to generate key sets and then query the directory server
for
> matches.  This would give someone with a fairly low-spec machine the
ability
> to search several hundred million keys per second.
>
> Ian Roberts
> --
> Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
> Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
> Website:  http://www.zergo.com

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 17 Apr 1998 14:19:20 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] pkix subject \ issuer names and RFC2247
To: [email-masked]

> From: Trevor Freeman <[email-masked]>
>
> In the list of attribute types for subject and issuer names, I do not see
> support for RFC2247. I think this needs to be added to the list of supported
> attributes.

Trevor,
I agree.

However, X.509 (and by extension, PKIX) has gone down the path of
defining and encouraging the use of GeneralName, instead of defining
and encouraging the use of DN attributes for the various name forms.

I don't know how successful you will be in reversing this trend,
but I wish you luck.

Dave Kemp

Approved-By: [email-masked]
Date:         Fri, 17 Apr 1998 10:44: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: Surendra Reddy <[email-masked]>
Subject:      [IETF-PKIX] PKIX - Operational Protocols through WebCAP
To: [email-masked]

I have just completed a simple/HTTP based Certificate Access
Protocol with XML encoding to transport service requests and
responses. This protocol is completely HTTP based and extensible
through XML DTDs. I am sending this as a ID. I am glad to invite
authors of HTTP/FTP operational protocol and OCSP documents
to be co-authors of this document, so that we can converge on
various issues that had already been discussed and resolved.

Here is an Abstract of this protocol draft:

                Web based Certificate Access Protocol
                Surendra Reddy([email-masked])

Abstract
   Web based Certificate Access Protocol is a set of extensions to HTTP/1.1
   with service requests as XML document DTDs.  WebCAP protocol provides a
   highly scalable and distributed architecture. Since HTTP is widely deployed
   protocol on the internet, deploying the PKI infrastructure
   on HTTP servers through WebCAP extensions provides more flexibility,
   all internet users can use it even if the site they belong has a
   firewall against intruders.  The WEBCAP provides some useful facilities
   for PKI; an information caching by both a proxy server and client software,
   a secure transport layer service for confidentiality, a flexible request
   forwarding which can be used in CA and CA communication.

   WebCAP protocol supports:

     o    registration - whereby a user establishes its identity to CA
          prior to that CA issuing a certificate or certificates for
          that user.

     o    initialization - initialization of necessary key materials
          into the client system.

     o    certification - issues certificates to a user's public key and
          returns that certificate to the client system

     o    revocation - performs certification revocation by authorized
          users.

     o    queries - supports basic queries for certificate retrieval,
          validation.

     o    cross certification - exchange information between CAs to
          establish a cross certifications.

   In HTTP/1.1, method parameter information was exclusively encoded in
   HTTP headers. Unlike HTTP/1.1, WebCAP, encodes method parameter
   information either in an Extensible Markup Language (XML) [Bray,
   Paoli, Sperberg-McQueen, 1998] request entity body, or in an HTTP
   header.  The use of XML to encode method parameters was motivated by
   the ability to add extra XML elements to existing structures,
   providing extensibility, and by XML's ability to encode information
   in ISO 10646 character sets, providing internationalization support.
   As a rule of thumb, parameters are encoded in XML entity bodies when
   they have unbounded length, or when they may be shown to a human
   user and hence require encoding in an ISO 10646 character set.
   Otherwise, parameters are encoded within HTTP headers.

   In addition to encoding method parameters, XML is used in WebCAP to
   encode the responses from methods, providing the extensibility and
   internationalization advantages of XML for method output, as well as
   input.

   The XML namespace extension is also used in this specification in order
   to allow for new XML elements to be added without fear of colliding with
   other element names.

.......................................................
Surendra K Reddy                phone:  +1(650) 506 5441
Development Manager             mobile: +1(650) 867 4757
Internet Applications Division  email(oracle): [email-masked]
Oracle Corporation              email(inet)  : [email-masked]

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Fri, 17 Apr 1998 10:56:36 -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: Trevor Freeman <[email-masked]>
Subject:      [IETF-PKIX] pkix subject \ issuer names and RFC2247
To: [email-masked]

In the list of attribute types for subject and issuer names, I do not see
support for RFC2247. I think this needs to be added to the list of supported
attributes.

Importance: Normal
Approved-By:  "S.Reddy Virtual Office" <[email-masked]>
Date:         Fri, 17 Apr 1998 10:59:29 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "S.Reddy Virtual Office" <[email-masked]>
Subject:      [IETF-PKIX] PKIX Operational protocols through WebCAP
To: [email-masked]

Date: 17 Apr 98 10:44:57 -0700
From: Surendra Reddy <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: PKIX - Operational Protocols through WebCAP

I have just completed a simple/HTTP based Certificate Access
Protocol with XML encoding to transport service requests and
responses. This protocol is completely HTTP based and extensible
through XML DTDs. I am sending this as a ID. I am glad to invite
authors of HTTP/FTP operational protocol and OCSP documents
to be co-authors of this document, so that we can converge on
various issues that had already been discussed and resolved.

Here is an Abstract of this protocol draft:

                Web based Certificate Access Protocol
                Surendra Reddy([email-masked])

Abstract
   Web based Certificate Access Protocol is a set of extensions to HTTP/1.1
   with service requests as XML document DTDs.  WebCAP protocol provides a
   highly scalable and distributed architecture. Since HTTP is widely
deployed
   protocol on the internet, deploying the PKI infrastructure
   on HTTP servers through WebCAP extensions provides more flexibility,
   all internet users can use it even if the site they belong has a
   firewall against intruders.  The WEBCAP provides some useful facilities
   for PKI; an information caching by both a proxy server and client
software,
   a secure transport layer service for confidentiality, a flexible request
   forwarding which can be used in CA and CA communication.

   WebCAP protocol supports:

     o    registration - whereby a user establishes its identity to CA
          prior to that CA issuing a certificate or certificates for
          that user.

     o    initialization - initialization of necessary key materials
          into the client system.

     o    certification - issues certificates to a user's public key and
          returns that certificate to the client system

     o    revocation - performs certification revocation by authorized
          users.

     o    queries - supports basic queries for certificate retrieval,
          validation.

     o    cross certification - exchange information between CAs to
          establish a cross certifications.

   In HTTP/1.1, method parameter information was exclusively encoded in
   HTTP headers. Unlike HTTP/1.1, WebCAP, encodes method parameter
   information either in an Extensible Markup Language (XML) [Bray,
   Paoli, Sperberg-McQueen, 1998] request entity body, or in an HTTP
   header.  The use of XML to encode method parameters was motivated by
   the ability to add extra XML elements to existing structures,
   providing extensibility, and by XML's ability to encode information
   in ISO 10646 character sets, providing internationalization support.
   As a rule of thumb, parameters are encoded in XML entity bodies when
   they have unbounded length, or when they may be shown to a human
   user and hence require encoding in an ISO 10646 character set.
   Otherwise, parameters are encoded within HTTP headers.

   In addition to encoding method parameters, XML is used in WebCAP to
   encode the responses from methods, providing the extensibility and
   internationalization advantages of XML for method output, as well as
   input.

   The XML namespace extension is also used in this specification in order
   to allow for new XML elements to be added without fear of colliding with
   other element names.

.......................................................
Surendra K Reddy                phone:  +1(650) 506 5441
Development Manager             mobile: +1(650) 867 4757
Internet Applications Division  email(oracle): [email-masked]
Oracle Corporation              email(inet)  : [email-masked]

Approved-By:  SGalperin <[email-masked]>
Date:         Fri, 17 Apr 1998 13:54:27 EDT
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: SGalperin <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

In a message dated 98-04-17 12:31:04 EDT, you write:

>
>  At 08:48 AM 4/17/98 -0700, you wrote:
>  >And in the event a client receives {is revoked, not issued}, which
>  >dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced
> this
>  >is no problem.
>
>  To the client, "not issued" is always more important than revoked or not
>  revoked. We can put that in the OCSP spec.
>
>  >As soon as OCSP clients are out there in any volume, there
>  >are those who will seek to determine the client's behavior in fringe
cases.
>
>  I fully agree. That's why I'm I don't think that issued/not issued should
>  be a MAY: I think it has to be a MUST. We can be sure that some clients
>  will blow the comparison unless they are always told whether or not the
>  cert was even issued.
>

Are we talking about fat OCSP client here ?
Does the OCSP client in this case have full certificate chain ?
Can we safely assume that fat OCSP client will need to verify signatures on
the chain first, validity and other X509v3 constraints and only then submit
OCSP request for status of every certificate in the chain ?

If this is so then, essentially, OCSP client is already in the possession of
the well-formed certificate signed by the (indirectly or directly) trusted CA
key. In these circumstances receiving an anwer "not issued" may only mean that
CA key is compromised and "unathorized" certificate has been signed. But if
someone has the CA key and can sign anything with it (including "unathorized"
certificates) then that someone can also make sure that "unathorized"
certificate has the same serial number as one of "authorized" and as long as
we only send serial number to identify a certificate in OCSP request the
substitution of the "authorized" cert with "unathorized" one will be
unnoticed. This makes "never issued" somewhat useless for fat OCSP clients.

Is this reasoning wrong ?

Also since CA archiving capacity is always finiteand we also talking about
allowing "historical" OCSP queries "never issued" will have to be replaced
with "info
unavailable" at least in some cases. This further redices the value of "never
issued" status.

--Slava Galperin

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Fri, 17 Apr 1998 10:52: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

Hi Paul,
    If a responder is working off CRLs, it can't tell whether a
certificate
was ever issued or not. So I would strongly oppose making issued a
mandatory field (except if you allow it to have a dontKnow value).

    Again, I do question why the client can't figure out for itself
whether
that certificate was issued or not.

Ambarish

Paul Hoffman / IMC wrote:
>
> At 08:48 AM 4/17/98 -0700, you wrote:
> >And in the event a client receives {is revoked, not issued}, which
> >dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
> >is no problem.
>
> To the client, "not issued" is always more important than revoked or not
> revoked. We can put that in the OCSP spec.
>
> >As soon as OCSP clients are out there in any volume, there
> >are those who will seek to determine the client's behavior in fringe cases.
>
> I fully agree. That's why I'm I don't think that issued/not issued should
> be a MAY: I think it has to be a MUST. We can be sure that some clients
> will blow the comparison unless they are always told whether or not the
> cert was even issued.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 17 Apr 1998 13:31: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
>
> To the client, "not issued" is always more important than revoked or not
> revoked. We can put that in the OCSP spec.
>
> >As soon as OCSP clients are out there in any volume, there
> >are those who will seek to determine the client's behavior in fringe cases.
>
> I fully agree. That's why I'm I don't think that issued/not issued should
> be a MAY: I think it has to be a MUST. We can be sure that some clients
> will blow the comparison unless they are always told whether or not the
> cert was even issued.

I disagree that an Issued bit should be a MUST.  For that matter, I
don't see that it even needs to be a MAY in OCSP, but others seem to
want it for some reason.

If you have a certificate for which the signature verifies, you have
prima facie evidence that:
  1) the certificate was issued, or
  2) the CA's private key was compromised, or
  3) the signature algorithm is broken.
In the latter two cases, all bets are off and OCSP isn't going to
help -- why would you trust a signed OCSP response any more than a
signed certificate?
In the first case, you know the answer before you even ask the
question.

If you have a certificate for which the signature does not verify,
what are you going to do with it, regardless of OCSP's claim that
it has or has not been issued?

And if you don't have a certificate and are just trolling the OCSP
server by issuer/serial, subject name, or some other search criteria,
why should it feel obliged to disclose which guesses are valid?

Dave Kemp

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 17 Apr 1998 12:54:32 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

> From: Michael Myers <[email-masked]>
>
> And in the event a client receives {is revoked, not issued}, which
> dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
> is no problem.  As soon as OCSP clients are out there in any volume, there
> are those who will seek to determine the client's behavior in fringe cases.

No doubt.  But I don't see dominance of one bit over the other as an
issue.  I'd suggest that clients treat the responses as follows:

Revoked  Issued   Valid?
-------  ------   ------
  F        n/a    Accept
  F        T      Accept
  F        F      Reject

  T        n/a    Reject
  T        T      Reject
  T        F      Reject

In other words, a certificate which is revoked is rejected, and
a certificate which was never issued is rejected.  Sound reasonable?

If the Issued bit is always present (not OPTIONAL in the ASN.1), then
OCSP responders which do not support the Issued function should set the
bit to True.  If the bit is OPTIONAL, then the responder is able to
report Issued, Not-issued, or don't-know.

I don't have a preference for whether the don't-know state is supported
in the OCSP syntax, since Issued is not used at all as an input to the
X.509 and PKIX path validation function.

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Fri, 17 Apr 1998 09:52: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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

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

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

Michael Myers <[email-masked]> scrawled:
>
> And in the event a client receives {is revoked, not issued}, which

I think you mean {is revoked, issued} here...

> dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
> is no problem.  As soon as OCSP clients are out there in any volume, there
> are those who will seek to determine the client's behavior in fringe cases.
>

I agree that the implications are not trivial.  For one thing, as I've said,
a responder working solely with CRL information can not determine a
certificate's existance if the cert has not been revoked.  One bit is not
enough to capture the semantics.

                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, 17 Apr 1998 10:39:54 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
Comments: To: [email-masked]
To: [email-masked]

I haven't been following this thread in minute detail, but I wanted to
mention one thought, to see how it fits.

I'm going to suggest that we provide THREE type of certificate/key identifiers:
(1) a short hash of the key as a keyID, AND
(2) a URI to the issuer's certificate repository, where the
subject's certificate  can be found, AND
(3) a certificate serial number or other pointer to the exact certificate
within that repository.

DISCUSSION:

About a month ago, I proposed an algorithm for processing certs
in a cross-certified envionment that involved both a top-down and
bottom-up search.

In order to be precise about the terminology, I'll assume two
domains -- the relying party's domain (R), and the signer's domain (S).

The signer's domain, S, is a conventional hiearchy, with a top
level CA whose certificate is self-signed.  Importantly, the chain
from the TLCA to the signer's own certificate works in both
directions, from Issuer to Subject top-down, and from Subject to
Issuer, bottom-up, using whatever naming, keyID, serial, etc.,
conventions we choose to implement.  In particular, I am
assuming that it is possible to start with the signer's certificate
and actually FIND all of the rest of the certificates in the signer's
chain, all the way to the top, using some kind of certificate locator
that is similar to the now deprecated CRL distribution point scheme,
i.e., a URI that is contained within each certificate that points to
the location of the Issuer's certificate, via LDAP, HTTP, or whatever.

The relying party's domain is constructed similarly.  However, the RP
already know the TLCA in his domain, and can reasonably process all
(or at least most) of the certificates issued by his TLCA on a top-down
basis, as they are received, perhaps using a local directory or cache.

Now, somewhere between the top and the bottom of the RP's chain, there
exists one or more unidirectional cross-certificates to some CA in the signer's
domain.  The trick is to discover and process it.

To do this, the RP examines the signer's digital signature to see if he
recognizes that key. If so, it was already in his directory/cache of
known keys/certificates, and the first part of the process is done.

If not, he finds the signer's certificate somehow, perhaps from an explicit
link in S/MIME or other container, and he can now provisionally validate
the signer's signature. Then he checks the public key of the Issuer (ifthat is
identified somehow) to see if he recognizes that key, and if he does the first
of the process is complete.  In this manner, the RP steadily climbs the
SIGNER's certificate chain, searching for a key he recognizes. If he hits the
TLCA in the signer's chain and still hasn't recognized a key he trusts, then
the digital signature does not validate, and the singer's certificate is rejected.

However, if the key was recognized, it was presumably because of the
existence of the cross-certificate, which contaid the same public key as
that contained in a certificate issued by a CA in the signer's domain.

O course this process can be carried out locally, without any clues being
contained in the certificate itself as to a keyID or hash of the key used to sign
the certificate, i.e., the Issuer's key, but equally obviously the process could
be facilitated if these kints were already present.  In particular, since the public
key of the issuer isn't contained in the subject's certificate, but only the digital
signature that is based on it, without a keyID of some sort it would be
necessary to jump up a level in the signer's chain in order to identify the
key, and then search for that key in the local directory or cache.

In order to make this process work in the cross-certified case, it has to be
an identifier that is associated with the key itself. Something like certIssuerName
and certSerial won't work, because that is tied to the certificate, not to the key.
so we need a keyID, probably a hash of the key.  However, the hash
doesn't have to be a full MD-5 or SHA-1 message digerst -- it would be more than
good enough to use even a 16 bit hash, followed by standard hash table
collision procedures to resolve which key it really was.

On the other hand, we've been through discussions ad nauseam about the
possibility of having two certificates within a given domain with the same
key. Maybe it matters and maybe it doesn't matter -- I don't want to rat hole
on that discussion again -- but in any case it would probably be desirable to have
a unique indicator for what certificate was intended as well.

to recap, therfore, what I am suggesting, is that we need a
short hash of the key as a keyID, AND a uri to the issuer's
certificate repository, AND a certificate serial number or
other pointer to the exact certificate within that repository.

Bob

>Andreas, Tim, John, Peter, Kevin and Paul,
>
>Let me jump into this thread. I will use the E-mail from Andreas to
>comment but will attempt to address the other E-mails as well.
>
>Generally speaking, I do not support the idea of making the
>AuthorityKeyidentifier or the keyidentifier mandatory. It might even be
>better to deprecate its use. After this initial statement let us see the
>details.
>
>> Some comments on the key identifier / authority identifier issue that
>> was recently discussed on this list:
>>
>> Let's assume I have a certificate of someone on my system that is about
>> to be verified. Usually I would begin by retrieving all certificates of
>> authority described by the issuer and the issuer alternative name (the
>> exact process is outside the scope of this discussion). The result is a
>> set of certificates.
>
>This might be one way to proceed, but I see another way. Basically we
>have not defined a way to walk *up* a path or *down* a path. We might
>need to define one. You suggest to walk UP a path while I would suggest
>to walk DOWN a path. You have some trust points and the question is
>whether you can, from one of these trust points go DOWN to the
>certificate you want to verify. In this way you may make sure that
>naming is unambiguous from the trust point and you may apply naming
>constraints. Otherwise, you can't do it easily.
>
>The reality is that for discovering a path, you might have to walk up
>and down, but the verification should only be done "walking down". This
>means that no digital signature verification should be done before
>getting one or more candidate paths down.
>
>> Now I have to find out, which Authority Certificate was used to sign the
>> User Certificate I am currently holding. I can do this by using all
>> public keys in the Authority Certificates an trying to verify the User
>> Certificate's signature. For any attempt that fails, I can rule out all
>> Authority Certificates which contain the same public key that I have
>> just tried. This process leaves me with a set of certificates which all
>> contain the same public key and this key was used to sign the User
>> Certificate. Key Identifiers can help me with this process so that I do
>> not have to make a series of signature verifications, those a reduced to
>> an octet string comparison. Question: is it worth the effort to save
>> these verification steps? How many different public keys do we expect a
>> CA to have? more that a handful (let's say 10)? Only if the number of
>> keys held by the same CA is large the key identifier will help.
>
>As said above, no verification of digital signature should be done
>before getting a full path. This saves signature checks (as requested by
>Paul Koning) without the need to overload the certificate by additional
>mandatory extensions (that take memory place when the certificate is
>stored in a smart card).
>
>> Now for the Authority Identifier. Again, I am at the point where I have
>> just retrieved the set of certificates. Given the issuer and serial of
>> the signing authority for that CA, I can quickly identify the single
>> certificate that should be used for verification. In fact, it is would
>> be possible to retrieve just this single certificate and not retrieving
>> the complete set.
>>
>> I have one problem with this approach: The verification path is not
>> fixed. Let us assume a CA gets certified by a set of other CAs. Some
>> users trust one of them, others some other CAs (which is why the CA
>> probably got this multiple certificates). When a user certificate
>> contains a reference to a single other CA, a user which does not trust a
>> specific CA will fail to verify the certificate, although there might be
>> a another path which would lead to a successful verification.
>
>I support this comment. This means that placing the key identifier will
>create failures in cases where successful verification could have be
>done applying a different approach.
>
>There are additional problems if we keep the keyidentifier that have not
>been mentioned. The key of a CA is supposed to change, let us say every
>two years. We have left undefined the strategy to adopt when the CA
>changes its key. There are two possibilities: the validity period of the
>CA keys overlap during let us say 6 months or there are contiguous. The
>later case is not very nice if a user wants to register one week prior
>the expiration of the CA key, since two certificates will have to be
>provided to him during a two weeks period. For the first case, we will
>have two certificates signing keys for the same CA during 6 months and
>the question is to know which one to use. Some people are going to say:
>use the key identifier. However there is another solution that does not
>mandate the use of the key identifier. Comparing the date "not before"
>of the user certificate with the date "not before" of the CA certificate
>(or self-signed certificate when we end-up to a point of trust) allows
>to make the difference.
>
>Remember what 4.2.1.1 currently says about the Authority key identifier:
>" This extension would be used where an issuer has multiple signing keys
>(either due to multiple concurrent key pairs or due to changeover)."
>
>> This situation can be solved, if we define that: an application may
>> first try the specific certificate defined and then defaults back to the
>> "try and search" algorithm.
>>
>> One question: Do we have an algorithm for a complete verification? There
>> is one that describes how to verify an existing FC path, but do we have
>> an algorithm on how to construct a path?
>
>We currently don't and we probably should define one.
>
>> Shouldn't the path be constructed and verified from bottom up?
>
>I would rephrase the sentence as:
>
>Shouldn't the candidate paths be constructed forwards and backwards and
>then verified from the top to the bottom ?
>
>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

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:  Paul Hoffman / IMC <[email-masked]>
Date:         Fri, 17 Apr 1998 09:29: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

At 08:48 AM 4/17/98 -0700, you wrote:
>And in the event a client receives {is revoked, not issued}, which
>dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
>is no problem.

To the client, "not issued" is always more important than revoked or not
revoked. We can put that in the OCSP spec.

>As soon as OCSP clients are out there in any volume, there
>are those who will seek to determine the client's behavior in fringe cases.

I fully agree. That's why I'm I don't think that issued/not issued should
be a MAY: I think it has to be a MUST. We can be sure that some clients
will blow the comparison unless they are always told whether or not the
cert was even issued.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Fri, 17 Apr 1998 09:22:10 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

All:

Tim has done a marvelous job of wording these sections. I believe that this
will lead to less confusion on implementor's parts and will get us a very
high level of interoperability in cert chaining.

I agree with all the new wording, but would propose a small change to one
part of the new 4.2.1.4 to make it clearer. Where it now says:

      (b) attribute values in string types other than PrintableString
      are case sensitive (this permits matching of attribute values as
      binary objects);

change to:

      (b) attribute values in string types other than PrintableString
      are matched as binary objects;

I propose this change because BMPString and UTF8String also have the
concept of "spaces", and someone reading Tim's version would wonder whether
or not to do the kind of space elimination mandated for PrintableString in
(d) later in the list. My suggested wording says "don't touch it at all,
compare as is".

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Sean Turner <[email-masked]>
Date:         Fri, 17 Apr 1998 12:18:46 -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: Sean Turner <[email-masked]>
Organization: IECA, Inc.
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Ian,

X.509 defines a matching rule for use in the directory to search for certs based on the following fields:

Serial Number, Issuer, Subject Key Identifier, Authority Key Identifier, Validity Period, Private Key Validity, Subject Public Key Algorithm Identifier, Key Usage, Subject Alternative Name, Certificate policy, and Path to Name.

Cheers,

Ian Roberts wrote:
>
> The discussion on Key Identifiers lead me down the following chain of
> thought;
>
> If the Key Identifier is useful for building a path, then it would be useful
> to be able to query a directory server for certificates containing keys with
> a given key identifier.
>
> If directory servers become sufficiently large (for example, the size of the
> Altavista search engine) then a lookup of a large number of certificates by
> Key Identifier should be possible within a couple of seconds (with many
> occurring concurrently).
>
> If the directory server contained 200 million certificates, then a possible
> attack would be to generate key sets and then query the directory server for
> matches.  This would give someone with a fairly low-spec machine the ability
> to search several hundred million keys per second.
>
> Ian Roberts
> --
> Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
> Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
> Website:  http://www.zergo.com

--
Sean Turner - IECA, Inc.

Importance: Normal
Approved-By:  Michael Myers <[email-masked]>
Date:         Fri, 17 Apr 1998 08:48:15 -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 Status Information on a Certificate
To: [email-masked]

And in the event a client receives {is revoked, not issued}, which
dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
is no problem.  As soon as OCSP clients are out there in any volume, there
are those who will seek to determine the client's behavior in fringe cases.

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of David P. Kemp
> Sent: Friday, April 17, 1998 8:14 AM
> To: [email-masked]
> Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
>
>
> > From: Denis Pinkas <[email-masked]>
> >
> > More exactly:
> >
> > it MUST issue one booolean  : certificate is revoked / is not revoked
> > it MAY issue another boolean: certificate was issued / was not issued
>
>
> I agree with Denis.
>

Approved-By: [email-masked]
Date:         Fri, 17 Apr 1998 10:27:05 -0400
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-opp-ftp-http-03.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
                          Operational Protocols: FTP and HTTP
        Author(s)       : R. Housley
        Filename        : draft-ietf-pkix-opp-ftp-http-03.txt
        Pages           : 5
        Date            : 16-Apr-98

 The protocol conventions described in this document satisfy some of
 the operational requirements of the Internet Public Key
 Infrastructure (PKI). This document specifies the conventions for
 using the File Transfer Protocol (FTP) and the Hypertext Transfer
 Protocol (HTTP) to obtain certificates and certificate revocation
 lists (CRLs) from PKI repositories. Additional mechanisms addressing
 PKIX operational requirements are specified in separate documents.

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

Internet-Drafts are available by anonymous FTP.  Login 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-opp-ftp-http-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-opp-ftp-http-03.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: ftp.ietf.org

        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:      [email-masked].  In the body type:
        "FILE /internet-drafts/draft-ietf-pkix-opp-ftp-http-03.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-opp-ftp-http-03.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-pkix-opp-ftp-http-03.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--OtherAccess--

--NextPart--

Importance: Normal
Approved-By:  Michael Myers <[email-masked]>
Date:         Fri, 17 Apr 1998 08:42: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 at IETF
To: [email-masked]

I agree.  In fact, I had some archive language in an earlier draft.  So
shall it be written--as an optional extension.

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of Jeff Weinstein
> Sent: Friday, April 17, 1998 1:58 AM
> To: [email-masked]
> Subject: Re: [IETF-PKIX] OCSP at IETF
>
>
> I strongly agree with Stephen on this.  One great value that OCSP
> services could add would be to provide historical as well as current
> revocation information.
>
>         --Jeff
>
> Stephen Farrell wrote:
> >
> > Hi Mike,
> >
> > Not sure if this needs a change, but...
> >
> > Part 1 now has a time input to the cert validation
> > algorithm (the time at which the cert should have been/be
> > valid).
> >
> > If OCSP is to fit seamlessly into this algorithm then you'll
> > need an extension to the request so that the response doesn't
> > refer to the current time, but to the time which was input
> > to the cert validation alg.
> >
> > Regards,
> > Stephen.
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 17 Apr 1998 11:14:02 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

> From: Denis Pinkas <[email-masked]>
>
> More exactly:
>
> it MUST issue one booolean  : certificate is revoked / is not revoked
> it MAY issue another boolean: certificate was issued / was not issued

I agree with Denis.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 17 Apr 1998 11:09:58 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

> From: Denis Pinkas <[email-masked]>
>
> The reality is that for discovering a path, you might have to walk up
> and down, but the verification should only be done "walking down". This
> means that no digital signature verification should be done before
> getting one or more candidate paths down.

Part 1 Section 6 states that conforming implementations must perform
path validation in a manner which achieves identical results to the
given procedure, which takes as input a full cert path and works
from top to bottom.

But I don't see how following this procedure saves on signature
computations:  for every point at which there is a choice of issuers,
you need a disambiguator.  That is either a signature verification or
something which gives a shortcut answer without ever giving a false
reject.  Heuristics such as validity checking (against the target date
only, NOT for issuer-subject validity nesting!) might help in a very
few cases.  AuthorityKeyIdentifier will allow you to reject all
inappropriate candidates, but it takes up space in the certs, as you
say.  Another, more radical, approach would be to define new
AlgorithmOIDs which include a one octet checkword in the signature
value, which could be compared against a specific high-entropy octet of
the authority public key.  This would eliminate 255/256 of the
unnecessary signature verifications.  NB: I'm not advocating this
approach, just using it as an illustration of a hack which could
improve pathbuilding efficiency without costing much space.

> > I have one problem with this approach: The verification path is not
> > fixed. Let us assume a CA gets certified by a set of other CAs. Some
> > users trust one of them, others some other CAs (which is why the CA
> > probably got this multiple certificates). When a user certificate
> > contains a reference to a single other CA, a user which does not trust a
> > specific CA will fail to verify the certificate, although there might be
> > a another path which would lead to a successful verification.
>
> I support this comment. This means that placing the key identifier will
> create failures in cases where successful verification could have be
> done applying a different approach.

I don't understand this comment.  If an entity has a certificate signed
by a particular issuer, that certificate will have the identifier of that
issuer's key.  A certificate from a different issuer will have a different
key identifier.  In what case will a key identifier cause a reject where
the signature would otherwise have verified correctly?

> > One question: Do we have an algorithm for a complete verification? There
> > is one that describes how to verify an existing FC path, but do we have
> > an algorithm on how to construct a path?
>
> We currently don't and we probably should define one.

Yes.  Santosh?

Dave Kemp

Approved-By:  Ian Roberts <[email-masked]>
Date:         Fri, 17 Apr 1998 15:45:26 +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: Ian Roberts <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

The discussion on Key Identifiers lead me down the following chain of
thought;

If the Key Identifier is useful for building a path, then it would be useful
to be able to query a directory server for certificates containing keys with
a given key identifier.

If directory servers become sufficiently large (for example, the size of the
Altavista search engine) then a lookup of a large number of certificates by
Key Identifier should be possible within a couple of seconds (with many
occurring concurrently).

If the directory server contained 200 million certificates, then a possible
attack would be to generate key sets and then query the directory server for
matches.  This would give someone with a fairly low-spec machine the ability
to search several hundred million keys per second.

Ian Roberts
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com

Approved-By:  Tim Polk <[email-masked]>
Date:         Fri, 17 Apr 1998 10:42:00 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

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

I have attached proposed text for the issuer and subject name sections.

Highlights:

(1) issuer name is required (that is, may not be an empty SEQUENCE).
(2) subject name is required for CA certs.  (This means you never chain off
altnames!)
(3) Name comparison rules are greatly relaxed from the X.520 text.  Binary
comparison of attribute values is permitted for everything except
PrintableString. That is, no white space compression or case conversion in
BMP or UTF8.

(Rationale for PrintableString:  It has already been implemented, and is
used in practically all certificates.  Upper and lowercase country codes,
etc. will break if we don't support it.)

Please take the time to review the text.
--=====================_892838520==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="name_text.txt"

4.1.2.4  Issuer Name

   The issuer name identifies the entity who has signed (and issued the
   certificate).  The issuer identity must be carried in the issuer name
   field. The issuer name field shall contain an X.500 distinguished
   name (DN).  The issuer field is defined as the X.501 type Name.  Name
   is defined by the following ASN.1 structures:

   Name ::= CHOICE {
     RDNSequence }

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   RelativeDistinguishedName ::=
     SET OF AttributeTypeAndValue

   AttributeTypeAndValue ::= SEQUENCE {
     type     AttributeType,
     value    AttributeValue }

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY DEFINED BY AttributeType

   DirectoryString ::= CHOICE {
         teletexString           TeletexString (SIZE (1..MAX)),
         printableString         PrintableString (SIZE (1..MAX)),
         universalString         UniversalString (SIZE (1..MAX)),
         utf8String              UTF8String (SIZE (1.. MAX)),
         bmpString               BMPString (SIZE (1..MAX))        }

   The Name describes a hierarchical name composed of attributes, such
   as country name, and corresponding values, such as US.  The type of
   the component AttributeValue is determined by the AttributeType; in
   general it will be a DirectoryString.

   The DirectoryString type is defined as a choice of PrintableString,
   TeletexString, BMPString UTF8String and UniversalString.  When creat-
   ing a distinguished name, including their own, conforming CAs shall
   choose from these options as follows:

      (a) if the character set is sufficient, the string will be
      represented as a PrintableString;

      (b) failing (a), if the BMPString character set is sufficient the
      string shall be represented as a BMPString; and

      (c) failing (a) and (b), the string shall be represented as a
      UTF8String.

   The TeletexString and UniversalString are included for backward com-
   patibility, and should not be used for certificates for new subjects.
   However, these types may be used in certificates where the name was
   previously established.  Certificate users should be prepared to
   receive certificates with these string types.

   Standard sets of attributes have been defined in the X.500 series of
   specifications.  Where CAs issue certificates with X.501 type names,
   it is recommended that these attributes types be used.

   Certificate users must be prepared to process the issuer dis-
   tinguished name and subject distinguished name (Section 4.1.2.6)
   fields to perform name chaining for certification path validation
   (see Section 7.) Name chaining is performed by matching the issuer
   distinguished name in one certificate with the subject name in
   another.

   This specification requires only a subset of the name comparison
   functionality specified in X.501. The requirements for conforming
   implementations are as follows:

      (a) attribute values encoded in different string types (e.g.,
      PrintableString and BMPString) may be assumed to represent dif-
      ferent strings;

      (b) attribute values in string types other than PrintableString
      are case sensitive (this permits matching of attribute values as
      binary objects);

      (c) attribute values in PrintableString are not case sensitive
      (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and

      (d) attribute values in PrintableString are compared after remov-
      ing leading and trailing white space and converting internal
      strings of one or more consecutive white space characters to a
      single space.

   These name comparison rules permit a certificate user to validate
   certificates issued using languages or encodings unfamiliar to the
   certificate user.

4.1.2.5  Validity

        (UNCHANGED)

4.1.2.6  Subject Name

   The subject name identifies the entity associated with the public key
   stored in the subject public key field. The subject identity may be
   carried in the subject field and/or the subjectAltName extension.  If
   the subject is a certification authority (e.g., the basic constraints
   extension [see 4.2.1.10] is present and the value of cA is TRUE,)
   then the subject identity must be carried in the subject field.  If
   identity information is present only in the subjectAltName extension
   (e.g., a key bound only to an email address or URI), then the subject
   name must be an empty sequence and the subjectAltName extension must
   be critical.

   Where it is non-null, the subject name field shall contain an X.500
   distinguished name (DN). The DN must be unique for each subject
   entity certified by the one CA as defined by the issuer name field.
   (A CA may issue more than one certificate with the same DN to the
   same subject entity.)

   The subject name field is defined as the X.501 type Name, and shall
   follow the encoding rules for the issuer name field (see 4.1.2.4).
   When encoding strings as the type PrintableString, conforming CAs
   should use mixed case but should not include leading or trailing
   white space and should limit internal white space to substrings of a
   single space.

   Implementations of this specification should be prepared to receive
   following X.501 attribute types: country, organization,
   organizational-unit, title, locality, state or province name, common
   name (e.g., "Tim Polk"), surname, given name, initials, and genera-
   tionqualifier (e.g., "Junior" or "IV".  The syntax and associated
   object identifiers for these attribute types are provided in the
   ASN.1 modules in Appendices A. and B.

   Legacy implementations exist where an RFC 822 name is embedded in the
   subject distinguished name as a PKCS #9 e-mail attribute, which has
   the ASN.1 type EmailAddress [PKCS #9]. Conforming implementations
   shall not generate new certificates with this attribute, but should
   be prepared to receive them.  (New certificates must use the
   rfc822Name in the subject alternative name field (see 4.2.1.7) to
   describe such identities.)

   The ASN.1 syntax for EmailAddress and the corresponding OID are sup-
   plied below.

   EmailAddress ::= IA5String

   pkcs-9 OBJECT IDENTIFIER ::=
          { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 9 }

   emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 }

--=====================_892838520==_--

Approved-By: [email-masked]
Date:         Fri, 17 Apr 1998 11:08:56 +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: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
Comments: To: [email-masked]
To: [email-masked]

Denis Pinkas wrote:
>
> Ambarish Malpani wrote:
>
> > Here is a list of the different kinds of status information that an OCSP
> > responder may want to return:
> >
> > 1. Revocation status of a certificate
> >     - revoked
> >     - on hold
> >     - not revoked
> >     - don't know about this CA
> >     - know about this CA, but not about this cert (??? I am not sure I
> >         think this state should ever be returned, but this corresponds
> >         to the state where the responder is looking up the CA's database
> >         and can't find this entry in the database. Mike, I believe you
> >         think this is an important state - is that correct?)
>
> The later would mean that the OCSP responder has access to more
> information than just  the CRL. I do not think that this response
> usefull for the client. If there were good arguments for keeping it (I
> have not been convinced by the arguments from Paul), then this status
> should be optional (no guarantee to get it back at any time).
Sorry that I bring that up again: the answer about knowing about a CA
but not about the referenced certificate would be a good one for use of
OCSP in the German Signature Law, where such a service is required.

Short overview: When asking a CA for the status of a certificate, it
answer with two booleans: certificate was issued / was not issued and
certifcate is revoked / is not revoked (the latter only when the
certificate was issued). The signature key is related to the CA but is
not the CAs certifcate signing key.

What we then need is a clarification between "not revoked": Let us
assume that an OCSP responder answers with "not revoked" based on a
decision of a CRLs where the certificate is NOT listed. This is a
different answer from "not revoked and I know about the certificate",
perhaps looked up on a CA database (see 3).

> > 2. Expiration status of a certificate
> >     - not yet valid (will be valid in the future)
> >     - valid (in its validity period)
> >     - expired
> >     - don't know about the expiration status
I think we have to rephrase that: not yet valid - certificate validity
period begins after the designated point in time.

>
> > 3. Issued status of the certificate
> >     - never issued (no cert with this serial number was ever issued by
> >       this CA)
> >     - issued
> >     - don't know if it was ever issued
>
> > My take on this issue: I believe OCSP is just a revocation status
> > protocol, so we should restrict the return status to just revoked,
> > onHold, notRevoked, and dontKnowAboutThisCA. This would leave the
> > syntax of the protocol simple and the semantics very clear - OCSP
> > basically returns the same information that you would get if you
> > had a CRL from the CA at the  instant of the response (NOTE: I am
> > NOT implying that a CRL is ever issued).
>
> Agreed. Let us keep it simple.

I think we should not restrict OCSP in its semantics to CRL like
semantics.

Andreas
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Fri, 17 Apr 1998 14:26:09 -0700
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 Status Information on a Certificate
Comments: To: Andreas Berger <[email-masked]>
To: [email-masked]

Andreas,

Your conclusion is:

" I think we should not restrict OCSP in its semantics to CRL like
  semantics."

I may agree with this. However, I think we should not mandate more than
what is available by access to CRL information only. This means that we
have to distinguish between a set of mandatory status and a set of
optional status.

> > Ambarish Malpani wrote:
> >
> > > Here is a list of the different kinds of status information that an OCSP
> > > responder may want to return:
> > >
> > > 1. Revocation status of a certificate
> > >     - revoked
> > >     - on hold
> > >     - not revoked
> > >     - don't know about this CA
> > >     - know about this CA, but not about this cert (??? I am not sure I
> > >         think this state should ever be returned, but this corresponds
> > >         to the state where the responder is looking up the CA's database
> > >         and can't find this entry in the database. Mike, I believe you
> > >         think this is an important state - is that correct?)
> >
> > The later would mean that the OCSP responder has access to more
> > information than just  the CRL. I do not think that this response
> > usefull for the client. If there were good arguments for keeping it (I
> > have not been convinced by the arguments from Paul), then this status
> > should be optional (no guarantee to get it back at any time).
>
> Sorry that I bring that up again: the answer about knowing about a CA
> but not about the referenced certificate would be a good one for use of
> OCSP in the German Signature Law, where such a service is required.

As long as this is optional.

> Short overview: When asking a CA for the status of a certificate, it
> answer with two booleans: certificate was issued / was not issued and
> certifcate is revoked / is not revoked (the latter only when the
> certificate was issued). The signature key is related to the CA but is
> not the CAs certifcate signing key.

More exactly:

it MUST issue one booolean  : certificate is revoked / is not revoked
it MAY issue another boolean: certificate was issued / was not issued

> What we then need is a clarification between "not revoked": Let us
> assume that an OCSP responder answers with "not revoked" based on a
> decision of a CRLs where the certificate is NOT listed. This is a
> different answer from "not revoked and I know about the certificate",
> perhaps looked up on a CA database (see 3).
>
> > > 2. Expiration status of a certificate
> > >     - not yet valid (will be valid in the future)
> > >     - valid (in its validity period)
> > >     - expired
> > >     - don't know about the expiration status
>
> I think we have to rephrase that: not yet valid - certificate validity
> period begins after the designated point in time.

We will have to support some date as originally requested by Stephen.

> > > 3. Issued status of the certificate
> > >     - never issued (no cert with this serial number was ever issued by
> > >       this CA)
> > >     - issued
> > >     - don't know if it was ever issued
> >
> > > My take on this issue: I believe OCSP is just a revocation status
> > > protocol, so we should restrict the return status to just revoked,
> > > onHold, notRevoked, and dontKnowAboutThisCA. This would leave the
> > > syntax of the protocol simple and the semantics very clear - OCSP
> > > basically returns the same information that you would get if you
> > > had a CRL from the CA at the  instant of the response (NOTE: I am
> > > NOT implying that a CRL is ever issued).
> >
> > Agreed. Let us keep it simple.
>
> I think we should not restrict OCSP in its semantics to CRL like
> semantics.
>
> Andreas

See above.

Regards,

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:         Fri, 17 Apr 1998 12:36:04 -0700
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 at IETF
To: [email-masked]

Jeff Weinstein wrote:
>
> I strongly agree with Stephen on this.  One great value that OCSP
> services could add would be to provide historical as well as current
> revocation information.
>
>         --Jeff

I strongly agree with both Stephen and Jeff on this.

Denis

> Stephen Farrell wrote:
> >
> > Hi Mike,
> >
> > Not sure if this needs a change, but...
> >
> > Part 1 now has a time input to the cert validation
> > algorithm (the time at which the cert should have been/be
> > valid).
> >
> > If OCSP is to fit seamlessly into this algorithm then you'll
> > need an extension to the request so that the response doesn't
> > refer to the current time, but to the time which was input
> > to the cert validation alg.
> >
> > Regards,
> > Stephen.

--
      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:         Fri, 17 Apr 1998 11:54:48 -0700
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] Key Identifiers
To: [email-masked]

Andreas, Tim, John, Peter, Kevin and Paul,

Let me jump into this thread. I will use the E-mail from Andreas to
comment but will attempt to address the other E-mails as well.

Generally speaking, I do not support the idea of making the
AuthorityKeyidentifier or the keyidentifier mandatory. It might even be
better to deprecate its use. After this initial statement let us see the
details.

> Some comments on the key identifier / authority identifier issue that
> was recently discussed on this list:
>
> Let's assume I have a certificate of someone on my system that is about
> to be verified. Usually I would begin by retrieving all certificates of
> authority described by the issuer and the issuer alternative name (the
> exact process is outside the scope of this discussion). The result is a
> set of certificates.

This might be one way to proceed, but I see another way. Basically we
have not defined a way to walk *up* a path or *down* a path. We might
need to define one. You suggest to walk UP a path while I would suggest
to walk DOWN a path. You have some trust points and the question is
whether you can, from one of these trust points go DOWN to the
certificate you want to verify. In this way you may make sure that
naming is unambiguous from the trust point and you may apply naming
constraints. Otherwise, you can't do it easily.

The reality is that for discovering a path, you might have to walk up
and down, but the verification should only be done "walking down". This
means that no digital signature verification should be done before
getting one or more candidate paths down.

> Now I have to find out, which Authority Certificate was used to sign the
> User Certificate I am currently holding. I can do this by using all
> public keys in the Authority Certificates an trying to verify the User
> Certificate's signature. For any attempt that fails, I can rule out all
> Authority Certificates which contain the same public key that I have
> just tried. This process leaves me with a set of certificates which all
> contain the same public key and this key was used to sign the User
> Certificate. Key Identifiers can help me with this process so that I do
> not have to make a series of signature verifications, those a reduced to
> an octet string comparison. Question: is it worth the effort to save
> these verification steps? How many different public keys do we expect a
> CA to have? more that a handful (let's say 10)? Only if the number of
> keys held by the same CA is large the key identifier will help.

As said above, no verification of digital signature should be done
before getting a full path. This saves signature checks (as requested by
Paul Koning) without the need to overload the certificate by additional
mandatory extensions (that take memory place when the certificate is
stored in a smart card).

> Now for the Authority Identifier. Again, I am at the point where I have
> just retrieved the set of certificates. Given the issuer and serial of
> the signing authority for that CA, I can quickly identify the single
> certificate that should be used for verification. In fact, it is would
> be possible to retrieve just this single certificate and not retrieving
> the complete set.
>
> I have one problem with this approach: The verification path is not
> fixed. Let us assume a CA gets certified by a set of other CAs. Some
> users trust one of them, others some other CAs (which is why the CA
> probably got this multiple certificates). When a user certificate
> contains a reference to a single other CA, a user which does not trust a
> specific CA will fail to verify the certificate, although there might be
> a another path which would lead to a successful verification.

I support this comment. This means that placing the key identifier will
create failures in cases where successful verification could have be
done applying a different approach.

There are additional problems if we keep the keyidentifier that have not
been mentioned. The key of a CA is supposed to change, let us say every
two years. We have left undefined the strategy to adopt when the CA
changes its key. There are two possibilities: the validity period of the
CA keys overlap during let us say 6 months or there are contiguous. The
later case is not very nice if a user wants to register one week prior
the expiration of the CA key, since two certificates will have to be
provided to him during a two weeks period. For the first case, we will
have two certificates signing keys for the same CA during 6 months and
the question is to know which one to use. Some people are going to say:
use the key identifier. However there is another solution that does not
mandate the use of the key identifier. Comparing the date "not before"
of the user certificate with the date "not before" of the CA certificate
(or self-signed certificate when we end-up to a point of trust) allows
to make the difference.

Remember what 4.2.1.1 currently says about the Authority key identifier:
" This extension would be used where an issuer has multiple signing keys
(either due to multiple concurrent key pairs or due to changeover)."

> This situation can be solved, if we define that: an application may
> first try the specific certificate defined and then defaults back to the
> "try and search" algorithm.
>
> One question: Do we have an algorithm for a complete verification? There
> is one that describes how to verify an existing FC path, but do we have
> an algorithm on how to construct a path?

We currently don't and we probably should define one.

> Shouldn't the path be constructed and verified from bottom up?

I would rephrase the sentence as:

Shouldn't the candidate paths be constructed forwards and backwards and
then verified from the top to the bottom ?

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:  Jeff Weinstein <[email-masked]>
Date:         Fri, 17 Apr 1998 01:57:54 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Jeff Weinstein <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP at IETF
To: [email-masked]

I strongly agree with Stephen on this.  One great value that OCSP
services could add would be to provide historical as well as current
revocation information.

        --Jeff

Stephen Farrell wrote:
>
> Hi Mike,
>
> Not sure if this needs a change, but...
>
> Part 1 now has a time input to the cert validation
> algorithm (the time at which the cert should have been/be
> valid).
>
> If OCSP is to fit seamlessly into this algorithm then you'll
> need an extension to the request so that the response doesn't
> refer to the current time, but to the time which was input
> to the cert validation alg.
>
> Regards,
> Stephen.

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 16 Apr 1998 17:17:27 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

At 07:02 PM 4/16/98 -0400, Stephen Kent wrote:
>I think the problem we see here is that some applications have a legitimate
>interest in requiring DNs for issuers, but not all application share this
>need. Thus it may be inappropriate to rerquire that ALL PKIX certs contain
>an Issuer DN, rather than allowing a null Issuer DN if an IssuerAltName is
>present.

It is only inappropriate to require it if we have a clear, unambiguous way
of doing cert path validation that includes IssuerAltNames. I don't think
we have one.

>What if we if we specify that a subjectAltName is validated
>against an IssuerAltName when both are present, and if the Subject name is
>null?  I do worry though that this might lead to confusion since the Issuer
>and IssuerAltName might differ under such circumstances.

That is an excellent example of confusion, and one that led me to believe
that we're not going to get reliable chaining with those kinds of
decisions. Let me give you another: there are plenty of kinds of AltNames
that might not be distinguished. I'm not talking about the malicious case
where BadCA tries to impersonate GoodCA. I'm talking about some of the many
kinds of names in GeneralNames that GoodCAEast might take and GoodCAWest
might take and have name collision without knowing it.

I have no love for DNs, but it seems much harder to have an accidental name
collision in the DN space than in many of the spaces in the AltNames.

And, let me bring up a topic again that no one responded to before: when
validating chains on AltNames, is it the AND of all the items in the
GeneralNames sequence, or is it the OR of them? If my IssuerAltName is a
SEQUENCE of three rfc822Names, and you're comparing against a cert that has
just one of those names, does the comparison pass or fail? In asking people
in the hallways in LA, I got about a 50/50 split of what people thought it
was. This alone should scare us away from using AltNames and expecting
people writing validating code to get it right.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Stephen Kent <[email-masked]>
Date:         Thu, 16 Apr 1998 19:02:15 -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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

Tim,

>At 12:11 PM -0400 4/9/98, Tim Polk wrote:
>>For those who weren't in the LA meeting, this proposal was requested by the
>>S/MIME working group.  An empty issuer name wreaks general havoc with their
>>protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
>>an important consideration.
>
>I will point out that TLS (née SSL) has a similar requirement, as it uses a
>list of Distinguished Names to specify supported CAs when requesting client
>certificates.

I think the problem we see here is that some applications have a legitimate
interest in requiring DNs for issuers, but not all application share this
need. Thus it may be inappropriate to rerquire that ALL PKIX certs contain
an Issuer DN, rather than allowing a null Issuer DN if an IssuerAltName is
present. Even in your example, its not clear that the list of CA names sent
in SSL/TLS be DNs, other than for historic reasons.  TLS could choose to
mandate use of GeneralNames for CAs in this context, as another minor
deviation from SSL that would make it more general.

Denis pointed out that use of the NameConstraints extension is problematic
when the Issuer and Subject name types differ, although that problem might
be mitigated.  What if we if we specify that a subjectAltName is validated
against an IssuerAltName when both are present, and if the Subject name is
null?  I do worry though that this might lead to confusion since the Issuer
and IssuerAltName might differ under such circumstances.

Steve

Approved-By:  "Flanigan, Bill" <[email-masked]>
Date:         Thu, 16 Apr 1998 14:52:57 -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: "Flanigan, Bill" <[email-masked]>
Subject:      Re: [IETF-PKIX] Unencumbered PKIX Minutes (Was: RE: [IETF-PKIX] D raft LA Minutes)
To: [email-masked]

Hello Warwick,

        I rest my case!

Bill

> -----Original Message-----
> From: Warwick Ford [SMTP:[email-masked]]
> Sent: Wednesday, April 15, 1998 10:29 PM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Unencumbered PKIX Minutes (Was: RE:
> [IETF-PKIX] Draft LA Minutes)
>
> Bill:
>
        [snip]

> We like the minutes to ...[snip]...just be an invention.
>
> Warwick
>
>
>

Approved-By: [email-masked]
Date:         Thu, 16 Apr 1998 10:22: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: Tim Dierks <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

At 12:11 PM -0400 4/9/98, Tim Polk wrote:
>For those who weren't in the LA meeting, this proposal was requested by the
>S/MIME working group.  An empty issuer name wreaks general havoc with their
>protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
>an important consideration.

I will point out that TLS (née SSL) has a similar requirement, as it uses a
list of Distinguished Names to specify supported CAs when requesting client
certificates.

 - Tim

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Thu, 16 Apr 1998 09:58:50 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

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

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

"Alexei V. Vopilov" <[email-masked]> scrawled:
>
> =======Marc Branchaud posted:
> [. . .]
> :
> :One thing this exercise has showed me is that "unknown cert" is really a
> :useless response value, since it is either bogus or subsumed by other values
> :(like "unknown CA").
>
> Should "unknown" statuses be read as followed?
>
> Revocation =  "NotAvailable" // cannot access to CRL information
>               "UnknownCA"    // cannot access to unknown CA database

Well, setting aside the issue of whether multi-valued responses are a good
idea or not, I would argue that the above two cases are equivalent.

If the responder can't access the proper CRL information, it's because it
hasn't collected the CRLs from the CA and so it basically doesn't recognize
the CA.  The same argument applies to responders with direct access to a
CA's database.

Come to think of it, there could be a situation where a responder holds an
expired CRL for which it has yet to receive a replacement.  One might argue
that a "NotAvailable" response would be OK, but I think it would be better
to provide a response based on the expired CRL, perhaps accompanied by some
kind of warning.

> Expiration =  "NotAvailable" // cannot access to known CA database _contents_
>               "UnknownCA"    // cannot access to unknown CA database

Expiration is independent of the contents of a CA's database or even the
recognition of the CA by the responder.  The only time the responder would
reply with an "unknown" expiration value is if it doesn't actually perform
the expiration calculation.  This calculation can be performed for _any_
certificate, so whether an unknown response is made is really just a matter
of how the responder is configured.

So, once again, I think a single kind of "unknown" response is adequate
here.

> Issued     =  "NotAvailable" // cannot access to known CA database _directory_
>               "UnknownCA"    // cannot access to unknown CA database
>

This is where complexity is justified, because a responder using only CRLs
can not know if an unrevoked certificate has ever been issued (revoked
certs, on the other hand, are known to have been issued).  So I agree that
these two kinds of "unknown" responses are a good thing.  The "NotAvailable"
response would be given by responders that only have CRL information (for
the given CA).  A responder with direct access to the CA's database shouldn't
normally use the "NotAvailable" response.

> Having this a Responder implementation can support only part of
> specification without interoperability problems.
> Note there is the difference between "NotAvailable" semantic for
> Expiration and Issued statuses.
>
> Note also that nothing (according to spec design)
> prevents implementing an OCSP Responder by extending CRLs
> issued by a CA (or by just ignoring them at all).
>

I'm not sure what you mean by this.  Could you elaborate?

As for the bigger picture, I'm still not convinced either way about whether
or not OCSP should have multi-valued responses.  I think the extra
complexity is manageable, but I also see the appeal of a simpler protocol.
It really depends on what people want to do with OCSP.  Are the issued/
unissued and expired/unexpired values needed?

I do think they're more marginal.  If the cert's signature verifies, then
it's a good bet that the cert was issued.  As for expiration, a client would
have to be pretty thin to not have a clock.

                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:  John Hughes <[email-masked]>
Date:         Thu, 16 Apr 1998 17:49:47 +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: John Hughes <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
Comments: To: [email-masked]
To: [email-masked]

Denis,

I concurr - as a "user" I would much prefer RFC822 names.

John

At 17:20 16/04/98 -0700, Denis Pinkas wrote:
>Tim,
>
>When I came backfrom LA I found 313 messages waiting for me (I was
>surely not the single person in that situation). Today, I reviewed the
>messages that I skipped and I find this one pretty important:
>
>> For those who weren't in the LA meeting, this proposal was requested by the
>> S/MIME working group.  An empty issuer name wreaks general havoc with their
>> protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
>> an important consideration.
>>
>> In addition, implementors have identified name chaining as a specific
>> difficulty in PKIX implementations.  Prohibiting empty issuer names greatly
>> simplifies path building and validation.
>>
>> When the issue was discussed in the meeting, no requirement for empty
>> issuer names was identified.  The original author of that section agreed
>> that empty subject names in end-entity certificates was sufficient for his
>> purposes.
>>
>> Response at the meeting indicated general support (I don't recall any
>> objectsions) for requiring issuer names in all certificates.  Of course,
>> this decision requires validation by the list.
>
>The topic was mentionned along many others and no one dared to interrupt
>the speaker. On one hand, you say : "this decision requires validation
>by the list" but on the other hand you are already assuming general
>consensus, just the day after the initial posting was made. So let us
>wait a second and discuss this issue (and don't rush to make the
>changes!)
>
>> Assuming general consensus, John has done an excellent job of identifying
>> the changes that are required in the document.  I will make sure they are
>> all implemented.
>>
>> Tim Polk
>>
>> At 07:23 PM 4/8/98 -0400, John Pawling wrote:
>> >All,
>> >
>> >Based on the disussion at the recent PKIX meetings, propose that the
>> >following text should be added to the PKIX X.509 Certificate and CRL
>> >Profile, Issuer Name section (4.1.2.4) and Subject Name section (4.1.2.6):
>> >"All subject and issuer names MUST be populated (i.e. not an empty
SEQUENCE)
>> >in PKIX-compliant X.509 certificates, except that the subject name in a
>> >user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in which
case
>> >the subjectAltName extension will include the subject's identifier and
MUST
>> >be marked as critical."
>
>The argumentation for this has been pretty short. More explanations
>would be needed about the rational. Shortly speaking and as I
>understood, "since applying naming constraints on non-DN names for CAs
>might be difficult, let us mandate DN names for CAs". This would mean
>imposing Full Distinguished Names( i.e. conforming to X.521) for CAs.
>
>One of the MAJOR benefits that we have been advocating when the PKIX
>group was formed was that our standards will allow to support other
>types of names (e.g. rfc822 names) which are more user-friendly than
>names like :</S=xxx/PRMD=Internet/ADMD=Atlas/C=FR>.
>
>I do like name formats like " person@domain_name " where the domain name
>is formed of hierarchical components. Imposing X.521 name formats does
>not seem to be appropriate.
>
>Beyond this point there are other arguments :
>
>1) If the end-entity at the end of a leaf is not mandated to use DNs,
>how can we easily apply naming constraints ?
>
>2) X.521 names should be deprecated because they take more place in a
>certificate, and if I wish to carry my own certificate in my smart card,
>it has better to be the shortest.
>
>I think this is not a minor point but an important matter and, up to
>now, only Tim and John have expressed their opinion, so let us ask for
>other opinions.
>
>Denis
>
>> >This following text should be deleted from the Issuer Name section
>> >(4.1.2.4): "The issuer identity may be carried in the issuer name field
>> >and/or the issuerAltName extension.  If identity information is present
only
>> >in the issuerAltName extension, then the issuer name may be an empty
>> >sequence and the issuerAltName extension must be critical."
>> >
>> >In the Issuer Name section (4.1.2.4), the phrase "Where it is non-null"
>> >should be deleted from "Where it is non-null, the issuer name field shall
>> >contain an X.500 distinguished name (DN)."
>> >
>> >In the Certificate Extensions section (4.2), the following text should be
>> >deleted: "If the CA issues certificates with an empty sequence for the
>> >issuer field, the CA must support the issuerAltName extension."
>> >
>> >In the Issuer Alternative Name section (4.2.1.8), the following text
should
>> >be deleted: "If the only issuer identity included in the certificate is an
>> >alternative name form (e.g., an electronic mail address), then the issuer
>> >distinguished name shall be empty (an empty sequence), and the
issuerAltName
>> >extension shall be present. If the subject field contains an empty
sequence,
>> >the issuerAltName extension shall be marked critical."
>> >
>> >The CRL Issuer Name section (5.1.2.3) should be changed to read as
follows:
>> >"The issuer name identifies the entity who has signed (and issued the
CRL).
>> >The issuer name field shall contain an X.500 distinguished name (DN).  The
>> >issuer name field is defined as the X.501 type Name, and shall follow the
>> >encoding rules for the issuer name field in the certificate (see
4.1.2.4)."
>> >
>> >In section 5.1.2.6  Revoked Certificates, the phrase "or issuer altrnative
>> >name" should be delted from: "Certificates are uniquely identified by the
>> >combination of the issuer name or issuer alternative name along with the
>> >user certificate serial number."
>> >
>> >In section 5.2.2 Issuer Alternative Name, the following text should be
>> >deleted: "Further, if the only issuer identity included in the CRL is an
>> >alternative name form (e.g., an electronic mail address), then the issuer
>> >distinguished name should be empty (an empty sequence), the issuerAltName
>> >extension should be used, and the issuerAltName extension must be marked
>> >critical."
>> >
>> >In section 6, Certificate Path Validation, the following text should be
>> >deleted: "(If the certificate has an empty sequence in the name field,
name
>> >chaining will use the critical subjectAltNames and issuerAltNames
fields.)"
>> >
>> >================================
>> >John Pawling, [email-masked]
>> >J.G. Van Dyke & Associates, Inc.
>> >www.jgvandyke.com
>> >================================
>> >
>> >
>
>--
>      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
>
>

 -------------------------------------------------------------------
| 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: [email-masked]
Date:         Thu, 16 Apr 1998 11:55:34 +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: Stephen Farrell <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP at IETF
Comments: cc: [email-masked]
To: [email-masked]

Hi Mike,

Not sure if this needs a change, but...

Part 1 now has a time input to the cert validation
algorithm (the time at which the cert should have been/be
valid).

If OCSP is to fit seamlessly into this algorithm then you'll
need an extension to the request so that the response doesn't
refer to the current time, but to the time which was input
to the cert validation alg.

Regards,
Stephen.

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Thu, 16 Apr 1998 17:20:24 -0700
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] Subject/Issuer Name Population
To: [email-masked]

Tim,

When I came backfrom LA I found 313 messages waiting for me (I was
surely not the single person in that situation). Today, I reviewed the
messages that I skipped and I find this one pretty important:

> For those who weren't in the LA meeting, this proposal was requested by the
> S/MIME working group.  An empty issuer name wreaks general havoc with their
> protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
> an important consideration.
>
> In addition, implementors have identified name chaining as a specific
> difficulty in PKIX implementations.  Prohibiting empty issuer names greatly
> simplifies path building and validation.
>
> When the issue was discussed in the meeting, no requirement for empty
> issuer names was identified.  The original author of that section agreed
> that empty subject names in end-entity certificates was sufficient for his
> purposes.
>
> Response at the meeting indicated general support (I don't recall any
> objectsions) for requiring issuer names in all certificates.  Of course,
> this decision requires validation by the list.

The topic was mentionned along many others and no one dared to interrupt
the speaker. On one hand, you say : "this decision requires validation
by the list" but on the other hand you are already assuming general
consensus, just the day after the initial posting was made. So let us
wait a second and discuss this issue (and don't rush to make the
changes!)

> Assuming general consensus, John has done an excellent job of identifying
> the changes that are required in the document.  I will make sure they are
> all implemented.
>
> Tim Polk
>
> At 07:23 PM 4/8/98 -0400, John Pawling wrote:
> >All,
> >
> >Based on the disussion at the recent PKIX meetings, propose that the
> >following text should be added to the PKIX X.509 Certificate and CRL
> >Profile, Issuer Name section (4.1.2.4) and Subject Name section (4.1.2.6):
> >"All subject and issuer names MUST be populated (i.e. not an empty SEQUENCE)
> >in PKIX-compliant X.509 certificates, except that the subject name in a
> >user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in which case
> >the subjectAltName extension will include the subject's identifier and MUST
> >be marked as critical."

The argumentation for this has been pretty short. More explanations
would be needed about the rational. Shortly speaking and as I
understood, "since applying naming constraints on non-DN names for CAs
might be difficult, let us mandate DN names for CAs". This would mean
imposing Full Distinguished Names( i.e. conforming to X.521) for CAs.

One of the MAJOR benefits that we have been advocating when the PKIX
group was formed was that our standards will allow to support other
types of names (e.g. rfc822 names) which are more user-friendly than
names like :</S=xxx/PRMD=Internet/ADMD=Atlas/C=FR>.

I do like name formats like " person@domain_name " where the domain name
is formed of hierarchical components. Imposing X.521 name formats does
not seem to be appropriate.

Beyond this point there are other arguments :

1) If the end-entity at the end of a leaf is not mandated to use DNs,
how can we easily apply naming constraints ?

2) X.521 names should be deprecated because they take more place in a
certificate, and if I wish to carry my own certificate in my smart card,
it has better to be the shortest.

I think this is not a minor point but an important matter and, up to
now, only Tim and John have expressed their opinion, so let us ask for
other opinions.

Denis

> >This following text should be deleted from the Issuer Name section
> >(4.1.2.4): "The issuer identity may be carried in the issuer name field
> >and/or the issuerAltName extension.  If identity information is present only
> >in the issuerAltName extension, then the issuer name may be an empty
> >sequence and the issuerAltName extension must be critical."
> >
> >In the Issuer Name section (4.1.2.4), the phrase "Where it is non-null"
> >should be deleted from "Where it is non-null, the issuer name field shall
> >contain an X.500 distinguished name (DN)."
> >
> >In the Certificate Extensions section (4.2), the following text should be
> >deleted: "If the CA issues certificates with an empty sequence for the
> >issuer field, the CA must support the issuerAltName extension."
> >
> >In the Issuer Alternative Name section (4.2.1.8), the following text should
> >be deleted: "If the only issuer identity included in the certificate is an
> >alternative name form (e.g., an electronic mail address), then the issuer
> >distinguished name shall be empty (an empty sequence), and the issuerAltName
> >extension shall be present. If the subject field contains an empty sequence,
> >the issuerAltName extension shall be marked critical."
> >
> >The CRL Issuer Name section (5.1.2.3) should be changed to read as follows:
> >"The issuer name identifies the entity who has signed (and issued the CRL).
> >The issuer name field shall contain an X.500 distinguished name (DN).  The
> >issuer name field is defined as the X.501 type Name, and shall follow the
> >encoding rules for the issuer name field in the certificate (see 4.1.2.4)."
> >
> >In section 5.1.2.6  Revoked Certificates, the phrase "or issuer altrnative
> >name" should be delted from: "Certificates are uniquely identified by the
> >combination of the issuer name or issuer alternative name along with the
> >user certificate serial number."
> >
> >In section 5.2.2 Issuer Alternative Name, the following text should be
> >deleted: "Further, if the only issuer identity included in the CRL is an
> >alternative name form (e.g., an electronic mail address), then the issuer
> >distinguished name should be empty (an empty sequence), the issuerAltName
> >extension should be used, and the issuerAltName extension must be marked
> >critical."
> >
> >In section 6, Certificate Path Validation, the following text should be
> >deleted: "(If the certificate has an empty sequence in the name field, name
> >chaining will use the critical subjectAltNames and issuerAltNames fields.)"
> >
> >================================
> >John Pawling, [email-masked]
> >J.G. Van Dyke & Associates, Inc.
> >www.jgvandyke.com
> >================================
> >
> >

--
      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:  David Boyce <[email-masked]>
Date:         Thu, 16 Apr 1998 16:16: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: David Boyce <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Comments: cc: Tim Polk <[email-masked]>
To: [email-masked]

Tim Polk writes:

>Part 1: Hashing DNs
>
> There is a major problem with substituting the hash of an issuer's DN for
>the DN itself.  First, the X.501 string matching rules ignore leading and
>trailing white space, and compress consecutive white space characters into
>a single white space character.  In addition, many of the X.501 Name
>subtypes are defined with "caseIgnoreMatch" and "caseIgnoreSubstringsMatch"
>.  The result is, c=us matches c=US matches c=uS.

While recognising the intent of your example, 'countryName' is a
particularly poor attribute to choose as an example of this, since many
applications only partially implement the ASN.1 annotation in X.520
(which defines the attribute) which states that it should be (two
character) values of ISO 3166, overlooking the fact that all the values
defined there have only one case (UPPER).  Arguably c=us and c=uS should
be rejected as invalid AVAs (I'd appreciate feedback on this point of
view.)

>This means that the hash of two DNs may be different, but the DNs may
>match.  You need to send the DN.

Another approach would be to define a canonicalised encoding of a DN
which deals with these issues (e.g. compress whitespace, force to
uppercase where appropriate) so that the X.501 string matching rules are
satisfied by a straight comparison.  This version of the DN could then
be hashed and used in place of the above Issuer DN hash.  (I belatedly
notice that Jeff Weinstein has also suggested this.)

It may even be sensible to emit such canonicalised DNs in Certificates
etc., but receiving applications should never assume that such
canonicalisation has been used.  I suppose PKIX *could* define it so
that receiving applications could expect canonicalised DNs, but it would
lock a lot of implementations out.

--
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:  Carlisle Adams <[email-masked]>
Date:         Thu, 16 Apr 1998 10:51:44 -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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Draft LA Minutes
To: [email-masked]

Hi Warwick,

> ----------
> From:         Warwick Ford[SMTP:[email-masked]]
> Sent:         Saturday, April 11, 1998 7:36 PM
> To:   [email-masked]
> Subject:      [IETF-PKIX] Draft LA Minutes
>
> Here are Draft LA Minutes for review and comment.
>
> Warwick
>
A couple of minor typos.  [Forgive me if someone has already pointed these
out, but I've been out of the office for over a week and may have missed
it...]

> CRMF, CMMC AND CMC
>
> (1) CMRF describes the certificate request message of choice for PKIX. CMC
> specifies an alternate format as "mandatory to implement". The sense of
> the
> group was that CMRF should be the mandatory request format for CMC.
>
Both instances of "CMRF" above should be "CRMF".

> (2) Carlisle Adams noted that secure initialization is not a feature of
> CMC. After some discussion, there was a straw poll. The sense of the group
> was that secure initialization should be feature of CMS and should be
> mandatory to implement. This requirement can be supported using the CRMF
> message format discussed above.
>
"CMS" above should be "CMC" (a small, but important, distinction).

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

Approved-By:  [email-masked]
Date:         Thu, 16 Apr 1998 10:34:22 -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: John Wray <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]

Tim Polk <[email-masked]> wrote:

>NOTE: I am drafting new text for the PKIX profile to limit the string
>matching burden. The proposed text will limit the pain for implementors by
>permitting binary comparison of two strings encoded as UTF8String or
>BMPString. It will also relieve implementors of the obligation to map
>character sets and match strings encoded as different types.  This limits
>the ugliness (ignoring case and compressing white space) to processing
>PrintableString. (As I understand it, implementors have already conquered
>this piece.) I will distribute that text SOON, on a new thread on this
list.

I guess I should really wait to see the proposed text, and I may have
misunderstood
your intent, but this sounds like the wrong thing to do.  PrintableString
is a
crippled code-set, in that characters that are quite common aren't
permitted in it
(e.g. underscores and accented characters).  If what you are proposing is a
set of
canonicalization rules that are to be applied to the Unicode encodings (BMP
& UTF8)
before they are placed in certificates to allow binary comparisons between
certificate names to give the same results as the X.501 rules would between
their
non-canonical equivalents, that will mean that names that stray outside the
limited printableString character set will lose the ability to be expressed
(in certificates) in the way the owner of that name prefers (e.g. with
appropriate capitalization).

If you do intend that the PKIX profile should require that names in
certificates
are represented in canonical form when encoded in Unicode-derived codesets,
I
think the same restriction should apply to printableString too (actually,
I'm
not sure why we need to keep printableString around at all, since the
encoding
of every printableString character is identical to the encoding of that
character in UTF8.  The only thing that the printableString option buys is
the
freedom to choose a different tag in the BER encoding, which seems
more of a liability than an advantage.  I can see the utility of keeping
printableString for things like C=xy, where <xy> is required to be within
the
printableString character-set, but I don't see any benefits to allowing an
attribute value to be expressed as a CHOICE { printableString, UTF8String,
... }).

I don't believe that restricting names in certificates will actually free
up
applications from having to deal with non-canonical names anyway, since the
entity
that initiates path validation is likely to be interacting with a human at
some
stage, and at that point any names should be expressed in "owner-preferred
form"
as opposed to canonical form.

I'm all for the PKIX profile specifying an algorithm to convert a string
(in _any_
permitted codeset, not just UTF8 and BMP) into a canonical form (actually,
that should
be one algorithm for each X.501 matching rule), but I don't think we should
constrain
the names in certificates to be stored in that canonical form.

John

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Thu, 16 Apr 1998 15:09:00 -0700
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] INFOSEC'COM 98
To: [email-masked]

INFOSEC'COM 98

                        International Congress
          on Information Systems and Telecommunications Security

           4 - 5 June 1998 - CNIT Paris-La Defense - FRANCE

The International Congress on Information Systems and Telecommunications
Security presents the state of the art, innovations, prospects and new
openings in the fields of information systems and telecommunications
security. The information presented is novel and the presentations by
the speakers are both diversified and of a high standard. As such, they
are mostly intended for specialists in the field (information systems
security managers, computer manufacturers, software publishers,
consultants, etc).

This Congress will take place in Paris (CNIT La Defense) alongside the
INFOSEC trade fair (from June 3 to June 5) where the exhibitors will
demonstrate their know-how in the area of information systems security
products and services.

To make things even more attractive, June happens to be the most
pleasant period of the year to visit Paris.

Thursday June, 4 1998

Opening session

General Strategy in terms of information systems security
General Jean-Louis DESVIGNES, SCSSI

Trusted Third Parties
Chairman : Jean-Philippe JOUAS - President of CLUSIF

* The use of PKIX profiles to support various application paradigms
  John HUGHES - ENTEGRITY SOLUTIONS (UK)
* Questions raised by key escrow systems
  Valerie SEDAILLIAN - Attorney (F)
* Certificate Authority System and e-comm project
  Pierre CHASSIGNEUX - GEMPLUS (F)

Evaluation
Chairman : Michel DUPUY - France Telecom

* Smartcard integrated circuit protection profile overview
  Jean-Paul THOMASSON - SGS-THOMSON Microelectronics (F)
* Protection profile for a European certification architecture
  Jean-Pierre LACOMBE - SETICS (F)
* Common criteria
  Carlos MARTIN - SCSSI Certification Center (F)

Networks
Chairman : Serge SAGHROUNE - Groupe ACCOR

* Secured connection of nomad stations :
  Dassault Electronique's experience
  Yves MEYER - DASSAULT ELECTRONIQUE (F)
* Tentative classification of digital attacks and Internet incidents
  Didier GRAS - XP Conseil - LEFEBVRE Consultants (F)
* Protection of transfering medical on the Internet :
  an application of the Montpellier University Hospital
  Stephane NATKIN - CESIR (F)
* Firewalls for ATM Networks
  Uwe ELLERMANN - HAMBURG UNIVERSITY (D)
* Security in electronic commerce
  Pascal LAGARDE - Industry Minister, Postal Telecommunication
  - SERICS (F)

Friday June 5, 1998

Entreprise
Chairman : Andre GRISSONNANCHE - AGC

* Information systems security networks in major
  compagnies : a new function, a new job, career development prospects
  Rene HANOUZ - CLUSIF (F)
* Risk management of contracted activities
  Gerard REMY - ALCATEL TELECOM (F)
* Management of crise situations : both a necessity and an opportunity
  Andre GRISSONNANCHE - AGC (F)
* Security flaws in a Year 2000 project : a case study
  Pascal LOINTIER - CIGNA (F)
* ROUND TABLE : The future of the security market
  Facilitator : Philippe ROSE - LE MONDE INFORMATIQUE
  Herve SCHAUER - HSC (F) / Andre GRISSONNANCHE - AGC (F) /
  Pierre-Luc REFALO - CEGETEL (F) /
  Jean-Luc JAMAUX - LA FRANCAISE DES JEUX (F)

Digital documents
Chairman : Benoit TIRARD - SYLAB FRANCE (F)

* Document marking legal value
* Electronic documents : the guarantee of integrity
* Protection of digital works on the web
* The sealing functionality : identification and tracking
  of the works in the market
Participants : Nicole TORTELLO, Editions Albin Michel, Representative of
the National Union of Publishers (F) - Bruno COUDERC, BJC Consultants,
Representative of APROGRED, association of professionals in electronic
document management (F)

Viruses
Chairman : Pascal LOINTIER - CIGNA (F)

* Virus writers / Enterprises / Anti-virus software
  publishers : dangerous liaisons
  Danielle KAMINSKY - Investigative Journalist (F)
* The new technology to replace anti-virus systems
  Eyal DOTAN - TEGAM International (US)

GENERAL INFORMATION

Schedules : from 9:00 AM to 6:00 PM
Simultaneous translation French / English and English / French
Registration Fee: 4.980 French Francs (VAT inc.)

For more information, please contact : M.C.I.
19, Rue d'Athenes - 75009 PARIS - FRANCE
Tel : +33 1.44.53.72.20 - Fax : +33 1.44.53.72.22
or the CLUSIF by email : [email-masked]

http://www.clusif.asso.fr/

--
      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:         Thu, 16 Apr 1998 10:04:42 -0700
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] Draft LA Minutes
To: [email-masked]

Warwick,

Two "minor" modifications :-)

> IETF-PKIX MINUTES - APRIL 1, 1998
>
> CERTIFICATE AND CRL PROFILE
>
> Tim Polk summarized the status and outstanding issues on Draft 07 of the
> profile.  It is essential that this document be progressed quickly since
> several other standards are waiting on it.  New additions to 07 include the
> addition of UTF-8 in accordance with IETF Best Practices, correction of the
> path processing algorithm to align with X.509, and removal of semantics for
> wildcards in alternative names.  A few other minor fixes have been noted
> but not yet published.  The S/MIME group has requested that issuer DN be
> required.  The TLS group has requested that wildcards not be forbidden.
>
> Beyond these minor issues, the document is currently stuck in last call
> owing to patent issues resulting from an Entrust patent issued in December.

In this last sentence, I would prefer that we delete the word "minor"
since the last two items that are mentionned might not be "minor". So
the corrected sentence would be:

" Beyond these issues, the document is currently stuck in last call
owing to patent issues resulting from an Entrust patent issued in
December."

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:  "Alexei V. Vopilov" <[email-masked]>
Date:         Thu, 16 Apr 1998 01:38:13 +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: "Alexei V. Vopilov" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

=======Marc Branchaud posted:
[. . .]
:
:One thing this exercise has showed me is that "unknown cert" is really a
:useless response value, since it is either bogus or subsumed by other values
:(like "unknown CA").

Should "unknown" statuses be read as followed?

Revocation =  "NotAvailable" // cannot access to CRL information
              "UnknownCA"    // cannot access to unknown CA database
Expiration =  "NotAvailable" // cannot access to known CA database
_contents_
              "UnknownCA"    // cannot access to unknown CA database
Issued     =  "NotAvailable" // cannot access to known CA database _directory_
              "UnknownCA"    // cannot access to unknown CA database

Having this a Responder implementation can support only part of
specification without interoperability problems.
Note there is the difference between "NotAvailable" semantic for
Expiration and Issued statuses.

Note also that nothing (according to spec design)
prevents implementing an OCSP Responder by extending CRLs
issued by a CA (or by just ignoring them at all).

--Alexei

Approved-By:  Warwick Ford <[email-masked]>
Date:         Wed, 15 Apr 1998 19:29:28 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Unencumbered PKIX Minutes (Was: RE: [IETF-PKIX] Draft LA Minutes)
To: [email-masked]

Bill:

The FINAL minutes get published in the Proceedings.  These are DRAFT
minutes circulated to the list to give participants the opportunity to
review and correct.  We like the minutes to reflect what actually happened
rather than just be an invention.

Warwick

At 05:47 PM 4/15/98 -0400, Flanigan, Bill wrote:
>Hello Warwick,
>
>        Why post this to the list?  Why not to the IETF Web site for
>Proceedings <http://www.ietf.org/proceedings/directory.html>?  Or is there a
>pending patent or trademark involved?  I prefer my own unencumbered (now and
>forever) PKIX minutes.
>
>Bill Flanigan
>
>> -----Original Message-----
>> From: Warwick Ford [SMTP:[email-masked]]
>> Sent: Saturday, April 11, 1998 7:37 PM
>> To:   [email-masked]
>> Subject:      [IETF-PKIX] Draft LA Minutes
>>
>> Here are Draft LA Minutes for review and comment.
>>
>> Warwick
>> ---------------------------------
>>
>        [snip]
>
>
>> ---------------------------------------------------------------------
>> Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>> [email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>> ---------------------------------------------------------------------
>
>

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

Approved-By:  "Flanigan, Bill" <[email-masked]>
Date:         Wed, 15 Apr 1998 17:47:36 -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: "Flanigan, Bill" <[email-masked]>
Subject:      [IETF-PKIX] Unencumbered PKIX Minutes (Was: RE: [IETF-PKIX] Draft LA Minutes)
To: [email-masked]

Hello Warwick,

        Why post this to the list?  Why not to the IETF Web site for
Proceedings <http://www.ietf.org/proceedings/directory.html>?  Or is there a
pending patent or trademark involved?  I prefer my own unencumbered (now and
forever) PKIX minutes.

Bill Flanigan

> -----Original Message-----
> From: Warwick Ford [SMTP:[email-masked]]
> Sent: Saturday, April 11, 1998 7:37 PM
> To:   [email-masked]
> Subject:      [IETF-PKIX] Draft LA Minutes
>
> Here are Draft LA Minutes for review and comment.
>
> Warwick
> ---------------------------------
>
        [snip]

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

Approved-By:  Jeff Weinstein <[email-masked]>
Date:         Wed, 15 Apr 1998 14:07:24 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Jeff Weinstein <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]

Tim Polk wrote:
> Part 1: Hashing DNs
>
>  There is a major problem with substituting the hash of an issuer's DN for
> the DN itself.  First, the X.501 string matching rules ignore leading and
> trailing white space, and compress consecutive white space characters into
> a single white space character.  In addition, many of the X.501 Name
> subtypes are defined with "caseIgnoreMatch" and "caseIgnoreSubstringsMatch"
> .  The result is, c=us matches c=US matches c=uS.
>
> This means that the hash of two DNs may be different, but the DNs may
> match.  You need to send the DN.

Can't you just canonicalize the DNs before hashing?

> Part 2. DN collisions
>
> >    Some people have argued that if DNs clash, everything in PKIX
> >breaks.
>
> Those people are WRONG. The security of PKIX implementations does *not*
> rely on the name space. The performance will be degraded by DN collisions,
> but implementations will not fail as a result.
>
> Path validation always relies on signatures.  There is no direct security
> implication to having n CAs with the same name (say "X").  Certificates
> bind a name AND KEY.  If the name is right, but the key is wrong, path
> validation will fail.  The impliciations are in the areas of performance,
> procedures, and jurisprudence.

  I do agree that security is not compromised.  However if you are saying
that the result is not "broken", then I strongly disagree.

> The key identifiers do help this situation.  They help the software to find
> useful paths quickly.
>
> A final addendum to your story.  Non-aligned country Z's CA (called "Z")
> issues certificates to East and West X's CAs, which are using the same name
> ("X"), with different constraints.  The path validation routines should
> work, whether or not the keyidentifers are in use.  East and West X use
> different key pairs, so everything works.  (Especially the path validation
> software, which works overtime to sort it all out.)

  Lets say that I am trying to validate an end-entity cert that is issued
by west-"X", but I only have CA cert for east-"X" available locally.  I will
try to validate the end-entity cert and get a signature failure.  At this
point there is no way for me to know that a cert for west-"X" even exists,
much less how to get it.  I don't consider this a degradation in performance,
but rather an avoidable failure.

  In the example you presented the CA "Z" clearly did the wrong thing by
issuing certs to two different entities with the same identifying
information.  In the case of two independent roots using the same
name, things get muddier.

        --Jeff

Date:         Wed, 15 Apr 1998 17:39:44 -0700
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] Types of OCSP Responders
To: [email-masked]

Ambarish,

Another response to one of the threads.

> I believe there are three types of OCSP responders:
>
> - CA Responders
>     Where a CA signs OCSP responses - either with the same key as it
> used to sign certificates, or with a different key (one reserved
> for OCSP responses)

Using the same key, as you mention later should be deprecated;
If it is a different key, then you are in the case 3 (CA Designated
Responders)

> - Client-Trusted Responders
>     Where a particular client decides to trust a particular OCSP
> responder to sign all/some OCSP responses for it. The client
> establishes this trust in a out of band(OOB) method and uses that
> same OOB method to check for revocation, change of public key of
> responder, etc.

This works fine but is not scalable.

> - CA Designated Responders
>     Where a CA assigns a special certificate to another entity (which
> could be controlled by the CA itself), to allow it to issue OCSP
> responses on its behalf.
>
>     The first two cases are non-controverial. Not sure they need to be
> discussed in great detail. The third case is more interesting.
>
> My take on CA Designated Responders:
>      I believe that this is actually the most important way in which
> OCSP responders  will be set up. Most people I talked to, didn't want
> the CA to use its private key to sign OCSP responses. I am not sure
> too many CAs have set up separate keys for signing certs and OCSP
> responses. This means that a CA would need to designate another
> name/public key to create legitimate OCSP responses on its behalf.

Agreed in principle.

>      Ofcourse, it is possible for all clients to set up OOB trust in
> these non-CA responders, but that is basically punting on the difficult
> problem of figuring out how to set up that trust.

>      I believe this protocol should specify how a CA designates another
> entity as its OCSP responder and how one deals with revocation of that
> entity.

Yes.

> Once again, my take on this issue, is that the CA should issue a
> certificate with a particular extension to say that the hold of the
> specified certificate (public key) is a legitimate OCSP responder for
> it.

This would be fine. I hope this is not patented  :-)

> That OCSP responder's certificate should ideally have a short
> validity period and the CA should ensure that the responder's key
> is atleast as well protected as its own. Again, IMHO, I think we
> should NOT specify a CRL based method for checking the responders
> cert for revocation - this method is unlikely to be used by most
> client and makes revocation checking very expensive. Rather,
> I would like to specify up front that a responder's cert can't be
> revoked, so a CA should be VERY, VERY careful in issuing
> responder certificates.

I disagree on this point. Checking that the CA or the OCSP responder is
not revoked would have to be done by checking CRLs. We should only allow
the OSCP responder to be placed on an ARL (Authority Revocation List)
since an ARL is very short (most of the time empty). In order to ease
that local verification we should allow the client to query that ARL
from the OCSP responder.

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:         Wed, 15 Apr 1998 17:17:33 -0700
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 Status Information on a Certificate
To: [email-masked]

Ambarish Malpani wrote:

> Here is a list of the different kinds of status information that an OCSP
> responder may want to return:
>
> 1. Revocation status of a certificate
>     - revoked
>     - on hold
>     - not revoked
>     - don't know about this CA
>     - know about this CA, but not about this cert (??? I am not sure I
>         think this state should ever be returned, but this corresponds
>         to the state where the responder is looking up the CA's database
>         and can't find this entry in the database. Mike, I believe you
>         think this is an important state - is that correct?)

The later would mean that the OCSP responder has access to more
information than just  the CRL. I do not think that this response
usefull for the client. If there were good arguments for keeping it (I
have not been convinced by the arguments from Paul), then this status
should be optional (no guarantee to get it back at any time).

> 2. Expiration status of a certificate
>     - not yet valid (will be valid in the future)
>     - valid (in its validity period)
>     - expired
>     - don't know about the expiration status

> 3. Issued status of the certificate
>     - never issued (no cert with this serial number was ever issued by
>       this CA)
>     - issued
>     - don't know if it was ever issued

> My take on this issue: I believe OCSP is just a revocation status
> protocol, so we should restrict the return status to just revoked,
> onHold, notRevoked, and dontKnowAboutThisCA. This would leave the
> syntax of the protocol simple and the semantics very clear - OCSP
> basically returns the same information that you would get if you
> had a CRL from the CA at the  instant of the response (NOTE: I am
> NOT implying that a CRL is ever issued).

Agreed. Let us keep it simple.

(text deleted)

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:         Wed, 15 Apr 1998 16:52:35 -0700
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: Method of Identifying Certificates
To: [email-masked]

Ambarish,

Here is an answer to one of the many threads that you opened:

> There have been three proposals for identifying certificates:
>
>     1. Hash(Issuer's DN) and the certificate's serial number
>     2. Hash(Issuer's DN and Issuer's Public Key) and the certificate's
>         serial number
>     3. Issuer's DN, Hash(Issuer's Public Key) and the certificate's
>        serial number
>
>     There are two main issues here:
>
>     a. Does the query need to include information about the issuer's
>        public key?
>     b. Should we send the whole Issuer DN, or just it's hash?
>
>     The second issue is a relatively simple one - how important
> is it to save bytes in the query - sending the hash of the issuer's DN
> is much smaller than sending the full DN. However, if we just send
> the hash of the DN, the responder may not be able to reconstruct
> the full DN, so querying a database that is indexed by anything other
> than the hash of the DN might be impossible.

Indeed. So we should send the whole issuer name (which may or may not be
a DN).

>     The first issue is more interesting: I contend that there is
> no way to enforce uniqueness of DN's across the whole world.
> However, public keys better be unique (otherwise you have broken
> the basic premise of public key cryptography).

(text deleted)

>     Fortunately, there is an easy way out of this problem - if we
> include the hash of the issuer's public key as a means of identifying
> the CA, clashes of DNs don't affect OCSP. Also, given that the
> AuthorityKeyIdentifier is going to be mandatory in PKIX, client's
> don't even need to do an additional hashing operation to provide
> this information.

Wait a second, the current definition of AuthorityKeyIdentifier is:

AuthorityKeyIdentifier ::= SEQUENCE {
     keyIdentifier             [0] KeyIdentifier           OPTIONAL,
     authorityCertIssuer       [1] GeneralNames            OPTIONAL,
     authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL

with

   KeyIdentifier ::= OCTET STRING

Which of the three optional fields is going to be mandatory ???
If it is the first one, the content is simply an octet string which may
or *may not* be a hash. What is/was the argument to have this field
mandatory ?

(text deleted)

>     Enough from me. What is the feeling on this issue in this group?
> Should  we include the hash of the issuer's public key to uniquely
> identify the issuer?

We should have that hash as an OPTIONAL element. This hash should be
composed of the hash algo and the hash value.

I originally proposed to have the hash of the certificate itself, i.e.
not the hash of the issuer's public key. This also allows to make the
distinction ... but this would mandate some OCSP responders to have
access to every end-user certificate to make the check. Having access to
the issuer's public key only is easy. If an OCSP responder relies on
CRLs, it needs the issuer's public key anyway, i.e. to check the CRL. So
computing a hash of it is not a big deal.

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:  Tim Polk <[email-masked]>
Date:         Wed, 15 Apr 1998 09:51:33 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Comments: cc: Ambarish Malpani <[email-masked]>
To: [email-masked]

This response has two parts... if you're bored by the first, please skip
down to see if part 2 is of interest.  Thanks!

Part 1: Hashing DNs

 There is a major problem with substituting the hash of an issuer's DN for
the DN itself.  First, the X.501 string matching rules ignore leading and
trailing white space, and compress consecutive white space characters into
a single white space character.  In addition, many of the X.501 Name
subtypes are defined with "caseIgnoreMatch" and "caseIgnoreSubstringsMatch"
.  The result is, c=us matches c=US matches c=uS.

This means that the hash of two DNs may be different, but the DNs may
match.  You need to send the DN.

NOTE: I am drafting new text for the PKIX profile to limit the string
matching burden. The proposed text will limit the pain for implementors by
permitting binary comparison of two strings encoded as UTF8String or
BMPString. It will also relieve implementors of the obligation to map
character sets and match strings encoded as different types.  This limits
the ugliness (ignoring case and compressing white space) to processing
PrintableString. (As I understand it, implementors have already conquered
this piece.) I will distribute that text SOON, on a new thread on this list.

Part 2. DN collisions

>    Some people have argued that if DNs clash, everything in PKIX
>breaks.

Those people are WRONG. The security of PKIX implementations does *not*
rely on the name space. The performance will be degraded by DN collisions,
but implementations will not fail as a result.

Path validation always relies on signatures.  There is no direct security
implication to having n CAs with the same name (say "X").  Certificates
bind a name AND KEY.  If the name is right, but the key is wrong, path
validation will fail.  The impliciations are in the areas of performance,
procedures, and jurisprudence.

Don't get me wrong.  It will be extraordinarily confusing, and path
building software will have a difficult task (n-1 out of n paths
rejected!), but the certificate user won't accept bad paths as a result fo
the name clash.  Of course, if one of the user's trusted CAs has the name
"X" they will have a very difficult time figuring which is the CA X they
want to trust.  That's ugly! And deterimining which CA X is the one to
cross certifiy with would be a nightmare.

The key identifiers do help this situation.  They help the software to find
useful paths quickly.

A final addendum to your story.  Non-aligned country Z's CA (called "Z")
issues certificates to East and West X's CAs, which are using the same name
("X"), with different constraints.  The path validation routines should
work, whether or not the keyidentifers are in use.  East and West X use
different key pairs, so everything works.  (Especially the path validation
software, which works overtime to sort it all out.)

Of course, if the CAs for East and West X both have a copy of the old
private key and both use it, we are up a serious creek. And nothing to
carve a paddle out of either.

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 14 Apr 1998 18:02:03 -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:      [IETF-PKIX] Definition of Secure Initialization
To: [email-masked]

All,

At 10:28 AM 4/14/98 -0700, Warwick wrote:
>>(2) Carlisle Adams noted that secure initialization is not a feature of
>>CMC. After some discussion, there was a straw poll. The sense of the group
>>was that secure initialization should be feature of CMS and should be
>>mandatory to implement. This requirement can be supported using the CRMF
>>message format discussed above.

Recall that we had defined secure initialization as the combination of two
mechanisms: out of band distribution of a trusted public key and out of
band distribution of a pre-authentication token.

As a consequence of some discussions and further thought on our L.A.
discussion, it's clear that latter is overly specific.  It is a mechanism,
not a requirement.  What is required is a high degree of confidence that
the attributes claimed by a certificate applicant are indeed held by that
applicant.

There are three mechanisms by which this assurance can be provided:

1. Use of a pre-authentication token as noted.

2. Use of an LRA's digital signature.

3. Correlation of claimed identity with externally reliable identification
information (two photo IDs, reference

The first two involve technical mechanisms of the protocol.  The third
mechanism is purely operational.

Comments anyone?  Otherwise I'm inclined to require a response to the
requirement as stated but leave the choice of mechanism optional.

The obvious observation is:  We need at least one to ensure
interoperability.  But how do we chose which one, assuming all are equally
responsive mechanisms to the requirement?  One way of making that decision
is to weigh the ease of implementation and deployment.

Approved-By:  "Phillip M. Hallam-Baker" <[email-masked]>
Date:         Tue, 14 Apr 1998 19:30:20 -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: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
To: [email-masked]

>And by the way, wouldn't a simple fix for this  be to amend the standards
>process so that NO standard under consideration may progress past the RFC
>stage until...
>    -    the one year anniversary is exceeded and no patent is applied for,
>    -    or a patent is applied for and licensing rights compliant to some
>"public usage" mode are instituted [This might be an interesting   project
>for some of our mutual ABA friends to look at, the drafting of  the legal
>language for the "public-usage" rights model.]
>    -    or the patent is assigned into the public domain  [ Also another
>project for our ABA friends to draft something for...].

Various people who should know (but may be wrong) tell me that the
one year rule may be about to disappear as a result of the GATT
treaty. No other country has this rule (as far as I am aware) and when
they signed GATT they insisted the US conform to common practice.

I think that what needs to happen is for this to be looked at with
a view to both fixing the loophole and the more general problem
that the premise of IETF process is that we are jointly developing
a standard as 'common property'. The IETF is not going to work
well in the long term if ten people sit round a table contributing
their work for free and afterwards one person demands payment
for the part they contributed.

If I were a member of the IESG my concern here would not
be the specifics of the case but the precedent set. To give an
example I am a member of the Oxford Union which is a
debating society which is regularly addressed by speakers
such as Presidents Carter, Regan, Henry Kissenger etc.
Despite the fact that speakers in that class generally expect
speaking fees in the tens of thousands the President of the
Union is prohibited from paying any speaker (except for travel
expenses) under any circumstances. The rationale being that
the moment you pay one you have to pay everyone and nobody
will do it for free.

The IETF agreement to the PKP license (RSA, D-H) terms was
never intended to set a wider precedent as to the acceptability
of encumbered technology. It was a matter of there being very
little choice, people wanted to use public key cryptography and
the consensus at the time was that access to the PKP patents
(and in particular D-H) was essential if there was to be any
secure email protocol.

Usefull though they may be I don't see that there is a need to
see the patent holder prosper in this case. In the first place
close reading of the patent suggests that the effect we want
may be achievable through mechanisms not covered by the
specific claims. If this proves not to be the case I would much
rather sink several million into solving the problem with hardware
than pay for license fees under these circumstances.

I think that Jeff Schiller is right that the problem is getting
that message to the right people in Nortel/Entrust.

"Millions for defense but not one cent in tribute"

        Phill

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 15:29: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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

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

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

Michael Myers <[email-masked]> scrawled:
>
> A related question:
>
> Given Marc's proposal for separate fields, should we provide guidance
> towards the uniform resolution of ambiguous states in a multi-valued
> response?  I'm concerned about this protocol otherwise introducing into
> clients exploitable behavior caused by less than full coverage of error
> cases.
>

That's a valid concern, and I believe some guidance is required.  As a start,
it might help to list those combinations which should be considerd as
malformed.  First, recall the three status vectors:

    Revocation Status     Expiration Status     Issued Status
    -----------------     -----------------     -------------
    revoked               not yet valid         issued
    on hold               valid                 never issued
    not revoked           expired               unknown
    unknown CA            unknown
    unknown cert

 - If Issued Status is "never issued" then the revocation status MUST be
"unknown cert" and the expiration status MUST be "unknown", otherwise the
response is malformed.  If the responder knows that the cert was never
issued, then the other values are indeterminable.  Note that a responder
can't determine if a certificate was never issued using only CRLs, so a
responder working with CRLs only will never create a "never issued"
response.

 - If Issued Status is "unknown" then the response is well-formed only if the
revocation status is either "not revoked" or "unknown CA".  This is because
if the cert is "revoked" or "on hold" then it is listed in a CRL, and so the
responder knows the cert was issued regardless of whether it is using CRLs or
has direct access to the CA's database.

Also, if Issued Status is "unknown" then "unknown cert" implies "unknown
CA".  Either the responder couldn't find a CRL or database for the cert's
CA, or the responder has a CRL from the CA but the cert isn't listed (so
it's really "not revoked").

 - If Issued Status is "issued" then use the following table to determine if
the response is malformed ("bad") or acceptable ("OK").

  Revocation   ||----------------- Expiration status ---------------
  status       ||  not yet valid  |  valid  |  expired  |  unknown
  =============||=================|=========|===========|===========
  revoked      || OK              | OK      | OK        | OK
  on hold      || bad             | OK      | OK        | OK
  not revoked  || OK              | OK      | OK        | OK
  unknown CA   || bad             | bad     | bad       | bad
  unknown cert || bad             | bad     | bad       | bad

The only way for a responder to know with any certainty that a cert has been
issued is if it has direct access to the CA's database or if the cert is
listed on a CRL.  In either case, responding with "unknown CA" or "unknown
cert" would be wrong.  "Unknown cert" would really mean "never issued" (if
the responder had direct access to a CA's database) or "not revoked" (if the
responder were using CRLs).

Also, I don't believe that a cert would be marked "on hold" before it became
valid.  Either it wouldn't appear on a CRL, or it wouldn't be marked as "on
hold" in the CA's database.  Hence the single "bad" entry in the "on hold"
row.  I'm willing to admit I'm wrong, though.  "On hold" has always been a
semantic riddle to me...

All of this is only to determine if the client should reject a response out
of hand.  The behaviour of a client upon accepting a response -- whether or
not it should accept the cert -- is a matter for the client's local
policies.

One thing this exercise has showed me is that "unknown cert" is really a
useless response value, since it is either bogus or subsumed by other values
(like "unknown CA").

                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:  [email-masked]
Date:         Tue, 14 Apr 1998 14:42:03 -0700
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] Draft LA Minutes
Comments: To: [email-masked]
To: [email-masked]

>Hence the (perceived) need to remove URIs.  But in thinking about this, it
>seems to me that almost anything in a cert can be used to form a network
>operation.  In particular, I'm thinking about the DN itself:  If the presence
>or absence of a cert in a directory is an indication of its status (I think
>Netscape works this way) then can using the DN to look up the cert be
>considered an infringement of the patent?

There's also RFC 2247, which covers encoding a DNS name as a DN.  It's only a
few months old, but it's possible the drafts date back a lot longer (although I
don't know if they go back a year).  Apart from that there's the obvious prior
art like the netscape-X-url attributes which have been in use for awhile.

Where did they file for patents?  Is it the usual US+Canada, or does it cover
other countries as well?

Peter (currently located at least 5000km from the nearest country with software
       patents :-)

Approved-By:  Slava Galperin <[email-masked]>
Date:         Tue, 14 Apr 1998 14:06:16 -0700
Reply-To: [email-masked], [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 Status Information on a Certificate
To: [email-masked]

My responses below is slightly edited and expanded repost of the
original message sent in private exchange with OCSP draft co-authors.

In my analysis below I will refer to the OCSP client classification
outlined in previous messages on OCSP usage scenarios.

On a general note, I do not seem to be able to find examples that would
require different course of action taken by PKI clients for various
negative OCSP responses. Course of action taken by the code in all those
cases is likely to be the same: reject the operation and inform human
operator  for troubleshooting and auditing purpose by either logging or
displaying particular error message. Differentiating between, for
example, revoked and expired(or not yet valid) in OCSP response seems to
only benefit thin clients, since fat clients have validity information
directly from the certificate and OCSP proxy(OCSP responder as a client
in Ambarish's post) do not care at all (more
on this below). I would be certainly interested to hear about practical
examples that do not fall into this category.

Ambarish Malpani wrote:
>
> Here is a list of the different kinds of status information that an OCSP
> responder may want to return:
>
> 1. Revocation status of a certificate
>     - revoked
>     - on hold
>     - not revoked
>     - don't know about this CA
>     - know about this CA, but not about this cert (??? I am not sure I
>         think this state should ever be returned, but this corresponds
>         to the state where the responder is looking up the CA's database
>         and can't find this entry in the database. Mike, I believe you
>         think this is an important state - is that correct?)
>

These status values are the only ones that can be reliably produced by a
responder that only has access to the revocation list (I do not mean
X509 CRL but any data source that contains information about ALL
currently revoked certificates, including those "on hold")
If OCSP definition clearly states that "not revoked" does not assume
"ever issued" or any other validity-related status then it should not be
a problem from OCSP responder liability perspective.

> 2. Expiration status of a certificate
>     - not yet valid (will be valid in the future)
>     - valid (in its validity period)
>     - expired
>     - don't know about the expiration status

Looks like only thin OCSP clients will be able to benefit from this
which means that it should be mandatory OCSP feature only if we find
"thin" clients to be an interesting class.Also validity status has to be
specified relative to some GeneralizedTime value (presumably
producedAt?) in OCSP response  which may not be the same as cleint's
local time. This means that instead of comparing certificate validity
period aginst local time a (thin) client will still have to check the
time from OCSP response and apply necessary logic (the only reasonable
case I can think of is when thin client uses nonce to guarantee response
freshness and does not pay attention to any time-based fields in the
OCSP response). This does not seem to be better than checking the cert
validity in the first place. Having one definition of validity seems to
be better than having two.

>
> 3. Issued status of the certificate
>     - never issued (no cert with this serial number was ever issued by
> this CA)
>     - issued
>     - don't know if it was ever issued

Again looks like only thin OCSP clients will be able to benefit from
this which means that it should be mandatory OCSP feature only if we
find "thin" clients to be an interesting class.
Also This could be easily combined with "Expiration status" above by
extending it with neverIssued value. (Also see below)

>
> My take on this issue: I believe OCSP is just a revocation status
> protocol,
> so we should restrict the return status to just revoked, onHold,
> notRevoked
> and dontKnowAboutThisCA. This would leave the syntax of the protocol
> simple and the semantics very clear - OCSP basically returns the same
> information that you would get if you had a CRL from the CA at the
> instant of the response (NOTE: I am NOT implying that a CRL is ever
> issued).
>
> However, if the consensus of the group is that it is important that all
> three types of states be returned, I would prefer there to be 3
> separate state fields, one for each of the different statii. This would
> allow us to add more states in the future (e.g. whether this certificate
> can be used for a specific kind of operation, or maybe some information
> about the CA of this cert) without affecting these basic status fields.
>
> What do the rest of you on the list feel about this issue:
>     - Should OCSP support one or more of these statuses?
>     - If we support multiple of these states, should we define separate
>         fields, or should we merge all states into one field?
>

Although I am personally in favor of only supporting revoked,
notRevoked, onHold and unknown statuses, I would like to propose the
following response structure which will accomodate both revocation (as
mandatory) and validity(as optional) status and will
put minimal overhead both in terms of size and implementation difficulty
for implementer that only wants to support the revocation status:

CertStatus ::= SEQUENCE {
    revocationStatus   RevocationStatus,
    validityStatus    ValidityStatus OPTIONAL
}

RevocationStatus ::= CHOICE {
        unknown      [0] IMPLICIT UnknownInfo,
        notRevoked   [1] IMPLICIT NULL,
        revoked      [2] IMPLICIT RevokedInfo,
        onHold       [3] IMPLICIT OnHoldInfo, -- revoked and
}

UnknownInfo ::= NULL -- this can be replaced with an enumeration
                     -- for various specific reasons such as doNotKnowAboutCA etc.

RevokedInfo ::= GeneralizedTime -- this could be extended to include
revocation reason or other relevant info
                                -- in this case also "revoked" can be combined with "onHold"

OnHoldInfo ::= NULL

ValidityStatus ::= ENUMERATED {
    unknown           (0),  --certificate information is not available
    neverIssued       (1)   --certificate was never issued
    notYetValid       (2),  --Cert is not yet valid as of producedAt
    valid             (3),  --Cert is valid as of producedAt (NOTE this
does not imply notRevoked !)
    expired           (4),  --Cert is expired as of producedAt
}

Note that here I am using discriminating context-specific tags in CHOICE
for RevocationStatus as a substitute for the ENUMERATED status values
which should satisfy both implmentation simplicity and extensibility.
This also elimiminates the need to specify constraints on values that
carry additional status-specific data because it is recorded directly in
the ASN.1
type structure.

I would be very interested in your feedback on this.

-- Slava

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Tue, 14 Apr 1998 13:54: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

>Once again:
>
>nextUpdate - a GeneralizedTime, which specifies when newer information
>        will be available from this CA. Has the same semantics as the
>        nextUpdate time in CRLs. There is a nextUpdate field with every
>        cert whose status is known. There is no guarantee that
>        revocation information will not be updated before nextUpdate
>        (just as there is no guarantee that a CRL will not be issued
>        before nextUpdate).
>
>Do you agree with this statement?

Yes, that seems fine. It matches PKIX part 1, which is what we should be
doing.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 13:29:30 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] Draft LA Minutes
To: [email-masked]

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

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

Bob Jueneman <[email-masked]> scrawled:
>
> I want to make sure that we are not throwing the baby out with the bath in
> retaliation against Entrust.
>
> In particular, I strongly object to the removal of the URI semantics for
> altnames,
> which might very well have many other valid uses, not the least of which
> might be an http, ftp, or ldap pointer to the issuer's certificate.
>

The question of why URIs are affected was raised at the meeting.  If I
remember right, the patent is broad enough that it may cover _any_ pointer in
a cert that may entail a network operation to retrieve the cert's status.
The patent's abstract says "[The method] is also applied more generally to
update any field in a certificate by reference to a secondary source of
authenticated information."  So it may apply to any network operation
derived from the contents of a certificate (of course, IANAL).

Hence the (perceived) need to remove URIs.  But in thinking about this, it
seems to me that almost anything in a cert can be used to form a network
operation.  In particular, I'm thinking about the DN itself:  If the
presence or absence of a cert in a directory is an indication of its status
(I think Netscape works this way) then can using the DN to look up the cert
be considered an infringement of the patent?

Obviously, there's some prior art here that makes the idea ludicrous.  But
since the IETF isn't into challenging belligerent patents, perhaps it needs
to consider its willingness to use certificates at all.  After all, a DN is
really just a special form of URI.

Just stirrin' the feces...  :)

                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:  "David P. Kemp" <[email-masked]>
Date:         Tue, 14 Apr 1998 15:11:13 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

> From: Marc Branchaud <[email-masked]>
>
> I do have a problem with something that even resembles and "expiration time"
> though, so if your concerns aren't addressed by the draft I'll be happy to
> revisit the issue.

I'll certainly reserve judgement until seeing the draft.  But at a
general level, I'll note that if the CA response contains only a
response creation time, then that leaves the RP without any guidance
as to what freshness threshold to use.  Some may think that is a
reasonable situation - after all, the RP is ultimately in charge of
whom he trusts and for what.

However, not providing a nextUpdate or expiration field in the response
allows a CA to claim "We support online status checking" but leaves
quality of service completely unspecified.  The CA could generate
status responses hourly or every 8 or 24 hours, and if RPs choose not
to be satisfied with the freshness of those responses, tough luck.

Goods on supermarket shelves are marked with expiration dates.  It
would have been far less helpful to mark them with manufacture dates,
leaving it entirely to the consumer to determine the point at which
they become too stale.

Similarly, one CA's CPS may guarantee 15 minute revocation response
time and another might guarantee 24 hours.  How is that information
communicated to RP software?  Sure, it might in theory be possible to
map Certificate Policies into quality-of-service parameters which are
then configured into the RP software, but that sounds like a management
nightmare.  It would be far more straightforward for the expiration
time to be included in the OCSP response.  That way, the software knows
exactly what it's getting without involving error-prone human
configuration.  An expiration field forces the CA to explicitly declare
it's response time claims in a form that can easily be verified.
This, IMHO, is a Good Thing.

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 11:50:35 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

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

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

Ambarish Malpani <[email-masked]> scrawled:
>
> We are proposing that OCSP responses have the following fields:
>
>     producedAt - a GeneralizedTime that indicates the time at which this
>         response was produced/signed. There is only one producedAt time
>         in the response (irrespective of how many certs are included in
>         the response)

I don't think that having only one producedAt time in a response is the right
way to go.  Suppose an OCSP server is an aggregate for two CAs. Further,
suppose that the server has direct access to one CA's database, while it
receives CRLs from the other.  To make things even more obvious, let's say
that when it receives a CRL, it pre-processes "revoked" responses for all the
listed certs (thus setting a producedAt time for each response derived from
the CRL).

Now a client may make a single request specifying two certificates, one from
each CA.  The server then has to choose which producedAt time to use, but
neither time is correct for both certs.

The solution is to either have a producedAt for each cert in a response, or
to allow multiple responses to a single request (which would require some
kind of message ID).  I'll have to think a bit more before deciding which one
I like best.

                 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:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 11:36:53 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

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

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

Ambarish Malpani <[email-masked]> scrawled:
>
>     nextUpdate - a GeneralizedTime, which specifies when newer information
>         will be available from this CA. Has the same semantics as the
>         nextUpdate time in CRLs. There is a nextUpdate field with every
>         cert whose status is known. There is no guarantee that revocation
>         information will not be updated before nextUpdate (just as there is
>         no guarantee that a CRL will not be issued before nextUpdate).
>
>     There has been some argument that by providing nextUpdate, a
> responder is dictating caching policy. I disagree. Clients/caches may
> decide to use or not use nextUpdate when considering caching policy.
> Just as nextUpdate is simply a hint in CRLs of when a new CRL is expected,
> nextUpdate is a hint in OCSP responses of when new revocation data is
> expected from this CA.
>

I'm really not a fan of nextUpdate...  :)

nextUpdate is being touted as a "definitely check after" time.  I contend
that the value is either meaningless or dangerous to a relying party.

It is especially meaningless when status information is obtained directly
from the CA database.  It's been suggested that such responders set
nextUpdate = thisUpdate = producedAt, but that seems terribly wasteful.

But even when status is based on CRLs (or some other periodic method),
nextUpdate is more like data than information.  It can provide RPs with a
false sense of security, leading them to believe that they won't have to
check status until nextUpdate.

As Dave Kemp implied, what the RP really needs is an idea of how fresh the
response is.  Savvy RPs that have read & understood the spec will basically
ignore nextUpdate in favour of their idea of the response's freshness.
Ignorant RPs will blindly accept nextUpdate as some formal kind of guideline,
and some will inevitably get burned.

In the first case, nextUpdate is useless, extraneous data.  In the second,
it's dangerous and misleading.  For these reasons, I think nextUpdate
shouldn't be used at all.

Paul Hoffman suggested that a formally-defined nextUpdate could be used to
get around broken HTTP caches.  There are other ways around this problem,
such as using POST.  Also, adding nextUpdate solely to fix broken HTTP
caching is really taking the protocol-independence out of OCSP.

Finally, I'd like to note that the ideas behind thisUpdate and nextUpdate
are taken directly from CRLs, and CRLs are considered by many to be an
unacceptable way of handling revocation.  Also, with the removal of CRL
distributions points, how effectively PKIX can support CRLs is even more
questionable.  My point is that there's no indication that CRLs will become
the normal way of revoking a certificate.  If that's the case, then forcing
OCSP to always use these mostly-ignored fields is a bad thing to do.

Yes, I am essentially saying that all OCSP really needs is producedAt.

                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:  Michael Myers <[email-masked]>
Date:         Tue, 14 Apr 1998 11:35:52 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

A related question:

Given Marc's proposal for separate fields, should we provide guidance
towards the uniform resolution of ambiguous states in a multi-valued
response?  I'm concerned about this protocol otherwise introducing into
clients exploitable behavior caused by less than full coverage of error cases.

For example, given the following hypothetical responses:

{revoked, not issued}
{revoked, not found}
{revoked, issued}
{revoked}

is the requester behavior upon receipt identical in all cases?  Some of
these are clearly bogus but are nonetheless producible.

At 10:24 AM 4/14/98 -0700, Marc Branchaud wrote:
>>     - If we support multiple of these states, should we define separate
>>         fields, or should we merge all states into one field?
>>
>
>Separate fields.  Using something like notRevoked == exists is just too
>confusing, and isn't always true either.
>
>                Marc

Approved-By:  Slava Galperin <[email-masked]>
Date:         Tue, 14 Apr 1998 11:28:44 -0700
Reply-To: [email-masked], [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 Usage Scenarios
To: [email-masked]

Ambarish Malpani wrote:
>
> Steve (Kent) had requested a description of the ways in which OCSP
> would be used. Here are the scenarios I can think of:
>
>     I see the following types of OCSP responders:
>
<snip>

I guess this classification can be expressed in more compact terms:

- type of certificate information a responder has access to (full
certificate state history or recent revocation data(not necessarily
X.509 CRL) only)
- type of trust model assumed (what key is used to sign OCSP
response(same as CA signing or different) and how client's trust to that
key is established (by trusting the key directly in client's local trust
policy or by delegation using some sort of certificate chain))

>
>     OCSP Clients:

OCSP client classification presented here is an edited version from my
original message sent in a private exchange with OCSP draft co-authors.
I feel that editing had left out some important (IMHO) details (and
questions) from the original text. I decided to include the full quote
to get feedback to my questions from a wider audience.

<SLIGHTLY MODIFIED QUOTE>
I guess from pragmatical perspective it would be more productive to
focus first on the classifications of OCSP clients and then on OCSP
responders
in this section. Once we agree upon classes of clients it will be
clearer what classes of responders and what kind of trust model is
necessary to support these clients.

I can count the following client classes

        fat PKI client
                this client has full access to certificate chain and
local trust
policy (which includes necessary trusted public keys in raw or X.509
certificate form) and performs full certificate validation logic
including signature verification and validity checks. This client only
needs up-to-date revocation status of every certificate in the
chain(preferrably retrieved in ONE network round-trip)

        thin PKI client
                this client also has full access to certificate chain
but is limited
in certificate validation capabilites, instead it delegates non-trivial
certificate validation logic to trusted server. However it has to
minimally be able to verify signatures on OCSP responses (including
time-stamps or nonce verification) and have rudimentary local trust
policy (at least trusted public key for OCSP provider). I am not sure
how large is this class of clients (embedded systems like VPN boxes ?)
and how interesting it is to support

        OCSP proxy
                untrusted enterprise-local transponder that consolidates
OCSP traffic
and configuration and provides local caching facility. This does not
necessarily has access to the entire certificate, but it does not seem
to be required to interpret requests and responses other than doing
superficial matching and freshness calculations

What else is missing ?
</SLIGHTLY MODIFIED QUOTE>

>
>     - Fat client
>         A client that understands certificates, signatures and time. It can
> check the certificate by itself and mainly wants a responder to specify
> the
> revocation status of a certificate
>
>     - Thin client
>         Understands signature verification. Doesn't necessarily understand
> time.
> Would like the OCSP responder to indicate whether the certificate has
> expired
> or not (which raises the question of how this client verifies the times
> on an
> OCSP response).
>
>     - OCSP responder as a client
>         An OCSP responder forwards an OCSP query to another responder.
>
>

Approved-By:  Paul Koning <[email-masked]>
Date:         Tue, 14 Apr 1998 13:53: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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

>>>>> "Andreas" == Andreas Berger <[email-masked]> writes:

 Andreas> Some comments on the key identifier / authority identifier
 Andreas> issue that was recently discussed on this list:

 Andreas> Let's assume I have a certificate of someone on my system
 Andreas> that is about to be verified. Usually I would begin by
 Andreas> retrieving all certificates of authority described by the
 Andreas> issuer and the issuer alternative name (the exact process is
 Andreas> outside the scope of this discussion). The result is a set
 Andreas> of certificates.

 Andreas> Now I have to find out, which Authority Certificate was used
 Andreas> to sign the User Certificate I am currently holding. I can
 Andreas> do this by using all public keys in the Authority
 Andreas> Certificates an trying to verify the User Certificate's
 Andreas> signature. For any attempt that fails, I can rule out all
 Andreas> Authority Certificates which contain the same public key
 Andreas> that I have just tried. This process leaves me with a set of
 Andreas> certificates which all contain the same public key and this
 Andreas> key was used to sign the User Certificate. Key Identifiers
 Andreas> can help me with this process so that I do not have to make
 Andreas> a series of signature verifications, those a reduced to an
 Andreas> octet string comparison. Question: is it worth the effort to
 Andreas> save these verification steps? How many different public
 Andreas> keys do we expect a CA to have? more that a handful (let's
 Andreas> say 10)? Only if the number of keys held by the same CA is
 Andreas> large the key identifier will help.

Given the cost of signature check, I would say that key identifiers
are valuable if they save just ONE signature check.  In other words,
I should have enough information such that I get zero signature check
failures in verifying a valid certificate chain.  Anything less is
unreasonable from a performance point of view.

(Another argument is that check failure can otherwise come from two
causes: corrupt/invalid certificate, and wrong key.  The former is
serious, the latter is not in the scenario you gave; how would I
decide what error to log if I cannot tell the difference between these
two causes?)

        paul

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Tue, 14 Apr 1998 10:53:53 -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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP Usage Scenarios
To: [email-masked]

Marc Branchaud wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Content-Type: text/plain; charset=us-ascii
>
> A good list, but how is a "Revocation Aggregator" any different from a
> "Mirror of a Responder"?  The mirror is just a special case of the
> aggregator.
>
>                 Marc
>

Hi Marc,
    The scenarios were not meant to be significantly different - just
wanted a description of all the different ways in which OCSP could
be used, so that when we come up with the spec, we make sure all the
cases are addressed.

Anyway, the "Mirror of Responder" might just collect revocation data
for a single CA, while an aggregator would collect revocation info
from varous CAs.

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:  Ambarish Malpani <[email-masked]>
Date:         Tue, 14 Apr 1998 10:48:51 -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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

Hi Paul,
    My mail about the description of nextUpdate doesn't contain the
word "hint" any more. In my set of mails, I tried to reflect the
issues as they currently stand - the spec is a little old. I would
like to be able to gauge peoples feelings on various issues (hopefully
over the next two weeks), before we come out with the next version of
the spec.

Once again:

nextUpdate - a GeneralizedTime, which specifies when newer information
        will be available from this CA. Has the same semantics as the
        nextUpdate time in CRLs. There is a nextUpdate field with every
        cert whose status is known. There is no guarantee that
        revocation information will not be updated before nextUpdate
        (just as there is no guarantee that a CRL will not be issued
        before nextUpdate).

Do you agree with this statement?

Regards,
Ambarish

Paul Hoffman / IMC wrote:
>
> At 06:50 PM 4/13/98 -0700, Ambarish Malpani wrote:
> >Just as
> >nextUpdate
> >is simply a hint in CRLs of when a new CRL is expected, nextUpdate is a
> >hint in OCSP responses of when new revocation data is expected from this
> >CA.
>
> I strongly disagree with the word "hint". In both the CRL and OCSP case,
> the nextUpdate is the time at which it is guaranteed that a new response
> will be issued. If you go to the primary CRL or OCSP distributor and it is
> issuing responses with nextUpdate before the current time, they are
> non-conformant. That's not a hint, it's a mandate.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

--
---------------------------------------------------------------------
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:         Tue, 14 Apr 1998 13:06:31 +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: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      Re: [IETF-PKIX] LDAP v2 schema - object classes for users and CAs
To: [email-masked]

Sean Turner wrote:

> Why weren't the object classes strongAuthenticationUser and
> certificationAuthority (from X.521) used for storing user and CA certs in the directory?
>
> In the case of the pkiUser, the object class is the same as strongAuthenticationUser,
> except for the name and oid.  So, couldn't we just reuse the object class from X.521?

I think that strongAuthenticationUser is more appropriate to designate a
"user that uses strong authentication *to communication with the
directory*" and should not necessarily be used to store certificates for
any other purpose. Specifically, the strongAuthenticationUser needs a
certificate that has a DN that matches the entry, since DNs are most
appropriate to describe a directory entry. A PKIX Certificate can have
just an eMail address and that cannot be easily mapped onto a directory
DN.

I think that we need attributes that hold certificates for various
purposes and strongAuthenticationUser is too narrow for that purpose.

Andreas
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Tue, 14 Apr 1998 10:28:26 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Draft LA Minutes
To: [email-masked]

A few important changes to the draft minutes.

>The S/MIME group has requested that issuer DN be
>required.

That's not true, and I don't think that's what Tim said. Some people, who
happen to also work on S/MIME, discovered a logic problem with chaining
through
AltNames. The problem completely goes away when we require CAs (not end
entities) to have filled-in subject names and that they chain through their
issuer names.

>Ambarish Galpani

Make that "Ambarish Malpani".

>Paul Hoffman raised the question of possible pending patents impacting CRMF
>and CMC, and suggested that the Chairs try to get commitments from authors
>that there are no patent encumbrances.

I explicitly said "no current or anticipated patent encumbrances." This is to
prevent the problem of a draft author or a chair knowing that a relevant
patent
application had been filed but not yet issued. I can understand how the
minutes
taker might have missed this distinction, but I think it is an important one.

>(2) Carlisle Adams noted that secure initialization is not a feature of
>CMC. After some discussion, there was a straw poll. The sense of the group
>was that secure initialization should be feature of CMS and should be
>mandatory to implement. This requirement can be supported using the CRMF
>message format discussed above.

I also brought up the idea that CMC and CMP should both offer CAs the same
services so that a CA vendor doesn't have to implement both in order to get
all
the services needed by their application. If we as a WG want to come out with
two parallel protocols to do the same thing, we should be real sure they do
the
same thing.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 10:24: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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

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

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

Ambarish Malpani <[email-masked]> scrawled:
>
>     - Should OCSP support one or more of these statuses?

I'm indifferent here.  I can see good points for revocation-only or
multi-status responses.

>     - If we support multiple of these states, should we define separate
>         fields, or should we merge all states into one field?
>

Separate fields.  Using something like notRevoked == exists is just too
confusing, and isn't always true either.

                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:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 10:20:42 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Usage Scenarios
To: [email-masked]

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

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

A good list, but how is a "Revocation Aggregator" any different from a
"Mirror of a Responder"?  The mirror is just a special case of the
aggregator.

                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: [email-masked]
Date:         Tue, 14 Apr 1998 16:39:42 +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: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Some comments on the key identifier / authority identifier issue that
was recently discussed on this list:

Let's assume I have a certificate of someone on my system that is about
to be verified. Usually I would begin by retrieving all certificates of
authority described by the issuer and the issuer alternative name (the
exact process is outside the scope of this discussion). The result is a
set of certificates.

Now I have to find out, which Authority Certificate was used to sign the
User Certificate I am currently holding. I can do this by using all
public keys in the Authority Certificates an trying to verify the User
Certificate's signature. For any attempt that fails, I can rule out all
Authority Certificates which contain the same public key that I have
just tried. This process leaves me with a set of certificates which all
contain the same public key and this key was used to sign the User
Certificate. Key Identifiers can help me with this process so that I do
not have to make a series of signature verifications, those a reduced to
an octet string comparison. Question: is it worth the effort to save
these verification steps? How many different public keys do we expect a
CA to have? more that a handful (let's say 10)? Only if the number of
keys held by the same CA is large the key identifier will help.

Now for the Authority Identifier. Again, I am at the point where I have
just retrieved the set of certificates. Given the issuer and serial of
the signing authority for that CA, I can quickly identify the single
certificate that should be used for verification. In fact, it is would
be possible to retrieve just this single certificate and not retrieving
the complete set.

I have one problem with this approach: The verification path is not
fixed. Let us assume a CA gets certified by a set of other CAs. Some
users trust one of them, others some other CAs (which is why the CA
probably got this multiple certificates). When a user certificate
contains a reference to a single other CA, a user which does not trust a
specific CA will fail to verify the certificate, although there might be
a another path which would lead to a successful verification.

This situation can be solved, if we define that: an application may
first try the specific certificate defined and then defaults back to the
"try and search" algorithm.

One question: Do we have an algorithm for a complete verification? There
is one that describes how to verify an existing FC path, but do we have
an algorithm on how to construct a path? Shouldn't the path be
constructed and verified from bottom up?

Andreas
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 14 Apr 1998 10:06:54 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP at IETF
To: [email-masked]

All,

We are aiming to accumulate comments these comments and produce a new draft
in roughly two weeks' time.  Your prompt response would be appreciated to
help us develop a sense of the group's consensus.

Mike

At 05:36 PM 4/13/98 -0700, Ambarish Malpani wrote:
>Hi All,
>     Great meeting a whole bunch of you at IETF.
>
>     I am going to post a set of emails about the issues raised about
>OCSP, to start a set of threads on topics in OCSP.
>
>Here is a summary of the topics that will be covered in the mails to
>follow:
>
>    - OCSP Usage Scenarios (as requested by Steve Kent)
>    - Status Information on a Certificate
>    - Types of OCSP Responders
>    - Method of identifying certs
>    - Semantics of thisUpdate, nextUpdate, producedAt
>    - Extended error states in responses
>    - Caching
>
>If you have input on any of these topics, please do the the mailing
>list know, so that we can address those concerns ASAP, reach a
>concensus about OCSP and finish up this project.
>
>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:  Bob Jueneman <[email-masked]>
Date:         Tue, 14 Apr 1998 10:49:25 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Draft LA Minutes
Comments: To: [email-masked]
To: [email-masked]

>
>Beyond these minor issues, the document is currently stuck in last call
>owing to patent issues resulting from an Entrust patent issued in December.
> Tim proposed that all text relating to unresolved issues be removed to a
>separate I-D, and the rest of the document be progressed immediately to
>Proposed Draft.  This means removing CRL distribution points, authority
>access info, and some policy qualifiers, and removing URI semantics from
>altnames.  (Sections impacted: Policy Qualifiers, CRL Distribution Points,
>and Issuing Distribution Points.)  Steve Kent reported that the Area
>Director had agreed with this approach.  A straw poll of those present
>indicated strong support for and no support against this approach.

I want to make sure that we are not throwing the baby out with the bath in
retaliation against Entrust.

In particular, I strongly object to the removal of the URI semantics for altnames,
which might very well have many other valid uses, not the least of which
might be an http, ftp, or ldap pointer to the issuer's certificate.

Bob

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 13 Apr 1998 19:20: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

At 06:50 PM 4/13/98 -0700, Ambarish Malpani wrote:
>Just as
>nextUpdate
>is simply a hint in CRLs of when a new CRL is expected, nextUpdate is a
>hint in OCSP responses of when new revocation data is expected from this
>CA.

I strongly disagree with the word "hint". In both the CRL and OCSP case,
the nextUpdate is the time at which it is guaranteed that a new response
will be issued. If you go to the primary CRL or OCSP distributor and it is
issuing responses with nextUpdate before the current time, they are
non-conformant. That's not a hint, it's a mandate.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 13 Apr 1998 19:08:33 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

At 06:04 PM 4/13/98 -0700, Ambarish Malpani wrote:
>    - know about this CA, but not about this cert (??? I am not sure I
>        think this state should ever be returned, but this corresponds
>        to the state where the responder is looking up the CA's database
>        and can't find this entry in the database. Mike, I believe you
>        think this is an important state - is that correct?)

I can think of many reasons to return this. The database is down but is
expected to come up in the future. The responder got an internal error from
its database query. There is a network problem between the database and the
responder. This response says "if you try again later, you'll probably get
one of the other response types." In the email world, we have found this
kind of response very valuable.

>    - Should OCSP support one or more of these statuses?

All three.

>    - If we support multiple of these states, should we define separate
>        fields, or should we merge all states into one field?

Separate.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 13 Apr 1998 19:15:11 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]

Good story, and a believable one. I think including some information about
the issuer's public key in the request is very important, possibly crucial.

>    1. Hash(Issuer's DN) and the certificate's serial number
>    2. Hash(Issuer's DN and Issuer's Public Key) and the certificate's
>        serial number
>    3. Issuer's DN, Hash(Issuer's Public Key) and the certificate's
>serial
>        number

1 won't work for the case you're worried about. Assuming that the OCSP
responder has a limited number of CAs for whom it is responding, either 2
or 3 should work fine. The choice is smaller number of bytes sent (2 would
be better) or smaller number of bytes over which the hash is computerd (3
would be better). I'm sure others have at least one opinion about these two
choices.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Mon, 13 Apr 1998 18:51: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP: Extended Error States in Responses
To: [email-masked]

OCSP as currently defined, defines a bunch of extended error
responses,
including things like CA's cert revoked etc. I think a responder should
NOT provide information about the CA at all. It is being asked about a
particular certificate and that is what it should respond about. It is
possible that a CA is certified by two other CA's, in addition to being
self-certified - in that case, saying a CA is revoked would really
depend
on the chain the client is interested in, which is not specified in a
given
request. If a client wants to check a chain, it should check a each
level
of the chain.
    I believe the responses for the revocation status of a cert should
be:
revoked, onHold, notRevoked, dontKnowAboutThisCA

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, 13 Apr 1998 18:50:45 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

We are proposing that OCSP responses have the following fields:

    producedAt - a GeneralizedTime that indicates the time at which this
        response was produced/signed. There is only one producedAt time
        in the response (irrespective of how many certs are included in
        the response)
    thisUpdate - a GeneralizedTime, which specifies the time at which
the
        response was known to be current - basically the time at which
        the CA's database was looked up. It may or may not have the same
        value as producedAt. There is a thisUpdate field with every cert
        whose status is known. Corresponds to the thisUpdate in a CRL.
    nextUpdate - a GeneralizedTime, which specifies when newer
information
        will be available from this CA. Has the same semantics as the
        nextUpdate time in CRLs. There is a nextUpdate field with every
        cert whose status is known. There is no guarantee that revocation
        information will not be updated before nextUpdate (just as there is
        no guarantee that a CRL will not be issued before nextUpdate).

    There has been some argument that by providing nextUpdate, a
responder
is dictating caching policy. I disagree. Clients/caches may decide to
use
or not use nextUpdate when considering caching policy. Just as
nextUpdate
is simply a hint in CRLs of when a new CRL is expected, nextUpdate is a
hint in OCSP responses of when new revocation data is expected from this
CA.

Comments?

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, 13 Apr 1998 18:06: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]

There have been three proposals for identifying certificates:

    1. Hash(Issuer's DN) and the certificate's serial number
    2. Hash(Issuer's DN and Issuer's Public Key) and the certificate's
        serial number
    3. Issuer's DN, Hash(Issuer's Public Key) and the certificate's
serial
        number

    There are two main issues here:
    a. Does the query need to include information about the issuer's
public
        key?
    b. Should we send the whole Issuer DN, or just it's hash?

    The second issue is a relatively simple one - how important is it to
save bytes in the query - sending the hash of the issuer's DN is much
smaller than sending the full DN. However, if we just send the hash of
the
DN, the responder may not be able to reconstruct the full DN, so
querying
a database that is indexed by anything other than the hash of the DN
might
be impossible.

    The first issue is more interesting: I contend that there is not way
to enforce uniqueness of DN's across the whole world. However, public
keys
better be unique (otherwise you have broken the basic premise of public
key cryptography).
    Consider the following (slightly long winded) story:

    Once upon a time, there was a country X, which has a famous CA,
CA of X. One year, it had a revolution, which resulted in the country
being divided into East X and West X. The U.S. supported West X, while
China supported East X. Ofcourse, both nations wanted to retain the name
CA of X, since it was well known across the world. Neither of them
continued to use the same public key (since both sides knew the
corresponding
private key), but both wanted to use the original DN.
    The issue of who would be allowed to retain the original DN was
taken
to the International Court in the Hague, but in the meantime,
Switzerland,
which was running a global OCSP responder, needed to figure out which
country's CA of X it would support.

    Fortunately, there is an easy way out of this problem - if we
include
the hash of the issuer's public key as a means of identifying the CA,
clashes of DNs don't affect OCSP. Also, given that the
AuthorityKeyIdentifier
is going to be mandatory in PKIX, client's don't even need to do an
additional hashing operation to provide this information.

    Some people have argued that if DNs clash, everything in PKIX
breaks. I
would like to make the following points:
    - Just because something else breaks, you shouldn't design your
        protocols with the same weaknesses.
    - In most of PKIX, along with a name, you also have a signature.
This
        signature implicitly identifies the public key associated with that
        name.
    - It is quite possible that even if issuer DNs clash, most domains
        will never see that clash, because they only trust one of the issuers
        with that DN. The only person who sees that clash might be an OCSP
        responder that tries to collect revocation data from all issuers.

    Enough from me. What is the feeling on this issue in this group?
Should
we include the hash of the issuer's public key to uniquely identify the
issuer?

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, 13 Apr 1998 18:05: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] Types of OCSP Responders
To: [email-masked]

I believe there are three types of OCSP responders:

- CA Responders
    Where a CA signs OCSP responses - either with the same key as it
used to
sign certificates, or with a different key (one reserved for OCSP
responses)

- Client-Trusted Responders
    Where a particular client decides to trust a particular OCSP
responder
to sign all/some OCSP responses for it. The client establishes this
trust
in a out of band(OOB) method and uses that same OOB method to check for
revocation, change of public key of responder, etc.

- CA Designated Responders
    Where a CA assigns a special certificate to another entity (which
could be controlled by the CA itself), to allow it to issue OCSP
responses
on its behalf.

    The first two cases are non-controverial. Not sure they need to be
discussed in great detail. The third case is more interesting.

My take on CA Designated Responders:
     I believe that this is actually the most important way in which
OCSP responders  will be set up. Most people I talked to, didn't want
the
CA to use its private key to sign OCSP responses. I am not sure too many
CAs have set up separate keys for signing certs and OCSP responses. This
means that a CA would need to designate another name/public key to
create
legitimate OCSP responses on its behalf.
     Ofcourse, it is possible for all clients to set up OOB trust in
these
non-CA responders, but that is basically punting on the difficult
problem
of figuring out how to set up that trust.
     I believe this protocol should specify how a CA designates another
entity as its OCSP responder and how one deals with revocation of that
entity. Once again, my take on this issue, is that the CA should issue a
certificate with a particular extension to say that the hold of the
specified certificate (public key) is a legitimate OCSP responder for
it. That OCSP responder's certificate should ideally have a short
validity
period and the CA should ensure that the responder's key is atleast as
well
protected as its own. Again, IMHO, I think we should NOT specify a CRL
based method for checking the responders cert for revocation - this
method
is unlikely to be used by most client and makes revocation checking very
expensive. Rather, I would like to specify up front that a responder's
cert can't be revoked, so a CA should be VERY, VERY careful in issuing
responder certificates.

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, 13 Apr 1998 18:04:14 -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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

Here is a list of the different kinds of status information that an OCSP
responder may want to return:

1. Revocation status of a certificate
    - revoked
    - on hold
    - not revoked
    - don't know about this CA
    - know about this CA, but not about this cert (??? I am not sure I
        think this state should ever be returned, but this corresponds
        to the state where the responder is looking up the CA's database
        and can't find this entry in the database. Mike, I believe you
        think this is an important state - is that correct?)

2. Expiration status of a certificate
    - not yet valid (will be valid in the future)
    - valid (in its validity period)
    - expired
    - don't know about the expiration status

3. Issued status of the certificate
    - never issued (no cert with this serial number was ever issued by
this CA)
    - issued
    - don't know if it was ever issued

My take on this issue: I believe OCSP is just a revocation status
protocol,
so we should restrict the return status to just revoked, onHold,
notRevoked
and dontKnowAboutThisCA. This would leave the syntax of the protocol
simple and the semantics very clear - OCSP basically returns the same
information that you would get if you had a CRL from the CA at the
instant of the response (NOTE: I am NOT implying that a CRL is ever
issued).

However, if the consensus of the group is that it is important that all
three types of states be returned, I would prefer there to be 3
separate state fields, one for each of the different statii. This would
allow us to add more states in the future (e.g. whether this certificate
can be used for a specific kind of operation, or maybe some information
about the CA of this cert) without affecting these basic status fields.

What do the rest of you on the list feel about this issue:
    - Should OCSP support one or more of these statuses?
    - If we support multiple of these states, should we define separate
        fields, or should we merge all states into one field?

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, 13 Apr 1998 18:01: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP Usage Scenarios
To: [email-masked]

Steve (Kent) had requested a description of the ways in which OCSP
would be used. Here are the scenarios I can think of:

    I see the following types of OCSP responders:

    - Revocation Aggregator
        Certain people could aggregate revocation information from various
CAs and provide OCSP responses for those CAs. The aggregator could rely
on CRLs for revocation data or use some other means to get that
information
from various CAs.

    - Next-to-CA Responder
        An OCSP responder could run next to the CA, where is imports
revocation information from the CA and provides it to requestors as OCSP
responses. There are two models here:
        a. The responder can read the CAs database directly, so that it
knows as much as the CA about the status of a certificate - whether it
was
ever issued, whether it has expired, or is not yet valid etc.
        b. The responder can't read the CAs database directly and relies
on the CA shipping it the information as either a CRL or in some other
format.

    - Mirror of a Responder
        For huge enterprises, with offices in say Korea and California,
the enterprise might want to have one responder next the the CA in
Korea, with
a second responder in California, to allow fast access to the data in
California. Once again, the California responder might need to
periodically
get updates from the responder/CA in Korea about the latest revocation
information.

    - Fetching Responder
        Some enterprises may choose to run an OCSP responder which is capable
of querrying other OCSP responders/CRLs for revocation status. If a
response
is received from another OCSP responder, it might ship that response as
is, or might use the original responder's response to create its own
response.
The second scenario would require a client to only trust a single OCSP
responder.

It is possible for a single responder to act in all of the above modes
at
one time.

    OCSP Clients:

    - Fat client
        A client that understands certificates, signatures and time. It can
check the certificate by itself and mainly wants a responder to specify
the
revocation status of a certificate

    - Thin client
        Understands signature verification. Doesn't necessarily understand
time.
Would like the OCSP responder to indicate whether the certificate has
expired
or not (which raises the question of how this client verifies the times
on an
OCSP response).

    - OCSP responder as a client
        An OCSP responder forwards an OCSP query to another responder.

A single client could send requests to one or more OCSP responders or
types of
OCSP responders.

Hopefully these scenarios cover the different ways in which people might
want to run/use OCSP responders. If anybody has some additional
scenarios
that a materially different, or if you think one or more of these
scenarios
can't happen, please share it with this list.

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, 13 Apr 1998 17:36: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP at IETF
To: [email-masked]

Hi All,
     Great meeting a whole bunch of you at IETF.

     I am going to post a set of emails about the issues raised about
OCSP, to start a set of threads on topics in OCSP.

Here is a summary of the topics that will be covered in the mails to
follow:

    - OCSP Usage Scenarios (as requested by Steve Kent)
    - Status Information on a Certificate
    - Types of OCSP Responders
    - Method of identifying certs
    - Semantics of thisUpdate, nextUpdate, producedAt
    - Extended error states in responses
    - Caching

If you have input on any of these topics, please do the the mailing
list know, so that we can address those concerns ASAP, reach a
concensus about OCSP and finish up this project.

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: [email-masked]
Date:         Mon, 13 Apr 1998 17:19:22 -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: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
Comments: To: [email-masked]
To: [email-masked]

Timing of responses:  what happens if a responder is sending "old" responses from its cache (with the "old" time?) saying that the cert is not revoked at the time of the "new" request?  Or do we assume that caching responders will synchronize all requests and not process delta CRLs or other interim status request?  Does this processing synchronization then become part of the minimum interoperability standards for responders that are then "allowed" to cache responses?

Michael

>>> Paul Hoffman / IMC <[email-masked]> 04/13/98 04:30PM >>>
At 02:21 PM 4/13/98 -0700, Michael Myers wrote:
>Could you expand on what you meant by "trusted" in the following?
>
>>I would very much like to take OCSP caching out of HTTP proxy
>>caches and put them in a trusted place. I look forward to your draft and
>>hope that, if the group likes it, we can use it instead of the HTTP portion
>>of the current OCSP draft.

Trusted = bound to the OCSP responder. HTTP proxy caches may be controlled
by the OCSP requestor, the OCSP responder, or someone else. The latter case
leads to problems of the requestor getting the most recent information.

I think that Marc means that his OCSP proxy cache will be controllable only
by the OCSP responder. This would let OCSP responders offload
previously-issued replies to the OCSP proxy cache and only request that are
not in the cache, or ones that require signing of the nonce, would make it
back to the responder. This maximizes the scalability of the responder by
giving it caching flexibility on an outside host, the OCSP cache.

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

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Mon, 13 Apr 1998 15:58:14 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

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

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

David,

I agree that freshness information is an absolute must, and the draft
protocol provides exactly that.  I know it's unfair of me to make such
claims about something that nobody's seen yet, so I'll just leave it at that
until everyone's had an opportunity to go over the draft.

I do have a problem with something that even resembles and "expiration time"
though, so if your concerns aren't addressed by the draft I'll be happy to
revisit the issue.

                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

"David P. Kemp" <[email-masked]> scrawled:
>
> > From: Marc Branchaud <[email-masked]>
> >
> > It's my hope that the draft will provide a focus (and solution) for the
> > caching issue, which has yet to be dealt with in any depth.  However,
> > nextUpdate is really a separate issue:  It firmly belongs in the realm of
> > OCSP-based-on-CRLs.  OCSP caching is a much broader issue.
>
> Marc,
>
>   I look forward to seeing the draft.  However, my inclination is to
> believe that nextUpdate (or more generally, "expirationTime") is crucial
> for OCSP-direct-to-the-CA, and is not limited to just OCSP-based-on-CRLs.
>
> The CA must have some finite delay between the time a revocation is
> requested by the subscriber and the time it is reflected in status
> responses as received by the RP, whether the responses are communicated
> by direct OCSP or by CRLs.  If the CA advertises response information
> current to within 5 minutes, then the relying party needs to know that
> the OCSP response it is currently processing came from the horse's
> mouth not more than 5 minutes ago, regardless of how many caches it has
> flowed through or what cache control strategies are in use.  Any
> solution to the caching issue must provide freshness information that
> the RP can use to verify that the CA is living up to it's performance
> claims, otherwise you might as well take the O out of OCSP.
>
> Dave Kemp

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 13 Apr 1998 15:30:00 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

At 02:21 PM 4/13/98 -0700, Michael Myers wrote:
>Could you expand on what you meant by "trusted" in the following?
>
>>I would very much like to take OCSP caching out of HTTP proxy
>>caches and put them in a trusted place. I look forward to your draft and
>>hope that, if the group likes it, we can use it instead of the HTTP portion
>>of the current OCSP draft.

Trusted = bound to the OCSP responder. HTTP proxy caches may be controlled
by the OCSP requestor, the OCSP responder, or someone else. The latter case
leads to problems of the requestor getting the most recent information.

I think that Marc means that his OCSP proxy cache will be controllable only
by the OCSP responder. This would let OCSP responders offload
previously-issued replies to the OCSP proxy cache and only request that are
not in the cache, or ones that require signing of the nonce, would make it
back to the responder. This maximizes the scalability of the responder by
giving it caching flexibility on an outside host, the OCSP cache.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Warwick Ford <[email-masked]>
Date:         Mon, 13 Apr 1998 18:11: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: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

At 02:25 PM 4/13/98 -0600, Bob Jueneman wrote:
>What/where is the "poised" list, what is its charter, and how does one
subscribe?

See the "Process for Organization of Internet StandardS ONg (poisson)" WG -
details on the IETF Web site.

Warwick

---------------------------------------------------------------------
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, 13 Apr 1998 14:21: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 and HTTP proxy caching
To: [email-masked]

Paul,

Could you expand on what you meant by "trusted" in the following?

Mike

At 01:57 PM 4/13/98 -0700, Paul Hoffman / IMC wrote:
>I would very much like to take OCSP caching out of HTTP proxy
>caches and put them in a trusted place. I look forward to your draft and
>hope that, if the group likes it, we can use it instead of the HTTP portion
>of the current OCSP draft.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>
>

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 13 Apr 1998 13:57: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

At 12:11 PM 4/13/98 -0700, Marc Branchaud wrote:
>An OCSP server is not necessarily a CRL-processing engine.

Quite right, and I hope I didn't sound like I believed that to be the case.

>  In many cases,
>certificate status can be served without using CRLs at all (like when the
>OCSP server has direct access to a CA's certificate store).  In these
>situations, "nextUpdate" has no meaning at all.

It has a meaning, but a weak one, and (I hope) the same weak one that
exists in CRLs. It means "the time that the {CA|OCSP server} guarantees to
give a new response".

>Instead of requiring nextUpdate, the solution is to make caching an explicit
>part of OCSP.  I'm working on a draft that does just this, and I'm in the
>process of running it by a couple of people before submitting it to the
>list.  I hope to have it out by (or before) Friday.

Excellent! I would very much like to take OCSP caching out of HTTP proxy
caches and put them in a trusted place. I look forward to your draft and
hope that, if the group likes it, we can use it instead of the HTTP portion
of the current OCSP draft.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 13 Apr 1998 14:25:52 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
To: [email-masked]

Warwick,

What/where is the "poised" list, what is its charter, and how does one subscribe?

I think these questions are very, very important. But so long as the IETF does not
require individual contributors to "join" anything more than a mailing list, and
does not require any legal assignment of IP rights by contributors to the IETF,
I think these issues are going to come up again and again. Even if I had ever
read RFC 2028 (and I haven't yet, although I'm going to), I never signed anything
that would bind me to such principles, either legally or morally. I didn't even know
that it existed -- I certainly haven't read every RFC that has ever been published.

In my own case, for example, I learned of a Novell patent that might
conceivably apply in this area after someone else mentioned it. Not
withstanding the fact that it was filed by someone who sits about 20 feet
away from me, the invention was developed before I joined Novell, and the
patent was only awarded recently, and without any internal fanfair. I therefore
could have fallen into the same trap Warwick fell into, quite innocently. And
anyone who thinks that everyone who is, or at one time might have been,
an employee or contractor for a large comporation, must therefore be aware of
all of the decisions that might be made regarding patents and their applicability,
no matter where they might be processed within the company, is somewhat
out of touch with reality, I believe. It simply isn't possible. Ask IBM, or Microsoft,
or General Motors.

Other organizations, for example the Key Recovery Alliance, and I believe
the Open Group, do require corporate membership, and an explicit
assignment of rights for work developed in a group setting to the organization
for precisely these reasons.  Without such an agreement, I think the
rights issue is quite murky, especially given the US patent law with its
emphasis on first to invent, vs. most of the rest of the world's first to file precedence.

Bob

>>> Warwick Ford <[email-masked]> 04/10 8:48 PM >>>
Perry:

I am not arguing the reasonableness of that action.  Having now seen how
unexpected subsequent actions can lead to a clearly unreasonable outcome
overall, I cannot disagree with you.  But in fairness to all, I think we
need to recognize that there is a misalignment in different people's
understandings and expectations.  Therefore, I am suggesting that we move
to better align and document understandings and expectations for the
future.  Like add some more precision to RFC 2028...

Also, in the interests of eliminating duplication, might I suggest that
this thread now be pursued only on the poised list where it most properly
belongs?

Warwick

At 11:59 AM 4/10/98 -0400, Perry E. Metzger wrote:
>I'm very angry about this sort of thing. I realize that you feel that
>it was reasonable for Nortel to file a patent on an idea already
>presented to the IETF, but I do not think this was reasonable
>behavior. The open standards process depends on people being fully
>informed of all the encumberances on technology they are
>considering.

(Disclaimer: These comments are my own and do not necessarily reflect
positions of VeriSign, Inc.)

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

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 13 Apr 1998 15:58: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

> From: Marc Branchaud <[email-masked]>
>
> It's my hope that the draft will provide a focus (and solution) for the
> caching issue, which has yet to be dealt with in any depth.  However,
> nextUpdate is really a separate issue:  It firmly belongs in the realm of
> OCSP-based-on-CRLs.  OCSP caching is a much broader issue.

Marc,

  I look forward to seeing the draft.  However, my inclination is to
believe that nextUpdate (or more generally, "expirationTime") is crucial
for OCSP-direct-to-the-CA, and is not limited to just OCSP-based-on-CRLs.

The CA must have some finite delay between the time a revocation is
requested by the subscriber and the time it is reflected in status
responses as received by the RP, whether the responses are communicated
by direct OCSP or by CRLs.  If the CA advertises response information
current to within 5 minutes, then the relying party needs to know that
the OCSP response it is currently processing came from the horse's
mouth not more than 5 minutes ago, regardless of how many caches it has
flowed through or what cache control strategies are in use.  Any
solution to the caching issue must provide freshness information that
the RP can use to verify that the CA is living up to it's performance
claims, otherwise you might as well take the O out of OCSP.

Dave Kemp

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 13 Apr 1998 13:53:53 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
To: [email-masked]

Bill, I think you make some good points.

And although you addressed your note to the PKIX list, you also serve as
Chair to the Federal PKI group, where the issue of patents, and conformance
to standards, is likely to be much more acute.

I think it might be useful to run this up the flagpole with NIST's and/or DoD's
IP lawyers, and see what the consequences might be of requiring conformance
to an IETF standard during some procurement if valid patents are excluded
as a matter of principle by a recognized(?) standards body.

Bob

>At 10:46 PM 4/9/98 -0700, Warwick Ford wrote:
>>I totally support the spirit behind the key clause in RFC 2028 regarding
>>intellectual property and the IETF.  However, this clause may warrant some
>>reconsideration ... taking into account the circumstances surrounding
>>Nortel Patent 5699431 (PKIX and CRL distribution points).
>>
>>   To ensure a fair and open process, participants in the IETF and its
>>   Working Groups must be able to disclose, and must disclose to the
>>   Working Group chairs any relevant current or pending intellectual
>>   property rights that are reasonably and personally known to the
>>   participant if they participate in discussions about a specific
>>   technology.
>>
>
>Like Warwick, I like the spirit of this rule.
>
>However, Article II of the United States Constitution specifically empowers
>Congress to:
>
> "promote the progress of science and useful arts, by securing for limited
>times to authors and inventors the exclusive right to their respective
>writings and discoveries;"
>
>Congress, therefore, gets to say what the rights of inventors are in the
>patent laws.  My questions are:
>
>1. Does the US patent law create a statutory right of inventors to maintain
>the secrecy their invention, if they choose, while a patent application is
>pending?  I thought perhaps it did.
>
>2. If so, may the IETF properly impose obligations on inventors that run
>counter to these rights, when they participate in IETF deliberations?
>
>3. If not, is the IETF exposing itself or its participants to possible
>damages from inventors whose rights have been abrogated by this rule?
>
>4. Has this rule been vetted by IETF legal counsel?
>
>Needless to say, I am not a lawyer, but I would want to know the answers to
>these questions before I pushed this patent disclosure issue too far, or
>attempted to punish those who may violate the patent clause in RFC 2028.
>Regards,
>
>Bill Burr

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 13 Apr 1998 13:40:41 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
Comments: To: [email-masked]
To: [email-masked]

Russ,. I think that is going way too far.

It is one thing to say that a standard should not mandate or be dependent
upon the use of a patented technique, but it is quite something else to
say that a conformant implementation MAY NOT use such a technique.

It would be acceptable to point out the possible interoperability problems that may
result from such a usage, but some applications, perhaps those used within a
closed user group, may be perfectly willing to use a superior technique that is
outside of the minimally compliant subset, even if some royalties are required.

I continue to be quite concerned by the obvious anti-intellectual property bias
of the IETF, of which this is the latest example. I fear that such an approach
may lead many vendors to realize that within the IETF innovation is to be punished,
and patents are the kiss of death, and they will begin to withdraw from such efforts
and adopt de facto or proprietary standards instead.

In addition to the possibility that inventors would not be able to reap the fruits of their
labor, I am also concerned that some misguided individuals or companies might
attempt to file a patent on techniques that are already in the public domain, jor
might be obvious to those skilled in the art, just to try to preempt or delay
someone else from using such a technique. (Note that I am specifically not making
any allegations about anyone in particular in this regard, specifically including Entrust/Nortel.)

As far as I am concerned, the only acceptable way of phrasing the comment about
a "removed" attribute would be something like the following:

"Applications making use of this attribute or extension without a license MAY
be infringing upon a patent held or filed by XYZ Corp., but until such claims
have been upheld in litigation this 'fact' cannot be necessarily be taken for
granted. The advice of a competent patent attorney in this matter may be
appropriate."

"In the interest of interoperability, applications conforming to this profile
generally SHOULD NOT issue certificates [or CRLs] that contain this
extension.  If this extension is present and marked non-critical
in a certificate [or CRL], conforming applications MAY ignore this
non-critical extension if they choose not to implement the option.
If this extension is present and marked critical in a certificate [or CRL],
conforming applications must reject the certificate [or CRL] containing
this critical extension if they choose not to implement the option. However,
conforming applications, including CAs, MAY issue certificates containing
the option if they choose to do so if they recognize (or intend) the possible
interoperability consequences, and conforming applications which
choose to implement the option may also support such extensions when
marked Critical."

Bob

>At the PKIX meeting in LA, Tim Polk gave a presentation on the extensions that
>will be removed from PKIX Part 1 to remove any dependance on recently issued
>patents.  A straw poll confirmed overwhelming support for this approach,
>and we
>are making the changes to remove the extensions.
>
>Many, many months ago, we decided that PKIX Part 1 should say something about
>every extension in X.509.  Keeping with this philosophy, I propose the
>following words for the extensions that are being "removed:"
>CAs conforming to this profile must not issue certificates [or CRLs] that
>contain this extension.  If this extension is present and marked non-critical
>in a certificate [or CRL], conforming applications must ignore this
>non-critical extension.  If this extension is present and marked critical in a
>certificate [or CRL], conforming applications must reject the certificate [or
>CRL] containing this critical extension.
>Russ

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:  Marc Branchaud <[email-masked]>
Date:         Mon, 13 Apr 1998 12:11:24 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

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

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

Paul,

I agree with you that HTTP caching muddies the OCSP waters considerably.  I
also agree that giving the relying party as much information as possible is
preferable to forbidding caching entirely.

However, relying on nextUpdate for that information is not the way to go.

An OCSP server is not necessarily a CRL-processing engine.  In many cases,
certificate status can be served without using CRLs at all (like when the
OCSP server has direct access to a CA's certificate store).  In these
situations, "nextUpdate" has no meaning at all.

Instead of requiring nextUpdate, the solution is to make caching an explicit
part of OCSP.  I'm working on a draft that does just this, and I'm in the
process of running it by a couple of people before submitting it to the
list.  I hope to have it out by (or before) Friday.

It's my hope that the draft will provide a focus (and solution) for the
caching issue, which has yet to be dealt with in any depth.  However,
nextUpdate is really a separate issue:  It firmly belongs in the realm of
OCSP-based-on-CRLs.  OCSP caching is a much broader issue.

                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:         Mon, 13 Apr 1998 12:59:00 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
Comments: To: [email-masked]
To: [email-masked]

Tony,

I am sometimes (perhaps justifiably) criticised for taking too legalistic a view
of some of these issues, byut to my way of thinking, the primary purpose
of a Critical flag is to force a particular extension to be brought to the
attention of the relying party.

If the relying party chooses to ignore the warning, etc., so be it -- any
loss that might result from him ignoring that warning pretty clearly falls
on his own head if the matter goes to court and the issue of "commercially
reasonable reliance" comes up.

If the user chooses to check "don't warn me again", I would hope that the
software would at least keep track of the particular VALUE of some
extension that was to be ignored.

The particular semantics associated with an extension that is marked
with a Critical flag should be carefully defined (now there's a novel
concept!), and the action required by any compliant implementation
should be spelled out.  But clearly, it must be acceptable to inform the user/
relying party and ask her what she wants to do -- after all, just as they
are allowed to read unsigned text, they are free to ignore
a digital signature that doesn't check, and also to ignore an invalid
certificate chain, just like I ignore all PGP-signatures, if they so desire.
Caveat Emptor!

In other words, the semantics of a Critical extension cannot be enforced
at gunpoint, not even by the IETF.  They are a warning, and do not carry
the force of law.

(However, I will concede that I am thinking about this primarily from a
digital signature standpoint. If an extension were to say, "Don't decrypt any
message encrypted using this certificate unless you agree to honor the following
constraints," then that might constitute an contract, and might be enforceable.)

Bob

>>> Tony Bartoletti <[email-masked]> 04/08 3:33 PM >>>
Bob,

At 08:06 AM 4/8/98 -0600, you wrote:

[tony snip here]

>More to the point, if an implementation "enforces" such a constraint, what
do they
>do if the formal validation fails?  I would generally expect that a
reasonable
>implementation would simply buck the decision up to the human user "The
>xxx constraint is violated by certificate yyy. Do you want to accept the
>certificate anyway?"  What is the norm for most implementations?
>
>Bob

Like an "harmonic convergence", your paragraph above mirrors my question in
the "Criticality of extensions" thread.  By extension (no pun intended) what
if, for certain "common" extensions, the window pops-up with the additional
check-box labeled "Don't warn me again"?  (I.e., henceforth always accept
the cert if this particular constraint fails.)  I suppose this is perfectly
legal, but is contrary to what many "expect" by "enforces constraints."

____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:  "Perry E. Metzger" <[email-masked]>
Date:         Mon, 13 Apr 1998 10:32:52 -0400
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] RFC 2028 and Nortel Patent 5699431
To: [email-masked]

Tony Rutkowski writes:
> That's an affiliation.  This is an old story...eventually it
> will probably happen.  The IETF should have legal personality
> and it can only acquire that by incorporation.

Gee, and this from a lawyer?

Unincorporated organizations have just as much reality as incorporated
ones. One of the largest investment banks in NYC, Goldman Sachs, is
not incorporated, and never has been. So is Brown Brothers Harriman,
for that matter, and lots of other ones.

There are, in fact, lots of real world organizations that, for one
reason or another, are not incorporated.

The major difference is, of course, that unincorporated organizations
have more personal liability for their participants, but they are
fully capable of functioning. People generally incorporate to reduce
liability, but it doesn't make the organization less real.

Perry

Approved-By: [email-masked]
Date:         Sat, 11 Apr 1998 22:06:57 -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: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

At 03:15 AM 4/4/98 -0800, Peter Gutmann wrote:

>A while back someone made the comment that "It's good that <large vendor>
>always puts the name of the MUA in their mail headers, because it allows you
>to bypass <vendor>-specific bugs".  This leads to a second type of extension,
>implementationWhichCreatedThis, which may be even more useful than the one
>described above.  As it is, it's already possible to identify certain
>implementations just by the bugs in the certificates they produce, but being
>able to make a positive ID would be really useful because by knowing how they
>(mis)interpret certain fields, your implementation could follow the same
>interpretation.

I agree that adding this attribute effectively raises the flag of surrender
in PKI standardization. It may be pragmatic, but it sends the wrong message.

I also suspect that if done, sooner or later some vendor would decide to
discriminate for or against certs generated by a certain vendor's software.
 This would lead to lying by the cert creation software.  This scenario has
already happened with browsers.

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:  Warwick Ford <[email-masked]>
Date:         Sat, 11 Apr 1998 16:36: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: Warwick Ford <[email-masked]>
Subject:      [IETF-PKIX] Draft LA Minutes
To: [email-masked]

Here are Draft LA Minutes for review and comment.

Warwick
---------------------------------

IETF-PKIX MINUTES - APRIL 1, 1998

CERTIFICATE AND CRL PROFILE

Tim Polk summarized the status and outstanding issues on Draft 07 of the
profile.  It is essential that this document be progressed quickly since
several other standards are waiting on it.  New additions to 07 include the
addition of UTF-8 in accordance with IETF Best Practices, correction of the
path processing algorithm to align with X.509, and removal of semantics for
wildcards in alternative names.  A few other minor fixes have been noted
but not yet published.  The S/MIME group has requested that issuer DN be
required.  The TLS group has requested that wildcards not be forbidden.

Beyond these minor issues, the document is currently stuck in last call
owing to patent issues resulting from an Entrust patent issued in December.
 Tim proposed that all text relating to unresolved issues be removed to a
separate I-D, and the rest of the document be progressed immediately to
Proposed Draft.  This means removing CRL distribution points, authority
access info, and some policy qualifiers, and removing URI semantics from
altnames.  (Sections impacted: Policy Qualifiers, CRL Distribution Points,
and Issuing Distribution Points.)  Steve Kent reported that the Area
Director had agreed with this approach.  A straw poll of those present
indicated strong support for and no support against this approach.

OCSP

Mike Myers described the current status.  Recent changes included adoption
of ASN.1 notation and transport independence.  It is also proposed that the
following changes be made.  Clients and servers SHALL support basic
response. Make clear that CRLs not be required to implement OCSP.  The
response is modified to only send back certID.  The "certificate data
required" response will be kept.  The policy ID extension will be deleted.
The CRL inclusion extension exceeds the scope, therefore the "noCRL"
response should be deleted.  Nobody raised objections to any of these.

With regards to specification of non-CA responders' certificates, it is
proposed that we define an extension to enable clients to specify which key
to use to sign responses.  It is also proposed to define an extension to
enable clients to specify the key they are currently relying on.  (The
responder only sends its certificate back if different.)  Re caching of
responses, it is proposed that a separate draft be produced on transport
mechanisms to address caching.  The reference to authority information
access will also be removed for patent reasons.

The possibility of using CMS to protect OCSP was raised.  This will be
considered.

Ambarish Galpani briefed the group on the following open issues:  What
types of responders to OCSP requests will be supported:  CA, client-trusted
responder, CA-designated responder?  Also the issue of the semantics of
thisUpdate, nextUpdate, and producedAt.  (Descriptions need to be tightened
up.)  Also the method of identification of certificates - should it include
a hash of the public key of the issuer?

Mike Myers raised some issues of response semantics:  Does notRevoked imply
that the certificate exists?  Should there be multiple status bits
returned, e.g., one bit for expired, one for revoked?  (General feeling:
Yes.)  What should the response be for a certificate known to have not been
issued?  It was also pointed out that there may be a patent by Silvio
Micali covering OCSP.  The authors were asked to explore.

IPSEC SUPPORT

Rodney Thayer described IPSEC PKI requirements, and work to prepare an
IPSEC specification for use of PKI and PKIX.  Issues include subject names
(and altnames), cross-certification, off-line operations, hard limits
(e.g., on hierarchy depth), identity vs. address vs. usage, and extended
key usage.  For cross-certificates, there is a need for an optional
nameConstraint containing DNSname, RFC822name, or IPaddress.  For IPaddress
Rodney proposed to use an address plus mask.  This is not yet resolved.

PKIX MINUTES - APRIL 2, 1998

LDA PROFILE AND SCHEMA

Pat Richard reported that the LDAP v2 profile had been rejected by the IESG
because of some security issues (subsequently fixed in a revised draft),
the absence of a schema, the need for a section on "acceptable searches",
and the fact that LDAP v2 rather than v3 is used.  A new schema draft has
been produced - the profile will not be approved by the IESG without
simultaneous approval of this schema.  Re v2/v3 there are various options.
Tim Howes reported that work is still under way on some v3 extensions
(access control, referrals, replication), but this probably does not impact
PKIX.  There are two choices on how to proceed: (1) produce v2 profile and
schema then make them informational when v3 is developed, and (2) stop work
on v2 and start work on just v3.  On a show of hands, there was
substantially more support for (1) than (2).  This will also be referred to
the list.

CRMF, CMMC AND CMC

Mike Myers outlined the status of these projects.  CRMF defines a standard
format for a certificate request.  CMMF defines message formats for other
certificate management functions.  CMC defines a protocol for carrying CRMF
and CMMF messages over CMS, to support certification of a public key,
querying status of certificate requests, and certificate/CRL retrieval.

Some comments were received on CRMF, regarding public-key MAC, registration
control, PKI archive options, the definition of dhMAC, and ASN.1
imports/exports.  These will be addressed in an updated draft of CRMF.

Paul Hoffman raised the question of possible pending patents impacting CRMF
and CMC, and suggested that the Chairs try to get commitments from authors
that there are no patent encumbrances.  Attention was also drawn to RFC
2028 which spells out expectations regarding intellectual property
disclosures by IETF participants.

Mike also presented a list of open issues (most submitted by Jim Schaad)
for CMMF and CMC. Some of the issues require discussion on the list before
resolution. The following significant issues were discussed:

(1) CMRF describes the certificate request message of choice for PKIX. CMC
specifies an alternate format as "mandatory to implement". The sense of the
group was that CMRF should be the mandatory request format for CMC.

(2) Carlisle Adams noted that secure initialization is not a feature of
CMC. After some discussion, there was a straw poll. The sense of the group
was that secure initialization should be feature of CMS and should be
mandatory to implement. This requirement can be supported using the CRMF
message format discussed above.

(3) The CMMF draft contains alternative formats for most messages. In brief
discussion of this fact, some attendees indicated a single format for
messages would be preferable. There was no discussion of how this could be
achieved.

(4) CMC includes a Diffie-Hellman based MAC. Paul Hoffman asked about the
patent status of this feature. The WG chair asked the authors to determine
the patent status and report to the group.

It was clarified that a new draft of CRMF will be produced taking into
account ASN.1 fixes and the fixes mentioned above.  This new draft will be
sent to the IESG to replace the draft they are currently considering.  The
target timescale for CMMF and CMC documents is to go to last call at the
Chicago IETF.

TIMESTAMP AND NOTARY DRAFTS

Rob Zucherrato presented an update on the timestamp and notary drafts. The
PKIX charter has not been modified, so both the timestamp draft and the
notary protocol draft have been moved to independent status. Jeff Schiller
informed the WG that he will not consider amending the charter until the
profile becomes an RFC.

Revised drafts for these protocols are now available under
"ietf-draft-adams-*". Most of the discussion centered on the difference
between the two protocols, which remains a source of confusion. The
timestamping protocol does not attempt to verify the identify of the
submitter; the notary protocol does. The notary protocol may also attempt
to validate a particular certification path at the time of submission. This
may be useful since secure archiving support is not widely deployed.

The title of the notary protocol may be one reason for the confusion. It
was suggested that the draft be renamed to reduce the ambiguity. Another
reason is the perceived overlap between the notary protocol and OCSP. The
goals of the protocols are very different; this should probably be
clarified in the notary draft.

Rob presented several outstanding issues for discussion. As a result of the
discussion, the group requested that the timestamp draft use CMS signed
data encapsulation, and omit the requester name in the response. (Since the
timestamp server does not verify the requester's identity, its appearance
in the response gives the wrong impression.)

In addition, Rob noted that both areas are the subject of numerous patents.
This may present a difficulty in progressing the drafts.

Brian LaMaachia presented implementation issues that he has encountered in
the area of path building. In particular, inconsistent use of key
identifiers and distinguished name fields makes it difficult to develop
paths. As a result of this discussion, the group proposed to require key
identifiers in all certificates and clarify the name matching rules. In
conjunction with the proposal to require issuer distinguished names in all
certificates, key identifiers will greatly simplify path building in PKIX1
compliant systems. The name matching rules will clarify ambiguities
introduced by BMPString and UTF8String encodings.

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

Approved-By:  Todd Glassey <[email-masked]>
Date:         Sat, 11 Apr 1998 13:10:03 -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: Todd Glassey <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: cc: warwick ford <[email-masked]>
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0029_01BD654B.240E6E40
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: Warwick Ford <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, April 09, 1998 8:43 PM
Subject: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431

>I totally support the spirit behind the key clause in RFC 2028 regarding
>intellectual property and the IETF.  However, this clause may warrant some
>reconsideration ... taking into account the circumstances surrounding
>Nortel Patent 5699431 (PKIX and CRL distribution points).
>
>   To ensure a fair and open process, participants in the IETF and its
>   Working Groups must be able to disclose, and must disclose to the
>   Working Group chairs any relevant current or pending intellectual
>   property rights that are reasonably and personally known to the
>   participant if they participate in discussions about a specific
>   technology.
>
>This clause does not completely protect against the problems that occurred
>with 5699431.  The Nortel individuals (including myself) who developed the
>original CRL Distribution Point idea had no intention, at that time, to
>file a patent claim for the idea.  We submitted the idea to various
>standards groups, as a bona fide standards contribution, and promoted its
>adoption.  We were not violating RFC 2028 nor any other standards committee
>policies at that time.  It was almost 12 months later that someone
>concluded that Nortel could and should file a patent for that invention
>provided the filing occurred before the 12-month anniversary of the
>original publication of the idea.  (This seemed to me a reasonable
>IP-defensive action at the time -- I never imagined that Nortel or its
>heirs would later try to tax the industry on the basis of this patent.)
>
>After the patent was filed, I don't believe I ever participated
>significantly in discussions about CDPs in the IETF (I moved to VeriSign
>shortly after that time, so had given up all stake in the patent anyway).
>I think certain Entrust PKIX participants, however, still have something to
>answer re RFC 2028 adherence (the campaign waged by certain individuals
>against OCSP in favor of CRLs/CDPs in December 1997 springs to mind).

Warwick,
I understand and agree with you but from a process and legal perspective the
bottom line is the bottom line - When modulated by USPTMO Policy and US Law,
the wording of the current IETF and IESG charters and Standards Process
Models allows for Intellectual Properties to be patented after they have
been granted IETF and IESG blessings, and that's what's at question here.
You clearly just got caught in the public reaction to this loophole.

To address the underlying issue:
--------------------------------------------
Maybe it should be submitted as a question to the IETF Secrateriat and the
IESG as a whole...  isn't  this something that the IETF and IESG wanted to
avoid by their efforts?, the making any one technology financially more
valuable by the adding of "IETF/IESG Standard" and then having a patent
appear out of nowhere after the fact.

And by the way, wouldn't a simple fix for this  be to amend the standards
process so that NO standard under consideration may progress past the RFC
stage until...
    -    the one year anniversary is exceeded and no patent is applied for,
    -    or a patent is applied for and licensing rights compliant to some
"public usage" mode are instituted [This might be an interesting   project
for some of our mutual ABA friends to look at, the drafting of  the legal
language for the "public-usage" rights model.]
    -    or the patent is assigned into the public domain  [ Also another
project for our ABA friends to draft something for...].

Although an easier change would be to adjust the wording of the IP specific
text to read that no single technology or method suite may be standardized
if it is patented and its the only submitted form of the invention/method.
Exceptions to this would be like the Certicom model where only there method
is patented and ECC is public domain... This seems to me the easiest way to
administer what is and isn't standardizable.  Either way it seems that the
intent of these particular requirements are to create and support the
operation of  a more impartial, A-political IETF and that is a very good
idea!.

Todd

>
>That aside, even if everyone had followed RFC 2028 to the letter, the basic
>problem of 5699431 would remain.
>The way around this problem is not obvious.  We might consider, for
>example, requiring that when someone files a patent or learns of a patent
>filing that they be required to disclose such facts.  However, this is just
>not practical.  Most corporate employees and contractors are bound by
>contracts that prohibit them from disclosing intellectual property
>information, including information about filed but ungranted patents,
>without authorization.  In large corporations, such authorization can never
>be guaranteed to be under the control of the IETF participant.  The
>situation is worse in the case of a past employer -- when one leaves a
>corporation one is typically contractually bound to maintain silence on
>intellectual property matters and is also no longer in a position to
>influence the corporation to release the information.  (As many of you
>know, this is precisely the invidious situation I was in throughout most of
>1996 and 1997, when I knew of the existence of the filing of 5699431 but
>could not bring it to the attention of the IETF.)
>
>The other possibility is to oblige participants not to sign invention
>disclosures for technology that they have previously discussed in the IETF.
> This might work.
>
>I also understand the US Federal Government is working on revising the code
>to align with patent policies elsewhere, so maybe the problem will go away.
>
>This problem is more difficult for the IETF than other standards groups
>because of the absence of relationships between corporations (who generally
>own the IP) and the IETF.
>
>Perhaps others have valuable insight...
>
>Warwick
>
>(Disclaimer: These comments are my own and do not necessarily reflect
>positions of VeriSign, Inc.)
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>---------------------------------------------------------------------
>

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

------=_NextPart_000_0029_01BD654B.240E6E40--

Approved-By:  Warwick Ford <[email-masked]>
Date:         Fri, 10 Apr 1998 23:39: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: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: John Day <[email-masked]>, [email-masked]
To: [email-masked]

John:

At 03:28 PM 4/10/98 -0400, John Day wrote:
>Actually, if Warwick submitted the stuff to ISO, they will claim copyright
>on all contributions (at least they have recently) and while copyright
>isn't a patent, they could make things messy.

To correct some details, it was not "Warwick" who submitted anything to
ISO.  Anyone who has taken the time to read the patent knows the standards
submission was a BNR corporate contribution to Standards Canada, originated
from Colin Ashford of BNR.  The Canadian National committee subsequently
endorsed this as a Canadian contribution to ISO/IEC.  ISO copyright is not
an issue here.

Warwick

---------------------------------------------------------------------
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:         Fri, 10 Apr 1998 09:38:36 -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: Scott Bradner <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

> As a non-organization IETF has no established
> legal relationships.

and as an organization the ISOC exists and the ISTF standards process
specifically refers to the ISOC

> It's most
> salient feature is that it probably helps minimize the liabilities
> of the participants in the process - especially the IESG.

the ISOC pays for insurance to cover the IESG (and the working
group chairs & the IAB)

> What
> if someone chooses to ignore the RFC?  If the answer is something
> other than nothing, it might be useful to articulate.

the same thing that happens when someone ignores the rules of
many other standards bodies - some wronged party, normally not the
standards body, throws lawyers at the situation

Scott

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 17:03:39 -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: Christian Huitema <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Scott Bradner <[email-masked]>, [email-masked], [email-masked]
To: [email-masked]

On Apr 10,  4:48pm, Scott Bradner wrote:
> Subject: Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
> --
> what about the expectation that there be at least two different examples of
> licenses prior to going to Draft Standard?
> --
>
> yes that is the case
>
> what was unclear from your note was teh idea that something might have
> to be done before any standards track work - a doc can go to
> proposed std without any of this
>
> also - there is no requirement for anyone to publish the details of
> the licence agreement just that there be more than one cases
> where the implementer felt that the license requirements were not
> too bad to be signed
>
> Scott
>-- End of excerpt from Scott Bradner

When I proposed the "let's see whether the licensing agreement work"
rule, I had really in mind a "rough consensus" approach.  If a significant
fraction of the working group believe that the license agreements are
inadequate, then there would be a case for either not progressing
the standard or at the very least authorizing work on an alternative
option.

If I understand correctly, CRL were only one of the options in PKIX,
and alternatives were debated.  If a significant fraction of the working
group believe that, in light of the patent announcement, the standard
should be revised, they should definitely be free to do so.

--
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 16:48:24 -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: Scott Bradner <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked], [email-masked]
To: [email-masked]

--
what about the expectation that there be at least two different examples of
licenses prior to going to Draft Standard?
--

yes that is the case

what was unclear from your note was teh idea that something might have
to be done before any standards track work - a doc can go to
proposed std without any of this

also - there is no requirement for anyone to publish the details of
the licence agreement just that there be more than one cases
where the implementer felt that the license requirements were not
too bad to be signed

Scott

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 16:42:45 -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: "Donald E. Eastlake 3rd" <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
To: [email-masked]

On Fri, 10 Apr 1998, Dave Crocker wrote:

> Date: Fri, 10 Apr 1998 12:57:15 -0700
> From: Dave Crocker <[email-masked]>
>
> ...
>
> Filing a claim after entering the knowledge into the standards process
> clearly goes against the IETF philosophy.  The fact that it is legal is
> really quite secondary.

Actually it is not clear that this is legal.  It is a somewhat murky area but
there is a concept of patent abuse which can lead to patent invalidation for
sufficiently egregious cases like this.

> ...
>
> d/
>
> __________________________________________________________________________
> Dave Crocker                 Brandenburg Consulting        +1 408 246 8253
> [email-masked]       675 Spruce Drive        (f) +1 408 249 6205
> www.brandenburg.com         Sunnyvale, CA 94086  USA

Donald
=====================================================================
Donald E. Eastlake 3rd     +1 978-287-4877(tel)     [email-masked]
   318 Acton Street        +1 978-371-7148(fax)     [email-masked]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.privacy.org/ipc

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 16:19:03 -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: Scott Bradner <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

--
If there are pre-existing claims, then they either
must be turned over to the IETF or the licensing arrangement must be
determined (and evaluated) prior to standardization.
--

actually that requirement was specifically removed in the revision of
1602 (now 2026) - the requirement for a preview of licensing arangements
turned out to be a real roadblock.  The rules are now that
the working group can decide to recommend going ahead even in
the face of a lack of specific details if it feels that the results
are important enough.

Scott

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 15:28:33 -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: John Day <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Dave Crocker <[email-masked]>
Comments: cc: Warwick Ford <[email-masked]>, [email-masked]
To: [email-masked]

At 14:23 -0400 4/10/98, Dave Crocker wrote:
>At 01:44 PM 4/10/98 -0400, John Day wrote:
>>According to a patent agent I know, you have 1 year from the time you
>>publish to file the patent or it can be considered public domain.  So if
>
>that's relative to publishing, but I believe that the ultimate
>determination for precedence of claim in the US is based on documentable
>demonstration of the practise, or somesuch.  In other words, it's when you
>did the work, not when you published or filed.
>
That may be the date for which you can claim to be first to invent and
therefore get the patent.  But if you have an idea, publish on it (and a
contribution to a standards meeting constitutes publishing), and then wait
more than a year to patent, the work is considered public domain (if
someone wants to complain).

Actually, if Warwick submitted the stuff to ISO, they will claim copyright
on all contributions (at least they have recently) and while copyright
isn't a patent, they could make things messy.

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 13:44:18 -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: John Day <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Dave Crocker <[email-masked]>
Comments: cc: Warwick Ford <[email-masked]>, [email-masked]
To: [email-masked]

At 11:22 -0400 4/10/98, Dave Crocker wrote:
>At 10:59 AM 4/10/98 -0400, John Day wrote:
>>since the idea was submitted to various standards organizations before the
>>patent was applied for one could argue that the invention is in the public
>>domain and the patent is invalid.  Of course, this requires lawyers, . . .
>
>My understanding is that US law attends to something along the lines of the
>time the practise is created, rather the than when the patent was filed.
>Filing date is taken as a prima facie indicator of precedents, but not the
>ultimate arbiter.

According to a patent agent I know, you have 1 year from the time you
publish to file the patent or it can be considered public domain.  So if
was more than a year from the time Warwick took the proposal to a standards
committee and the time Nortel filed the patent, the patent can be shown to
be invalid.  (at least in the US.)

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 10:18:08 -0400
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: cc: [email-masked]
To: [email-masked]

At 10:46 PM 4/9/98 -0700, Warwick Ford wrote:
>I totally support the spirit behind the key clause in RFC 2028 regarding
>intellectual property and the IETF.  However, this clause may warrant some
>reconsideration ... taking into account the circumstances surrounding
>Nortel Patent 5699431 (PKIX and CRL distribution points).
>
>   To ensure a fair and open process, participants in the IETF and its
>   Working Groups must be able to disclose, and must disclose to the
>   Working Group chairs any relevant current or pending intellectual
>   property rights that are reasonably and personally known to the
>   participant if they participate in discussions about a specific
>   technology.
>

Like Warwick, I like the spirit of this rule.

However, Article II of the United States Constitution specifically empowers
Congress to:

 "promote the progress of science and useful arts, by securing for limited
times to authors and inventors the exclusive right to their respective
writings and discoveries;"

Congress, therefore, gets to say what the rights of inventors are in the
patent laws.  My questions are:

1. Does the US patent law create a statutory right of inventors to maintain
the secrecy their invention, if they choose, while a patent application is
pending?  I thought perhaps it did.

2. If so, may the IETF properly impose obligations on inventors that run
counter to these rights, when they participate in IETF deliberations?

3. If not, is the IETF exposing itself or its participants to possible
damages from inventors whose rights have been abrogated by this rule?

4. Has this rule been vetted by IETF legal counsel?

Needless to say, I am not a lawyer, but I would want to know the answers to
these questions before I pushed this patent disclosure issue too far, or
attempted to punish those who may violate the patent clause in RFC 2028.
Regards,

Bill Burr

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 09:58:53 -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: Tony Rutkowski <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Scott Bradner <[email-masked]>, [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

Scott,

>> legal relationships.
>
>and as an organization the ISOC exists and the ISTF standards process
>specifically refers to the ISOC

That's an affiliation.  This is an old story...eventually it
will probably happen.  The IETF should have legal personality
and it can only acquire that by incorporation.

The legal relationships that Warwick and I are talking
about are between a legal person (e.g., IETF, Inc) and
its participating members.  These plainly don't exist,
and can't exist under the present model.

>the ISOC pays for insurance to cover the IESG (and the working
>group chairs & the IAB)

I know how that was set up, and what it may or may not cover. :-)
Good luck.  In the U.S. legal system, you minimize your liability
with legal structures and process - not insurance.

--tony

Approved-By:  Warwick Ford <[email-masked]>
Date:         Fri, 10 Apr 1998 19:48:30 -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: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked], [email-masked]
To: [email-masked]

Perry:

I am not arguing the reasonableness of that action.  Having now seen how
unexpected subsequent actions can lead to a clearly unreasonable outcome
overall, I cannot disagree with you.  But in fairness to all, I think we
need to recognize that there is a misalignment in different people's
understandings and expectations.  Therefore, I am suggesting that we move
to better align and document understandings and expectations for the
future.  Like add some more precision to RFC 2028...

Also, in the interests of eliminating duplication, might I suggest that
this thread now be pursued only on the poised list where it most properly
belongs?

Warwick

At 11:59 AM 4/10/98 -0400, Perry E. Metzger wrote:
>I'm very angry about this sort of thing. I realize that you feel that
>it was reasonable for Nortel to file a patent on an idea already
>presented to the IETF, but I do not think this was reasonable
>behavior. The open standards process depends on people being fully
>informed of all the encumberances on technology they are
>considering.

(Disclaimer: These comments are my own and do not necessarily reflect
positions of VeriSign, Inc.)

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

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Fri, 10 Apr 1998 14:27: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: Paul Hoffman / IMC <[email-masked]>
Subject:      [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

Greetings again. As I brought up last week at the LA IETF meeting, OCSP is
still in dangerous territory with respect to HTTP proxy caches. Basically,
we are betting that all HTTP proxy caches work according to spec, none of
the caches have clock skews from the HTTP servers that are emitting OCSP
responses, and all the caches work perfectly. If we're wrong, people will
get what appear to be authoritative responses that are out of date. No one
in their right mind should then rely on OCSP responses that didn't include
a nonce.

There are two ways to fix this problem: cache busting (making sure that no
request/response gets cached) or giving the user more knowledge about what
the result they get means. I think the latter is cleaner and more amenable
to scaling.

The current OCSP draft says about nextUpdate in section 2.4:

    The producer of the response MAY include a value for nextUpdate.  The
    exact interval between thisUpdate and nextUpdate for given response is
    a matter of local security and operational policy.  If the nextUpdate
    field is not present, the response is is known to be correct at the
    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
    check again with the responder.  If the value of nextUpdate is set, it
    is just a hint, not a guarantee, of when the responder expects to have
    new information about that certificate's status.

PKIX part 1, section 5.1.2.5, says:

   This field indicates the date by which the next CRL will be issued.
   The next CRL could be issued before the indicated date, but it will
   not be issued any later than the indicated date.
. . .
   This profile requires inclusion of nextUpdate in all CRLs issued by
   conforming CAs.

Notice the differences? :-)

If we adopt the requirements from PKIX part 1 (nextUpdate has a definitive
meaning, and it the field MUST be included), the recipient of an OCSP
response does not need to worry about broken caches and clock skew. Without
the kind of definitive wording used in PKIX, we *cannot* allow proxy
caching in OCSP because the end user would never know if they were getting
something that the OCSP server really believed in.

Thus, I propose that the wording from PKIX part 1 replace the current OCSP
wording.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  "Flanigan, Bill" <[email-masked]>
Date:         Fri, 10 Apr 1998 16:32:43 -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: "Flanigan, Bill" <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
To: [email-masked]

Don/Perry,

        Right on!  However, timing in life is EVERYTHING.  Maybe the
big-picture plan/hope was for either (1) Part I to become a Proposed
Standard BEFORE 97/12/16 or (2) the PTO wouldn't issue until AFTER 98/08/28.
Comments?

Bill Flanigan

> -----Original Message-----
> From: Dave Crocker [SMTP:[email-masked]]
> Sent: Friday, April 10, 1998 3:57 PM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
>
> At 11:59 AM 4/10/98 -0400, Perry E. Metzger wrote:
> >I'm very angry about this sort of thing. I realize that you feel that
> >it was reasonable for Nortel to file a patent on an idea already
> >presented to the IETF, but I do not think this was reasonable
> >behavior.
>
> The IETF has a pretty clear and straightforward position with respect to
> intellectual property:  If there are pre-existing claims, then they either
> must be turned over to the IETF or the licensing arrangement must be
> determined (and evaluated) prior to standardization.  "Inventions" that
> take place in the IETF context belong to the IETF.
>
> That's the philosophy.
>
> It creates a clear distinction between was an individual (or organization)
> can legally do and what they are ethically/morally bound to do.  An
> attitude which relies solely on the question of what is legal does not
> result in behavior that is generally felt to be socially acceptable.
> Quite
> the contrary.
>
> Filing a claim after entering the knowledge into the standards process
> clearly goes against the IETF philosophy.  The fact that it is legal is
> really quite secondary.
>
> Corporate constraints on their employees and consultants cannot be
> ignored,
> but neither can the choices available to the individuals.  The fact that a
> company asserts the requirement for confidentiality does not automatically
> bind the individual, nor does it prevent them from taking other actions.
>
> Perhaps we need to add language which states the intent even more clearly
> and which dictates the relevant behavioral rules more thoroughly.  However
> we also need to consider actions to be taken when the spirit or rules are
> violated.  Within the limited context of the IETF, there are nonetheless
> some choices we have in reacting to transgressions.
>
> Let's try to work through the possible timings and actions more thoroughly
> than we have in the past -- i.e., a case analysis -- treating this as a
> programming exercise, rather than a simple statement of a broad principle.
>
> d/
>
> __________________________________________________________________________
> Dave Crocker                 Brandenburg Consulting        +1 408 246 8253
> [email-masked]       675 Spruce Drive        (f) +1 408 249 6205
> www.brandenburg.com         Sunnyvale, CA 94086  USA

Approved-By:  Dave Crocker <[email-masked]>
Date:         Fri, 10 Apr 1998 13:27: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: Dave Crocker <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Scott Bradner <[email-masked]>, [email-masked]
To: [email-masked]

At 04:19 PM 4/10/98 -0400, Scott Bradner wrote:
>turned out to be a real roadblock.  The rules are now that
>the working group can decide to recommend going ahead even in
>the face of a lack of specific details if it feels that the results
>are important enough.

what about the expectation that there be at least two different examples of
licenses prior to going to Draft Standard?

d/

__________________________________________________________________________
Dave Crocker                 Brandenburg Consulting        +1 408 246 8253
[email-masked]       675 Spruce Drive        (f) +1 408 249 6205
www.brandenburg.com         Sunnyvale, CA 94086  USA

Approved-By:  "Flanigan, Bill" <[email-masked]>
Date:         Fri, 10 Apr 1998 16:13:10 -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: "Flanigan, Bill" <[email-masked]>
Subject:      [IETF-PKIX] Some observations - technical and notTechnical
To: [email-masked]

technical:  instructions for joining the exploder at
<http://www.ietf.org/html.charters/pkix-charter.html> are hosed.  Needs
fixing!

notTechnical:  10 of the 14 I-Ds are presently authored or co-authored by
former/current employees of Entrust Technologies, Ltd.  Needs fixing?

Approved-By:  Dave Crocker <[email-masked]>
Date:         Fri, 10 Apr 1998 12:57:15 -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: Dave Crocker <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
To: [email-masked]

At 11:59 AM 4/10/98 -0400, Perry E. Metzger wrote:
>I'm very angry about this sort of thing. I realize that you feel that
>it was reasonable for Nortel to file a patent on an idea already
>presented to the IETF, but I do not think this was reasonable
>behavior.

The IETF has a pretty clear and straightforward position with respect to
intellectual property:  If there are pre-existing claims, then they either
must be turned over to the IETF or the licensing arrangement must be
determined (and evaluated) prior to standardization.  "Inventions" that
take place in the IETF context belong to the IETF.

That's the philosophy.

It creates a clear distinction between was an individual (or organization)
can legally do and what they are ethically/morally bound to do.  An
attitude which relies solely on the question of what is legal does not
result in behavior that is generally felt to be socially acceptable.  Quite
the contrary.

Filing a claim after entering the knowledge into the standards process
clearly goes against the IETF philosophy.  The fact that it is legal is
really quite secondary.

Corporate constraints on their employees and consultants cannot be ignored,
but neither can the choices available to the individuals.  The fact that a
company asserts the requirement for confidentiality does not automatically
bind the individual, nor does it prevent them from taking other actions.

Perhaps we need to add language which states the intent even more clearly
and which dictates the relevant behavioral rules more thoroughly.  However
we also need to consider actions to be taken when the spirit or rules are
violated.  Within the limited context of the IETF, there are nonetheless
some choices we have in reacting to transgressions.

Let's try to work through the possible timings and actions more thoroughly
than we have in the past -- i.e., a case analysis -- treating this as a
programming exercise, rather than a simple statement of a broad principle.

d/

__________________________________________________________________________
Dave Crocker                 Brandenburg Consulting        +1 408 246 8253
[email-masked]       675 Spruce Drive        (f) +1 408 249 6205
www.brandenburg.com         Sunnyvale, CA 94086  USA

Approved-By:  Dave Crocker <[email-masked]>
Date:         Fri, 10 Apr 1998 11:23: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: Dave Crocker <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: John Day <[email-masked]>
Comments: cc: John Day <[email-masked]>, Warwick Ford <[email-masked]>, [email-masked]
To: [email-masked]

At 01:44 PM 4/10/98 -0400, John Day wrote:
>According to a patent agent I know, you have 1 year from the time you
>publish to file the patent or it can be considered public domain.  So if

that's relative to publishing, but I believe that the ultimate
determination for precedence of claim in the US is based on documentable
demonstration of the practise, or somesuch.  In other words, it's when you
did the work, not when you published or filed.

d/
________________________________________________________________________
Dave Crocker                Brandenburg Consulting       +1 408 246 8253
[email-masked]      675 Spruce Drive       (f) +1 408 249 6205
www.brandenburg.com        Sunnyvale, CA 94086  USA

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Fri, 10 Apr 1998 11:59:57 -0400
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] RFC 2028 and Nortel Patent 5699431
To: [email-masked]

Warwick Ford writes:
> That aside, even if everyone had followed RFC 2028 to the letter, the basic
> problem of 5699431 would remain.
> The way around this problem is not obvious.  We might consider, for
> example, requiring that when someone files a patent or learns of a patent
> filing that they be required to disclose such facts.  However, this is just
> not practical.  Most corporate employees and contractors are bound by
> contracts that prohibit them from disclosing intellectual property
> information, including information about filed but ungranted patents,
> without authorization.

In that case, they should seek a waiver before going to the IETF
meetings.

I'm very angry about this sort of thing. I realize that you feel that
it was reasonable for Nortel to file a patent on an idea already
presented to the IETF, but I do not think this was reasonable
behavior. The open standards process depends on people being fully
informed of all the encumberances on technology they are
considering.

> In large corporations, such authorization can never
> be guaranteed to be under the control of the IETF participant.

Thats simply not true. Many large corporations are pefectly reasonable
about this. Those that cannot get their employers to be reasonable
about this should either not try to contribute technology at the IETF
or should change employers. I'm not joking. This sort of stuff simply
isn't acceptable, and the excuse that "Large companies are hard to
deal with" isn't sufficient.

I'm not trying to single you out, Warwick -- I'm sure you've done
everything here in good faith, but sometimes that isn't enough.

Perry

Approved-By:  Dave Crocker <[email-masked]>
Date:         Fri, 10 Apr 1998 08:22:39 -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: Dave Crocker <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: John Day <[email-masked]>
Comments: cc: Warwick Ford <[email-masked]>, [email-masked]
To: [email-masked]

At 10:59 AM 4/10/98 -0400, John Day wrote:
>since the idea was submitted to various standards organizations before the
>patent was applied for one could argue that the invention is in the public
>domain and the patent is invalid.  Of course, this requires lawyers, . . .

My understanding is that US law attends to something along the lines of the
time the practise is created, rather the than when the patent was filed.
Filing date is taken as a prima facie indicator of precedents, but not the
ultimate arbiter.

d/
________________________________________________________________________
Dave Crocker                Brandenburg Consulting       +1 408 246 8253
[email-masked]      675 Spruce Drive       (f) +1 408 249 6205
www.brandenburg.com        Sunnyvale, CA 94086  USA

Approved-By:  Sean Turner <[email-masked]>
Date:         Fri, 10 Apr 1998 10:28:40 -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: Sean Turner <[email-masked]>
Organization: IECA, Inc.
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Tim,

I don't know if this is out of scope, but I don't think you should mandate AuthorityKeyIdentifier in self-signed certs.  The value of such a 'pointer' is dubious, unless this is how you check to see if the cert is self-signed.

Thoughts?

Tim Polk wrote:
>
> Along the lines of my last message:
>
> There was general discussion in the LA meeting about key identifiers.  If
> key identifiers are available, they greatly simplify path building and
> validation.  Unfortunately, there is no agreed method for generating the
> key identifiers.  Some vendors insert them, others try to "guess" them.
> Draft 07 of the profile recommends a method for generating key identifiers
> and recommends support for key identifiers, but there are no requirements.
>
> It was suggested that key identifiers be mandated for use in all
> certificates.  To facilitate chain building, I proposed we require
> authority key identifers in all certificates, and subject key identifiers
> in all CA certificates.  (Subject key identifiers in end-entity
> certificates do not affect chain-building.)
>
> There is no need to mandate a particular method for generating key
> identifiers if we include key identifiers in the certificate.  Assume a
> "CA-X" signs certificates with a private key "X-private" which has a
> corresponding public key "X-public".  The requirements are that the subject
> key identifier in CA certificates naming "CA-X" as the subject and
> containing "X-public" be the same as the authority key identifier ("AKI-X")
> in certificates issued by CA-X signed by the private key "X-private".
>
> Mandating a method is only needed if key identifiers are *implied*. I think
> it's too late for that - too many implementations have chosen different
> mechanisms all ready.
>
> Anyway, the general sense of the group (I don't think we took a straw poll)
> was that requiring key identifiers was a good idea.  This position still
> requires validation by the list.
>
> Note key identifiers would still be non-critical.  Certificate users would
> not be *required* to recognize them, much less use them.  Conforming CAs
> would simply be required to populate the extension.
>
> Tim Polk

--
Sean Turner - IECA, Inc.

Approved-By:  [email-masked]
Date:         Thu, 9 Apr 1998 20:22:53 -0700
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] Key Identifiers
Comments: To: [email-masked]
To: [email-masked]

>The issuer and serial number point to a single certificate.  The keyIdentifier
>field may be used to identify a set of certificates, all of which contain the
>same public key.
>
>In a network PKI, a CA may be the subject of n certificates from up to n
>issuers.  Many will contain the same public key. (Again, there may be more
>than one live key pair for rollover purposes.) In pathbuilding, any of those n
>certificates may be the one you need to construct a path.  The keyIdentifier
>allows you to quickly eliminate certificates for the "wrong" public key.

This is where I've never quite understood the purpose of the keyIdentifier:
Since it's tied to a CA's public key, for which there may be multiple
certificates, all it'll do is identify a (possibly unlimited) collection of
certs which may have issued the one I want to verify.  The authorityCert fields
bind unambiguously to an issuing cert, but the keyIdentifier only binds to an
arbitrary collection of certs which share the same key (while I'm on the topic,
it might be a good idea to explicitly point out that the authorityCertIssuer is
the issuerName of the issuing cert and not the issuerName of the subject cert -
this is obvious to people used to S/MIME's way of identifying certs, but may
confuse others).

The whole structure of that extension has always struck me as somewhat
peculiar.  What the text which goes with it (for PKIX, but not X.509) says is
that it should be treated like:

AuthorityKeyIdentifier ::= CHOICE {
    keyIdentifier   OCTET STRING,
    authorityCert   IssuerAndSerialNumber     -- From PKCS #7
    }

This is logically equivalent to 4.2.1.1/X.509 12.2.2.1, but without the need
for constraints and an accompanying explanatory text.

Given the parallel thread about bloat in certs and S/MIME, what would be useful
is the addition of a third possibility:

   authorityIdentifier [ 0 ] OCTET STRING

the OCTET STRING being the hash of the S/MIME-style IssuerAndSerialNumber.
This uniquely identifiers the issuer cert, and doesn't cause the unnecessary
bloat which use of the AuthorityCert will.

An alternative is a new extension authorityCertIdentifier:

AuthorityCertIdentifier ::= CHOICE {
    authorityIdentifier OCTET STRING,
    authorityCert       IssuerAndSerialNumber     -- From PKCS #7
    }

with recommended usage being the authorityIdentifier.  This uniquely identifies
an issuing cert (which seems to be what the intent of authorityKeyIdentifier
is), and doesn't cause unnecessary bloat.

Peter.

Approved-By:  Warwick Ford <[email-masked]>
Date:         Thu, 9 Apr 1998 22:46:01 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
To: [email-masked]

I totally support the spirit behind the key clause in RFC 2028 regarding
intellectual property and the IETF.  However, this clause may warrant some
reconsideration ... taking into account the circumstances surrounding
Nortel Patent 5699431 (PKIX and CRL distribution points).

   To ensure a fair and open process, participants in the IETF and its
   Working Groups must be able to disclose, and must disclose to the
   Working Group chairs any relevant current or pending intellectual
   property rights that are reasonably and personally known to the
   participant if they participate in discussions about a specific
   technology.

This clause does not completely protect against the problems that occurred
with 5699431.  The Nortel individuals (including myself) who developed the
original CRL Distribution Point idea had no intention, at that time, to
file a patent claim for the idea.  We submitted the idea to various
standards groups, as a bona fide standards contribution, and promoted its
adoption.  We were not violating RFC 2028 nor any other standards committee
policies at that time.  It was almost 12 months later that someone
concluded that Nortel could and should file a patent for that invention
provided the filing occurred before the 12-month anniversary of the
original publication of the idea.  (This seemed to me a reasonable
IP-defensive action at the time -- I never imagined that Nortel or its
heirs would later try to tax the industry on the basis of this patent.)

After the patent was filed, I don't believe I ever participated
significantly in discussions about CDPs in the IETF (I moved to VeriSign
shortly after that time, so had given up all stake in the patent anyway).
I think certain Entrust PKIX participants, however, still have something to
answer re RFC 2028 adherence (the campaign waged by certain individuals
against OCSP in favor of CRLs/CDPs in December 1997 springs to mind).

That aside, even if everyone had followed RFC 2028 to the letter, the basic
problem of 5699431 would remain.
The way around this problem is not obvious.  We might consider, for
example, requiring that when someone files a patent or learns of a patent
filing that they be required to disclose such facts.  However, this is just
not practical.  Most corporate employees and contractors are bound by
contracts that prohibit them from disclosing intellectual property
information, including information about filed but ungranted patents,
without authorization.  In large corporations, such authorization can never
be guaranteed to be under the control of the IETF participant.  The
situation is worse in the case of a past employer -- when one leaves a
corporation one is typically contractually bound to maintain silence on
intellectual property matters and is also no longer in a position to
influence the corporation to release the information.  (As many of you
know, this is precisely the invidious situation I was in throughout most of
1996 and 1997, when I knew of the existence of the filing of 5699431 but
could not bring it to the attention of the IETF.)

The other possibility is to oblige participants not to sign invention
disclosures for technology that they have previously discussed in the IETF.
 This might work.

I also understand the US Federal Government is working on revising the code
to align with patent policies elsewhere, so maybe the problem will go away.

This problem is more difficult for the IETF than other standards groups
because of the absence of relationships between corporations (who generally
own the IP) and the IETF.

Perhaps others have valuable insight...

Warwick

(Disclaimer: These comments are my own and do not necessarily reflect
positions of VeriSign, Inc.)

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

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:46:01 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

I agree with this.

Dave S.

John Pawling wrote:

> Tim,
>
> I agree with your recommendations and have a few comments:
>
> 1) PKIX I should require each AuthorityKeyIdentifier to be popoulated with
> the keyIdentifier field rather than the pair (authorityCertIssuer,
> authorityCertSerialNumber).
>
> 2) I agree that PKIX I need not mandate that end-entity certs MUST include
> subjectKeyIdentifiers, but I believe that the spec should state that each
> end-entity cert SHOULD include a subjectKeyIdentifier.  This is useful for
> CAs to identify the key material that is included in a cert to assist with
> cert mgmt.  It also useful is some application environments.  For example,
> the US DoD ACP120 spec uses the subjectKeyIdentifier in the recipient's key
> management v3 X.509 certificate to match the recipient's copy of the
> encrypted session key with the recipient's key material.
>
> ================================
> John Pawling, [email-masked]
> J.G. Van Dyke & Associates, Inc.
> www.jgvandyke.com
> ================================
>
> At 12:39 PM 4/9/98 -0400, Tim Polk wrote:
> >Along the lines of my last message:
> >
> >There was general discussion in the LA meeting about key identifiers.  If
> >key identifiers are available, they greatly simplify path building and
> >validation.  Unfortunately, there is no agreed method for generating the
> >key identifiers.  Some vendors insert them, others try to "guess" them.
> >Draft 07 of the profile recommends a method for generating key identifiers
> >and recommends support for key identifiers, but there are no requirements.
> >
> >It was suggested that key identifiers be mandated for use in all
> >certificates.  To facilitate chain building, I proposed we require
> >authority key identifers in all certificates, and subject key identifiers
> >in all CA certificates.  (Subject key identifiers in end-entity
> >certificates do not affect chain-building.)
> >
> >There is no need to mandate a particular method for generating key
> >identifiers if we include key identifiers in the certificate.  Assume a
> >"CA-X" signs certificates with a private key "X-private" which has a
> >corresponding public key "X-public".  The requirements are that the subject
> >key identifier in CA certificates naming "CA-X" as the subject and
> >containing "X-public" be the same as the authority key identifier ("AKI-X")
> >in certificates issued by CA-X signed by the private key "X-private".
> >
> >Mandating a method is only needed if key identifiers are *implied*. I think
> >it's too late for that - too many implementations have chosen different
> >mechanisms all ready.
> >
> >Anyway, the general sense of the group (I don't think we took a straw poll)
> >was that requiring key identifiers was a good idea.  This position still
> >requires validation by the list.
> >
> >Note key identifiers would still be non-critical.  Certificate users would
> >not be *required* to recognize them, much less use them.  Conforming CAs
> >would simply be required to populate the extension.
> >
> >Tim Polk
> >

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:34:18 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Subject:      [IETF-PKIX] Key Usage Role in Cert Path Validation
To: [email-masked]

I would like to add another path processing action to the current list
(a-l) of Section 6, Certificate Path Validation:

"(m) If a key usage extension is marked critical, ensure the keyCertSign
bit is set."

The last sentence on p. 50 should then be modified to:

"Note that actions (h) through (m) are not applied to the end entity
certificate (certificate n)."

Dave S.

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:26:45 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

Paul,

I disagree.  If a certificate contains a critical "proprietary" extension of
any sort, whether it be CRL distribution points or some other private
extension, and PKIX-1 compliance is claimed, then the certificate may be
rejected.  If a certificate contains a non-critical "proprietary" extension of
any sort, then the extension may be ignored.  This is written in black and
white.  There is no reason to make an exception in this case.

With these actions you are harming more than just Nortel, you are affecting any
number of communities worldwide that were PKIX-1 compliant until now.  Again,
PKIX-1 stands independent of X.509.  Ignore the extension if you like, but
please leave well enough alone.

Dave S.

Paul Hoffman / IMC wrote:

> At 01:43 PM 4/9/98 -0700, Anil R. Gangolli wrote:
> >It is unreasonable for the profile to forbid (classify "non-conformant")
> >applications that are able to process such extensions under the
> >the profile's interpretation of critical/non-critical
> >(which still needs clarification -- but that's another thread).
>
> The problem with this approach is that two conformant implementations could
> come up with different results when processing the same cert path. I can
> already hear the end users saying "but my cert validates fine on this piece
> of software; yours must be broken". Trying to explain to them that the
> reason it didn't validate on one client is because someone didn't pay blood
> money for a submarine patent to Entrust won't do much good. I think that
> clear statements of what interoperable implementations do is the most
> important thing here.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:15:42 -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: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
Comments: To: [email-masked]
To: [email-masked]

I agree.

Dave S.

Anil R. Gangolli wrote:

> As much as I agree with the intent, this approach seems too severe
> and probably sets a bad precedent.
>
> It is reasonable to mandate that CAs conforming to the profile not include
> such proprietary extensions, and consequently that certificates including
> the extension do not conform to the profile.
>
> It is unreasonable for the profile to forbid (classify "non-conformant")
> applications that are able to process such extensions under the
> the profile's interpretation of critical/non-critical
> (which still needs clarification -- but that's another thread).
>
> --a.
>
> Paul Hoffman / IMC wrote:
> >
> > >Many, many months ago, we decided that PKIX Part 1 should say something about
> > >every extension in X.509.  Keeping with this philosophy, I propose the
> > >following words for the extensions that are being "removed:"
> > >CAs conforming to this profile must not issue certificates [or CRLs] that
> > >contain this extension.  If this extension is present and marked non-critical
> > >in a certificate [or CRL], conforming applications must ignore this
> > >non-critical extension.  If this extension is present and marked critical
> > in a
> > >certificate [or CRL], conforming applications must reject the certificate [or
> > >CRL] containing this critical extension.
> >
> > That sounds good to me. It covers the area completely without leaving "holes"
> > in the spec for implementors to guess about.
> >
> > I would feel differently if Entrust had different licensing for their patent.
> > If the patent were licensed along the lines of Netscape's SSL patent (no fees
> > or contract required, just an agreement to not hold any SSL-related patents
> > against Netscape), I would say we shouldn't rip out all the features. However,
> > since Entrust wants money from every commercial entity that uses these
> > features, this group have no choice but to excise the features. I think Russ'
> > wording is the best way to do this.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
>
> --
> Anil R. Gangolli
> Structured Arts Computing Corp.
> http://www.StructuredArts.com
> mailto:[email-masked]

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:15: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: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

The feature may be excised by deleting it from the profile.  I've had people tell
me in the past that we're not writing X.509 here.  If X.509 provides a feature
that you don't like, then ignore it.  There are enough differences between PKIX-1
and X.509 to make them independent standards.  There is no reason to forbid this
technology.

Dave S.

Paul Hoffman / IMC wrote:

> >Many, many months ago, we decided that PKIX Part 1 should say something about
> >every extension in X.509.  Keeping with this philosophy, I propose the
> >following words for the extensions that are being "removed:"
> >CAs conforming to this profile must not issue certificates [or CRLs] that
> >contain this extension.  If this extension is present and marked non-critical
> >in a certificate [or CRL], conforming applications must ignore this
> >non-critical extension.  If this extension is present and marked critical
> in a
> >certificate [or CRL], conforming applications must reject the certificate [or
> >CRL] containing this critical extension.
>
> That sounds good to me. It covers the area completely without leaving "holes"
> in the spec for implementors to guess about.
>
> I would feel differently if Entrust had different licensing for their patent.
> If the patent were licensed along the lines of Netscape's SSL patent (no fees
> or contract required, just an agreement to not hold any SSL-related patents
> against Netscape), I would say we shouldn't rip out all the features. However,
> since Entrust wants money from every commercial entity that uses these
> features, this group have no choice but to excise the features. I think Russ'
> wording is the best way to do this.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:05: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: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

I can live with deleting the text if we must, but I cannot agree to forbidding the
technology.  I greatly oppose such text.

Dave S.

Russ Housley wrote:

> At the PKIX meeting in LA, Tim Polk gave a presentation on the extensions that
> will be removed from PKIX Part 1 to remove any dependance on recently issued
> patents.  A straw poll confirmed overwhelming support for this approach,
> and we
> are making the changes to remove the extensions.
>
> Many, many months ago, we decided that PKIX Part 1 should say something about
> every extension in X.509.  Keeping with this philosophy, I propose the
> following words for the extensions that are being "removed:"
> CAs conforming to this profile must not issue certificates [or CRLs] that
> contain this extension.  If this extension is present and marked non-critical
> in a certificate [or CRL], conforming applications must ignore this
> non-critical extension.  If this extension is present and marked critical in a
> certificate [or CRL], conforming applications must reject the certificate [or
> CRL] containing this critical extension.
> Russ

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 9 Apr 1998 15:36:03 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

At 01:43 PM 4/9/98 -0700, Anil R. Gangolli wrote:
>It is unreasonable for the profile to forbid (classify "non-conformant")
>applications that are able to process such extensions under the
>the profile's interpretation of critical/non-critical
>(which still needs clarification -- but that's another thread).

The problem with this approach is that two conformant implementations could
come up with different results when processing the same cert path. I can
already hear the end users saying "but my cert validates fine on this piece
of software; yours must be broken". Trying to explain to them that the
reason it didn't validate on one client is because someone didn't pay blood
money for a submarine patent to Entrust won't do much good. I think that
clear statements of what interoperable implementations do is the most
important thing here.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  "Anil R. Gangolli" <[email-masked]>
Date:         Thu, 9 Apr 1998 13:43:41 -0700
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] Removing Extensions from PKIX Part 1
To: [email-masked]

As much as I agree with the intent, this approach seems too severe
and probably sets a bad precedent.

It is reasonable to mandate that CAs conforming to the profile not include
such proprietary extensions, and consequently that certificates including
the extension do not conform to the profile.

It is unreasonable for the profile to forbid (classify "non-conformant")
applications that are able to process such extensions under the
the profile's interpretation of critical/non-critical
(which still needs clarification -- but that's another thread).

--a.

Paul Hoffman / IMC wrote:
>
> >Many, many months ago, we decided that PKIX Part 1 should say something about
> >every extension in X.509.  Keeping with this philosophy, I propose the
> >following words for the extensions that are being "removed:"
> >CAs conforming to this profile must not issue certificates [or CRLs] that
> >contain this extension.  If this extension is present and marked non-critical
> >in a certificate [or CRL], conforming applications must ignore this
> >non-critical extension.  If this extension is present and marked critical
> in a
> >certificate [or CRL], conforming applications must reject the certificate [or
> >CRL] containing this critical extension.
>
> That sounds good to me. It covers the area completely without leaving "holes"
> in the spec for implementors to guess about.
>
> I would feel differently if Entrust had different licensing for their patent.
> If the patent were licensed along the lines of Netscape's SSL patent (no fees
> or contract required, just an agreement to not hold any SSL-related patents
> against Netscape), I would say we shouldn't rip out all the features. However,
> since Entrust wants money from every commercial entity that uses these
> features, this group have no choice but to excise the features. I think Russ'
> wording is the best way to do this.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

--
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:[email-masked]

Approved-By:  Tim Polk <[email-masked]>
Date:         Thu, 9 Apr 1998 15:41:17 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Kevin,

The issuer and serial number point to a single certificate.  The
keyIdentifier field may be used to identify a set of certificates, all of
which contain the same public key.

If you envision a hierarchical PKI, the issuer and serial number are
sufficient, because the CA has only one certificate with that public key.
If the CA has mutiple key pairs, it will have one certificate issued by the
"parent CA" for each public key.

In a network PKI, a CA may be the subject of n certificates from up to n
issuers.  Many will contain the same public key. (Again, there may be more
than one live key pair for rollover purposes.) In pathbuilding, any of
those n certificates may be the one you need to construct a path.  The
keyIdentifier allows you to quickly eliminate certificates for the "wrong"
public key.

Tim Polk

At 12:00 PM 4/9/98 -0700, Kevin Kingdon wrote:
>Tim,
>
>How does the combination of authorityCertIssuer and
>authorityCertSerialNumber not "solve the problem?" Doesn't it uniquely
>identify the authority certificate? Isn't this enough for building a
>certificate chain? How is this any different from the S/MIME use of
>issuer-serialNumber to identify a certificate?
>
>Kevin Kingdon
>RSA Data Security, Inc.
>
>> -----Original Message-----
>> From: Tim Polk [SMTP:[email-masked]]
>> Sent: Thursday, April 09, 1998 11:19 AM
>> To:   [email-masked]
>> Subject:      Re: [IETF-PKIX] Key Identifiers
>>
>> [Kevin Kingdon]  snip...
>>  The authorityCertIssuer and authorityCertSerialNumber do not solve
>> the
>> problem; the keyIdentifier field in the AuthorityKeyIdentifier
>> extension
>> *does* solve it.  That is a *very* important point.
>> [Kevin Kingdon]  snip...
>
>

Approved-By:  Kevin Kingdon <[email-masked]>
Date:         Thu, 9 Apr 1998 12:00: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: Kevin Kingdon <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Tim,

How does the combination of authorityCertIssuer and
authorityCertSerialNumber not "solve the problem?" Doesn't it uniquely
identify the authority certificate? Isn't this enough for building a
certificate chain? How is this any different from the S/MIME use of
issuer-serialNumber to identify a certificate?

Kevin Kingdon
RSA Data Security, Inc.

> -----Original Message-----
> From: Tim Polk [SMTP:[email-masked]]
> Sent: Thursday, April 09, 1998 11:19 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Key Identifiers
>
> [Kevin Kingdon]  snip...
>  The authorityCertIssuer and authorityCertSerialNumber do not solve
> the
> problem; the keyIdentifier field in the AuthorityKeyIdentifier
> extension
> *does* solve it.  That is a *very* important point.
> [Kevin Kingdon]  snip...

Approved-By:  Tim Polk <[email-masked]>
Date:         Thu, 9 Apr 1998 14:19:03 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

John,

Thanks for the clarifying things!  I certainly agree with both points.

The authorityCertIssuer and authorityCertSerialNumber do not solve the
problem; the keyIdentifier field in the AuthorityKeyIdentifier extension
*does* solve it.  That is a *very* important point.

I also agree with the second point.  The document should recommend the use
of the subject key identifier, even for end-entities.

Tim

At 01:36 PM 4/9/98 -0400, John Pawling wrote:
>Tim,
>
>I agree with your recommendations and have a few comments:
>
>1) PKIX I should require each AuthorityKeyIdentifier to be popoulated with
>the keyIdentifier field rather than the pair (authorityCertIssuer,
>authorityCertSerialNumber).
>
>2) I agree that PKIX I need not mandate that end-entity certs MUST include
>subjectKeyIdentifiers, but I believe that the spec should state that each
>end-entity cert SHOULD include a subjectKeyIdentifier.  This is useful for
>CAs to identify the key material that is included in a cert to assist with
>cert mgmt.  It also useful is some application environments.  For example,
>the US DoD ACP120 spec uses the subjectKeyIdentifier in the recipient's key
>management v3 X.509 certificate to match the recipient's copy of the
>encrypted session key with the recipient's key material.
>
>================================
>John Pawling, [email-masked]
>J.G. Van Dyke & Associates, Inc.
>www.jgvandyke.com
>================================
>
>
>

Approved-By:  John Pawling <[email-masked]>
Date:         Thu, 9 Apr 1998 13:36:36 -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: John Pawling <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Tim,

I agree with your recommendations and have a few comments:

1) PKIX I should require each AuthorityKeyIdentifier to be popoulated with
the keyIdentifier field rather than the pair (authorityCertIssuer,
authorityCertSerialNumber).

2) I agree that PKIX I need not mandate that end-entity certs MUST include
subjectKeyIdentifiers, but I believe that the spec should state that each
end-entity cert SHOULD include a subjectKeyIdentifier.  This is useful for
CAs to identify the key material that is included in a cert to assist with
cert mgmt.  It also useful is some application environments.  For example,
the US DoD ACP120 spec uses the subjectKeyIdentifier in the recipient's key
management v3 X.509 certificate to match the recipient's copy of the
encrypted session key with the recipient's key material.

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

At 12:39 PM 4/9/98 -0400, Tim Polk wrote:
>Along the lines of my last message:
>
>There was general discussion in the LA meeting about key identifiers.  If
>key identifiers are available, they greatly simplify path building and
>validation.  Unfortunately, there is no agreed method for generating the
>key identifiers.  Some vendors insert them, others try to "guess" them.
>Draft 07 of the profile recommends a method for generating key identifiers
>and recommends support for key identifiers, but there are no requirements.
>
>It was suggested that key identifiers be mandated for use in all
>certificates.  To facilitate chain building, I proposed we require
>authority key identifers in all certificates, and subject key identifiers
>in all CA certificates.  (Subject key identifiers in end-entity
>certificates do not affect chain-building.)
>
>There is no need to mandate a particular method for generating key
>identifiers if we include key identifiers in the certificate.  Assume a
>"CA-X" signs certificates with a private key "X-private" which has a
>corresponding public key "X-public".  The requirements are that the subject
>key identifier in CA certificates naming "CA-X" as the subject and
>containing "X-public" be the same as the authority key identifier ("AKI-X")
>in certificates issued by CA-X signed by the private key "X-private".
>
>Mandating a method is only needed if key identifiers are *implied*. I think
>it's too late for that - too many implementations have chosen different
>mechanisms all ready.
>
>Anyway, the general sense of the group (I don't think we took a straw poll)
>was that requiring key identifiers was a good idea.  This position still
>requires validation by the list.
>
>Note key identifiers would still be non-critical.  Certificate users would
>not be *required* to recognize them, much less use them.  Conforming CAs
>would simply be required to populate the extension.
>
>Tim Polk
>

Approved-By:  Tim Polk <[email-masked]>
Date:         Thu, 9 Apr 1998 12:39:41 -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: Tim Polk <[email-masked]>
Subject:      [IETF-PKIX] Key Identifiers
To: [email-masked]

Along the lines of my last message:

There was general discussion in the LA meeting about key identifiers.  If
key identifiers are available, they greatly simplify path building and
validation.  Unfortunately, there is no agreed method for generating the
key identifiers.  Some vendors insert them, others try to "guess" them.
Draft 07 of the profile recommends a method for generating key identifiers
and recommends support for key identifiers, but there are no requirements.

It was suggested that key identifiers be mandated for use in all
certificates.  To facilitate chain building, I proposed we require
authority key identifers in all certificates, and subject key identifiers
in all CA certificates.  (Subject key identifiers in end-entity
certificates do not affect chain-building.)

There is no need to mandate a particular method for generating key
identifiers if we include key identifiers in the certificate.  Assume a
"CA-X" signs certificates with a private key "X-private" which has a
corresponding public key "X-public".  The requirements are that the subject
key identifier in CA certificates naming "CA-X" as the subject and
containing "X-public" be the same as the authority key identifier ("AKI-X")
in certificates issued by CA-X signed by the private key "X-private".

Mandating a method is only needed if key identifiers are *implied*. I think
it's too late for that - too many implementations have chosen different
mechanisms all ready.

Anyway, the general sense of the group (I don't think we took a straw poll)
was that requiring key identifiers was a good idea.  This position still
requires validation by the list.

Note key identifiers would still be non-critical.  Certificate users would
not be *required* to recognize them, much less use them.  Conforming CAs
would simply be required to populate the extension.

Tim Polk

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 9 Apr 1998 09:34:39 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

>Many, many months ago, we decided that PKIX Part 1 should say something about
>every extension in X.509.  Keeping with this philosophy, I propose the
>following words for the extensions that are being "removed:"
>CAs conforming to this profile must not issue certificates [or CRLs] that
>contain this extension.  If this extension is present and marked non-critical
>in a certificate [or CRL], conforming applications must ignore this
>non-critical extension.  If this extension is present and marked critical
in a
>certificate [or CRL], conforming applications must reject the certificate [or
>CRL] containing this critical extension.

That sounds good to me. It covers the area completely without leaving "holes"
in the spec for implementors to guess about.

I would feel differently if Entrust had different licensing for their patent.
If the patent were licensed along the lines of Netscape's SSL patent (no fees
or contract required, just an agreement to not hold any SSL-related patents
against Netscape), I would say we shouldn't rip out all the features. However,
since Entrust wants money from every commercial entity that uses these
features, this group have no choice but to excise the features. I think Russ'
wording is the best way to do this.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Tim Polk <[email-masked]>
Date:         Thu, 9 Apr 1998 12:11:08 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

For those who weren't in the LA meeting, this proposal was requested by the
S/MIME working group.  An empty issuer name wreaks general havoc with their
protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
an important consideration.

In addition, implementors have identified name chaining as a specific
difficulty in PKIX implementations.  Prohibiting empty issuer names greatly
simplifies path building and validation.

When the issue was discussed in the meeting, no requirement for empty
issuer names was identified.  The original author of that section agreed
that empty subject names in end-entity certificates was sufficient for his
purposes.

Response at the meeting indicated general support (I don't recall any
objectsions) for requiring issuer names in all certificates.  Of course,
this decision requires validation by the list.

Assuming general consensus, John has done an excellent job of identifying
the changes that are required in the document.  I will make sure they are
all implemented.

Tim Polk

At 07:23 PM 4/8/98 -0400, John Pawling wrote:
>All,
>
>Based on the disussion at the recent PKIX meetings, propose that the
>following text should be added to the PKIX X.509 Certificate and CRL
>Profile, Issuer Name section (4.1.2.4) and Subject Name section (4.1.2.6):
>"All subject and issuer names MUST be populated (i.e. not an empty SEQUENCE)
>in PKIX-compliant X.509 certificates, except that the subject name in a
>user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in which case
>the subjectAltName extension will include the subject's identifier and MUST
>be marked as critical."
>
>This following text should be deleted from the Issuer Name section
>(4.1.2.4): "The issuer identity may be carried in the issuer name field
>and/or the issuerAltName extension.  If identity information is present only
>in the issuerAltName extension, then the issuer name may be an empty
>sequence and the issuerAltName extension must be critical."
>
>In the Issuer Name section (4.1.2.4), the phrase "Where it is non-null"
>should be deleted from "Where it is non-null, the issuer name field shall
>contain an X.500 distinguished name (DN)."
>
>In the Certificate Extensions section (4.2), the following text should be
>deleted: "If the CA issues certificates with an empty sequence for the
>issuer field, the CA must support the issuerAltName extension."
>
>In the Issuer Alternative Name section (4.2.1.8), the following text should
>be deleted: "If the only issuer identity included in the certificate is an
>alternative name form (e.g., an electronic mail address), then the issuer
>distinguished name shall be empty (an empty sequence), and the issuerAltName
>extension shall be present. If the subject field contains an empty sequence,
>the issuerAltName extension shall be marked critical."
>
>The CRL Issuer Name section (5.1.2.3) should be changed to read as follows:
>"The issuer name identifies the entity who has signed (and issued the CRL).
>The issuer name field shall contain an X.500 distinguished name (DN).  The
>issuer name field is defined as the X.501 type Name, and shall follow the
>encoding rules for the issuer name field in the certificate (see 4.1.2.4)."
>
>In section 5.1.2.6  Revoked Certificates, the phrase "or issuer altrnative
>name" should be delted from: "Certificates are uniquely identified by the
>combination of the issuer name or issuer alternative name along with the
>user certificate serial number."
>
>In section 5.2.2 Issuer Alternative Name, the following text should be
>deleted: "Further, if the only issuer identity included in the CRL is an
>alternative name form (e.g., an electronic mail address), then the issuer
>distinguished name should be empty (an empty sequence), the issuerAltName
>extension should be used, and the issuerAltName extension must be marked
>critical."
>
>In section 6, Certificate Path Validation, the following text should be
>deleted: "(If the certificate has an empty sequence in the name field, name
>chaining will use the critical subjectAltNames and issuerAltNames fields.)"
>
>================================
>John Pawling, [email-masked]
>J.G. Van Dyke & Associates, Inc.
>www.jgvandyke.com
>================================
>
>

Approved-By: [email-masked]
Date:         Wed, 9 Sep 1998 11:37:13 +0200
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mark Shuttleworth <[email-masked]>
Organization: Thawte Consulting
Subject:      [IETF-PKIX] Enforcing constraints
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms432C625C457E29CF13C6C705
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi folk

I think nameConstraints and basicConstraints, if implemented,
should be completely enforced.  People tend to ignore warnings
if there is an OK button there... especially if the warning
message is "The digital encryption certificate that has been
presented fails IETF PKIX X.509 constraints, path validation
or EKU processing rules. Abort, retry or ignore?"

--
Mark Shuttleworth
Thawte
--------------ms432C625C457E29CF13C6C705
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

--------------ms432C625C457E29CF13C6C705--

Approved-By: [email-masked]
Date:         Wed, 8 Apr 1998 17:25:00 -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: Tim Dierks <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

At 10:23 AM -0600 4/8/98, Bob Jueneman wrote:
>Tim, do I gather from the fact that the OID is just now being established
>for RSA with SHA-1 digital signatures, that few if any implementations are
>presently prepared to accept such an algorithm?

Also, the common SSL implementations (Consensus, Microsoft, Netscape,
others) support the RSA SHA-1 OID and encoding mechanism.

 - Tim

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 9 Apr 1998 08:16:10 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

Sounds good to me.

At 09:31 AM 4/9/98 -0400, Russ Housley wrote:
>At the PKIX meeting in LA, Tim Polk gave a presentation on the extensions
that
>will be removed from PKIX Part 1 to remove any dependance on recently issued
>patents.  A straw poll confirmed overwhelming support for this approach,
>and we
>are making the changes to remove the extensions.
>
>Many, many months ago, we decided that PKIX Part 1 should say something about
>every extension in X.509.  Keeping with this philosophy, I propose the
>following words for the extensions that are being "removed:"
>CAs conforming to this profile must not issue certificates [or CRLs] that
>contain this extension.  If this extension is present and marked non-critical
>in a certificate [or CRL], conforming applications must ignore this
>non-critical extension.  If this extension is present and marked critical
in a
>certificate [or CRL], conforming applications must reject the certificate [or
>CRL] containing this critical extension.
>Russ
>
>

Approved-By:  Russ Housley <[email-masked]>
Date:         Thu, 9 Apr 1998 09:31:20 -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: Russ Housley <[email-masked]>
Subject:      [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

At the PKIX meeting in LA, Tim Polk gave a presentation on the extensions that
will be removed from PKIX Part 1 to remove any dependance on recently issued
patents.  A straw poll confirmed overwhelming support for this approach,
and we
are making the changes to remove the extensions.

Many, many months ago, we decided that PKIX Part 1 should say something about
every extension in X.509.  Keeping with this philosophy, I propose the
following words for the extensions that are being "removed:"
CAs conforming to this profile must not issue certificates [or CRLs] that
contain this extension.  If this extension is present and marked non-critical
in a certificate [or CRL], conforming applications must ignore this
non-critical extension.  If this extension is present and marked critical in a
certificate [or CRL], conforming applications must reject the certificate [or
CRL] containing this critical extension.
Russ

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Thu, 9 Apr 1998 08:38:22 -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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] LDAP v2 schema - object classes for users and CAs
To: [email-masked]

Hi Sean,

The last paragraph of clause 3 includes the reasons for defining these
object classes. There are 2 basic reasons.

Firstly the mandatory attributes contained in the X.509 CA object class are
not mandatory for PKIX. PKIX CAs may choose to make CRLs available through
http or ftp for instance and not from a directory. However those same CAs
may choose to populate either the cACertificate or crossCertificatePair
attribute or both or neither. The only way to accommodate this is to make
all the attributes optional. When you suggest empty attributes do you mean
for instance that the CRL attribute type would have a single value which is
a signed construct corresponding to the right syntax or do you mean that
only an attribute type would be present and no value? The latter I don't
believe is possible (Tim/Pat can you comment?). The former (and probably
also the latter) creates a security problem in that a relying party
retrieving such an object could assume that no certificates had been
revoked.

The second reason for the new object classes is that the addition / deletion
of auxiliary object class values to the object class attribute is a facility
not widely supported by LDAPv2 servers. This support would be required if we
tried to use the X.509 object classes again because of the mandatory
attributes. You can't "preload" the object class values without also loading
the attributes. Also you can't delete the attributes from an entry without
removing the auxiliary object class values (user certificate is a mandatory
attribute). This would mean that every time you added/deleted the
certificate attribute from a user's entry or one of the mandatory attributes
from a CAs entry, you need to modify the object class attribute.

Hope this helps explain the rationale. (Incidentally I anticipate that
similar modifications will be proposed to X.509 as well).

Sharon

> ----------
> From:         Sean Turner[SMTP:[email-masked]]
> Sent:         April 9, 1998 7:19 AM
> To:   [email-masked]
> Subject:      [IETF-PKIX] LDAP v2 schema - object classes for users and
> CAs
>
> Sharon (and co-editors),
>
> I took a look at the first draft and have a couple of comments/questions:
>
> Why weren't the object classes strongAuthenticationUser and
> certificationAuthority (from X.521) used for storing user and CA certs in
> the directory?
>
> In the case of the pkiUser, the object class is the same as
> strongAuthenticationUser, except for the name and oid.  So, couldn't we
> just reuse the object class from X.521?
>
> In the case of pkiCA, it seems strange to me that you'd move the
> cACertificate, certificateRevocationList, and authorityRevocationList to
> 'MAY CONTAIN'.  I think you'd want these attributes to always be present
> in a CA's directory entry.  If there's no information for the CRL, ARL, or
> cross certificate pair they can be constructed to be 'empty'.  Even if
> there are reasons for making them optional attributes, I still can't see
> the reason for a new object class - why not just the one out of X.521?
>
> Thanks,
>
> --
> Sean Turner - IECA, Inc.
>

Approved-By:  Sean Turner <[email-masked]>
Date:         Thu, 9 Apr 1998 07:19:01 -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: Sean Turner <[email-masked]>
Organization: IECA, Inc.
Subject:      [IETF-PKIX] LDAP v2 schema - object classes for users and CAs
To: [email-masked]

Sharon (and co-editors),

I took a look at the first draft and have a couple of comments/questions:

Why weren't the object classes strongAuthenticationUser and certificationAuthority (from X.521) used for storing user and CA certs in the directory?

In the case of the pkiUser, the object class is the same as strongAuthenticationUser, except for the name and oid.  So, couldn't we just reuse the object class from X.521?

In the case of pkiCA, it seems strange to me that you'd move the cACertificate, certificateRevocationList, and authorityRevocationList to 'MAY CONTAIN'.  I think you'd want these attributes to always be present in a CA's directory entry.  If there's no information for the CRL, ARL, or cross certificate pair they can be constructed to be 'empty'.  Even if there are reasons for making them optional attributes, I still can't see the reason for a new object class - why not just the one out of X.521?

Thanks,

--
Sean Turner - IECA, Inc.

Approved-By:  John Pawling <[email-masked]>
Date:         Wed, 8 Apr 1998 19:23: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: John Pawling <[email-masked]>
Subject:      [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

All,

Based on the disussion at the recent PKIX meetings, propose that the
following text should be added to the PKIX X.509 Certificate and CRL
Profile, Issuer Name section (4.1.2.4) and Subject Name section (4.1.2.6):
"All subject and issuer names MUST be populated (i.e. not an empty SEQUENCE)
in PKIX-compliant X.509 certificates, except that the subject name in a
user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in which case
the subjectAltName extension will include the subject's identifier and MUST
be marked as critical."

This following text should be deleted from the Issuer Name section
(4.1.2.4): "The issuer identity may be carried in the issuer name field
and/or the issuerAltName extension.  If identity information is present only
in the issuerAltName extension, then the issuer name may be an empty
sequence and the issuerAltName extension must be critical."

In the Issuer Name section (4.1.2.4), the phrase "Where it is non-null"
should be deleted from "Where it is non-null, the issuer name field shall
contain an X.500 distinguished name (DN)."

In the Certificate Extensions section (4.2), the following text should be
deleted: "If the CA issues certificates with an empty sequence for the
issuer field, the CA must support the issuerAltName extension."

In the Issuer Alternative Name section (4.2.1.8), the following text should
be deleted: "If the only issuer identity included in the certificate is an
alternative name form (e.g., an electronic mail address), then the issuer
distinguished name shall be empty (an empty sequence), and the issuerAltName
extension shall be present. If the subject field contains an empty sequence,
the issuerAltName extension shall be marked critical."

The CRL Issuer Name section (5.1.2.3) should be changed to read as follows:
"The issuer name identifies the entity who has signed (and issued the CRL).
The issuer name field shall contain an X.500 distinguished name (DN).  The
issuer name field is defined as the X.501 type Name, and shall follow the
encoding rules for the issuer name field in the certificate (see 4.1.2.4)."

In section 5.1.2.6  Revoked Certificates, the phrase "or issuer altrnative
name" should be delted from: "Certificates are uniquely identified by the
combination of the issuer name or issuer alternative name along with the
user certificate serial number."

In section 5.2.2 Issuer Alternative Name, the following text should be
deleted: "Further, if the only issuer identity included in the CRL is an
alternative name form (e.g., an electronic mail address), then the issuer
distinguished name should be empty (an empty sequence), the issuerAltName
extension should be used, and the issuerAltName extension must be marked
critical."

In section 6, Certificate Path Validation, the following text should be
deleted: "(If the certificate has an empty sequence in the name field, name
chaining will use the critical subjectAltNames and issuerAltNames fields.)"

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

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 8 Apr 1998 14:33:38 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
Comments: cc: Robert Jueneman <[email-masked]>
To: [email-masked]

Bob,

At 08:06 AM 4/8/98 -0600, you wrote:

[tony snip here]

>More to the point, if an implementation "enforces" such a constraint, what
do they
>do if the formal validation fails?  I would generally expect that a
reasonable
>implementation would simply buck the decision up to the human user "The
>xxx constraint is violated by certificate yyy. Do you want to accept the
>certificate anyway?"  What is the norm for most implementations?
>
>Bob

Like an "harmonic convergence", your paragraph above mirrors my question in
the "Criticality of extensions" thread.  By extension (no pun intended) what
if, for certain "common" extensions, the window pops-up with the additional
check-box labeled "Don't warn me again"?  (I.e., henceforth always accept
the cert if this particular constraint fails.)  I suppose this is perfectly
legal, but is contrary to what many "expect" by "enforces constraints."

____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 Hoffman / IMC <[email-masked]>
Date:         Wed, 8 Apr 1998 11:46: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

At 11:36 AM 4/8/98 -0400, David P. Kemp wrote:
>> >Validity Period Nesting
> . . .
>As before, this should not be a MUST, a SHOULD, or even a MAY in any
>PKIX or S/MIME document.  If someone is checking validity period
>nesting, they may possibly reject valid certification paths.   There is
>no security benefit to checking nesting; the only checking required is
>to ensure that each certificate is currently valid.

After reading David's earlier response to the nesting issue, I now agree
with him. It's just not important, since the EE is validating each step of
the path. To me, this is now a non-issue.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 8 Apr 1998 11:11:35 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Criticality of extensions
Comments: cc: "David P. Kemp" <[email-masked]>
To: [email-masked]

At 11:15 AM 4/8/98 -0400, you wrote:
>> From: Tony Bartoletti <[email-masked]>
>>
>> Regarding the last exchanges from Graham Bland and Paul Koning, I am
>> prompted to build this (possible) table:
>>
>>   Behaviors on Extensions:
>>
>>                           |  Critical           |  Non-Critical
>>                           |  Extensions         |  Extensions
>>   --------------------------------------------------------------------
>>   Extension Not           |   REJECT ?          |   IGNORE
>>   Recognised/Understood   |                     |
>>   --------------------------------------------------------------------
>>   Extension               |   CP/CPS ?          |   "RP Policy" ?
>>   Recognized/Understood   |                     |
>>   --------------------------------------------------------------------
>
>
>I like this table.

Thanks.  I intended it as a straw-man, and find I can think more clearly
when I have a picture to look at.

>
>Comments:
>
>1) Is there a reason for the question mark after REJECT?  If we can't
>   count on the application failing a critical extension it does not
>   support, then there isn't much reason to have the critical bit at all.

I agree.  I suppose I wanted to see if anyone would offer an argument
to the contrary.

>2) At least three words could be used in the row headings:
>   Recognised, Understood, Supported.  I believe that
>   Recognised/Understood does not have the right connotation; the idea
>   being that an application must not only "recognize" (know the syntax
>   of) an extension, it must also take some specified action before being
>   allowed to claim compliance with a standard or profile.  "Supported"
>   better captures that flavor, but other suggestions are welcome.

Right.  "Recognized" and "Supported" are really the two qualities that
I believe are confused in many minds here, and this gets to the heart
of my central question.  To expand:

Originally (I believe), the critical flag intended to tell the application
that "it must be *able* to [process, deal with] the extension in the course
of determining the validity.  This wording leaves some room for the RP to
exercise its discretion, perhaps through the setting of some preferences.

As an analogy, if I read in a Word-5 document in my Word-7 application,
make a change, and then attempt to save it, the application should pop-up
a window to warn me that "some formatting may be lost" if I attempt to
save it as a Word-5 document.  I can do so, but the application "did its
job".

In contrast, (I feel) that many intend to use the critical flag in some
manner to "enforce policy".  The scenario being, in a court of law, the
CA says, "The critical flag was set, and yet the plaintiff clearly chose
to ignore it, and validate the cert anyway."  The plaintiff says, "But my
application popped up a window, and gave me a choice of how to continue."

Well, the app certainly "recognised" the extension, and arguably it even
"processed" the extension.  But it did not "force compliance with the
(semantic) intent of the extension.

The point being, "recognizing", "able to process" and "forces processing
compliant with the semantic intent of the extension" are terms that must
be specified or explained when stating what it means for an application
to be "PKIX compliant".  The term "process" alone is overloaded.

>3) I've already ranted about conditioning the behavior of supported
>   extensions on the critical bit.  But to reiterate, I believe the
>   lower row should have the identical entries in both columns.  At
>   most, the "RP Policy" should be a binary choice, either treat a
>   non-critical extension identically to the same extension marked
>   critical, or ignore it.  (If the lower right box is IGNORE only, you
>   have Peter Gutmann's scenario of "this extension does nothing except
>   bulk up the certificate".  I'd prefer the box to be CP/CPS only, but
>   recognize that the RP always has the option of using downrev
>   software which doesn't support the extension.)

This seems to agree with my former use of "supports" above, but argues
back to my use of "REJECT?".  If I want to ignore a extension that I
would otherwise understand, I fall back to a downrev but I don't REJECT.

>
>Proposal:
>
>   Behaviors on Extensions:
>
>                           |  Critical           |  Non-Critical
>                           |  Extensions         |  Extensions
>   --------------------------------------------------------------------
>   Extension Not           |   REJECT            |   IGNORE
>   Supported               |                     |
>   --------------------------------------------------------------------
>   Extension               |   CP/CPS ?          |   RP configurable:
>   Supported               |                     |   CP/CPS or IGNORE
>   --------------------------------------------------------------------

Maybe we need a bigger table;)

___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:  Sharon Boeyen <[email-masked]>
Date:         Wed, 8 Apr 1998 13:58:27 -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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] LDAP v2 schema
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

> The structure is thus correct. However, adding more explanations to say
> that you may find there "new by new", "old by new" and "new by old"
> self-signed certificates would not hurt. Wouldn't it ?
>
I have no problem with additional explanatory text but for 509 it would need
to be submitted as ballot comment to the DTC. Will you be initiating that?

> An additional minor(?) question coming from what I heard at the meeting.
> Should the CRL distribution points and the reference to the patent from
> Entrust be deleted ?
>
I wasn't at the meeting but it is my understanding that CRL distribution
points and reference to the patent will be deleted.

> Finally, an editorial comment: Change section 5 into 4.2 and renumber
> the following.
Yup!

Thanks,
Sharon

Approved-By:  Brian Korver <[email-masked]>
Date:         Wed, 8 Apr 1998 10:51: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: Brian Korver <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

Tim Polk writes:
>
> Bob,
>
> The OID has been around for several years.  Version 1.5 of PKCS #1, which
> is the current version, was published in November of 1993.  Unfortunately,
> the OID was defined after that publication date.  Although RFC 2313 is more
> recent, it did not include any new information.
>
> There are a number of implementations that use this OID.  The S/MIME
> community uses it; I first heard about it when a vendor using the OIW oid
> for RSA and SHA-1 couldn't pass the interoperability tests.  The rationale
> for switching was that vendors had to support that oid for S/MIME, so why
> not use the same one?  The OIW oid is kind of an orphan now, anyway, so we
> did.
>
> Tim Polk

FYI, SET uses this OID as well.

brian
[email-masked]

Approved-By:  Robert Jueneman <[email-masked]>
Date:         Wed, 8 Apr 1998 08:06: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: Robert Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
Comments: To: [email-masked]
To: [email-masked]

On the issue of nested validity dates, I don't agree.

At time T, all that I need to know is whether the certificate chain is valid at
that instant. It makes no sense at all to reject a certificate at time T because
at time T+2 some CA's certificate will have expired, i.e., at time T+1.

This isn't even a nonrepudiation issue, at least for transactions that took place
at time T.

Since the CA's certificate might well be renewed prior to the time that it expires,
enforcing nesting of validity period prior to the earliest expiration makes no
sense at all.

I could care less whether some particular vendor's product misunderstands
the problem -- that's their problem to solve, and if they don't the marketplace
will solve it for them.  I am certainly NOT prepared to concede a de facto
veto power to Microsoft, Netscape, or anyone else.

Having said all that, I would certainly expect that CAs would typically issue
certificates with nested dates, but that shouldn't be an imposed constraint.

On the other hand, I do agree that some kind of an implementationCreatedBy
attribute would be useful, if only for debugging and information purposes.
If the IETF could QUICKLY agree upon the syntax and OID for such an attribute,
I could probably still get it into our forthcoming CA product release. Alternatively,
I could define an OID, and let everyone else adopt it. But there is no point in
our implementing such a concept if no one else does.

I would NOT suggest that everyone start trying to track a moving target of
everyone's favorite lame-brain implementation, especially within a standards
group. But as Peter has pointed out, the various implementations are
currently all over the map in certain areas, and if some vendors choose to be
more flexible in trying to interoperate with other vendor's products, that is
a valid way of trying to create their market niche.  After all, it takes a while
to turn around an oil tanker, and even after new releases become available
it will take a while before all of the old software versions disappear.

>Just out of interest, has anyone here seriously deployed X.509v3 software
>which actually uses and enforces basicConstraints, keyUsage/extendedKeyUsage,
>and the various policy constraints (as required by PKIX, including attention
>to critical flags) which interoperates correctly with mass-market software
>like MSIE, Exchange, Netscape Navigator, etc etc?

More to the point, if an implementation "enforces" such a constraint, what do they
do if the formal validation fails?  I would generally expect that a reasonable
implementation would simply buck the decision up to the human user "The
xxx constraint is violated by certificate yyy. Do you want to accept the
certificate anyway?"  What is the norm for most implementations?

Bob

>>>The validity period of a certificate must lie within the validity period of
>>>the certificate which signed it.
>>I'm not entirely happy with this suggestion. One can issue a new CA
>>certificate for a CA key whose original cert has expired, while keeping the
>>value of the key (and key version number extension) the same.
>
>The main reason for this is that currently the situation with enforcing
>nesting is ambiguous (as pointed out in the style guide), so that implementors
>can choose to enforce it either way.  The reason I recommended nesting is that
>given that it's a toss-up between enforcing and not enforcing it, and
>Microsoft (AFAIK) enforces it, you may as well do it too.  This has the added
>benefit that your certs will appear valid to MS software.
>
>The reason for being fascist about it ("do it this way or else") was that
>without clear guidelines we'll get the same situation that we already have
>with cert extensions, where 50% of people do it one way, 50% do it the other
>way, and the remaining 50% do it a third way which comes as a complete
>surprise to everyone else.
>
>>>This leads to a second type of extension, implementationWhichCreatedThis,
>>>which may be even more useful than the one described above.  As it is, it's
>>>already possible to identify certain implementations just by the bugs in the
>>>certificates they produce, but being able to make a positive ID would be
>>>really useful because by knowing how they (mis)interpret certain fields, your
>>>implementation could follow the same interpretation.
>
>>This way madness lies.
>>
>>It leads to a situation where each vendor has their own subtly different
>>protocol, and each implementation needs to be able to talk all of these
>>protocols.
>
>And this differs from the current situation in which way?  (See
>http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt for more details -
>there's a more recent version which has another round of CA and implementation
>bugs at the end which I haven't uploaded yet, so it's even worse than the
>already depressing picture painted in the guide.  It only covers cert formats,
>but the fact that there are implementations which will happily process the
>incorrect, illogical, and inconsistent nonsense which is appearing in some
>certs indicates that we're already in a situation where implementations are
>having to bend over backwards to handle the broken certificates others are
>issuing.  All that this proposal does is formalise the identification of cert
>types).
>
>It's nice to see that someone agrees with me that the current situation is
>crazy though :-).
>
>Just out of interest, has anyone here seriously deployed X.509v3 software
>which actually uses and enforces basicConstraints, keyUsage/extendedKeyUsage,
>and the various policy constraints (as required by PKIX, including attention
>to critical flags) which interoperates correctly with mass-market software
>like MSIE, Exchange, Netscape Navigator, etc etc?
>
>Peter.

Approved-By:  Tim Polk <[email-masked]>
Date:         Wed, 8 Apr 1998 13:17:06 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

Bob,

The OID has been around for several years.  Version 1.5 of PKCS #1, which
is the current version, was published in November of 1993.  Unfortunately,
the OID was defined after that publication date.  Although RFC 2313 is more
recent, it did not include any new information.

There are a number of implementations that use this OID.  The S/MIME
community uses it; I first heard about it when a vendor using the OIW oid
for RSA and SHA-1 couldn't pass the interoperability tests.  The rationale
for switching was that vendors had to support that oid for S/MIME, so why
not use the same one?  The OIW oid is kind of an orphan now, anyway, so we
did.

Tim Polk

At 10:23 AM 4/8/98 -0600, Bob Jueneman wrote:
>Tim, do I gather from the fact that the OID is just now being established
for RSA with SHA-1 digital signatures, that few if any implementations are
presently prepared to accept such an algorithm?  What is the recommend
algorithm OID for use in certificates in that case?  Bob  (Sorry, for some
reason my Enter key seems to be stuck or not working for text input. ???)
>>
>>>>> Tim Polk <[email-masked]> 04/08 7:16 AM >>>
>>The PKIX draft included the brief description of signatures using RSA since
>>there was no RFC to point to.  We used the OIW oid since there wasn't an
>>oid for RSA with SHA-1 in the pkcs-1 arc.
>>
>>Since we started, PKCS #1 Version 1.5 has become RFC 2313.  The next
>>(final!) draft will simply point to RFC 2313 for details on implementing
>>RSA signatures.
>>
>>The next draft will also use RSA with SHA-1 from the pkcs-1 arc.
>>Unfortunately, the RSA with SHA-1 oid is not in RFC 2313 (or any other
>>published version of PKCS #1.)  The following text was RSA-approved, so it
>>should be correct:
>>
>>**** RSA with SHA-1 text ****
>>
>>The signature algorithm with SHA-1 and the RSA encryption algorithm
>>is implemented using the padding and encoding conventions described in
>>PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1
>>hash algorithm.  The ASN.1 object identifier used to identify this
>>signature algorithm is:
>>
>>     sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
>>         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>>         pkcs-1(1) 5  }
>
>
>

Approved-By:  Robert Moskowitz <[email-masked]>
Date:         Wed, 8 Apr 1998 12:45:45 -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: Robert Moskowitz <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

At 10:44 AM 4/8/98 -0400, Paul Koning wrote:
>
>When certificates are used to authorize something that lasts for a
>while, it seems to me one would also want to determine the end of the
>validity period for a certificate.  For example, if a certificate is
>used to set up an IPSec (ISAKMP) SA, it would seem logical to limit
>the lifetime of that SA to be the validity period of the certificate
>used.
>
BTW, this behaviour is the recommended behaviour for IPsec (per wg
concensus) and will get captured in some IPsec document, most likely
Rodney's IPsec cert profile.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 8 Apr 1998 12:43:36 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

> From: Paul Koning <[email-masked]>
>
> When certificates are used to authorize something that lasts for a
> while, it seems to me one would also want to determine the end of the
> validity period for a certificate.  For example, if a certificate is
> used to set up an IPSec (ISAKMP) SA, it would seem logical to limit
> the lifetime of that SA to be the validity period of the certificate
> used.

I'm not sure I agree with the example.  My assumption would be that
the SA is authenticated at the time of creation and lasts for whatever
period is appropriate to the application.  If the cert happened to
expire 1/2 hour after the SA was established, and I otherwise intended
for the SA to last 8 hours, I wouldn't want to truncate the SA.
If I really needed 1/2 hour freshness granularity, I'd just negotiate
a new SA (with a new certification path check) every 1/2 hour.
If you took the "continuously valid" approach, you would need to check
not only validity period of the certs, but also their revocation status
throughout the SA lifetime.

But assuming that the example is valid, the "current time" would
become a "current time interval", which would need to be contained
in the validity period of every cert in the path.  That still doesn't
involve any nesting checks on the certs.

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 8 Apr 1998 10:23:28 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
Comments: To: [email-masked]
To: [email-masked]

Tim, do I gather from the fact that the OID is just now being established for RSA with SHA-1 digital signatures, that few if any implementations are presently prepared to accept such an algorithm?  What is the recommend algorithm OID for use in certificates in that case?  Bob  (Sorry, for some reason my Enter key seems to be stuck or not working for text input. ???)
>
>>>> Tim Polk <[email-masked]> 04/08 7:16 AM >>>
>The PKIX draft included the brief description of signatures using RSA since
>there was no RFC to point to.  We used the OIW oid since there wasn't an
>oid for RSA with SHA-1 in the pkcs-1 arc.
>
>Since we started, PKCS #1 Version 1.5 has become RFC 2313.  The next
>(final!) draft will simply point to RFC 2313 for details on implementing
>RSA signatures.
>
>The next draft will also use RSA with SHA-1 from the pkcs-1 arc.
>Unfortunately, the RSA with SHA-1 oid is not in RFC 2313 (or any other
>published version of PKCS #1.)  The following text was RSA-approved, so it
>should be correct:
>
>**** RSA with SHA-1 text ****
>
>The signature algorithm with SHA-1 and the RSA encryption algorithm
>is implemented using the padding and encoding conventions described in
>PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1
>hash algorithm.  The ASN.1 object identifier used to identify this
>signature algorithm is:
>
>     sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
>         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>         pkcs-1(1) 5  }

Approved-By: [email-masked]
Date:         Tue, 7 Apr 1998 17:49: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: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Comments on CMP-07
To: [email-masked]

The following are my comments on the CMP draft.  Please note that some of
the comments may be changed based on the outcome of issues dealing with the
CRMF draft which I have already asked about.

Not all of these comments are of equal weight, some are merely nits while
others are issues I feel strongly about.  I have not given weighting in this
message so that my personal opinions do not necessaryly come out as
opinions.

1.  Section 1.2.2 paragraph 4:  This paragraph defines the term "root CA"  I
wish to be sure that the fact this is the directly trusted root does not
imply that this is the CA which is going to issue my certificate.  I cannot
remember any text stating this but I wish to verify it.

2.  Section 1.3, page 6:  The graph is nice, however the letters marking the
paths are not refered to in the text.  It is dificult in some cases to be
sure what the letters refer to.  This is especially true of c and d.  Please
make a table of what the letters mean or refer to them from the text itself.

3.  Section 1.3 page 7: Formatting note:  please be consistant about how you
format the notes in the text.  I have found atleast two different ways of
this being done.  I suggest that you put in the word "NOTES:" and then a
numbered indented list.  This allows me to have an easy transistion both
into and out of the notes when reading the text.  The first pass on page 7 I
got lost about what I was reading since I was on a computer screen rather
than on a printed page.

4.  Section 2.1, paragraph #1:  The paragraph makes reference to obtaining
the information about the PKI functions supported, but gives no supporting
material on how this would be done.  Is this out-of-band in the same way
that acquiring the root CA public key is?

5.  Section 2.3, pargraph #1: Reference is made to the fact that a given
CA/RA may choose how to implement the POP enforcement, and the profile at
the end says it must be done, however I cannot find anyplace which says how
a client would find out which of the different methods are or are not
supported by the CA/RA.

6.  Section 2.3.2, pargraph 2:  You use the term "immediate", can you be
more explicit what you mean by this?  Is it legitiment that a e-mail based
protocol would use the direct method considering that the messages may take
several days to complete the round trip?

7.  Section 2.4, paragraph #1: I always dislike this type of hair splitting
but:  If I have a CA which has issued a certificate to an RA by the
definition in section 1.2.1 this might not apply to that CA.  In a more
general note, how does one go about updating the keys in a CA which has only
issued certificates to other CAs?  I would have thought that the same
procedure applied.

8.  Section 2.4, paragraph #2:  This paragraph contains the phrase "if
certificates are made available using an X.500 directory".  What are we
suppose to do if the certificates are NOT made available with an X.500
directory?  Never update the root CA keys?  This needs to be fleshed out.

9.  Section 2.4, paragraph #3:  If the CA changes some of the extensions on
the CA:  1) is this a kosher change to make and 2) how should these changes
be reflected in the new certificates?  According to new policy?

10.  Section 2.4, paragraph #3:  The time period of the cross-certificate
certs may also need to be modified according to how one thinks that the
certificates are in use over the wider internet.  Specifically how long
external entities will take to get the new certificate and establish a trust
point on it.

11.  Section 2.4.1:  It is ok to change the encoding of the name at this
point?  I specficically ask about this after some of the discussions at the
IETF about the new use of UTF8 and the fact that the perfered encoding rules
for distinguished names may end up changing over time.  It seems to me that
this would be a good place to handle this issue by doing a roll over of the
root certificates with new names, but maybe the same keys.

12.  Section 2.4.1, paragraph #8:  I disagree that the old CA private key
can be thrown away with impunitity at this time.  Specifically if you use
such an extension as CRL Distribution points, an internet client with an old
certificate may come looking for a new CRL and get one it cannot understand
as it is signed with the new key only.  Either one needs to determine a way
to return the new set of chainging certificates with this CRL or the CRL
with the old private key needs to be generated until such as time as the old
certificate expires.

13.  Section 2.4.2.2, paragraph #1:  Under what circumstances should the
client make this decision that the certificate must be the wrong one.  I can
see that this could be a problem in the internet where going and finding the
new CA key may be expensive.  One can no longer state that the signature was
bad on the certificate, one just weasel about how the certificate might be
good, if only one knew how to find the correct signing certificate.  Such a
lookup would be required anytime a certificate, including an apparently self
signed certificate, failed to verify.  After all the self-signed certificate
may really be a newWithOld or oldWithNew as the subject and issuer DNs would
match in these cases.

14.  Section 3.1, paragraph 5:  I dislike the term PKIProtection.  This
implies more to me that it really means.  What it really is would be
PKIAuthentication as all you are doing is authenticating the data not
protecting (or masking) the data.  Protection implies encryption to me.

15.  Section 3.1.1: Why is sender a GeneralName rather than a GeneralNames?
It seems to me that often times I would need to put a more compete set of
names here.  Two circumstances would be: a) during initialization when I
might not know which of several different names you might know me by and b)
if I don't have a Subject DN in my certificate but rather have a Subject
AltName extension which contains several different possible names.

16.  Section 3.1.1, page 22:  In the pargaraph on using sigantures for the
PKIProtection field, I have two questions:
        A)  Can I use a signature field at this location during the
initialization operation?  I can see the ability to do this if I am signing
with an already existing trusted certificate from a different infrastructure
that maps.  On the other hand I can see you "forbidding" this as being
incompatable with the published criteria of startup.
        B)  In the event that I posses multiple different signature pairs
which are all currently active (some of which may be historical but with
currently active certificates) how does the receiving party know which of
the potentially different certificates I used?  Does this require some type
of exhaustive testing?  Or are you assuming that one would only try the
currently published certificate(s) in the directory service?

17.  Section 3.2.3:  I see benifit of taking the PKIStatus and
PKIFailureInfo from both the CMMF and CMP documents and making them common
to the CRMF document.  This is espcially true as they currently have the
same name and are likely to diverge in terms of what additional errors may
be appended to the ends of the lists.

18.  Section 3.2.5:
        Bullet 1:  States that the certificate must be self-signed.  This
appears to go againist the statment that a root CA may be part of a
heirarchy as the certificate would not be self-signed in that case.
        Bullet 3:  PKIX part #1 is changing its stance on the lack of a
subject field in CA certificates.  You should choose working which is
agreement with the modifications to part #1.

19.  Section 3.2.8, page 27, first paragraph:  As I could not follow the
reasoning and was unable to easily find the referenced document, please
include a brief statement in the text about why this decryption of the
integer is not part of the security attack referenced in the security
section in the appendix.  Please note that it was not clear to me from
reading the document that I was suppose to compute the owf of the integer
and verify that it matched the witness value in order to state that the
challenge was to be returned.

20.  Section 3.2.9, page 27:  In the event that the POP challenge fails, is
there some specific error which should be returned? or can I just return
random errors.  Under what circumstances should the CA/RA retry the
challenge (i.e. what if the error returned isBadMessageCheck) or should all
challenge failures lead to imediate failures to enroll?

21.  Section 3.3.4, page 30, last paragraph:  The last line in this
statement is true only if the CA has not published the certificate until
after the confirmation of the POP has been received.  If the PKIConfirm has
not been received and the certificate has been published then the
certificate must be revoked by the CA.

22.  Section 3.3.11:  You should add a statement to this section which
states that a CA should never modify the requested subject name of a cross
certificate request.  If the CA desired to modify the subject name of a
cross certificate request, the CA should just deny the request.  If this is
done then the cross certificate cannot be used for the purpose required
(i.e. name chaining back to a trusted certificate).   I would like to say
that this refers to the actual bytes of the encoding of the name, but
recognized that doing a binary match of subject and issuer DNs is not the
"correct" way to do name chaining, even if it is what most people do.

23.  Section 3.3.18:  It is unclear to me from the content in the ASN
comment if these are real messages or are really just comments on the types
of things one must do.  If they are just types of things why do they have
real OIDs assigned to them.  On the other hand if they are real things to be
implemented, why do they have the word example at the top and consist of a
set of comments rather than real messages?

24.  Section 4.1, paragraph #2:  There was an explicit statement in the
front of the draft which stated that the root CA did not have to be at the
root of a heirarchy, but now there is a statement which says that all Root
CAs must have self-signed certificate.  These statements appear to be
contraditory, is there a reason why this section says that the CA must have
a "self-signed" certificate and not just a certificate?

25.  Section B.7, page 53:  the comment on subject says it may be NULL-DN
only if a subjectAltName extension is also proposed.  This should be
harmonized with the changes to go into part1 of PKIX and state that it may
be a NULL-DN only if the certificate is for a non PKI-Managment end-entity
and a subjectAltName extension is proposed.

26.  Appendix D:  Please remove the section on Encoding Considerations.  If
you want to state that the data is binary and appropriate care must be
taken, that is fine.  However you should not restrict the CTE to being
base64, let my MIME application take care of this as it might perfer to use
a binary encoding.

When I get back from vacation I will try and do a detailed analysis of the
docuement to look for deeper problems, however this should be a start for
conversations.

jim schaad

Approved-By: [email-masked]
Date:         Tue, 7 Apr 1998 17:51: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: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Comments on CMP-07
To: [email-masked]

The following are my comments on the CMP draft.  Please note that some of
the comments may be changed based on the outcome of issues dealing with the
CRMF draft which I have already asked about.

Not all of these comments are of equal weight, some are merely nits while
others are issues I feel strongly about.  I have not given weighting in this
message so that my personal opinions do not necessaryly come out as
opinions.

1.  Section 1.2.2 paragraph 4:  This paragraph defines the term "root CA"  I
wish to be sure that the fact this is the directly trusted root does not
imply that this is the CA which is going to issue my certificate.  I cannot
remember any text stating this but I wish to verify it.

2.  Section 1.3, page 6:  The graph is nice, however the letters marking the
paths are not refered to in the text.  It is dificult in some cases to be
sure what the letters refer to.  This is especially true of c and d.  Please
make a table of what the letters mean or refer to them from the text itself.

3.  Section 1.3 page 7: Formatting note:  please be consistant about how you
format the notes in the text.  I have found atleast two different ways of
this being done.  I suggest that you put in the word "NOTES:" and then a
numbered indented list.  This allows me to have an easy transistion both
into and out of the notes when reading the text.  The first pass on page 7 I
got lost about what I was reading since I was on a computer screen rather
than on a printed page.

4.  Section 2.1, paragraph #1:  The paragraph makes reference to obtaining
the information about the PKI functions supported, but gives no supporting
material on how this would be done.  Is this out-of-band in the same way
that acquiring the root CA public key is?

5.  Section 2.3, pargraph #1: Reference is made to the fact that a given
CA/RA may choose how to implement the POP enforcement, and the profile at
the end says it must be done, however I cannot find anyplace which says how
a client would find out which of the different methods are or are not
supported by the CA/RA.

6.  Section 2.3.2, pargraph 2:  You use the term "immediate", can you be
more explicit what you mean by this?  Is it legitiment that a e-mail based
protocol would use the direct method considering that the messages may take
several days to complete the round trip?

7.  Section 2.4, paragraph #1: I always dislike this type of hair splitting
but:  If I have a CA which has issued a certificate to an RA by the
definition in section 1.2.1 this might not apply to that CA.  In a more
general note, how does one go about updating the keys in a CA which has only
issued certificates to other CAs?  I would have thought that the same
procedure applied.

8.  Section 2.4, paragraph #2:  This paragraph contains the phrase "if
certificates are made available using an X.500 directory".  What are we
suppose to do if the certificates are NOT made available with an X.500
directory?  Never update the root CA keys?  This needs to be fleshed out.

9.  Section 2.4, paragraph #3:  If the CA changes some of the extensions on
the CA:  1) is this a kosher change to make and 2) how should these changes
be reflected in the new certificates?  According to new policy?

10.  Section 2.4, paragraph #3:  The time period of the cross-certificate
certs may also need to be modified according to how one thinks that the
certificates are in use over the wider internet.  Specifically how long
external entities will take to get the new certificate and establish a trust
point on it.

11.  Section 2.4.1:  It is ok to change the encoding of the name at this
point?  I specficically ask about this after some of the discussions at the
IETF about the new use of UTF8 and the fact that the perfered encoding rules
for distinguished names may end up changing over time.  It seems to me that
this would be a good place to handle this issue by doing a roll over of the
root certificates with new names, but maybe the same keys.

12.  Section 2.4.1, paragraph #8:  I disagree that the old CA private key
can be thrown away with impunitity at this time.  Specifically if you use
such an extension as CRL Distribution points, an internet client with an old
certificate may come looking for a new CRL and get one it cannot understand
as it is signed with the new key only.  Either one needs to determine a way
to return the new set of chainging certificates with this CRL or the CRL
with the old private key needs to be generated until such as time as the old
certificate expires.

13.  Section 2.4.2.2, paragraph #1:  Under what circumstances should the
client make this decision that the certificate must be the wrong one.  I can
see that this could be a problem in the internet where going and finding the
new CA key may be expensive.  One can no longer state that the signature was
bad on the certificate, one just weasel about how the certificate might be
good, if only one knew how to find the correct signing certificate.  Such a
lookup would be required anytime a certificate, including an apparently self
signed certificate, failed to verify.  After all the self-signed certificate
may really be a newWithOld or oldWithNew as the subject and issuer DNs would
match in these cases.

14.  Section 3.1, paragraph 5:  I dislike the term PKIProtection.  This
implies more to me that it really means.  What it really is would be
PKIAuthentication as all you are doing is authenticating the data not
protecting (or masking) the data.  Protection implies encryption to me.

15.

Approved-By: [email-masked]
Date:         Wed, 8 Apr 1998 10:29:59 -0400
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-ocsp-03.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           : X.509 Internet Public Key Infrastructure
                          Online Certificate Status Protocol - OCSP
        Author(s)       : C. Adams, M. Myers, A. Malpani, R. Ankney, S. Galperin
        Filename        : draft-ietf-pkix-ocsp-03.txt
        Pages           : 13
        Date            : 07-Apr-98

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
establishes 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 and appendix B
accumulates ASN.1 syntactic elements.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pkix-ocsp-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-03.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: ftp.ietf.org

        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:      [email-masked].  In the body type:
        "FILE /internet-drafts/draft-ietf-pkix-ocsp-03.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-ocsp-03.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ocsp-03.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--OtherAccess--

--NextPart--

Approved-By:  Paul Koning <[email-masked]>
Date:         Wed, 8 Apr 1998 11:43:33 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Criticality of extensions
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

 David> 3) I've already ranted about conditioning the behavior of
 David> supported extensions on the critical bit.  But to reiterate, I
 David> believe the lower row should have the identical entries in
 David> both columns.  At most, the "RP Policy" should be a binary
 David> choice, either treat a non-critical extension identically to
 David> the same extension marked critical, or ignore it.  (If the
 David> lower right box is IGNORE only, you have Peter Gutmann's
 David> scenario of "this extension does nothing except bulk up the
 David> certificate".  I'd prefer the box to be CP/CPS only, but
 David> recognize that the RP always has the option of using downrev
 David> software which doesn't support the extension.)

 David> Proposal:

 David> Behaviors on Extensions:

>                           |  Critical           |  Non-Critical
>                           |  Extensions         |  Extensions
>   --------------------------------------------------------------------
>   Extension Not           |   REJECT            |   IGNORE
>   Supported               |                     |
>   --------------------------------------------------------------------
>   Extension               |   CP/CPS ?          |   RP configurable:
>   Supported               |                     |   CP/CPS or IGNORE
>   --------------------------------------------------------------------

I find this still more confusing than necessary.

How about simply: if the extension is supported, act on it.  (In other
words, the bottom row has the same entries in both slots.)

The notion of a configuration parameter that controls whether you do
something with an extension is something I don't really understand.
In any case, if you want to do such a thing, simply model it as
configuration management control over whether the thing in question is
supported.  (In other words, a flag that switches you from the first
to the second row.)  That works for any extension (critical or not)
for whatever that's worth.  It also doesn't need to appear in the spec
at all since it's a local matter.

        paul

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 8 Apr 1998 11:36:20 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
>
> >Validity Period Nesting
> >-----------------------
> >
> >The validity period of a certificate must lie within the validity period
> of the
> >certificate which signed it.
>
> I think this should be a SHOULD. If someone is checking the validity dates,
> they will notice the problem if it isn't followed. If they're not, they are
> pretty messed up anyways.

As before, this should not be a MUST, a SHOULD, or even a MAY in any
PKIX or S/MIME document.  If someone is checking validity period
nesting, they may possibly reject valid certification paths.   There is
no security benefit to checking nesting; the only checking required is
to ensure that each certificate is currently valid.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 8 Apr 1998 11:15:24 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Criticality of extensions
To: [email-masked]

> From: Tony Bartoletti <[email-masked]>
>
> Regarding the last exchanges from Graham Bland and Paul Koning, I am
> prompted to build this (possible) table:
>
>   Behaviors on Extensions:
>
>                           |  Critical           |  Non-Critical
>                           |  Extensions         |  Extensions
>   --------------------------------------------------------------------
>   Extension Not           |   REJECT ?          |   IGNORE
>   Recognised/Understood   |                     |
>   --------------------------------------------------------------------
>   Extension               |   CP/CPS ?          |   "RP Policy" ?
>   Recognized/Understood   |                     |
>   --------------------------------------------------------------------

I like this table.

Comments:

1) Is there a reason for the question mark after REJECT?  If we can't
   count on the application failing a critical extension it does not
   support, then there isn't much reason to have the critical bit at all.

2) At least three words could be used in the row headings:
   Recognised, Understood, Supported.  I believe that
   Recognised/Understood does not have the right connotation; the idea
   being that an application must not only "recognize" (know the syntax
   of) an extension, it must also take some specified action before being
   allowed to claim compliance with a standard or profile.  "Supported"
   better captures that flavor, but other suggestions are welcome.

3) I've already ranted about conditioning the behavior of supported
   extensions on the critical bit.  But to reiterate, I believe the
   lower row should have the identical entries in both columns.  At
   most, the "RP Policy" should be a binary choice, either treat a
   non-critical extension identically to the same extension marked
   critical, or ignore it.  (If the lower right box is IGNORE only, you
   have Peter Gutmann's scenario of "this extension does nothing except
   bulk up the certificate".  I'd prefer the box to be CP/CPS only, but
   recognize that the RP always has the option of using downrev
   software which doesn't support the extension.)

Proposal:

   Behaviors on Extensions:

                           |  Critical           |  Non-Critical
                           |  Extensions         |  Extensions
   --------------------------------------------------------------------
   Extension Not           |   REJECT            |   IGNORE
   Supported               |                     |
   --------------------------------------------------------------------
   Extension               |   CP/CPS ?          |   RP configurable:
   Supported               |                     |   CP/CPS or IGNORE
   --------------------------------------------------------------------

Approved-By:  Paul Koning <[email-masked]>
Date:         Wed, 8 Apr 1998 10:44:28 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

 David> ...  Occam's razor dictates that the simplest possible
 David> interpretation of an ambiguous specification be used, and the
 David> simplest and most logical interpretation of "Validity" is that
 David> the validity period of the cert being checked includes the
 David> current date/time.  The current date check is always required;
 David> any nesting checks would be above and beyond what is
 David> necessary.

 David> I'm all in favor of amending X.509 to explicitly specify the
 David> current date/time check.

 David> There is no security-relevant rationale for enforcing validity
 David> nesting - the issuer is responsible for creating certs in
 David> accordance with it's policy, and that might reasonably include
 David> recertification of the issuer's key.  I would be opposed to
 David> PKIX or X.509 requiring or even recommending a nesting check.

When certificates are used to authorize something that lasts for a
while, it seems to me one would also want to determine the end of the
validity period for a certificate.  For example, if a certificate is
used to set up an IPSec (ISAKMP) SA, it would seem logical to limit
the lifetime of that SA to be the validity period of the certificate
used.

That's not directly related to the nesting question, but it does show
a scenario for going beyond "current date check" for some
applications.  Also, if it is done, and nesting is not required, then
what would the "end of the validity period" be?  The end date of the
last cert in the chain?  The earliest of the end dates in the chain?

        paul

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 8 Apr 1998 10:06:22 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

> From: Peter Gutmann <[email-masked]>
>
> >>The validity period of a certificate must lie within the validity period of
> >>the certificate which signed it.
> >I'm not entirely happy with this suggestion. One can issue a new CA
> >certificate for a CA key whose original cert has expired, while keeping the
> >value of the key (and key version number extension) the same.
>
> The main reason for this is that currently the situation with enforcing
> nesting is ambiguous (as pointed out in the style guide), so that implementors
> can choose to enforce it either way.

If X.509 is ambiguous, then X.509 should be fixed.

Section 12.4.3 says:

  The inputs to the certification path processing procedure are:
    a) a set of certificates comprising a certification path
      ...
    f) the current date/time

  The following checks are applied to a certificate:
    a) Check that the signature verifies, that dates are valid, that the
    certificate subject and certificate issuer names chain correctly, and
    that the certificate has not been revoked.

I suppose it is possible to interpret "that dates are valid" to mean
that validity of the certificate being checked must nest within the
validity of the issuer cert.  But that seems to me like a perverse and
highly extrapolated reading of the text.  Occam's razor dictates that
the simplest possible interpretation of an ambiguous specification be
used, and the simplest and most logical interpretation of "Validity" is
that the validity period of the cert being checked includes the current
date/time.  The current date check is always required; any nesting
checks would be above and beyond what is necessary.

I'm all in favor of amending X.509 to explicitly specify the current
date/time check.

There is no security-relevant rationale for enforcing validity
nesting - the issuer is responsible for creating certs in accordance
with it's policy, and that might reasonably include recertification of
the issuer's key.  I would be opposed to PKIX or X.509 requiring
or even recommending a nesting check.

The style guide, of course, may point out the interoperability
considerations and make whatever recommendations are appropriate
for its audience.

> >This way madness lies.
> >
> >It leads to a situation where each vendor has their own subtly different
> >protocol, and each implementation needs to be able to talk all of these
> >protocols.
>
> And this differs from the current situation in which way?
>
> It's nice to see that someone agrees with me that the current situation is
> crazy though :-).

We agree that the current situation is crazy.  We may disagree on
specific fixes.

Implementations which are clearly incorrect (non-conformant with any
possible reading of the standard) should be fixed.  One doesn't rewrite
the standard to accommodate the application behavior of the third 50%
("which comes as a complete surprise to everyone else") unless the
surprising behavior achieves consensus as a superior
thinking-out-of-the-box approach.

Where the standard is ambiguous, it should be clarified in the way
which makes sense, not necessarily the way which enables the maximum
number of current implementations to claim compliance.
Remember, the IETF doesn't vote.  We don't survey the current sorry
state-of-the-art and attempt to codify it.

Approved-By:  Tim Polk <[email-masked]>
Date:         Wed, 8 Apr 1998 09:16:09 -0400
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

The PKIX draft included the brief description of signatures using RSA since
there was no RFC to point to.  We used the OIW oid since there wasn't an
oid for RSA with SHA-1 in the pkcs-1 arc.

Since we started, PKCS #1 Version 1.5 has become RFC 2313.  The next
(final!) draft will simply point to RFC 2313 for details on implementing
RSA signatures.

The next draft will also use RSA with SHA-1 from the pkcs-1 arc.
Unfortunately, the RSA with SHA-1 oid is not in RFC 2313 (or any other
published version of PKCS #1.)  The following text was RSA-approved, so it
should be correct:

**** RSA with SHA-1 text ****

The signature algorithm with SHA-1 and the RSA encryption algorithm
is implemented using the padding and encoding conventions described in
PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1
hash algorithm.  The ASN.1 object identifier used to identify this
signature algorithm is:

     sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-1(1) 5  }

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Wed, 8 Apr 1998 15:06:08 -0700
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] LDAP v2 schema
Comments: To: Nada Kapidzic Cicovic <[email-masked]>
To: [email-masked]

Nada,

Since I answered to Sharon a few minutes ago, this mail may arrive
sooner that the previous. Nevertheless let us talk on this topic while
it is still hot.

>>Sharon Boeyen wrote:
>>>
>>> Hi Denis, I'm not sure I understand. Why can't these new by new and new by
>>> old be held in this attribute as currently defined? They are still
>>> self-signed certificates.
>>
>> They could. We could mix "oranges" and "apples" and then sort them out.
>> However self-signed certificates are not really  what we call
>> "cross-certificates" (alias CA-certificates).
>
> This is true, and that is why cross-certificates (as defined in PKIX part
> 3) are stored in crossCertificatePair attribute, whereas self-signed
> certificates (i.e. certificates which have the same subject and issuer
> field) are stored in cACertificate attribute.

I acknowledged this in my previous E-mail to Sharon.

> Denis, if I understand you right you would like to define three classes of
> certificates as compared to current two classes above:
>
> 1. Self-signed certificates of new-with-new type.
> 2. Self-signed certificates of old-with-new and new-with-old type.
> 3. Cross-certificates.

> Class 1 certificates are to be stored in cACertificate. Class 3
> certificates are to be stored in crossCertificatePair, and you would like
> to have a new attribute to store certificates of type 2.
>
> Did I understand you correctly?

This is not what I had in mind originally, but I like it better !

The problem would be whether this would also fit with the ISO defect
report question and answer.

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:         Wed, 8 Apr 1998 14:50:56 -0700
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] LDAP v2 schema
Comments: To: Sharon Boeyen <[email-masked]>
To: [email-masked]

Sharon,

Thank you for your fast response.

> > The defect report is DR 185. The text was agreed at the Jan '98 meeting
> > and is ready/submitted for ballot. I'm not sure if the ballot has issued
> > or if Hoyt has put the document on his server yet (he's away this week).
> > The text that will be balloted is exactly the text that currently appears
> > in the schema draft.
> >
> > I believe that the resolution of the defect does exactly what you want and
> > ensures the separation of the apples from the oranges. The apples bucket
> > (cACertificate attribute) holds certificates in which the issuer  and
> > subject are the same (regardless of the keys). The oranges bucket
> > (crossCertificatePair attribute) holds certificates for CA subjects in
> > which the issuer and subject are different (with the forward and reverse
> > elements used to differentiate the certs issued to the CA and by the CA of
> > interest).
> >
> > Isn't this the separation you need?

You are fully right. I misread the document (or read it too fast while
in the plane).
The structure is thus correct. However, adding more explanations to say
that you may find there "new by new", "old by new" and "new by old"
self-signed certificates would not hurt. Wouldn't it ?

An additional minor(?) question coming from what I heard at the meeting.
Should the CRL distribution points and the reference to the patent from
Entrust be deleted ?

Finally, an editorial comment: Change section 5 into 4.2 and renumber
the following.

Denis

>> Sharon Boeyen wrote:
>>>
>>> Hi Denis, I'm not sure I understand. Why can't these new by new and new
>> by
>>> old be held in this attribute as currently defined? They are still
>>> self-signed certificates.
>>
>> They could. We could mix "oranges" and "apples" and then sort them out.
>> However self-signed certificates are not really  what we call
>> "cross-certificates" (alias CA-certificates).
>>
>>> The text in the draft is lifted directly from the resolution of a defect
>> on
>>> that topic in 509, so if there is a problem we may need to address it
>> there
>>> as well.
>>
>> Could you give a pointer to this defect report and/or provide it ?
>>
>> Denis
>>
>>>> Sharon (and other co-editors),
>>>>
>>>> I reviewed the first draft and I have a comment on it:
>>>>
>>>> On top of page 4, the document says: "The cACertificate attribute
>> (...)
>>>> may be used to store self-signed certificates.
>>>>
>>>> My question is as follows: why not consider an independent attribute
>> to
>>>> store self-signed certificates ? It might then be easier to get them.
>>>>
>>>> By self-signed cerificates, I mean not only "new by new" self-signed
>>>> certificates, but also "new by old" self-signed certificates and "old
>> by
>>>> new" self-signed certificates.
>>>>
>>>>
>>>> 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:  Nada Kapidzic Cicovic <[email-masked]>
Date:         Wed, 8 Apr 1998 14:54:01 +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: Nada Kapidzic Cicovic <[email-masked]>
Subject:      Re: [IETF-PKIX] LDAP v2 schema
Comments: To: [email-masked]
To: [email-masked]

Sharon and Denis,

I hope you do not mind me jumping into the discussion.

At 10:55 4/8/98 -0700, Denis Pinkas wrote:
>Sharon Boeyen wrote:
>>
>> Hi Denis, I'm not sure I understand. Why can't these new by new and new by
>> old be held in this attribute as currently defined? They are still
>> self-signed certificates.
>
>They could. We could mix "oranges" and "apples" and then sort them out.
>However self-signed certificates are not really  what we call
>"cross-certificates" (alias CA-certificates).

This is true, and that is why cross-certificates (as defined in PKIX part
3) are stored in crossCertificatePair attribute, whereas self-signed
certificates (i.e. certificates which have the same subject and issuer
field) are stored in cACertificate attribute.

Denis, if I understand you right you would like to define three classes of
certificates as compared to current two classes above:

1. Self-signed certificates of new-with-new type.
2. Self-signed certificates of old-with-new and new-with-old type.
3. Cross-certificates.

Class 1 certificates are to be stored in cACertificate. Class 3
certificates are to be stored in crossCertificatePair, and you would like
to have a new attribute to store certificates of type 2.

Did I understand you correctly?

Regards,

Nada

>
>> The text in the draft is lifted directly from the resolution of a defect on
>> that topic in 509, so if there is a problem we may need to address it there
>> as well.
>
>Could you give a pointer to this defect report and/or provide it ?
>
>Denis
>
>> > Sharon (and other co-editors),
>> >
>> > I reviewed the first draft and I have a comment on it:
>> >
>> > On top of page 4, the document says: "The cACertificate attribute (...)
>> > may be used to store self-signed certificates.
>> >
>> > My question is as follows: why not consider an independent attribute to
>> > store self-signed certificates ? It might then be easier to get them.
>> >
>> > By self-signed cerificates, I mean not only "new by new" self-signed
>> > certificates, but also "new by old" self-signed certificates and "old by
>> > new" self-signed certificates.
>> >
>> >
>> > 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
>> >
>
>--
>      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:  Sharon Boeyen <[email-masked]>
Date:         Wed, 8 Apr 1998 08:30:58 -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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] LDAP v2 schema
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

> The defect report is DR 185. The text was agreed at the Jan '98 meeting
> and is ready/submitted for ballot. I'm not sure if the ballot has issued
> or if Hoyt has put the document on his server yet (he's away this week).
> The text that will be balloted is exactly the text that currently appears
> in the schema draft.
>
> I believe that the resolution of the defect does exactly what you want and
> ensures the separation of the apples from the oranges. The apples bucket
> (cACertificate attribute) holds certificates in which the issuer  and
> subject are the same (regardless of the keys). The oranges bucket
> (crossCertificatePair attribute) holds certificates for CA subjects in
> which the issuer and subject are different (with the forward and reverse
> elements used to differentiate the certs issued to the CA and by the CA of
> interest).
>
> Isn't this the separation you need?
>
>
> ----------
> From:         Denis Pinkas[SMTP:[email-masked]]
> Sent:         April 8, 1998 1:55 PM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] LDAP v2 schema
>
> Sharon Boeyen wrote:
> >
> > Hi Denis, I'm not sure I understand. Why can't these new by new and new
> by
> > old be held in this attribute as currently defined? They are still
> > self-signed certificates.
>
> They could. We could mix "oranges" and "apples" and then sort them out.
> However self-signed certificates are not really  what we call
> "cross-certificates" (alias CA-certificates).
>
> > The text in the draft is lifted directly from the resolution of a defect
> on
> > that topic in 509, so if there is a problem we may need to address it
> there
> > as well.
>
> Could you give a pointer to this defect report and/or provide it ?
>
> Denis
>
> > > Sharon (and other co-editors),
> > >
> > > I reviewed the first draft and I have a comment on it:
> > >
> > > On top of page 4, the document says: "The cACertificate attribute
> (...)
> > > may be used to store self-signed certificates.
> > >
> > > My question is as follows: why not consider an independent attribute
> to
> > > store self-signed certificates ? It might then be easier to get them.
> > >
> > > By self-signed cerificates, I mean not only "new by new" self-signed
> > > certificates, but also "new by old" self-signed certificates and "old
> by
> > > new" self-signed certificates.
> > >
> > >
> > > 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
> > >
>
> --
>       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:         Wed, 8 Apr 1998 10:55:42 -0700
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] LDAP v2 schema
To: [email-masked]

Sharon Boeyen wrote:
>
> Hi Denis, I'm not sure I understand. Why can't these new by new and new by
> old be held in this attribute as currently defined? They are still
> self-signed certificates.

They could. We could mix "oranges" and "apples" and then sort them out.
However self-signed certificates are not really  what we call
"cross-certificates" (alias CA-certificates).

> The text in the draft is lifted directly from the resolution of a defect on
> that topic in 509, so if there is a problem we may need to address it there
> as well.

Could you give a pointer to this defect report and/or provide it ?

Denis

> > Sharon (and other co-editors),
> >
> > I reviewed the first draft and I have a comment on it:
> >
> > On top of page 4, the document says: "The cACertificate attribute (...)
> > may be used to store self-signed certificates.
> >
> > My question is as follows: why not consider an independent attribute to
> > store self-signed certificates ? It might then be easier to get them.
> >
> > By self-signed cerificates, I mean not only "new by new" self-signed
> > certificates, but also "new by old" self-signed certificates and "old by
> > new" self-signed certificates.
> >
> >
> > 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
> >

--
      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 Ankney <[email-masked]>
Date:         Wed, 8 Apr 1998 06:12:30 -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: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

----------
> From: Marc Branchaud <[email-masked]>
> I've seen two previous messages about this same point but it has yet to
be
> addressed...
>
> In section 7.2.1 of Part 1, there's the following description of an RSA
> signature algorithm:
>
>    The data to be signed (e.g., the one-way hash function output value)
>    is first ASN.1 encoded as an OCTET STRING and the result is encrypted
>    (e.g., using RSA Encryption) to form the signed quantity.
>
> This is _not_ how PKCS1 works, and I think this should be changed so that
> they're more consistent:
>
>    The data to be signed (i.e., the DigestInfo SEQUENCE as described in
>    PKCS1) is first ASN.1 encoded as an OCTET STRING and the result is
>    encrypted (i.e., using RSA Encryption) to form the signed quantity.
>

But it's not encoded.  The PKCS #1 block is the PKCS padding (zero bytes,
block type, hex 'FF', zero byte delimiter) followed by the BER/DER encoding
of DigestInfo.

> FYI: DigestInfo is a SEQUENCE of the hash value and a hash algorithm ID.
>
> Actually, these last two paragraphs of section 7.2.1 deal with the BIT
STRING
> encoding of the signed value.  I don't see any practical deviation here
from
> what is described in section 10.1 of PKCS1, so I think it would be even
> clearer to just omit these paragraphs and leave the details entirely to
> PKCS1.
>

Agreed.

> I admit I'm not familiar with the OIW's RSA-with-SHA1 algorithm.  If it's
> significantly different than PKCS1 (e.g. it doesn't use DigestInfo) then
I
> suggest PKIX define a more PKCS1-like version of RSA-with-SHA1.
Otherwise,
> it's just too confusing.  Since RSA-with-SHA1 isn't common yet, now's a
good
> time to make sure it's not some mutant algorithm.  If there's a good
reason
> why RSA-with-SHA1 can't be PKCS1-like, I'd like to hear it and I'd like
the
> draft to be clear when it's talking about RSA-with-SHA1's non-PKCS1
behavior.
>

The OIW OID is for the ISO 9796 version of RSA, not PKCS #1.  On the off
chance someone is using it correctly, PKIX should use the RSADSI OID
for SHA1-with-RSAEncryption (per the OIDs in the SET spec).

> I'd dearly like to know why this inconsistency exists before the draft
> becomes an RFC.
>
>                 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/
>
+------------------------------------------------------------------------+

Regards,
Rich

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Tue, 7 Apr 1998 15:03:42 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

>Canonical string encodings
>--------------------------
>
>Definition: Least inclusive encoding means encoding a string using the
minimal
>character set which is capable of encoding the string.  For DN's this means
>using PrintableString if possible, then T61String if possible, then
BMPString.

Two things here. This is *not* canonical string encodings, and shouldn't be
discussed as such. "Least inclusive encoding" is a much better term.
Canonical encoding for things like BMPString mean decomposition of combined
characters and so on.

Second, I do not think people should use T61String. However, since people
can populate the parts of a DN with any damn string type they want, the
spec should say something about trying real hard to accept every string
type, including UniversalString and UTF8String. (Yes, there will possibly
be purposes to use the upper two bytes in a UTC-4 encoding.)

>Validity Period Nesting
>-----------------------
>
>The validity period of a certificate must lie within the validity period
of the
>certificate which signed it.

I think this should be a SHOULD. If someone is checking the validity dates,
they will notice the problem if it isn't followed. If they're not, they are
pretty messed up anyways.

>Alternative Name Usage
>----------------------
>
>Name components which are explicitly provided for in the issuer and subject
>alternative name extensions (in particular email addresses and URL's) must be
>encoded using the alternative name extension and not stuffed into a DN using
>whatever OID is convenient.

A better way to say this (which I hope Tim is doing) is to simply list the
components which are allowed in a name.

>Extension Handling
>------------------

I like your chart very much.

>Compliance
>----------

This is out of scope for PKIX part 1, and is a politcal rathole. If you
really want it, I suggest you do it as a separate draft for an
authenticated attribute.

>Other Extensions
>----------------

Ditto.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 7 Apr 1998 14:08:52 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

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

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

Brian Korver <[email-masked]> scrawled:
>
> I believe that PKIX is now using RSA's PKCS1 RSA-with-SHA1 OID, which
> is identical to the MD* versions except for the digest algorithm.
>

Not according to draft-ietf-pkix-ipki-part1-07.txt.

After posting my original message, I became aware of the PKCS SHA1 OID.
Although I couldn't find any RSA-with-SHA OIDs on RSA's site, SET uses the
following:

   id-sha1-with-rsa-signature OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

If SET is correct, then I suggest that PKIX use this OID instead of the OIW
one, and that the last two paragraphs of part 1's section 7.2.1 be deleted
(since they're redundant to PKCS1).

                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: [email-masked]
Date:         Tue, 7 Apr 1998 14:44:06 -0400
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-ipki-part1-07.txt
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.

        Title           : Internet Public Key Infrastructure
                          X.509 Certificate and CRL Profile
        Author(s)       : D. Solo, R. Housley, W. Ford, T. Polk
        Filename        : draft-ietf-pkix-ipki-part1-07.txt
        Pages           : 116
        Date            : 06-Apr-98

   This is the seventh draft of the Internet Public Key Infrastructure
   X.509 Certificate and CRL Profile.  This draft is a complete
   specification.  This text includes minor modifications over the
   previous draft. This draft introduces UTF8 support, updates the path
   validation process to conform with the current X.509 specification,
   forbids wildcarding in subject alternative names, and clarifies
   conformance requirements. Please send comments on this document to
   the [email-masked] mail list.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pkix-ipki-part1-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-part1-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-ipki-part1-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-ipki-part1-07.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ipki-part1-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:  Tony Bartoletti <[email-masked]>
Date:         Tue, 7 Apr 1998 12:04: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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Criticality of extensions
To: [email-masked]

Regarding the last exchanges from Graham Bland and Paul Koning, I am
prompted to build this (possible) table:

  Behaviors on Extensions:

                          |  Critical           |  Non-Critical
                          |  Extensions         |  Extensions
  --------------------------------------------------------------------
  Extension Not           |   REJECT ?          |   IGNORE
  Recognised/Understood   |                     |
  --------------------------------------------------------------------
  Extension               |   CP/CPS ?          |   "RP Policy" ?
  Recognized/Understood   |                     |
  --------------------------------------------------------------------

As Graham points out, everyone can accept IGNORE (extension) in the
"Non-Critical/Not-Understood" category, or else extensibility equates
to "closed-loop proprietary".

Beyond this, I believe it is the nature of particular extensions that
must determine how "critical bit" is to be interpreted.  I know this is
unfortunately "chicken and egg", especially for the "Critical/Not-Grokked"
category.

Correct me if I am mistaken, but some extensions are employed by the
CA to contain their own liability caveats, key-usage conditions, etc.,
while others may contain elements opaque to the CA that convey similar
conditions as desired by the key-holder (perhaps above and beyond the
simple "non-verified subscriber info" data.)  If this is true, how can
one hope to formulate a consistent meaning for "critical" as regards
"compliant" software?

___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:         Mon, 7 Sep 1998 15:40:33 +0200
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mark Shuttleworth <[email-masked]>
Organization: Thawte Consulting
Subject:      Re: [IETF-PKIX] Questions about PKCS
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msA45153645DB487BCBAE7E080
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

If an application supports an extension, surely it should process
it whether or not that extension is marked critical?  Criticality
just means that processing automatically fails if the extension
is not supported.

For example, for the new chained CA service, we are putting in
a non-critical nameConstraints.  The current browsers will ignore
it, but the next generation should process it.  This gives us a
smooth roll-in to the newer browsers.  When enough support it,
we start making the extension critical.

--
Mark Shuttleworth
Thawte
--------------msA45153645DB487BCBAE7E080
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

--------------msA45153645DB487BCBAE7E080--

Approved-By:  Brian Korver <[email-masked]>
Date:         Tue, 7 Apr 1998 10:39:15 -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: Brian Korver <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

Marc Branchaud writes:
> I've seen two previous messages about this same point but it has yet to be
> addressed...
>
> In section 7.2.1 of Part 1, there's the following description of an RSA
> signature algorithm:
>
>    The data to be signed (e.g., the one-way hash function output value)
>    is first ASN.1 encoded as an OCTET STRING and the result is encrypted
>    (e.g., using RSA Encryption) to form the signed quantity.
>
> This is _not_ how PKCS1 works, and I think this should be changed so that
> they're more consistent:
>
>    The data to be signed (i.e., the DigestInfo SEQUENCE as described in
>    PKCS1) is first ASN.1 encoded as an OCTET STRING and the result is
>    encrypted (i.e., using RSA Encryption) to form the signed quantity.
>
> FYI: DigestInfo is a SEQUENCE of the hash value and a hash algorithm ID.
>
> Actually, these last two paragraphs of section 7.2.1 deal with the BIT STRING
> encoding of the signed value.  I don't see any practical deviation here from
> what is described in section 10.1 of PKCS1, so I think it would be even
> clearer to just omit these paragraphs and leave the details entirely to
> PKCS1.
>
> I admit I'm not familiar with the OIW's RSA-with-SHA1 algorithm.  If it's
> significantly different than PKCS1 (e.g. it doesn't use DigestInfo) then I
> suggest PKIX define a more PKCS1-like version of RSA-with-SHA1.  Otherwise,
> it's just too confusing.  Since RSA-with-SHA1 isn't common yet, now's a good
> time to make sure it's not some mutant algorithm.  If there's a good reason
> why RSA-with-SHA1 can't be PKCS1-like, I'd like to hear it and I'd like the
> draft to be clear when it's talking about RSA-with-SHA1's non-PKCS1 behavior.

I believe that PKIX is now using RSA's PKCS1 RSA-with-SHA1 OID, which
is identical to the MD* versions except for the digest algorithm.

>
> I'd dearly like to know why this inconsistency exists before the draft
> becomes an RFC.
>
>                 Marc

brian
[email-masked]

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 7 Apr 1998 10:35:35 -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: Marc Branchaud <[email-masked]>
Subject:      [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

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

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

I've seen two previous messages about this same point but it has yet to be
addressed...

In section 7.2.1 of Part 1, there's the following description of an RSA
signature algorithm:

   The data to be signed (e.g., the one-way hash function output value)
   is first ASN.1 encoded as an OCTET STRING and the result is encrypted
   (e.g., using RSA Encryption) to form the signed quantity.

This is _not_ how PKCS1 works, and I think this should be changed so that
they're more consistent:

   The data to be signed (i.e., the DigestInfo SEQUENCE as described in
   PKCS1) is first ASN.1 encoded as an OCTET STRING and the result is
   encrypted (i.e., using RSA Encryption) to form the signed quantity.

FYI: DigestInfo is a SEQUENCE of the hash value and a hash algorithm ID.

Actually, these last two paragraphs of section 7.2.1 deal with the BIT STRING
encoding of the signed value.  I don't see any practical deviation here from
what is described in section 10.1 of PKCS1, so I think it would be even
clearer to just omit these paragraphs and leave the details entirely to
PKCS1.

I admit I'm not familiar with the OIW's RSA-with-SHA1 algorithm.  If it's
significantly different than PKCS1 (e.g. it doesn't use DigestInfo) then I
suggest PKIX define a more PKCS1-like version of RSA-with-SHA1.  Otherwise,
it's just too confusing.  Since RSA-with-SHA1 isn't common yet, now's a good
time to make sure it's not some mutant algorithm.  If there's a good reason
why RSA-with-SHA1 can't be PKCS1-like, I'd like to hear it and I'd like the
draft to be clear when it's talking about RSA-with-SHA1's non-PKCS1 behavior.

I'd dearly like to know why this inconsistency exists before the draft
becomes an RFC.

                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: [email-masked]
Date:         Tue, 7 Apr 1998 15:12:41 +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: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      [IETF-PKIX] Definition of short OIDs in Distinguished Names
To: [email-masked]

Hello all,

I am looking for a reference of the commonly used short forms for the
attributes used in Distinguished Names. So for I have those:

C  (COUNTRY)
O  (ORGANIZATION)
OU (ORGANIZATIONAL UNIT)
CN (COMMON NAME)
S  (SURNAME)
L  (LOCALITY)
ST (STREET ADDRESS)
T  (TITLE)
SN (SERIAL NUMBER)
BC (BUSINESS CATEGORY)
D  (DESCRIPTION)
SP (STATE OR PROVINCE)
EMAIL (EMAIL ADDRESS)
DC (DOMAIN COMPONENT)

I know that any OID can appear in a Distinguished Name. I was just
wondering what to use so that most software can show them correctly.
Especially I am missing: ZIP code or equivalent, a date of birth (or any
date for that matter) and possibly a place of birth.

Andreas
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  Paul Koning <[email-masked]>
Date:         Tue, 7 Apr 1998 11:08:17 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Criticality of extensions
To: [email-masked]

>>>>> "Graham" == Graham Bland <[email-masked]> writes:

>...
 Graham> 2. If you understand the extension it then it is up to you
 Graham> what to do, if an implementation takes the trouble to
 Graham> understand the extension then it would seem sensible that it
 Graham> would act upon it.  It can ignore the contents completely if
 Graham> it wants as in 1.

I suppose "understand" is a somewhat vague concept, but I don't think
the definition you used is very useful.

For any particular component of a message or data structure, I can see
only two things you could do with it:

1. Know what it means and act on that.
2. Not know what it means (and ignore it or reject the cert according
to the "critical" flag.

The in-between notion of "I know what it means but I'm not going to
act on it" doesn't compute.

 Graham> There are three ways forward as I see it

 Graham> a) Set up a subset but don't call the certificates X509 v3,
 Graham> this allows extensions to be non critical but mandated.

I wouldn't call that a subset, and I think that having such a rule
shouldn't prevent you from calling the certificates in question
X.509.

 Graham> b) Make all mandated extensions critical.

I'd say that's a bad idea.  "Critical" means that it is necesary to
process the extension in question or bad things would happen (e.g.,
security holes).  If support of a certain extension is mandated by a
profile, then that's all there is to say; if the nature of the
extension is that it isn't critical then mandating it doesn't make it
critical.

 Graham> c) Add a single critical extension of PKIX compliance the
 Graham> presence of which would mandate implementations to act as in
 Graham> a).

I don't like that either for the same reason.

        paul

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Tue, 7 Apr 1998 08:59:32 -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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] LDAP v2 schema
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

Hi Denis, I'm not sure I understand. Why can't these new by new and new by
old be held in this attribute as currently defined? They are still
self-signed certificates.

The text in the draft is lifted directly from the resolution of a defect on
that topic in 509, so if there is a problem we may need to address it there
as well.

> ----------
> From:         Denis Pinkas[SMTP:[email-masked]]
> Sent:         April 7, 1998 5:48 PM
> To:   [email-masked]
> Subject:      [IETF-PKIX] LDAP v2 schema
>
> Sharon (and other co-editors),
>
> I reviewed the first draft and I have a comment on it:
>
> On top of page 4, the document says: "The cACertificate attribute (...)
> may be used to store self-signed certificates.
>
> My question is as follows: why not consider an independent attribute to
> store self-signed certificates ? It might then be easier to get them.
>
> By self-signed cerificates, I mean not only "new by new" self-signed
> certificates, but also "new by old" self-signed certificates and "old by
> new" self-signed certificates.
>
>
> 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:         Tue, 7 Apr 1998 14:48:20 -0700
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] LDAP v2 schema
To: [email-masked]

Sharon (and other co-editors),

I reviewed the first draft and I have a comment on it:

On top of page 4, the document says: "The cACertificate attribute (...)
may be used to store self-signed certificates.

My question is as follows: why not consider an independent attribute to
store self-signed certificates ? It might then be easier to get them.

By self-signed cerificates, I mean not only "new by new" self-signed
certificates, but also "new by old" self-signed certificates and "old by
new" self-signed certificates.

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:         Tue, 7 Apr 1998 05:24:37 -0700
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] Duct-taping X.509
Comments: To: [email-masked]
To: [email-masked]

>>The validity period of a certificate must lie within the validity period of
>>the certificate which signed it.
>I'm not entirely happy with this suggestion. One can issue a new CA
>certificate for a CA key whose original cert has expired, while keeping the
>value of the key (and key version number extension) the same.

The main reason for this is that currently the situation with enforcing
nesting is ambiguous (as pointed out in the style guide), so that implementors
can choose to enforce it either way.  The reason I recommended nesting is that
given that it's a toss-up between enforcing and not enforcing it, and
Microsoft (AFAIK) enforces it, you may as well do it too.  This has the added
benefit that your certs will appear valid to MS software.

The reason for being fascist about it ("do it this way or else") was that
without clear guidelines we'll get the same situation that we already have
with cert extensions, where 50% of people do it one way, 50% do it the other
way, and the remaining 50% do it a third way which comes as a complete
surprise to everyone else.

>>This leads to a second type of extension, implementationWhichCreatedThis,
>>which may be even more useful than the one described above.  As it is, it's
>>already possible to identify certain implementations just by the bugs in the
>>certificates they produce, but being able to make a positive ID would be
>>really useful because by knowing how they (mis)interpret certain fields, your
>>implementation could follow the same interpretation.

>This way madness lies.
>
>It leads to a situation where each vendor has their own subtly different
>protocol, and each implementation needs to be able to talk all of these
>protocols.

And this differs from the current situation in which way?  (See
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt for more details -
there's a more recent version which has another round of CA and implementation
bugs at the end which I haven't uploaded yet, so it's even worse than the
already depressing picture painted in the guide.  It only covers cert formats,
but the fact that there are implementations which will happily process the
incorrect, illogical, and inconsistent nonsense which is appearing in some
certs indicates that we're already in a situation where implementations are
having to bend over backwards to handle the broken certificates others are
issuing.  All that this proposal does is formalise the identification of cert
types).

It's nice to see that someone agrees with me that the current situation is
crazy though :-).

Just out of interest, has anyone here seriously deployed X.509v3 software
which actually uses and enforces basicConstraints, keyUsage/extendedKeyUsage,
and the various policy constraints (as required by PKIX, including attention
to critical flags) which interoperates correctly with mass-market software
like MSIE, Exchange, Netscape Navigator, etc etc?

Peter.

Approved-By:  Graham Bland <[email-masked]>
Date:         Tue, 7 Apr 1998 09:55: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: Graham Bland <[email-masked]>
Subject:      [IETF-PKIX] Criticality of extensions
To: [email-masked]

An implementation must ignore any non critical extensions which it does not
understand.  If this was not the case then no new extensions could ever be
added to a certificate until all existing implementations had been modified
to accept them.  Practically this freezes the addition of new extensions at
this point in time.

By my understanding X.509 v3 provides an extensible standard and to do this
allows a certificate issuer to add extensions in three ways:

One is a critical extension, if you don't understand AND act upon this
extension then the certificate is invalid.  Acting upon means taking note
of, an implementation can decide that the appropriate action is to ignore it
as in Certificate Policies.

The second two are for non critical extensions
1. If you don't understand the extension you can still use the certificate
and ignore the extension (as you don't know what it is)

2. If you understand the extension it then it is up to you what to do, if an
implementation takes the trouble to understand the extension then it would
seem sensible that it would act upon it.  It can ignore the contents
completely if it wants as in 1.

There are three ways forward as I see it

a) Set up a subset but don't call the certificates X509 v3, this allows
extensions to be non critical but mandated.

b) Make all mandated extensions critical.

c) Add a single critical extension of PKIX compliance the presence of which
would mandate implementations to act as in a).

Graham Bland

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 6 Apr 1998 14:58:15 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
To: [email-masked]

> From: Peter Gutmann <[email-masked]>
>
> >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.
>
>    [... and ...]
>
> 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.

I agree that X.509 and PKIX do not do a very good job of describing the
meaning of the critical flag, and that moreover, the definitions of some
specific extensions overload the meaning of the critical flag in ways
that were not origininally intended.

However, I don't think it is correct to assert that an implementation is
free to ignore any non-critical extension.

X.509 says:
  "When an implementation processing a certificate does not recognize
   an extension, if the criticality flag is FALSE, it may ignore that
   extension."

PKIX part 1 says:
  "Conforming CAs are required to support the basic Constraints extension,
   the key usage extension, ..."

and
  "At a minimum, applications conforming to this profile shall recognize
   extensions ...

   In addition, this profile recommends support for ..."

My reading of this text is that the intention of the authors is that
"recognize" and "support" have the identical meaning, regardless of what
a dictionary would say.  It would be helpful if someone did a global
search and replace on those documents to change every occurrence of
"recognize" to "support", but the intended meaning seems semi-unambiguous :-)
even without that change.

Therefore, an implementation might claim not to support, say, basic
constraints, in which case it's off the hook.  But it may *not* both
1) claim to support an extension and 2) ignore it if marked non-critical.

Similarly, an application which claims PKIX conformance must support a
fixed set of extensions and must not ignore any of those extensions,
regardless of the state of the criticality flag.

Approved-By: [email-masked]
Date:         Mon, 6 Apr 1998 11:50:52 +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: Michael Roe <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
Comments: To: [email-masked]
To: [email-masked]

In reply to Peter Gutmann's message:
> Validity Period Nesting
> -----------------------
>
> The validity period of a certificate must lie within the validity period of
> the
> certificate which signed it.
>
> Rationale: This ensures that the certificate will be regarded as valid by
> software which enforces validity period nesting.

I'm not entirely happy with this suggestion.
One can issue a new CA certificate for a CA key whose original cert has
expired, while keeping the value of the key (and key version number extension)
the same. This should allow a user certificate signed using the CA key to have
a lifetime overlapping that that of the CA cert:

          TIME ---->

       CA_Cert 1 valid     CA Cert 2 valid
    <-------------------><----------------->
            User cert valid
           <--------------------->

Where CA_Cert 1 and CA Cert 2 both certify key K_CA, and K_CA^{-1} signs
user cert.

Doing this can make certificate re-issuing easier by avoiding a flag day where
everyone's user certificate runs out at the same time. On the other hand,
it makes life more complex for UAs, because they have to somehow get hold
of CA Cert 2 when it's issued and attach it to their existing user cert.
So not everyone will want to do this., but it ought to be *permitted*.

However, I'll admit you can do gradual certificate re-issue with all
validity periods nested:

  TIME --->
   CA cert 1
  <------------------>
        |   Ca cert 2
        | <------------------>
        |         |
        V         V
       Ucert1  User cert 2
     <-------><------------->

> Other Extensions
> ----------------
>
> A while back someone made the comment that "It's good that <large vendor>
> always puts the name of the MUA in their mail headers, because it allows you
> to bypass <vendor>-specific bugs".  This leads to a second type of extension,
> implementationWhichCreatedThis, which may be even more useful than the one
> described above.  As it is, it's already possible to identify certain
> implementations just by the bugs in the certificates they produce, but being
> able to make a positive ID would be really useful because by knowing how they
> (mis)interpret certain fields, your implementation could follow the same
> interpretation.

This way madness lies.

It leads to a situation where each vendor has their own subtly different
protocol, and each implementation needs to be able to talk all of these
protocols. Standards exist to save us from this fate!

Mike

Approved-By:  Paul Koning <[email-masked]>
Date:         Mon, 6 Apr 1998 11:47:27 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical flag processing (was: Re: RE: Signed Label )
To: [email-masked]

>>>>> "Bob" == Bob Jueneman <[email-masked]> writes:

 Bob> Russ, I just recently joined this list, and I am not at all up
 Bob> to speed with the context,.............
 Bob> Please pardon my cross-posting to both lists, but I think the
 Bob> issue is important to both groups, and I don't know how many
 Bob> people are members of both.

Another problem with the PKIX mailer is that it is somewhere between
very difficult and impossible (depending on your mail reader) to tell
that a message has been cross-posted and if so, to where.

        paul

Approved-By:  [email-masked]
Date:         Sat, 4 Apr 1998 03:15:39 -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] Duct-taping X.509
To: [email-masked]

Yesterday, someone sent me a random collection of 11 certs which Netscape had
accumulated for him while web-browsing.  After picking them apart, I've come to
the conclusion that we're all doomed.  There will be a general breakdown in
society culminating in an armageddon-type war, after which a new civilisation
will evolve from ants.

Three of the certs he sent were the dime-a-dozen Verisign SSL client certs.
Out of the remaining 8, 6 didn't have valid encodings, one had an extension
which identified it as a CA cert and another which identified it as a non-CA
cert, and the remaining one, dating from three weeks ago, used the MD2 hash
algorithm which has been deprecated for quite some time.  All this was without
even checking the validity, constraints, and whatever else you need to check to
validate a cert.

As a result, and based on various comments I've received in response to recent
postings, I've come up with the following proposal to try and sort out this
mess.  This is (yet another) X.509 profile (and PKIX and S/MIME) profile which
should fix all the problems I've been pointing out recently.  It's a very rough
sketch, if anyone has any further suggestions please let me know.

Peter.

-- Snip --

The following doesn't modify (in an incompatible manner) any existing standard
or profile.  All it does is provide a consistent interpretation of other
standards and profiles, and provide a means of communicating that this
interpretation has been followed.

Canonical string encodings
--------------------------

Definition: Least inclusive encoding means encoding a string using the minimal
character set which is capable of encoding the string.  For DN's this means
using PrintableString if possible, then T61String if possible, then BMPString.

Strings are encoded using the least inclusive encoding

If IA5String is used, it is limited to printable (non-control) characters only
(making it equivalent to VisibleString).

If T61String is used, it is limited to ISO 8859-1 only.  No shifting or escape
codes are allowed.  Anything which doesn't fit into 8859-1 is encoded as a
BMPString.

Rationale: These rules provide an unambiguous encoding for DN's (and character
strings in general), and ensure that the nameConstraints extension works as
intended.

Validity Period Nesting
-----------------------

The validity period of a certificate must lie within the validity period of the
certificate which signed it.

Rationale: This ensures that the certificate will be regarded as valid by
software which enforces validity period nesting.

Alternative Name Usage
----------------------

Name components which are explicitly provided for in the issuer and subject
alternative name extensions (in particular email addresses and URL's) must be
encoded using the alternative name extension and not stuffed into a DN using
whatever OID is convenient.

Rationale: These things were never intended to be put into DN's anyway, but
were a kludge which appeared because X.509v1 didn't provide any other way of
specifying them.

Extension Handling
------------------

Definition: Processing an extension means acting on the information contained
in all the fields of the extension (for example processing a keyUsage extension
means enforcing the key usage constraints specified in the extension).

If an extension is marked critical:

  If the implementation cannot process it, the certificate should be rejected.

  If the implementation can process it, the implementation must process the
  extension.

If an extension is not marked critical:

  If it is included in the compliance level for this implementation, the
  implementation must process the extension.

  If it is not included in the compliance level for this implementation, it may
  handle the extension as it sees fit (pick a standard, decide on an
  interpretation of it, and go with that).

Rationale: This clarifies the handling of critical extensions, resolves the
ambiguities over how extensions should be handled, and guarantees that certain
types of important extensions will be handled properly.

Compliance
----------

Compliance with these recommendations is handled through use of a "secret
handshake extension" (for want of a better term), by which compliant CA's,
implementations, and certificates identify themselves.  When submitting a
certification request, an implementation can specify which compliance level it
handles and the CA can accept or reject it based on this.  When selecting a CA,
a user can check the CA's certificate(s) to see whether they comply, and to
what level.  When verifying a certificate, a CA or end user can again check the
certificate to find the level of compliance.  For example any level of
compliance will guarantee that DN's are encoded in an unambiguous manner,
allowing precise DN comparisons for things like nameConstraints enforcement.

secretHandshake EXTENSION ::= {
    SYNTAX SecretHandshakeSyntax
    IDENTIFIED BY id-ce-secretHandshake
    }

SecretHandshakeSyntax ::= SEQUENCE {
    complianceLevel     INTEGER DEFAULT (0),
    ...
    }

The compliance levels are as follows:

Level   Supports
-----   --------

0       Canonical string encodings
        Alternative name usage
        Validity period nesting
        Correct handling of critical extension
        Correct handling of extensions basicConstraints, keyUsage,
          issuerAltName, and subjectAltName

1       All of level 0 plus:
        Correct handling of extensions certificatePolicies, policyConstraints,
          and extendedKeyUsage

2       All of level 1 plus:
        Correct handling of extensions policyMappings, and nameConstraints

n       Other possibilties like reliance limits

These are just suggestions, an alternative is to have a SET OF properly
supported extensions, however this has the disadvantage that implementors can
pick and mix whatever they happen to feel like supporting.

Another alternative is to have groups of extensions, eg:

1       All of level 0 plus:
        Policy extensions (certificatePolicies, policyConstraints,
            policyMappings)

2       All of level 0 plus:
        Constraints (extendedKeyUsage, others?)

This one will require a bit string instead of an integer value, but it's
getting back to the pick and mix problem again.

Other Extensions
----------------

A while back someone made the comment that "It's good that <large vendor>
always puts the name of the MUA in their mail headers, because it allows you
to bypass <vendor>-specific bugs".  This leads to a second type of extension,
implementationWhichCreatedThis, which may be even more useful than the one
described above.  As it is, it's already possible to identify certain
implementations just by the bugs in the certificates they produce, but being
able to make a positive ID would be really useful because by knowing how they
(mis)interpret certain fields, your implementation could follow the same
interpretation.

Approved-By:  [email-masked]
Date:         Fri, 3 Apr 1998 20:22:26 -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] Tagging problems
Comments: To: [email-masked]
To: [email-masked]

>You wrote "the TBSCertificate has an 'EXPLICIT' keyword in the definition
>which means that everything in it has explicit tagging)".  Doesn't the
>EXPLICIT refer only to the tagging of that item?  I thought the only
>specification of implicit/explicit tagging which extended beyond the immediate
>definition was in the DEFINITIONS statement.  Can you quote chapter & verse
>for your broader interpretation?

Actually seeing an EXPLICIT at that point in the definition came as a
considerable surprise to me, because I couldn't remember it being allowed in a
type definition unless it's immediately preceded by a tag.  Assuming there was
some obscure part of the ASN.1 spec which I'd missed, I used the interpretation
which was necessary to make the ASN.1 work, which was that everything beyond
this point was EXPLICIT TAGS (if you assume that only that item has explicit
tags then everything else will use the module-wide setting of implicit tags,
making it incompatible with X.509v3).

In any case, the current usage is invalid ASN.1.

Is there any reason why the module, and the one in Appendix A, use implicit
tags?  Although I haven't gone through it with a fine-toothed comb, it looks
like if the IMPLICIT TAGS was removed the whole thing would suddenly work.

Peter.

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 3 Apr 1998 15:38:28 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Babelfish and names
Comments: To: [email-masked]
To: [email-masked]

43?  42?

Ha, ha, ha, ha, ha!

I never heard those jokes before. They're hysterical!  Got any more?

A. 47.

Q. What's a prime number between 6x8 and 7x7?

>>> Tony Bartoletti <[email-masked]> 04/03 2:11 PM >>>
At 03:44 PM 4/3/98 -0500, you wrote:
>> 47
>>
>> Bob
>
>Isn't that 43 ??
>
>Regards,
>Rich

That's right.  6 times 7.

___tony___

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 3 Apr 1998 15:34:05 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Suspended Certificate in CRL
Comments: To: [email-masked]
To: [email-masked]

It depends a lot on how CRLs are distributed.

CAs may issue CRLs on a periodic basis, whether one a day, once week,
or once a month, but the vast majority will be for relatively benign reasons,
such as marriage/change of name, or quit the company. Unless someone
is a purchasing agent, those aren't earth-shaking events.

However, if someone suspects a compromised key, there is nothing that
prevents the CA from issuing a emergency CRL ahead of time.  For those relying
parties who are only selling disk rags, it may not be worth the bother of
getting a new CRL list all that often, so they can afford the risk. But if someone
trys to buy the Hope diamond, the relying party had better go get the very
latest CRL list, just in case. In that eventuality, the suspended certificate
would show up in the list, and would be of inestimable value.

Bob

>Regarding suspension of certificates I would like to know the opinion
>and ideas of others. IMO, suspended certificates and CRLs don't go
>together very well.
>
>The problem is the following: Let's say the CA issues CRLs every day.
>Now somebody requests suspension of his certificate because he cannot
>find his smartcard right now. If you don't allow multiple CRLs at the
>same validity time frame, the suspended certificate will show up on the
>next CRL, which will be issued the next day. So it will take up to 24
>hours until the certificate is suspended. During this time he has either
>found his smartcard and wants his certificate to be reactivated or he
>didn't find it and wants his certificate to be revoked.
>
>If you allow multiple CRLs for the same validity time frame, i.e. the
>CA issues a CRL whenever somebody requests suspension or revocation
>you will never know if it is the latest CRL you are using for
>verification.
>
>So, only in case of online-verification where you ask the CA directly
>about the status of a certain certificate, suspension of certificates
>is useful.
>
>Objections ?
>
>Best regards, Petra Glöckner

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:  Tony Bartoletti <[email-masked]>
Date:         Fri, 3 Apr 1998 13:11: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] Babelfish and names
To: [email-masked]

At 03:44 PM 4/3/98 -0500, you wrote:
>> 47
>>
>> Bob
>
>Isn't that 43 ??
>
>Regards,
>Rich

That's right.  6 times 7.

___tony___

Approved-By:  Darryl Stal <[email-masked]>
Date:         Fri, 3 Apr 1998 15:53: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: Darryl Stal <[email-masked]>
Subject:      Re: [IETF-PKIX] Babelfish and names
To: [email-masked]

Sorry guys, you're both wrong....it's 42. :)

> > 47
> >
> > Bob
>
> Isn't that 43 ??
>
> Regards,
> Rich
>

Approved-By: [email-masked]
Date:         Fri, 3 Apr 1998 09:20:37 +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: Petra Glöckner <[email-masked]>
Subject:      Re: [IETF-PKIX] Suspended Certificate in CRL
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msA77FE3A8E98F2E45C208007B
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Regarding suspension of certificates I would like to know the opinion
and ideas of others. IMO, suspended certificates and CRLs don't go
together very well.

The problem is the following: Let's say the CA issues CRLs every day.
Now somebody requests suspension of his certificate because he cannot
find his smartcard right now. If you don't allow multiple CRLs at the
same validity time frame, the suspended certificate will show up on the
next CRL, which will be issued the next day. So it will take up to 24
hours until the certificate is suspended. During this time he has either
found his smartcard and wants his certificate to be reactivated or he
didn't find it and wants his certificate to be revoked.

If you allow multiple CRLs for the same validity time frame, i.e. the
CA issues a CRL whenever somebody requests suspension or revocation
you will never know if it is the latest CRL you are using for
verification.

So, only in case of online-verification where you ask the CA directly
about the status of a certain certificate, suspension of certificates
is useful.

Objections ?

Best regards, Petra Glöckner
--------------msA77FE3A8E98F2E45C208007B
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

--------------msA77FE3A8E98F2E45C208007B--

Approved-By:  Rich Ankney <[email-masked]>
Date:         Fri, 3 Apr 1998 15:44: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: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] Babelfish and names
To: [email-masked]

> 47
>
> Bob

Isn't that 43 ??

Regards,
Rich

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 3 Apr 1998 12:39:58 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Babelfish and names
Comments: To: [email-masked]
To: [email-masked]

Trevor,

You might actually be onto something with your suggestion #2.
Suggestion #1 would be fine for all of us non-PC, white anglo-saxon males,
but might get us stoned the next time we visit Quebec.

I could buy making the DN an organization OID, either independently and
nationally registered under the joint-iso-ccitt arc, or subordinate to the OID
of the CA, for those organizations which are not nationally registered.

Then ALL of the display names, in whatever languages are desired,
could be presented in the subjectAltName, thereby neatly avoiding the
emotional and ethnocentric issue of of which name is "preferred" or
in the dominant language.

Presumably, the CA would still be responsible for the due diligence in
verifying right to use of all of the names, but unlike the case of DNs,
we could more easily include a Nonverified Subscriber Information flag
to indicate which names might not be "official."

Certainly if Peter Gutman's assessment is correct, even a Babelfish
would have extreme difficulty in comparing DNs in different character sets.

(Do you suppose all of the people on this list have read the Hitchhikers Guide
to the Galaxy, and know what we are talking about?  Yeah, probably.)

47

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

>>> Trevor Freeman <[email-masked]> 04/02 11:47 PM >>>
The prospect of Babelfish technology being available to chain building
software so that it could understand the five ways Vogon's have of writing
the same name is a nonsense. And if it where available it probably would be
imminently patented. I therefore have two suggestion to make, one mildly
radical, the other heresy.
Suggestion one.
If we stop thinking of the subject name as one which a user may understand,
we could easily embody the concept of an internal system name using a single
namespace that the certificate chain building software universally
understands, and an external display name with n namespaces in a certificate
which the user understands. The internal name would be the one used in chain
building by the software, the display name would only be used when
displaying a representation of the certificate to the user.
How do we do that?
Simple.
Mandate that the subject and issuer name be present and in English. That the
subject and issuer alternate names be present and are the default display
name of choice by certificate interpreting UI software and can be in any
language. Now anyone who understands English, just happens to understand the
system namespace but that is coincidence. Vogons would fine the subject DN a
mystery, but would understand the display name(altSubjectName). As long as
the certificate UI software always understands English, you will always be
able to display something about the certificate. If I happen to have the
Vogon version  installed, then I would get the Vogon name. We can define how
we represent the internal and display names in the directory in the LDAP
schema.
Suggestion two
If I have made the split of internal names and display names - why have
English(or any language) in the internal names at all? Software would work
just as well using DN comprising on decimal integers or OID's. e.g. c=US,
o=12345, ou = 12345. Now the names I use for chain building would therefore
consist of a well understood set of characters which are intrinsically case
insensitive and language independent. Now my name searching can always
reliable be done on binary blob comparisons.

Approved-By:  "Charles W. Gardiner" <[email-masked]>
Date:         Fri, 3 Apr 1998 09:47: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: "Charles W. Gardiner" <[email-masked]>
Subject:      Re: [IETF-PKIX] Tagging problems
Comments: To: [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

    You wrote "the TBSCertificate has an 'EXPLICIT' keyword in the definition
which means that everything in it has explicit tagging)".  Doesn't the EXPLICIT
refer only to the tagging of that item?  I thought the only specification of
implicit/explicit tagging which extended beyond the immediate definition was in
the DEFINITIONS statement.  Can you quote chapter & verse for your broader
interpretation?

Charlie Gardiner

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Thu, 2 Apr 1998 22:47: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: Trevor Freeman <[email-masked]>
Subject:      [IETF-PKIX] Babelfish and names
To: [email-masked]

The prospect of Babelfish technology being available to chain building
software so that it could understand the five ways Vogon's have of writing
the same name is a nonsense. And if it where available it probably would be
imminently patented. I therefore have two suggestion to make, one mildly
radical, the other heresy.
Suggestion one.
If we stop thinking of the subject name as one which a user may understand,
we could easily embody the concept of an internal system name using a single
namespace that the certificate chain building software universally
understands, and an external display name with n namespaces in a certificate
which the user understands. The internal name would be the one used in chain
building by the software, the display name would only be used when
displaying a representation of the certificate to the user.
How do we do that?
Simple.
Mandate that the subject and issuer name be present and in English. That the
subject and issuer alternate names be present and are the default display
name of choice by certificate interpreting UI software and can be in any
language. Now anyone who understands English, just happens to understand the
system namespace but that is coincidence. Vogons would fine the subject DN a
mystery, but would understand the display name(altSubjectName). As long as
the certificate UI software always understands English, you will always be
able to display something about the certificate. If I happen to have the
Vogon version  installed, then I would get the Vogon name. We can define how
we represent the internal and display names in the directory in the LDAP
schema.
Suggestion two
If I have made the split of internal names and display names - why have
English(or any language) in the internal names at all? Software would work
just as well using DN comprising on decimal integers or OID's. e.g. c=US,
o=12345, ou = 12345. Now the names I use for chain building would therefore
consist of a well understood set of characters which are intrinsically case
insensitive and language independent. Now my name searching can always
reliable be done on binary blob comparisons.

Approved-By:  [email-masked]
Date:         Thu, 2 Apr 1998 15:33:30 -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] Tagging problems
To: [email-masked]

One of the responses I got to my posting yesterday about extensions was a
question about tagging.  The following text is what's currently in the guide
about this subject, I hope this is accurate (the more you look at the tagging
which is used, the more confusing it gets.  Is the Appendix A definition
actually digestible by an ASN.1 parser, and does it produce valid certificate
encodings?).  Anyway, if there are errors in this please let me know, it's
rather difficult to follow the tagging:

-- Snip --

The default tagging for certificates varies depending on which standard you're
using.  The original X.509v3 definition uses the ASN.1 default of explicit
tags.  The PKIX definition is quite confusing because the ASN.1 definitions in
the appendices use TAGS IMPLICIT but mix in X.509v3 definitions which use
explicit tags.  Appendix A has such a mixture of implied implicit and implied
explicit tags that it's not really possible to tell what tagging you're
supposed to use.  Appendix B (which first appeared in draft 7, March 1998) is
better in that it starts with TAGS IMPLICIT, but switches to TAGS EXPLICIT
after the first few definitions (this isn't very obvious, the TBSCertificate
has an 'EXPLICIT' keyword in the definition which means that everything in it
has explicit tagging).  The definitions given in the body of the document use
explicit tags, and the definitions of TBSCertificate and and TBSCertList have
both EXPLICIT and IMPLICIT tags present.  To resolve this, you can either rely
entirely on Appendix B with the 'IMPLICIT TAGS' at the start either removed or
changed to 'EXPLICIT TAGS' (this doesn't change the encoding because nothing in
the section covered by implicit tagging is actually tagged) or use the X.509v3
definitions.  The SET definitions consistently use implicit tags.

-- Snip --

Would it be possible to switch to a unified use of explicit tags as per
X.509v3?  This would make things a lot easier to handle.

Peter.

Approved-By: [email-masked]
Date:         Thu, 2 Apr 1998 20:29:15 +0200
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] Suspended Certificate in CRL
To: [email-masked]

--openmail-part-024b43e1-00000001
Content-Type: multipart/alternative; boundary=openmail-part-024b43e1-00000002

--openmail-part-024b43e1-00000002
Content-Type: text/plain; charset=ISO-8859-1; name="Suspended"
Content-Disposition: inline; filename="Suspended"
Content-Transfer-Encoding: quoted-printable

>From IPKI documents (draft-ietf-pkix-ipki3cmp-05.txt), I can't figure
out how suspension and subsequent reactivation of a certificate shall be=

managed in a CRL.

I understand that certificate extensions
(draft-ietf-pkix-ipki-part1-06.txt par. 5.3.2) can dictate how a
suspended certificate shall be handled  by a relying party.  =20

Furthermore, draft-ietf-pkix-ipki-part4-02.txt par.4.4.4 mentions
certificate suspension among operational requirements to be addressed by=

a policy or CPS:
 ...
 * Circumstances under which a certificate may be suspended;
 * Who can request the suspension of a certificate;
 * Procedures to request certificate suspension;
 * How long the suspension may last;
  ...

My questions are:
a) shall a certificate be removed from a CRL when its suspension period
expires or after its reactivation?
b) why hasn't made provision for a reactivation message?

Thanks,
G.
=2D---------------------------------------------
Giorgio Gatto
Finsiel S.p.A.
Via Matteucci 34b
56126 Pisa (Italy)
+39 50 968675 phone
+39 50  968626 fax
mailto:[email-masked]
http:www.finsiel.it

--openmail-part-024b43e1-00000002
Content-Type: application/rtf; name="Suspended"
Content-Disposition: attachment; filename="Suspended"
Content-Transfer-Encoding: base64

--openmail-part-024b43e1-00000002--

--openmail-part-024b43e1-00000001

--openmail-part-024b43e1-00000001--

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 2 Apr 1998 08:19: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:      [IETF-PKIX] Critical flag processing (was: Re: RE: Signed Label )
Comments: To: [email-masked], [email-masked], [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

Russ,

I just recently joined this list, and I am not at all up to speed with the context, but
I believe that throwing out all Critical attributes, either in certificates or
elsewhere, would be like throwing the baby out with the bath water.

My view of the Critical flag is that it important to protect the interests of the CA
or the signer of a message, or both, against unwarranted assumptions of
validity made on the basis of software which does not implement some
particular attribute. (Since NONE of the ietf standards in this area have done
a very good job of defining minimally, average, and fully compliant suites of
functions, implementors who cannot swallow everything whole all at once
are forced to pick and choose features without much guidance. And
unfortunately, the one or two ubiquitous browsers end up setting de facto
standards.  Hopefully now that Netscape has released their source code
into the public domain, some of these incompatibility issues can be
resolved more quickly.)

In particular, the various constraints, together with the CPS and user notice fields,
serve a very important purpose -- they are the equivalent of a legal notice or
caveat -- sort of a Miranda warning to the relying party.

In addition to the 'standard' attributes (which are confusing and sometimes
fluid enough), there is also the issue of propritetary attributes which may be
defined by some organization, and may or may not ever be well accepted
by the general vendor population. Without the Critical flag, a user who
believes that some attribute was particuarly important has no legal defense
against a relying party whose software ignores that attribute.

Take a Reliance Limit, of example.  I don't intend to get into a debate as to
whether that is a good concept or not, but its use in enshrined in several
state's statutes, and in the forthcoming release of Novell's PKIS (Public Key
Infrastructure Services) product we intend to define and support such an attribute
under our own OID, unless or until such time as the ietf cares to standardize such
a use.

The subscriber can either include the attributre or not, and if included, mark it
Critical or not, recognizing the potential interoperability problems that may cause.

But if the Reliance Limit is deemed to be quite important for that user's piece of
mind, interoperability problems IS PRECISELY WHAT IS DESIRED.

If someone's browser doesn't recognize the extension, it should reject the
certificate. The relying party can then decide whether to proceed with the
transaction, but the burden of proof and the burden of liability presumably
will have shifted to the relying party in that case, even if the orignator had been
unforgivably careless with his keys, for example.

It seems to me that the same would apply to a security label or other construct
in S/MIME. The originator is essentially telling the recipient, and perhaps
more importantly the user's agent, "If you can't understand and agree to my terms,
don't read, or at least don't believe my message."

I don't see how you can reasonably do without such a construct.

A random poll of ietf attendees is not sufficient justification for removing a critical
(no pun intended) feature. It IS sufficient justification to demand that we fix
the sloppy syntax and semantics that has been created between the X.509 v3,
PKIX, and S/MIME doucments.

Please pardon my cross-posting to both lists, but I think the issue is important
to both groups, and I don't know how many people are members of both.

Bob

>
>>>> Russ Housley <[email-masked]> 04/01 7:03 PM >>>
>Tim:
>
>Your note has a huge impact.  You point out that the message originator
>cannot ensure that the recipient will honor any attributbes in SignerInfo,
>even if they are marked critical.  For example, the recipient can ignore
>the critical attribute containing the security label.
>
>Here at the IETF meeting, I have asked several people about the usefulness
>of critical attributes.  Of the people that I polled, no one supports them.
> At this point, I am planning to remove critical attributes from the next
>draft of the CMS document.
>
>Russ
>
>At 10:28 AM 3/31/98 +0100, Tim Dean wrote:
>>Russ,
>>>>What happens if a recipient receives a forwarded message that include a
>>>>security policy in the eSSSecurityLabel  that he/she in does not
>understand,
>>>>is that still an error?
>>
>>>Absolutely.  The security label must be marked critical, so the inability
>>>to process the critical attribute must cause an error to be reported to the
>>>user.
>>
>>>>I think the proposed text will mislead implementations to always discarding
>>>>the message if a security policy is unknown.  I do not think that is right.
>>
>>>We disagree.  Rule-based access control cannot be enforced if the recipient
>>>is allowed to ignore the security label.
>>
>>Two thoughts:
>>
>>1.  Insisting that the UA software parse and understand the label before
>showing the message to the user
>>raises serious denial-of-service issues.  There are many circumstances
>when operational necessity
>>demands label-based access control is over-ridden - certainly on reception
>in a distributed system.
>>There are likely to be many, many label formats floating around out there,
>and systems should not stop
>>working just because they don't recognise all of them.
>>
>>2. I am somewhat doubtful that access control in the recipient's user
>agent is going to add a jot of Real
>>Security in practice.  It would surely be extremely unwise to place any
>kind of reliance on it.  Any
>>Computer Scientist worth his salt is quickly going to figure how to
>by-pass this check and read
>>everything which arrives in his computer.  (And he is probably the kind of
>person you didn't want to
>>unintentionally send a message to anyway!)
>>
>>Therefore I think I must agree with John R's suggestion on this: or at
>least make the it a configurable
>>option dependent on security policy.  Also, ESS should probably contain a
>health warning about relying
>>on recipient side access control processing.  By all means check message
>labels on transmission and at
>>points along the path: for example just before the message is about to
>exit your organisation.  Hopefully
>>the label semantics are understood at least that far.  After that I
>suspect it may be too late.
>>
>>Tim
>>
>>-----------------------------------------------
>>Tim Dean
>>Defence Evaluation & Research Agency
>>Malvern
>>United Kingdom
>>telephone:      +44-1684-894239
>>facsimile:      +44-1684-896113
>>e-mail:         [email-masked]
>>----------------------------------------------------
>>
>>
>>
>>
>>John Ross wrote:
>>>What happens if a recipient receives a forwarded message that include a
>>>security policy in the eSSSecurityLabel  that he/she in does not understand,
>>>is that still an error?
>>
>>Absolutely.  The security label must be marked critical, so the inability
>>to process the critical attribute must cause an error to be reported to the
>>user.
>>
>>>I think the proposed text will mislead implementations to always discarding
>>>the message if a security policy is unknown.  I do not think that is right.
>>
>>We disagree.  Rule-based access control cannot be enforced if the recipient
>>is allowed to ignore the security label.
>>
>
>>>All I think needs to be done is to leave such decisions to local policy;
>>>Thus reword your text as..
>>>
>>>"Receiving agents SHOULD have a local policy which specifies
>>>what action is taken when an eSSSecurityLabel is received which
>>>includes a security-policy-identifier that the processing software
>>>does not recognize."
>>>
>>>
>>>If think there is a need to specify default handling, then It should be to
>>>ignore security labels when the policy is not understood.
>>
>>Completely disagree!
>>
>>>Also, I still think that the security policy should not be optional.
>>
>>Wow.  We agree on this one.  The syntax that we are using comes from X.411.
>> In X.411, this field is optional, and we are trying to maintain
>>compatibility.  I suggest that we use english text to state that the
>>security policy must be present.
>>
>>-- Russ
>>

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:         Thu, 2 Apr 1998 09:32: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
Comments: To: [email-masked]
To: [email-masked]

Peter Gutmann wrote:
>
> Moshe Litvin <[email-masked]> writes:
>
> >Unless explicitly specified an application must process any extension it
> >understands regardless of the criticality flag.
>
> This isn't expressed very clearly in the current PKIX text.

Indeed.

>  What it says
> (section 4.2) is that "CA's are required to support <various constraint
> extensions>",

It is not all that it says.When section 4.2 defines the critical flag al
l it says two things about it:

1. A certificate using system (an application
   validating a certificate) must reject the certificate if it
   encounters a critical extension it does not recognize.
2 A non-critical extension may be ignored if it is not recognized.

(the numbering is not from the draft).

Both sentences apply to application that do not recognize an extension,
I havn't seen in PKIX permision for an application to disregard a known
extension just because it is marked not-critical.

> The X.509v3 draft says (in various places) that the
> extensions are advisory only.  In either case it implies that you can recognise
> whatever you like, but there's no requirement to act on it.

I would like to see the paragraphs that led you to this conclusion. More
specifically I would like to see where it is written that in the general
case an application that recognise an extension can decide weather to
honor it or not depending on the critical flag.

By the general case I meen a text that is not related to a specific
extension

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:         Wed, 1 Apr 1998 22:18:00 -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
To: [email-masked]

After getting a number of responses to my comments on cert extension handling,
and finding that for n respondents there are about n+3 interpretations of how
extensions should be handled, I've updated the style guide to include the
following on cert extensions.  As usual, I'd welcome comments on this.

Peter.

Extensions
----------

Extensions ::= SEQUENCE OF Extension

Extension ::= SEQUENCE {
    extnid                  OBJECT IDENTIFIER,
    critical                BOOLEAN DEFAULT FALSE,
    extnValue               OCTETSTRING
    }

X.509 certificate extensions are like a LISP property list: an
ISO-standardised place to store crufties.  Extensions can consist of key and
policy information, certificate subject and issuer attributes, certificate
path constraints, CRL distribution points, and private extensions.

X.509 Amendment 1 of 30 June 1996 and the X.509v3 draft of June 1997 contains
the ASN.1 formats for the standard V3 Certificate, V2 CRL and V2 CRLEntry
extensions.  In theory you should be able to handle all of these, but there
are large numbers of them and some may not be in active use, or may be
meaningless in some contexts.

                    'It's called a shovel,' said the Senior Wrangler.  'I've
                    seen the gardeners use them.  You stick the sharp end in
                    the ground.  Then it gets a bit technical'
                        -- Terry Pratchett, "Reaper Man"

Extensions are encoded with IMPLICIT tags, it's traditional to specify this in
some other part of the standard which is at least 20 pages away from the
section where the extension is actually defined.

There are a whole series of superseded and deprecated OIDs for extensions,
often going back through several generations.  Older software and certificates
will still use obsolete OIDs, any new software should try and emit attributes
tagged with the OID du jour rather than using deprecated OIDs.

We can break extensions into two types, constraint extensions and
informational extensions.  Constraint extensions limit the way in which the
key in a certificate, or the certificate itself, can be used.  For example
they may limit the key usage to digital signatures only, or limit the DN's for
which a CA may issue certificates.  The most common constraint extensions are
basic constraints, key usage and extended key usage, certificate policies
(modified by policy mappings and policy constraints), and name constraints. In
contrast, informational extensions contain information which may or may not be
useful for certificate users, but which doesn't limit the certificate use in
any way.  For example an informational extension may contain additional
information which identifies the CA which issued it.  The most common
informational extensions are key identifiers and alternative names.

The processing of these extensions is mostly specified in three different
standards, which means that there are three more or less mutually incompatible
ways to handle them.  In theory, constraint extensions should be enforced
religiously, however the three standards which cover certificates differ both
in how they specify the interpretation of the critical flag, and how they
require constraint extensions to be enforced.

                    We could not get it out of our minds that some subtle but
                    profoundly alien element had been added to the aesthetic
                    feeling behind the technique.
                        - H.P.Lovecraft, "At the Mountains of Madness".

The original X.509v3 specification requires that a certificate be regarded as
invalid if an unrecognised critical extension is encountered.  As for the
extension itself, you can use whatever interpretation you choose (that is, the
extension is specified as being of an advisory nature only).  This means that
if you encounter constraints which require that a key be used only for digital
signatures, you're free to use it for encryption anyway.  If you encounter a
key which is marked as being a non-CA key, you can use it as a CA key anyway.
The X.509v3 interpretation of extensions is a bit like the recommended 130kmh
speed limit on autobahns, the theoretical limit is 130, you're sitting there
doing 180, and you're getting overtaken by Porsches doing about 250.  Using
this interpretation, it's mostly pointless including any extensions because
everyone is free to ignore them.

The second interpretation of extensions comes from the IETF-PKIX X.509
profile. Like X.509v3, this also requires that a certificate be regarded as
invalid if an unrecognised critical extension is encountered.  However it
seems to imply that a critical extension must be processed, and probably
considers non-critical extensions to be advisory only.  Unfortunately the
wording is ambiguous enough that a number of interpretations exist.  Section
4.2 says that "CA's are required to support <constraint extensions>", but the
degree of support is left open, and what non-CA's are supposed to do isn't
specified. The paragraph which follows this says that implementations "shall
recognise extensions", which implies that you can recognise whatever you like,
but there's no requirement to actually act on it.

The third interpretation comes from S/MIME, which requires that
implementations correctly handle a subset of the constraint and informational
extensions.  However, as with IETF-PKIX, "correctly handle" isn't specified,
so it's possible to "correctly handle" an extension as per X.509v3, as per
IETF-PKIX (choose the interpretation you prefer), or as per S/MIME, which
leaves the issue open (it specifies that implementations may include various
bits and pieces in their extensions, but not how they should be enforced).
S/MIME seems to place a slightly different interpretation on the critical
flag, limiting its use to the small subset of extensions which are mentioned
in the S/MIME spec, so it's not possible to add other critical extensions to
an S/MIME certificate.

Finally, the waters are further muddied by CA policies, which can add their
own spin to the above interpretations.  For example the Verisign CPS, section
2.4.3, says that "all persons shall process the extension [...] or else ignore
the extension", which would seem to cover all the bases.

The whole issue is complicated by the fact that some of the most common
implementations will reject a certificate which contains critical constraint
extensions, so that even if you interpret the critical flag to mean "this
extension must be enforced" (rather than just "reject this certificate if you
don't recognise the extension"), you can't use it because it will render the
certificate unusable.  These implementations provide yet another
interpretation of the critical flag, "reject this certificate if you encounter
a critical extension".

                    Zaphod stared at him as if expecting a cuckoo to leap out
                    of his forehead on a small spring.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

Because of this confusion, it's probably impossible to include a set of
constraint extensions in a certificate which will be handled properly by
different implementations.

The best interpretation of constraint extensions is that if a certificate is
marked as an X.509v3 certificate, constraints should always be enforced.  This
includes enforcing implied settings if the extension is missing, so that a
certificate being used in a CA role which has no basicConstraints extension
present should be regarded as being invalid.  However even if one of the
standards is reworded to precisely define extension handling, there are still
plenty of other standards and interpretations which can be used.  The only
solution to this is to include a critical policy extension which requires that
all constraint extensions up and down the cert chain be enforced.  Going back
to the autobahn analogy, this mirrors the situation at the Austrian border,
where everyone slows down to the strictly enforced speed limit as soon as they
cross the border.

Currently the only way to include a constraint enforcement extension is to
make it a critical policy extension.  This is somewhat unfortunate since
including some other random policy may make the extension unrecognisable,
causing it, and the entire certificate, to be rejected (as usual, what
constitutes an unrecognisable extension is open to debate: if you can process
all the fields in an extension but don't recognise the contents of one of the
fields, it's up to you whether you count this as being unrecognisable or not).

A better alternative would be to define a new extension, enforceConstraints:

enforceConstraints EXTENSION ::= {
    SYNTAX EnforceConstraintsSyntax
    IDENTIFIED BY id-ce-enforceConstraints
    }

EnforceConstraintsSyntax ::= BOOLEAN DEFAULT FALSE

This makes the default setting compatible with the current "do whatever you
feel like" enforcement of extensions.  Enforcing constraints is defined as
enforcing all constraints contained in constraint extensions, incuding implied
settings if the extension is missing, as part of the certificate chain
validation process (which means that they should be enforced up and down the
cert chain).  Recognising/supporting/handling/<whatever other wording is used
in standards> an extension is defined as processing and acting on all
components of all fields of an extension.

                    'Where was I?' said Zaphod Beeblebrox the Fourth.
                    'Pontificating' said Zaphod Beeblebrox.
                    'Oh yes'.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

Just to mention a further complication with critical extensions, there are
instances in which it's possible to create certificates which are always
regarded as being invalid due to conflicts with extensions.  For example a
generation n-1 critical extension might be replaced by a generation n critical
extension, resulting in a mixture of certs with generation n-1 extensions,
generation n-1 and generation n extensions (for compatibility) and
(eventually) generation n extensions only.  However until every piece of
software is upgraded, generation n-1 software will be forced to reject all
certs with generation n extensions, even the (supposedly)
backwards-compatibile certs with both generations of extension in them.

                    'Mr.Beeblebrox, sir', said the insect in awed wonder,
                    'you're so weird you should be in movies'.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

Approved-By: [email-masked]
Date:         Wed, 1 Apr 1998 10:12:01 -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
To: [email-masked]

Moshe Litvin <[email-masked]> writes:

>Unless explicitly specified an application must process any extension it
>understands regardless of the criticality flag.

This isn't expressed very clearly in the current PKIX text.  What it says
(section 4.2) is that "CA's are required to support <various constraint
extensions>", but the degree of support is left open, and this only covers what
CA's can do.  The following paragraph says that implementations "shall
recognise extensions", and the X.509v3 draft says (in various places) that the
extensions are advisory only.  In either case it implies that you can recognise
whatever you like, but there's no requirement to act on it.  It would help if
the degree of "support" for an extension were made explicit in the text, ie
explicitly state that conformant implementations must enforce any constraint
extensions which are present, and perhaps point out that this differs markedly
from X.509v3 in which the requirement to enforce the constraint is absent.

I can see that this is going to take a long writeup in the style guide to cover
the intricacies of extension handling and straight X.509v3 vs PKIX.

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

Presumably a ca=TRUE basicConstraint will be accompanied by a
keyUsage=keyCertSign | crlSign constraint (I would hope that a CA's cert
signing key isn't goint to be used for, say, key exchange purposes).  If you
follow the X.509v3 text, you're free to ignore this and use it for key
exchange/data encipherment/whatever anyway.  If the constraint is a NOP (as in
your example) then it doesn't matter, but where it really is a constraint
present, you want to be sure it's going to be enforced by implementations
which encounter it.

Bob Jueneman <[email-masked]> added:

>Constraint extensions are optional unless indicated by the Critical flag.

That's certainly what X.509v3 says, and PKIX seems to imply as well (depending
on how you interpret "shall recognise" - see the comments above).

I'll do a longer writeup which summarises the different points of view later
today after I've had some sleep, and try to think up a unified solution which
is compatible with current implementations (if that's possible).

Peter.

Approved-By:  Moshe Litvin <[email-masked]>
Date:         Wed, 1 Apr 1998 19:37:47 +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: Bob Jueneman <[email-masked]>
To: [email-masked]

Just to be on the same page PKIX part 1 specify in section 4.2:

   Each extension in a certificate may be designated as crit-
   ical or non-critical.  A certificate using system (an application
   validating a certificate) must reject the certificate if it
   encounters a critical extension it does not recognize.

That is the draft gives permission to ignore the extension only if you
don't understand it.

Bob Jueneman wrote:
>
> I disagree.
> >
> >>>> Moshe Litvin <[email-masked]> 04/01 12:14 AM >>>
>
> >> 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.
>
> I STRONGLY disagree. From my perspective, one of the most important
> reasons for defining the Critical flag was to force applications to reject
> a certificate if they didn't understand some attribute which the subscriber
> or CA thought was particularly important.. In particular, a user notice field,
> a reliance limit field, or some other constraint which either
> the CA or the subscriber feels is absolutely crucial for her protection.

There is a connection between important and critical, but it is not the
same. An extremely important extension can be marked as not critical
without any compromise to the security.

Let me return to my example of a basicConstraint extension with ca=TRUE
and no pathLenConstraint.

This is a very important certificate because it gives it holder
"absolute" power. If an application consider every certificate without
basic constraint as a non CA certificate (a reasonable approach) that
extension gives him invaluable information.

But there is no loss of security if an application ignores the
extension.

That is important does not mean critical, while the opposite is probably
true, there is no need in making an extension critical if it is of no
importance.

> >> 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.
>
> No, it isn't.  Constraint extensions are optional unless indicated by the
> Critical flag.

Where does it says that?

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:  Bob Jueneman <[email-masked]>
Date:         Wed, 1 Apr 1998 06:52: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]

I disagree.
>
>>>> Moshe Litvin <[email-masked]> 04/01 12:14 AM >>>

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

I STRONGLY disagree. From my perspective, one of the most important
reasons for defining the Critical flag was to force applications to reject
a certificate if they didn't understand some attribute which the subscriber
or CA thought was particularly important.. In particular, a user notice field,
a reliance limit field, or some other constraint which either
the CA or the subscriber feels is absolutely crucial for her protection.

The various constraints, of course, potentially fall into that category, but
there are interoperability  issues with existing software that have to be
taken into account.
>
>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.

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

This brings up a whole 'nother issue. what does it mean to be PKIX compliant?
My interpretation of the PKIX spec is that it is a very long laundry list of nice to have
features, but I claim that I could be PKIX compliant and only implement a relatively
small subset of those features.  Basically, the only thing I _really_ have to do
is recognize and honor the Critical flag.

I'm not necessarily espousing that philosophy, only pointing out that that is
how I read the spec. Certainly if everything in the spec is supposed to be
mandatory, I'm going to have to get up on my high horse and start objecting t
o some things a lot more loudly, starting with the use of both Teletex and
Universal strings, the entire section of X.400 attributes (which are completely
useless from the standpoint of international applications), and the complete
lack, so far, of any agreed upon set of RDN component attributes and their
appropriate schemas, etc, etc.

If the standard is going to address what it means to be PKIX-compliant in
terms of what portions other than the very basic elements plus the Critical
flag, I believe we are going to have to define some Category A, B, and C
elements. We probably need to do that anyway -- the current spec is rich
with function, and other than a few instances nice things to have, but it
is unlikely that anyone is going to implement either a CA toolkit or a relying party
validation module that would include all of those functions in the first release.

The spec needs to be broken down into modular chunks, for the sake of
interoperability.

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

No, it isn't.  Constraint extensions are optional unless indicated by the
Critical flag.  If you want to change the spec so that all such constraints
are marked with the Critical flag, that's worth discussing. But that's not
what it says now.

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

Date: Thu, 30 Apr 1998 16:10:38 -0700
To: Michael Myers <[email-masked]>, Marc Branchaud <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate,  producedAt 
Cc: [email-masked]
Sender: [email-masked]

At 03:34 PM 4/30/98 -0700, Michael Myers wrote:
>For these reasons, I would agree with the proposed text with the first
>three lines deleted.  There is no way for anyone to implement a client that
>would enforce them.

I agree with Mike. The source of the data is not important here, and trying
to force heuristics on it seems inappropriate.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 30 Apr 1998 15:34:54 -0700
To: Marc Branchaud <[email-masked]>, Paul Hoffman / IMC <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt 
Cc: [email-masked]
Sender: [email-masked]

Marc, 

How can it be shown whether or not the responder is working directly off a
certificate database or not?  Or off a digitially signed image of a
database for that matter?  Furthermore, the site or sites receiving a
request may front a database with a periodically produced CRL for a variety
of reasons.  Lastly, there may very well exist refresh latency at sites or
on servers that do have a certifiate database.  Consider the case of a cron
job on a cert server that periodically sweeps it certificate database,
produces pre-signed responses and includes in them the next time at which
this event is expected to occur.

For these reasons, I would agree with the proposed text with the first
three lines deleted.  There is no way for anyone to implement a client that
would enforce them.

Mike

At 01:09 PM 4/30/98 -0700, Marc Branchaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Content-Type: text/plain; charset=us-ascii
>
>
>Paul Hoffman / IMC <[email-masked]> scrawled:
>> 
>> At 02:24 PM 4/29/98 -0700, Ambarish Malpani wrote:
>> >I would like to have nextUpdate be allowed. For cases where the OCSP
>> >responder is working off a CRL, it should reflect the value of
>> >nextUpdate
>> >in the CRL. However, for cases where the responder is working off the
>> >CAs database (which could be updated at any instant), I would like to
>> >have nextUpdate be optional, which means that this response was valid
>> >only at the thisUpdate time and can change even in the next second.
>> 
>> This works for me as long as the semantics of nextUpdate are clear and
>> mandatory. "If the nextUpdate field is included, it MUST be [[[insert exact
>> words from PKIX part 1]]]. If it not included, the recipient cannot infer
>> any information about how long the OCSP response will be valid."
>> 
>
>I would like nextUpdate to be removed entirely, but I guess I can live with
>it being optional.  I would like Paul's suggested wording to go even further,
>though.  Although referencing part 1 looks like an easy way out, part 1's
>description of nextUpdate is really sparse.  Here's what I suggest:
>
>   The nextUpdate field MAY be included if the responder derives the response
>   from a CRL.  In that case, the value of nextUpdate in the response MUST
>   match the value of nextUpdate in the CRL.  The nextUpdate field SHOULD NOT
>   be included if the responder has direct access to the CA's revocation
>   database (i.e. it can obtain revocation information in real time).  When
>   it is included, the nextUpdate field SHOULD be interpreted to mean that
>   fresh revocation information should be available no later than
>   nextUpdate's time, and may be available sooner.  In general, nextUpdate is
>   not a guarantee of the lifetime of a response's validity.  Clients SHOULD
>   use their own local policies to determine how long they believe a response
>   to be valid, regardless of the presence of the nextUpdate field in the
>   response.
>
>		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
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNUjahFrdFXNdDxPlAQH8JgMAlcl12gaRmUpdYM8dPzAelLtAFkYRSjIA
>kN7WIe9F/V2Nv0GHw9+H+pD9AGY6ohEWnn7yoc76JbXh6XBMY/OziyjfELPpICBg
>A4MvDxlTRovSIRXsrGazlzgXIWsmrFY7
>=Vcae
>-----END PGP SIGNATURE-----
>
>

To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt 
Date: Thu, 30 Apr 1998 13:09:41 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

Paul Hoffman / IMC <[email-masked]> scrawled:
> 
> At 02:24 PM 4/29/98 -0700, Ambarish Malpani wrote:
> >I would like to have nextUpdate be allowed. For cases where the OCSP
> >responder is working off a CRL, it should reflect the value of
> >nextUpdate
> >in the CRL. However, for cases where the responder is working off the
> >CAs database (which could be updated at any instant), I would like to
> >have nextUpdate be optional, which means that this response was valid
> >only at the thisUpdate time and can change even in the next second.
> 
> This works for me as long as the semantics of nextUpdate are clear and
> mandatory. "If the nextUpdate field is included, it MUST be [[[insert exact
> words from PKIX part 1]]]. If it not included, the recipient cannot infer
> any information about how long the OCSP response will be valid."
> 

I would like nextUpdate to be removed entirely, but I guess I can live with
it being optional.  I would like Paul's suggested wording to go even further,
though.  Although referencing part 1 looks like an easy way out, part 1's
description of nextUpdate is really sparse.  Here's what I suggest:

   The nextUpdate field MAY be included if the responder derives the response
   from a CRL.  In that case, the value of nextUpdate in the response MUST
   match the value of nextUpdate in the CRL.  The nextUpdate field SHOULD NOT
   be included if the responder has direct access to the CA's revocation
   database (i.e. it can obtain revocation information in real time).  When
   it is included, the nextUpdate field SHOULD be interpreted to mean that
   fresh revocation information should be available no later than
   nextUpdate's time, and may be available sooner.  In general, nextUpdate is
   not a guarantee of the lifetime of a response's validity.  Clients SHOULD
   use their own local policies to determine how long they believe a response
   to be valid, regardless of the presence of the nextUpdate field in the
   response.

		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

Date: Thu, 30 Apr 1998 11:14:03 -0700
To: Stephen Samson <[email-masked]>, [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: Entrust Technologies Announces License Terms for CRL Distribution Points Patent
Cc: Jeff Schiller <[email-masked]>, Steve Kent <[email-masked]>, Tim Polk <[email-masked]>, Warwick Ford <[email-masked]>
Sender: [email-masked]

Stephen,

It appears the text is not yet posted at this URL.  On reference, I receive
a page that states:

"Our Apologies

This link is either outdated or missing at this time. Please refer yourself
to our homepage or feel free to use the sitemap."

Mike

At 01:26 PM 4/30/98 -0400, Stephen Samson wrote:
>Members of the IETF Community;
>
>Entrust Technologies is very pleased to provide details of its previously
>announced royalty-free license for the CRL Distribution Points Patent.
>
>By following the link:  http://www.entrust.com/products/patent.htm to our
>website, you will be able to read a summary of the license terms. In the
>spirit of open Standards, Entrust has fashioned the license in fair,
>reasonable and equitable terms that should appeal to all interested parties.
>
>A party interested in taking a license should contact the author directly,
>so that appropriate license documentation can be drafted. Please direct any
>questions to:
>
>Steve Samson
>
>Entrust Technologies Inc.
>750 Heron Rd.,  8th Floor
>Ottawa, Ontario, Canada, K1V 1A7
>
>voice:			613-247-3725
>fax:			613-247-3412
>email:			[email-masked]
>Entrust Validation String:	SCKM-HQDL-X75G
>
>

From: Stephen Samson <[email-masked]>
To: [email-masked]
Cc: Jeff Schiller <[email-masked]>, Steve Kent <[email-masked]>, Tim Polk <[email-masked]>, Warwick Ford <[email-masked]>
Subject: Entrust Technologies Announces License Terms for CRL Distribution Points Patent
Date: Thu, 30 Apr 1998 13:26:06 -0400
Sender: [email-masked]

Members of the IETF Community;

Entrust Technologies is very pleased to provide details of its previously
announced royalty-free license for the CRL Distribution Points Patent.

By following the link:  http://www.entrust.com/products/patent.htm to our
website, you will be able to read a summary of the license terms. In the
spirit of open Standards, Entrust has fashioned the license in fair,
reasonable and equitable terms that should appeal to all interested parties.

A party interested in taking a license should contact the author directly,
so that appropriate license documentation can be drafted. Please direct any
questions to:

Steve Samson

Entrust Technologies Inc.
750 Heron Rd.,  8th Floor
Ottawa, Ontario, Canada, K1V 1A7

voice:			613-247-3725
fax:			613-247-3412
email:			[email-masked]
Entrust Validation String:	SCKM-HQDL-X75G

To: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates 
Date: Thu, 30 Apr 1998 10:18:44 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

Ambarish Malpani <[email-masked]> scrawled:
> 
> So, here are the options:
> 
> 1. Hash(IssuerDN and IssuerPublicKey) and CertSerialNumber
> 2. Hash(IssuerDN), Hash(IssuerPublicKey) and CertSerialNumber
> 3. IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber
> 

I prefer option 3.  The OCSP server needs to know which CA issued the cert, 
but using a hash of the IssuerDN just adds an unneeded layer of indirection.

		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

Date: Thu, 30 Apr 1998 10:14:50 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

> From: Ambarish Malpani <[email-masked]>
> 
> So, here are the options:
> 
> 1. Hash(IssuerDN and IssuerPublicKey) and CertSerialNumber
> 2. Hash(IssuerDN), Hash(IssuerPublicKey) and CertSerialNumber
> 3. IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber
> 
> What are the opinions of the group? I would like to have a quick
> flurry of opinions before we decide to go one way or the other.
      ...

> > The second issue is a relatively simple one - how important is it to
> > save bytes in the query - sending the hash of the issuer's DN is much
> > smaller than sending the full DN. However, if we just send the hash of
> > the DN, the responder may not be able to reconstruct the full DN, so
> > querying a database that is indexed by anything other than the hash
> > of the DN might be impossible.

I am worried about hashing the DN for the sole purpose of saving
bytes in the query.  Even if the canonicalization issue is solved, there
remains the problem stated here: given the hash, the responder cannot
(not "may not be able to"!) reconstruct the DN, so that forces
all implementations to index by hash of the canonicalized DN.  That
is an unnecessary constraint on implementors.

It precludes meaningful error messages "can't find cert for issuer=xyz
serial=123" which may be helpful when customers ask why their queries
aren't working.

And it adds a translation step, which I tend to resist on philosophical
grounds: if you have "x", then you shouldn't used a transformed
version "f(x)" in protocols unless there are compelling reasons to do
so.  I don't regard the potential byte savings as compelling.
The example in PKIX part 1 "C=US, O=gov, OU=nist" encodes to 42
octets, vs. 22 octets for SHA(DN).  Longer DNs would offer somewhat
greater savings.

OTOH, hashing SubjectPublicKeyInfo saves enough space to be worthwhile
- with parameters (which should always be included with the public key
even if they are not present in the Issuer's certificate) the example
public key encodes to 436 octets.  22 is more than an order of
magnitude smaller.  And the public key doesn't have as much "meaning"
to be obliterated by hashing as the DN has.

So I vote for option 3: IssuerDN, SerialNumber, Hash(IssuerPublicKey)

Dave Kemp

Date: Thu, 30 Apr 1998 11:12:25 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Ambarish Malpani <[email-masked]>
CC: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Ambarish Malpani wrote:
 
> Hi All,
>     Would like to get closure on the method of identifying
> certificates. I think nobody has any objections to including the
> issuer's public key in the information that is used to identify the
> issuer. The main point of contention is whether to send the whole
> DN or the hash of the DN.
> 
> Tim, hopefully your issue with sending over the hash of the DN can
> be addressed by canonicalizing the issuer's DN before hashing it
> (are there any such canonicalization rules)?
> 
> So, here are the options:
> 
> 1. Hash(IssuerDN and IssuerPublicKey) and CertSerialNumber
> 2. Hash(IssuerDN), Hash(IssuerPublicKey) and CertSerialNumber
> 3. IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber

>From the option that are proposed, option 3 is the only one that is
working for all environments. 

The argument is that neither Hash(IssuerDN) nor Hash(IssuerDN and
IssuerPublicKey) can be used to find which CA has issued a certificate
unless you get an hint by some other means.

In the option 3, we should allow either IssuerDN or alternate name to be
used, since I do not think it is appropriate to mandate DNs for CAs (no
argument has been given on the list up to now to explain why DNs would
work better that alternate names as long as the latter are unique).

Regards,

Denis

> What are the opinions of the group? I would like to have a quick
> flurry of opinions before we decide to go one way or the other.
> 
> Regards,
> Ambarish

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

Date: Wed, 29 Apr 1998 17:05:43 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
Sender: [email-masked]

At 02:24 PM 4/29/98 -0700, Ambarish Malpani wrote:
>I would like to have nextUpdate be allowed. For cases where the OCSP
>responder is working off a CRL, it should reflect the value of
>nextUpdate
>in the CRL. However, for cases where the responder is working off the
>CAs database (which could be updated at any instant), I would like to
>have nextUpdate be optional, which means that this response was valid
>only at the thisUpdate time and can change even in the next second.

This works for me as long as the semantics of nextUpdate are clear and
mandatory. "If the nextUpdate field is included, it MUST be [[[insert exact
words from PKIX part 1]]]. If it not included, the recipient cannot infer
any information about how long the OCSP response will be valid."

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 29 Apr 1998 14:24:59 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
Sender: [email-masked]

Hi All,
    Again, would like to close on this issue: I think thisUpdate and
producedAt are non-controversial. The main issue is should nextUpdate
be allowed and if it is allowed, should it be optional or not.

I would like to have nextUpdate be allowed. For cases where the OCSP
responder is working off a CRL, it should reflect the value of
nextUpdate
in the CRL. However, for cases where the responder is working off the
CAs database (which could be updated at any instant), I would like to
have nextUpdate be optional, which means that this response was valid
only at the thisUpdate time and can change even in the next second.

Marc, can you live with this specification or do you violently disagree?

Again, would like a quick flurry of activity on this topic so that we
can close it ASAP.

Regards,
Ambarish

Ambarish Malpani wrote:
> 
> We are proposing that OCSP responses have the following fields:
> 
>     producedAt - a GeneralizedTime that indicates the time at which this
>         response was produced/signed. There is only one producedAt time
>         in the response (irrespective of how many certs are included in
>         the response)
>     thisUpdate - a GeneralizedTime, which specifies the time at which the
>         response was known to be current - basically the time at which
>         the CA's database was looked up. It may or may not have the same
>         value as producedAt. There is a thisUpdate field with every cert
>         whose status is known. Corresponds to the thisUpdate in a CRL.
>     nextUpdate - a GeneralizedTime, which specifies when newer information
>         will be available from this CA. Has the same semantics as the
>         nextUpdate time in CRLs. There is a nextUpdate field with every
>         cert whose status is known. There is no guarantee that revocation
>         information will not be updated before nextUpdate (just as there is
>         no guarantee that a CRL will not be issued before nextUpdate).
> 
...Deleted...
> 
> Comments?
> 
> Ambarish
> 

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Wed, 29 Apr 1998 14:11:09 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Sender: [email-masked]

Hi All,
    Would like to get closure on the method of identifying
certificates. I think nobody has any objections to including the
issuer's public key in the information that is used to identify the
issuer. The main point of contention is whether to send the whole
DN or the hash of the DN.

Tim, hopefully your issue with sending over the hash of the DN can
be addressed by canonicalizing the issuer's DN before hashing it
(are there any such canonicalization rules)?

So, here are the options:

1. Hash(IssuerDN and IssuerPublicKey) and CertSerialNumber
2. Hash(IssuerDN), Hash(IssuerPublicKey) and CertSerialNumber
3. IssuerDN, Hash(IssuerPublicKey) and CertSerialNumber

What are the opinions of the group? I would like to have a quick
flurry of opinions before we decide to go one way or the other.

Regards,
Ambarish

Ambarish Malpani wrote:
> 
> There have been three proposals for identifying certificates:
> 
>     1. Hash(Issuer's DN) and the certificate's serial number
>     2. Hash(Issuer's DN and Issuer's Public Key) and the certificate's
>         serial number
>     3. Issuer's DN, Hash(Issuer's Public Key) and the certificate's
> serial
>         number
> 
>     There are two main issues here:
>     a. Does the query need to include information about the issuer's
> public
>         key?
>     b. Should we send the whole Issuer DN, or just it's hash?
> 
>     The second issue is a relatively simple one - how important is it to
> save bytes in the query - sending the hash of the issuer's DN is much
> smaller than sending the full DN. However, if we just send the hash of
> the
> DN, the responder may not be able to reconstruct the full DN, so
> querying
> a database that is indexed by anything other than the hash of the DN
> might
> be impossible.
> 
>     The first issue is more interesting: I contend that there is not way
> to enforce uniqueness of DN's across the whole world. However, public
> keys
> better be unique (otherwise you have broken the basic premise of public
> key cryptography).
>     Consider the following (slightly long winded) story:
> 
>     Once upon a time, there was a country X, which has a famous CA,
> CA of X. One year, it had a revolution, which resulted in the country
> being divided into East X and West X. The U.S. supported West X, while
> China supported East X. Ofcourse, both nations wanted to retain the name
> CA of X, since it was well known across the world. Neither of them
> continued to use the same public key (since both sides knew the
> corresponding
> private key), but both wanted to use the original DN.
>     The issue of who would be allowed to retain the original DN was
> taken
> to the International Court in the Hague, but in the meantime,
> Switzerland,
> which was running a global OCSP responder, needed to figure out which
> country's CA of X it would support.
> 
>     Fortunately, there is an easy way out of this problem - if we
> include
> the hash of the issuer's public key as a means of identifying the CA,
> clashes of DNs don't affect OCSP. Also, given that the
> AuthorityKeyIdentifier
> is going to be mandatory in PKIX, client's don't even need to do an
> additional hashing operation to provide this information.
> 
>     Some people have argued that if DNs clash, everything in PKIX
> breaks. I
> would like to make the following points:
>     - Just because something else breaks, you shouldn't design your
>         protocols with the same weaknesses.
>     - In most of PKIX, along with a name, you also have a signature.
> This
>         signature implicitly identifies the public key associated with that
>         name.
>     - It is quite possible that even if issuer DNs clash, most domains
>         will never see that clash, because they only trust one of the issuers
>         with that DN. The only person who sees that clash might be an OCSP
>         responder that tries to collect revocation data from all issuers.
> 
>     Enough from me. What is the feeling on this issue in this group?
> Should
> we include the hash of the issuer's public key to uniquely identify the
> issuer?
> 
> Ambarish
> 

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

From: John Everson <[email-masked]>
Date: Wed, 29 Apr 1998 15:03:11 -0500
Subject: RE: OCSP status tally
TO: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

--openmail-part-098dd9db-00000001
Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.RTF"

I think the key is to allow for maximum flexibility without excess.
Either method provides the basic functionality, however Slava's optional
components provide flexibility. I'm afraid the flexibility will produce
too many variations if they are implemented at all. I still prefer:

CertStatusType ::= ENUMERATED {
    unknown              (-2),
    notRevoked           (-1),
    revoked (unspecified) (0),
    keyCompromise         (1),
    cACompromise          (2),
    affiliationChanged    (3),
    superseded            (4),
    cessationOfOperation  (5),
    certificateHold       (6) }

but would be happy with either one considering the alternative:

CertStatusType ::= ENUMERATED {
    notRevoked     (0),
    revoked        (1),
    unknown        (2) }

Which provides too little flexibility.

John Everson
Sprint

-----Original Message-----
From: mmyers [mailto:[email-masked]]
Sent: Wednesday, April 29, 1998 12:13 PM
To: John.Everson; dpkemp; ietf-pkix
Cc: mmyers
Subject: RE: OCSP status tally

John,

Would the revocationReason construct in Slava's recent proposal meet
your
needs?  Recall that he had proposed:

RevocationStatus ::= CHOICE {         
      unknown      [0] IMPLICIT UnknownInfo,
       notRevoked   [1] IMPLICIT NULL,
       revoked      [2] IMPLICIT RevokedInfo }

UnknownInfo ::= NULL -- this can be replaced with an enumeration
                     -- for various specific reasons such as
                     -- doNotKnowAboutCA etc.

RevokedInfo ::= SEQUENCE {
      revocationTime GeneralizedTime,
      revocationReason RevocationReason OPTIONAL -- this could include
                                                  -- "onHold" }

Mike

At 09:00 AM 4/29/98 -0500, John Everson wrote:
>
>It seems a shame to provide less functionality. I prefer going with all
>the defined codes from CRLReason:
>
>CertStatusType ::= ENUMERATED {
>    unknown              (-2),
>    notRevoked           (-1),
>    revoked (unspecified) (0),
>    keyCompromise         (1),
>    cACompromise          (2),
>    affiliationChanged    (3),
>    superseded            (4),
>    cessationOfOperation  (5),
>    certificateHold       (6) }
>
>John Everson
>Sprint
>
>-----Original Message-----
>From: dpkemp [mailto:[email-masked]]
>Sent: Tuesday, April 28, 1998 4:13 PM
>To: ietf-pkix
>Cc: dpkemp
>Subject: Re: OCSP status tally
>
>
>> From: Michael Myers <[email-masked]>
>>   
>> I would like to propose we move forward with the following simplified
>> construction:
>>   
>> CertStatusType ::= ENUMERATED {
>>     notRevoked     (0),
>>     revoked        (1),
>>     onHold         (2),
>>     unknownCA      (3),
>>     unknownCert    (4) }
>
>
>It seems unusual to include a specific status code for "onHold", but
>not for any of the other X.509-defined reason codes.  And it seems
>unusual to have two codes which mean "unknown" but for different
>reasons; is there any business requirement for RPs to make a
>distinction between unknownCA and unknownCert?
>
>Might I suggest:
>
>CertStatusType ::= ENUMERATED {
>    notRevoked     (0),
>    revoked        (1),
>    unknown        (2) }
>
>
>or less enthusiastically, include all the defined codes from CRLReason:
>
>CertStatusType ::= ENUMERATED {
>    unknown              (-2),
>    notRevoked           (-1),
>    revoked (unspecified) (0),
>    keyCompromise         (1),
>    cACompromise          (2),
>    affiliationChanged    (3),
>    superseded            (4),
>    cessationOfOperation  (5),
>    certificateHold       (6) }
>
>
>
>
>> From: Andreas Berger <[email-masked]>
>>
>> Sorry that I bring that up again: the answer about knowing about a CA
>> but not about the referenced certificate would be a good one for use
>of
>> OCSP in the German Signature Law, where such a service is required.
>
>Without knowing both "the law" and the text of this specific law, it's
>impossible to be 100% sure of it's intent.  However, I'm 99.98% sure
:-)
>that "knowing about a CA" means that the RP possesses the certificate
>of the CA as part of the cert path being validated, or that the CA's
>cert can be validated or is a trust point, or that the RP has some
>out-of-band reason to believe that the CA exists.
>
>I have a hard time believing that the law's intent is to require the
>use of OCSP-like technology with status codes enabling the OCSP
>responder to claim "I know / don't-know about this CA".  The RP's
>knowledge is what's important, not a repository/responder's knowledge.
>
>
>Dave Kemp
>
>
>

--openmail-part-098dd9db-00000001--

Date: Wed, 29 Apr 1998 10:12:48 -0700
To: John Everson <[email-masked]>, [email-masked], [email-masked]
From: Michael Myers <[email-masked]>
Subject: RE: OCSP status tally
Sender: [email-masked]

John,

Would the revocationReason construct in Slava's recent proposal meet your
needs?  Recall that he had proposed:

RevocationStatus ::= CHOICE {        
	unknown      [0] IMPLICIT UnknownInfo,
       notRevoked   [1] IMPLICIT NULL,
       revoked      [2] IMPLICIT RevokedInfo }

UnknownInfo ::= NULL -- this can be replaced with an enumeration
                     -- for various specific reasons such as
                     -- doNotKnowAboutCA etc.

RevokedInfo ::= SEQUENCE {
	revocationTime GeneralizedTime,
	revocationReason RevocationReason OPTIONAL -- this could include
                                                  -- "onHold" }

Mike

At 09:00 AM 4/29/98 -0500, John Everson wrote:
>
>It seems a shame to provide less functionality. I prefer going with all
>the defined codes from CRLReason:
>
>CertStatusType ::= ENUMERATED {
>    unknown              (-2),
>    notRevoked           (-1),
>    revoked (unspecified) (0),
>    keyCompromise         (1),
>    cACompromise          (2),
>    affiliationChanged    (3),
>    superseded            (4),
>    cessationOfOperation  (5),
>    certificateHold       (6) }
>
>John Everson
>Sprint
>
>-----Original Message-----
>From: dpkemp [mailto:[email-masked]]
>Sent: Tuesday, April 28, 1998 4:13 PM
>To: ietf-pkix
>Cc: dpkemp
>Subject: Re: OCSP status tally
>
>
>> From: Michael Myers <[email-masked]>
>>  
>> I would like to propose we move forward with the following simplified
>> construction:
>>  
>> CertStatusType ::= ENUMERATED {
>>     notRevoked     (0),
>>     revoked        (1),
>>     onHold         (2),
>>     unknownCA      (3),
>>     unknownCert    (4) }
>
>
>It seems unusual to include a specific status code for "onHold", but
>not for any of the other X.509-defined reason codes.  And it seems
>unusual to have two codes which mean "unknown" but for different
>reasons; is there any business requirement for RPs to make a
>distinction between unknownCA and unknownCert?
>
>Might I suggest:
>
>CertStatusType ::= ENUMERATED {
>    notRevoked     (0),
>    revoked        (1),
>    unknown        (2) }
>
>
>or less enthusiastically, include all the defined codes from CRLReason:
>
>CertStatusType ::= ENUMERATED {
>    unknown              (-2),
>    notRevoked           (-1),
>    revoked (unspecified) (0),
>    keyCompromise         (1),
>    cACompromise          (2),
>    affiliationChanged    (3),
>    superseded            (4),
>    cessationOfOperation  (5),
>    certificateHold       (6) }
>
>
>
>
>> From: Andreas Berger <[email-masked]>
>>
>> Sorry that I bring that up again: the answer about knowing about a CA
>> but not about the referenced certificate would be a good one for use
>of
>> OCSP in the German Signature Law, where such a service is required.
>
>Without knowing both "the law" and the text of this specific law, it's
>impossible to be 100% sure of it's intent.  However, I'm 99.98% sure :-)
>that "knowing about a CA" means that the RP possesses the certificate
>of the CA as part of the cert path being validated, or that the CA's
>cert can be validated or is a trust point, or that the RP has some
>out-of-band reason to believe that the CA exists.
>
>I have a hard time believing that the law's intent is to require the
>use of OCSP-like technology with status codes enabling the OCSP
>responder to claim "I know / don't-know about this CA".  The RP's
>knowledge is what's important, not a repository/responder's knowledge.
>
>
>Dave Kemp
>
>
>

Date: Wed, 29 Apr 1998 08:10:33 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: OCSP status tally
Sender: [email-masked]

Denis,

I'm looking for a label on the value that addresses the case when the OCSP
server specifically does not have or have access to information on a given
certificate, even though the OCSP server may otherwise recognize the
certificate's issuer (and hence unknownCA is inappropriate). As I had noted
previously, this situation could easily occur for some uses of CRL
Distribution Points, CRLLists or other delegation mechanism.  If you feel
that unknownCert is an inappropriate label, what would you propose we
otherwise use to label this value?

Mike

At 10:35 AM 4/29/98 -0700, Denis Pinkas wrote:
>
>However " unknownCert    (4)" implies that the cert is accessible by the
>OCSP server and would conflict with "notRevoked" when the cert is *not*
>accessible by the OCSP server.
>
>Unless there is a further indication that states whether the cert is or
>is not accessible, the proposal does not work.
>
>Denis

Date: Wed, 29 Apr 1998 08:08:44 -0700
To: [email-masked], Michael Myers <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: OCSP status tally
Cc: [email-masked]
Sender: [email-masked]

Denis,

I'm looking for a label on the value that addresses the case when the OCSP
server specifically does not have or have access to information on a given
certificate, even though the OCSP server may otherwise recognize the
certificate's issuer (and hence unknownCA is inappropriate). As I had noted
previously, this situation could easily occur for some uses of CRL
Distribution Points, CRLLists or other delegation mechanism.  If you feel
that unknownCert is an inappropriate label, what would you propose we
otherwise use to label this value?

Mike

At 10:35 AM 4/29/98 -0700, Denis Pinkas wrote:
>
>However " unknownCert    (4)" implies that the cert is accessible by the
>OCSP server and would conflict with "notRevoked" when the cert is *not*
>accessible by the OCSP server.
>
>Unless there is a further indication that states whether the cert is or
>is not accessible, the proposal does not work.
>
>Denis

From: John Everson <[email-masked]>
Date: Wed, 29 Apr 1998 09:00:30 -0500
Subject: RE: OCSP status tally
TO: [email-masked], [email-masked]
Sender: [email-masked]

--openmail-part-0987991b-00000001
Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="BDY.RTF"

It seems a shame to provide less functionality. I prefer going with all
the defined codes from CRLReason:

CertStatusType ::= ENUMERATED {
    unknown              (-2),
    notRevoked           (-1),
    revoked (unspecified) (0),
    keyCompromise         (1),
    cACompromise          (2),
    affiliationChanged    (3),
    superseded            (4),
    cessationOfOperation  (5),
    certificateHold       (6) }

John Everson
Sprint

-----Original Message-----
From: dpkemp [mailto:[email-masked]]
Sent: Tuesday, April 28, 1998 4:13 PM
To: ietf-pkix
Cc: dpkemp
Subject: Re: OCSP status tally

> From: Michael Myers <[email-masked]>
>  
> I would like to propose we move forward with the following simplified
> construction:
>  
> CertStatusType ::= ENUMERATED {
>     notRevoked     (0),
>     revoked        (1),
>     onHold         (2),
>     unknownCA      (3),
>     unknownCert    (4) }

It seems unusual to include a specific status code for "onHold", but
not for any of the other X.509-defined reason codes.  And it seems
unusual to have two codes which mean "unknown" but for different
reasons; is there any business requirement for RPs to make a
distinction between unknownCA and unknownCert?

Might I suggest:

CertStatusType ::= ENUMERATED {
    notRevoked     (0),
    revoked        (1),
    unknown        (2) }

or less enthusiastically, include all the defined codes from CRLReason:

CertStatusType ::= ENUMERATED {
    unknown              (-2),
    notRevoked           (-1),
    revoked (unspecified) (0),
    keyCompromise         (1),
    cACompromise          (2),
    affiliationChanged    (3),
    superseded            (4),
    cessationOfOperation  (5),
    certificateHold       (6) }

> From: Andreas Berger <[email-masked]>
>
> Sorry that I bring that up again: the answer about knowing about a CA
> but not about the referenced certificate would be a good one for use
of
> OCSP in the German Signature Law, where such a service is required.

Without knowing both "the law" and the text of this specific law, it's
impossible to be 100% sure of it's intent.  However, I'm 99.98% sure :-)
that "knowing about a CA" means that the RP possesses the certificate
of the CA as part of the cert path being validated, or that the CA's
cert can be validated or is a trust point, or that the RP has some
out-of-band reason to believe that the CA exists.

I have a hard time believing that the law's intent is to require the
use of OCSP-like technology with status codes enabling the OCSP
responder to claim "I know / don't-know about this CA".  The RP's
knowledge is what's important, not a repository/responder's knowledge.

Dave Kemp

--openmail-part-0987991b-00000001--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-part4-03.txt
Date: Wed, 29 Apr 1998 10:01:33 -0400
Sender: [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 
                          Certificate Policy and Certification Practices Framework
	Author(s)	: W. Ford, S. Chokhani
	Filename	: draft-ietf-pkix-ipki-part4-03.txt
	Pages		: 45
	Date		: 28-Apr-98
	
   This  document  presents  a  framework  to  assist  the  writers   of
   certificate   policies   or  certification  practice  statements  for
   certification  authorities  and  public  key   infrastructures.    In
   particular,  the  framework  provides  a comprehensive list of topics
   that potentially (at the writer's discretion) need to be covered in a
   certificate  policy definition or a certification practice statement.
   This document is being submitted to the RFC Editor with a request for
   publication as an Informational RFC.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ipki-part4-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part4-03.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: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ipki-part4-03.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-ipki-part4-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ipki-part4-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 29 Apr 1998 10:35:00 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

> Marc, All:
> 
> I would like to propose we move forward with the following simplified
> construction:
> 
> CertStatusType ::= ENUMERATED {
>     notRevoked     (0),
>     revoked        (1),
>     onHold         (2),
>     unknownCA      (3),
>     unknownCert    (4) }

Mike,

It seems that you are continuing your own track without looking to the
other E-mails.
I have advocated mandatory and optional status and you have not
commented on it.

The following structure would be fine:

CertStatusType ::= ENUMERATED {
   notRevoked     (0),
   revoked        (1),
   onHold         (2),
   unknownCA      (3) }

However " unknownCert    (4)" implies that the cert is accessible by the
OCSP server and would conflict with "notRevoked" when the cert is *not*
accessible by the OCSP server.

Unless there is a further indication that states whether the cert is or
is not accessible, the proposal does not work.

Denis

> In the unknownCA case, a repository may not have acquired information
> necessary to produce any other assertion.  The unknownCert value addresses
> all other states not explicitly address by notRevoked or revoked.  In
> particular, it may be the case that a certain repositories can be proven to
> have only received a subset of a CA's information via mechanisms such as
> CRL Distribution Points, CRLList or other means of delegating authority.
> 
> Mike

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

Date: Tue, 28 Apr 1998 23:53:51 -0400 (EDT)
From: Rich Salz <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

Perhaps "indeterminant" instead of "unknowncert", if it really is intended
to be the catch-all choice.

Date: Tue, 28 Apr 1998 18:26:23 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: OCSP status tally
Sender: [email-masked]

Slava,

Looks like our messages crossed each other on the way to the list where I
had asked for opinions on {revoked, notRevoked, unknown}.  Your proposal
certainly has merit.  It better addresses inclusion of a time value than
the current ASN.1 does and links a generic "revoked" statment more closely
to reasons for the revocation state.  At this point I'd be interested in
hearing what others may think.

Mike

At 05:17 PM 4/28/98 -0700, you wrote:
>
>May I reintroduce my original suggestion to have the following
>RevocationStauts definition with small variations (hoping that after
>numerous discussions we had the intent here will be a little clearer
>this time):
>
>RevocationStatus ::= CHOICE {        
>	unknown      [0] IMPLICIT UnknownInfo,
>        notRevoked   [1] IMPLICIT NULL,
>        revoked      [2] IMPLICIT RevokedInfo,
>
>}
>
>UnknownInfo ::= NULL -- this can be replaced with an enumeration
>                     -- for various specific reasons such as
>doNotKnowAboutCA etc.
>
>RevokedInfo ::= SEQUENCE {
>	revocationTime GeneralizedTime,
>	revocationReason RevocationReason OPTIONAL -- this could include
>"onHold"
>}

Date: Tue, 28 Apr 1998 17:17:17 -0700
From: Slava Galperin <[email-masked]>
Organization: Teknowledge Corporation
To: Michael Myers <[email-masked]>
CC: Marc Branchaud <[email-masked]>, [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

Michael Myers wrote:
> 
> Marc, All:
> 
> I would like to propose we move forward with the following simplified
> construction:
> 
> CertStatusType ::= ENUMERATED {
>     notRevoked     (0),
>     revoked        (1),
>     onHold         (2),
>     unknownCA      (3),
>     unknownCert    (4) }
> 
> In the unknownCA case, a repository may not have acquired information
> necessary to produce any other assertion.  The unknownCert value addresses
> all other states not explicitly address by notRevoked or revoked.  In
> particular, it may be the case that a certain repositories can be proven to
> have only received a subset of a CA's information via mechanisms such as
> CRL Distribution Points, CRLList or other means of delegating authority.
> 

I think it might be reasonable to include revocation reason or
revocation date when sending "revoked" status (and in this case it may
be combined with "onHold" case).
Also various "do not know"s can be folded into single "unknown" response
since it seems unlikely that OCSP requester cares about the difference.

May I reintroduce my original suggestion to have the following
RevocationStauts definition with small variations (hoping that after
numerous discussions we had the intent here will be a little clearer
this time):

RevocationStatus ::= CHOICE {        
	unknown      [0] IMPLICIT UnknownInfo,
        notRevoked   [1] IMPLICIT NULL,
        revoked      [2] IMPLICIT RevokedInfo,

}

UnknownInfo ::= NULL -- this can be replaced with an enumeration
                     -- for various specific reasons such as
doNotKnowAboutCA etc.

RevokedInfo ::= SEQUENCE {
	revocationTime GeneralizedTime,
	revocationReason RevocationReason OPTIONAL -- this could include
"onHold"
}

I would like to stress that if OCSP requester does not care about the
details attached to specific status it can stop after parsing the CHOICE
tag and is not required to parse CHOICE inner content. Therefore for
less sophisticated OCSP requresters this definitions is just as simple
as ENUMERATED whereas more sophisticated ones can take advantage of the
information associated with a particular status code.

--

Slava

Date: Tue, 28 Apr 1998 16:09:57 -0700
To: [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: OCSP status tally
Sender: [email-masked]

Dave,

Someone else may wish to argue for onHold independant of other revocation
reasons, but I'm all for simplicity.  In addition, I wholeheartedly support
your proposed consolidation of unknownCA and unknownCert.  My prior
proposal reflected what I had heard from others on their needs.

So, all:  pending any further debate on the matter, the next rev of OCSP
will specify the following response value structure and content:

At 05:12 PM 4/28/98 -0400, you wrote:
>Might I suggest:
>
>CertStatusType ::= ENUMERATED {
>    notRevoked     (0),
>    revoked        (1),
>    unknown        (2) }
>

Mike

Date: Tue, 28 Apr 1998 16:09:35 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP at IETF
Sender: [email-masked]

Hi All,
    I would like to get closure on all the open issues about OCSP. I
would like to summarize what I felt the group/people were saying about
each of these topics. If you disagree or feel strongly about the
proposed solution, please let me know.

Results under each topic below:

Ambarish Malpani wrote:
> 
> Hi All,
>      Great meeting a whole bunch of you at IETF.
> 
>      I am going to post a set of emails about the issues raised about
> OCSP, to start a set of threads on topics in OCSP.
> 
> Here is a summary of the topics that will be covered in the mails to
> follow:
>
 
>     - OCSP Usage Scenarios (as requested by Steve Kent)
Nothing needed to be resolved.

>     - Status Information on a Certificate
As Mike/Dave suggested, we will allow of the following states:
    notRevoked, revoked, unknown
Syntax to be decided.
There will *not* be an issued/notIssued state.
Right now, I don't think we should include an expired state (Dave?)
Andreas/Alexei, do you think your concerns have been addressed?

>     - Types of OCSP Responders
We will allow all three types of OCSP responders:
    - CA responding
    - Somebody the OCSP querrier decides to trust by out of band means
    - Somebody designated by the CA to issue OCSP responses on its
        behalf. The CA will designate another entity as a
        designated responder by issuing it a certificate with an
        special extension.

>     - Method of identifying certs
Am raising this topic again in a separate mail.

>     - Semantics of thisUpdate, nextUpdate, producedAt
Am raising this topic again in a separate mail.

>     - Extended error states in responses
Don't think we need the extended error responses, other than one
that says the server is busy right now (come back later)

>     - Caching
Am raising this topic again in a separate mail.

> 
> If you have input on any of these topics, please do the the mailing
> list know, so that we can address those concerns ASAP, reach a
> concensus about OCSP and finish up this project.
> 
> Thanks,
> Ambarish
-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

Date: Tue, 28 Apr 1998 16:02:41 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
To: IETF PKIX <[email-masked]>
Subject: [Fwd: [IETF-PKIX] OCSP Status Information on a Certificate]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------062C0D6D7EAC0041641869B6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry, I thought this was going out to the list.

Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303
--------------062C0D6D7EAC0041641869B6
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <[email-masked]>
Date: Tue, 28 Apr 1998 13:04:07 -0700
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
X-Mailer: Mozilla 4.01 [en] (WinNT; U)
MIME-Version: 1.0
To: "David P. Kemp" <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
X-Priority: 3 (Normal)
References: <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Dave,
    Did think about the expired issue for some time - however, if
you don't have a time that you trust on your local machine, how do
you know to trust the time on the OCSP response (the thisUpdate,
nextUpdate, producedAt times).

Regards,
Ambarish

David P. Kemp wrote:
> 
> > From: Marc Branchaud <[email-masked]>
> >
> > So I guess (unless I've forgotten someone) that the tally now stands at:
> >
> >       Issued / Revoked / Expired == 1
> >       Revoked only == 0
> >       Abstain == 1
> >
> 
> Add one for Revoked only, or add a new category Revoked / Expired.
> 
> As before, I don't see any rationale for Issued.
> 
> Expired could be useful if one assumes that the client does not have
> a reliable clock, that the responder does have access to a trusted
> time source, and that the RP uses OCSP for every verification.
> 
> Last month my wife's PC started dating files sometime in 2003 for no
> apparent reason.  The lithium battery was fine, the clock has been
> fine since we reset it, and the machine doesn't have a modem installed
> so it's never been exposed to hackers on the net.  Gamma rays, I guess.
> Anyway, OCSP Expired status may be useful.

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					       (650) 849-9880
ValiCert, Inc.				        [email-masked]
3160 W. Bayshore Road		              http://www.valicert.com
Palo Alto, CA 94303

--------------062C0D6D7EAC0041641869B6--

Date: Tue, 28 Apr 1998 17:12:52 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: OCSP status tally
Sender: [email-masked]

> From: Michael Myers <[email-masked]>
> 
> I would like to propose we move forward with the following simplified
> construction:
> 
> CertStatusType ::= ENUMERATED {
>     notRevoked     (0),
>     revoked        (1),
>     onHold         (2),
>     unknownCA      (3),
>     unknownCert    (4) }

It seems unusual to include a specific status code for "onHold", but
not for any of the other X.509-defined reason codes.  And it seems
unusual to have two codes which mean "unknown" but for different
reasons; is there any business requirement for RPs to make a
distinction between unknownCA and unknownCert?

Might I suggest:

CertStatusType ::= ENUMERATED {
    notRevoked     (0),
    revoked        (1),
    unknown        (2) }

or less enthusiastically, include all the defined codes from CRLReason:

CertStatusType ::= ENUMERATED {
    unknown              (-2),
    notRevoked           (-1),
    revoked (unspecified) (0),
    keyCompromise         (1),
    cACompromise          (2),
    affiliationChanged    (3),
    superseded            (4),
    cessationOfOperation  (5),
    certificateHold       (6) }

> From: Andreas Berger <[email-masked]>
>
> Sorry that I bring that up again: the answer about knowing about a CA
> but not about the referenced certificate would be a good one for use of
> OCSP in the German Signature Law, where such a service is required.

Without knowing both "the law" and the text of this specific law, it's
impossible to be 100% sure of it's intent.  However, I'm 99.98% sure :-)
that "knowing about a CA" means that the RP possesses the certificate
of the CA as part of the cert path being validated, or that the CA's
cert can be validated or is a trust point, or that the RP has some
out-of-band reason to believe that the CA exists.

I have a hard time believing that the law's intent is to require the
use of OCSP-like technology with status codes enabling the OCSP
responder to claim "I know / don't-know about this CA".  The RP's
knowledge is what's important, not a repository/responder's knowledge.

Dave Kemp

To: [email-masked]
Subject: Re: OCSP status tally 
Date: Tue, 28 Apr 1998 12:57:18 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

Sounds good to me.

		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

Michael Myers <[email-masked]> scrawled:
> 
> Marc, All:
> 
> I would like to propose we move forward with the following simplified
> construction:
> 
> CertStatusType ::= ENUMERATED {
>     notRevoked     (0),
>     revoked        (1),
>     onHold         (2),
>     unknownCA      (3),
>     unknownCert    (4) }
> 
> In the unknownCA case, a repository may not have acquired information
> necessary to produce any other assertion.  The unknownCert value addresses
> all other states not explicitly address by notRevoked or revoked.  In
> particular, it may be the case that a certain repositories can be proven to
> have only received a subset of a CA's information via mechanisms such as
> CRL Distribution Points, CRLList or other means of delegating authority.
> 
> Mike
> 

Date: Tue, 28 Apr 1998 12:53:45 -0700
To: Marc Branchaud <[email-masked]>, [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: OCSP status tally
Sender: [email-masked]

Marc, All:

I would like to propose we move forward with the following simplified
construction:

CertStatusType ::= ENUMERATED {
    notRevoked     (0),
    revoked        (1),
    onHold         (2),
    unknownCA      (3),
    unknownCert    (4) }

In the unknownCA case, a repository may not have acquired information
necessary to produce any other assertion.  The unknownCert value addresses
all other states not explicitly address by notRevoked or revoked.  In
particular, it may be the case that a certain repositories can be proven to
have only received a subset of a CA's information via mechanisms such as
CRL Distribution Points, CRLList or other means of delegating authority.

Mike

At 11:51 AM 4/28/98 -0700, Marc Branchaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Content-Type: text/plain; charset=us-ascii
>
>
>Ambarish has reminded me of several other "votes" in favour of OCSP 
>returning revocation status only.  So the current tally is:
>
>	Revoked only == 5
>	Issued / Revoked / Expired == 1
>	Abstain == 1
>
>		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
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNUYlRFrdFXNdDxPlAQES7wMAkgJ65JuIh1A8dc3KcWpvW9uw+OcHvP2Y
>G7F1Rryl7c91L+vGDVTk83cbhHjjC3p9tT0JPdPrSntEkmYQOhJTUFTd/BtcEoh/
>AyPuPaetlBJgKHA2F2vSQxb0RGqF2TJm
>=fwGW
>-----END PGP SIGNATURE-----
>
>

Date: Tue, 28 Apr 1998 15:32:13 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
Sender: [email-masked]

> From: Marc Branchaud <[email-masked]>
> 
> So I guess (unless I've forgotten someone) that the tally now stands at:
> 
> 	Issued / Revoked / Expired == 1
> 	Revoked only == 0
> 	Abstain == 1
> 

Add one for Revoked only, or add a new category Revoked / Expired.

As before, I don't see any rationale for Issued.

Expired could be useful if one assumes that the client does not have
a reliable clock, that the responder does have access to a trusted
time source, and that the RP uses OCSP for every verification.

Last month my wife's PC started dating files sometime in 2003 for no
apparent reason.  The lithium battery was fine, the clock has been
fine since we reset it, and the machine doesn't have a modem installed
so it's never been exposed to hackers on the net.  Gamma rays, I guess.
Anyway, OCSP Expired status may be useful.

To: [email-masked]
Subject: OCSP status tally
Date: Tue, 28 Apr 1998 11:51:49 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

Ambarish has reminded me of several other "votes" in favour of OCSP 
returning revocation status only.  So the current tally is:

	Revoked only == 5
	Issued / Revoked / Expired == 1
	Abstain == 1

		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

To: [email-masked]
Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate 
Date: Tue, 28 Apr 1998 10:53:38 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

"Alexei V. Vopilov" <[email-masked]> scrawled:
> 
> Marc, here are my comments.
> Basically I'm voting for all three (Revoked/Expired/Issued),
> not because of possible clients fatness, but because I can free
> a client from need to have the whole public certificate prior
> to issue OCSP request on it.
> 

That seems a strange requirement to me.  What benefit is there to knowing 
the status of a certificate that you don't have?  The whole reason for 
needing a certificate's status is to be able to trust the public key 
therein.  Without the certificate, you don't have the public key, so what's 
the point?

> Also, I don't think that OSCP must be only online CRL facility.
> Although, the name OSCP claims to deliver something more than
> a 'revoked' status the draft statements declare it _is_ for
> checking a certificate when no proper CRL is available on client
> side. At the same time other draft statements propose to provide
> more information returned for a requestor.
> 

I agree that OCSP has the potential to be more than just a CRL proxy server. 
As for the draft, I can't speak for the authors but I believe that any 
wording about different status types will be changed to reflect the 
discussions on the list.

> Finally, it would be a good idea (IMO) to support in OCSP protocol
> the case when a requestor will elect to _not_ use certificate until
> OCSP responder returns all the statuses as per standard verification
> procedure. Thus, regardless of certificate contents it is considered
> as invalid presumably.
> 

This is Pat's inverted OCSP semantics argument (see the CDP Alternative 
Proposal thread).

> more comments follow...
> 
> -----Original Message-----
> From: Marc Branchaud <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: 16 ai?aey 1998 a. 21:06
> Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
> 
> [ . . .]
> 
> :> Revocation =  "NotAvailable" // cannot access to CRL information
> :>               "UnknownCA"    // cannot access to unknown CA database
> :
> :Well, setting aside the issue of whether multi-valued responses are a good
> :idea or not, I would argue that the above two cases are equivalent.
> :
> :If the responder can't access the proper CRL information, it's because it
> :hasn't collected the CRLs from the CA and so it basically doesn't recognize
> :the CA.  The same argument applies to responders with direct access to a
> :CA's database.
> 
> ALX: Thus, you eliminate _any_ need for OSCP if a party has CRL, containing
> ALX: "next_update" value < present time, right?
> 

No, not at all.  The point is that the "NotAvailable" and "UnknownCA"
revocation status responses are the same.  Your question is about something
else entirely, and I don't agree with it.  If an entity has an expired CRL
(next_update < present_time) then it had better at least attempt some kind of
operation to get fresher revocation information, either through OCSP or a
"traditional" CRL retrieval.

> :Come to think of it, there could be a situation where a responder holds an
> :expired CRL for which it has yet to receive a replacement.  One might argue
> :that a "NotAvailable" response would be OK, but I think it would be better
> :to provide a response based on the expired CRL, perhaps accompanied by some
> :kind of warning.
> 
> ALX: Ok, make the response of bitmask type might work.
> ALX: Unknown CA   = 0
> ALX: Revoked      = 1
> ALX: NotRevoked     = 2
> ALX: NotAvaliable = Revoked|NotRevoked
> ALX: It is the way to provide 'some kind of warning'
> 

I'm interpreting your | to mean logical-OR, in which case your NotAvailable
field is always 1 and doesn't help.  A more appropriate bit would be a
"stale" bit that got set if the responder was forced to use expired
revocation information.

Even better would be a warning that had an indication of just how stale the 
information is, so that the client can better decide whether to accept it.

> :> Expiration =  "NotAvailable" // cannot access to known CA database
> :> _contents_
> :>               "UnknownCA"    // cannot access to unknown CA database
> :
> :Expiration is independent of the contents of a CA's database or even the
> :recognition of the CA by the responder.  The only time the responder would
> :reply with an "unknown" expiration value is if it doesn't actually perform
> :the expiration calculation.  This calculation can be performed for _any_
> :certificate, so whether an unknown response is made is really just a matter
> :of how the responder is configured.
> :So, once again, I think a single kind of "unknown" response is adequate
> :here.
> 
> ALX: IMO, if an entry in CA database is the body of certificate for
> ALX: requested status on, the _almost only_ way to check expiration
> ALX: status is to have access to CA database entry (call it 'contents').
> ALX: NOTE that OCSP v3 does not require for certificate body  be
> ALX: present in the request and  even be available on the requestor side.
> 

I disagree.  I think OCSP assumes that the requestor has the certificate to 
begin with.  Like I said above, I can't imagine why anyone would want to 
know the status of a certificate they don't posess.

> :> Issued     =  "NotAvailable" // cannot access to known CA database
> :> _directory_
> :>               "UnknownCA"    // cannot access to unknown CA database
> :>
> :
> :This is where complexity is justified, because a responder using only CRLs
> :can not know if an unrevoked certificate has ever been issued (revoked
> :certs, on the other hand, are known to have been issued).  So I agree that
> :these two kinds of "unknown" responses are a good thing.  The "NotAvailable"
> :response would be given by responders that only have CRL information (for
> :the given CA).  A responder with direct access to the CA's database
> :shouldn't normally use the "NotAvailable" response.
> 
> ALX: Suppose, Responder has access to CA database. He _is_ able to
> ALX: navigate using serial number and issuer info, but cannot grab the
> ALX: certificate body. In that case it would specify
> ALX: Expired = NotAvailable
> ALX: Issued  = Issued
> 

Again, the need for Expired is based on your assumption that OCSP clients 
might not have the certificate they're querying about.  I don't agree with 
that assumption.

> :> Having this a Responder implementation can support only part of
> :> specification without interoperability problems.
> :> Note there is the difference between "NotAvailable" semantic for
> :> Expiration and Issued statuses.
> :>
> :> Note also that nothing (according to spec design)
> :> prevents implementing an OCSP Responder by extending CRLs
> :> issued by a CA (or by just ignoring them at all).
> :>
> :
> :I'm not sure what you mean by this.  Could you elaborate?
> 
> ALX: OK, suppose my employees are using certificates from VeriXXX
> ALX: issued in country XXX to complete transactions both
> ALX: in XXX and my country (let it be YYY ;-). But 'good days' are
> ALX: over and country XXX want to put all transactions in YYY down by
> ALX: forcing VeriXXX to revoke all it YYY certificates.
> ALX: But my business will not stop while I rely on OCSP that will just
> ALX: ignore bother CRLs from VeriXXX.
> 

I don't see a problem with this scenario.  Your business can also keep going
if it just decides to ignore revocation altogether.  If you're willing to
trust an OCSP responder that ignores CRLs, that's your choice.  IF the
responder is malicious, there's not much you can do anyway.  And if you're
willing to continue to do business with YYY behind XXX's back, that's also
your choice.  A PKI isn't a policing mechanism.

> :As for the bigger picture, I'm still not convinced either way about whether
> :or not OCSP should have multi-valued responses.  I think the extra
> :complexity is manageable, but I also see the appeal of a simpler protocol.
> :It really depends on what people want to do with OCSP.  Are the issued/
> :unissued and expired/unexpired values needed?
> 
> ALX: How many lines of code it would require for supporting all the
> ALX: statuses, assuming an OSCP responder process _more_ than just
> ALX: information from CRLs, i.e. direct CA database access?
> ALX: IMO, 50% Requestors need status to be just "good/bad"
> ALX: while other 50% need to know "why bad"? The second group
> ALX: of requestors tends to be expanded by those from first one
> ALX: who got "unknown" status.
> ALX: If so, the support of just Revoked/NotRevoked/Unknown statuses
> ALX: will (optimistically) serve probably 1% of requestors grabbed
> ALX:  from both groups.
> 

So I guess (unless I've forgotten someone) that the tally now stands at:

	Issued / Revoked / Expired == 1
	Revoked only == 0
	Abstain == 1

		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

From: "Mullar Tim" <[email-masked]>
To: [email-masked]
Subject: OCSP
Date: Tue, 28 Apr 1998 09:45:47 PDT
Sender: [email-masked]

exist an implementation of OCSP Protocol??

Thank you in advance

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From: "Todd Glassey" <[email-masked]>
To: "Stephen P. Wilson" <[email-masked]>, "Warwick Ford" <[email-masked]>
Cc: "Tim Polk" <[email-masked]>, <[email-masked]>, "Stephen Samson" <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for   CRL Distribution Points Patent
Date: Tue, 28 Apr 1998 07:38:49 -0700
Sender: [email-masked]

Yeah Entrust... But there is the bigger issue of the overall ISOC/IESG
Intellectual Properties Policy implemented through the IETF.

The bottom line is that until the IP language is reworded in RFC's 2026 and
2028, this type of occurrence is still possible and this will continue to
cast F.U.D. on our standards.

Todd

-----Original Message-----
From: Stephen P. Wilson <[email-masked]>
To: Warwick Ford <[email-masked]>
Cc: Tim Polk <[email-masked]>; [email-masked] <[email-masked]>;
Stephen Samson <[email-masked]>
Date: Friday, April 24, 1998 1:41 AM
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL
Distribution Points Patent

>Warwick Ford wrote:
>>
>> I also am very pleased to see this move by Entrust.  When can we see
>> the full statement of licensing terms?  Royalty-free is good, but we
>> need to be sure that there are no other problematic terms or
>> conditions associated with the license.
>
>Excuse my ignorance, it's quite possible I'm misunderstanding this (it
>is somewhat confusing to me...) - but, just because they are saying now
>that it's going to be royalty free, doesn't mean that it's always going
>to be royalty free, does it?
>
>Didn't something similar happen with .GIF files? - whereby, after being
>freely "use-able" for a long time, the company with the patent decided
>that anyone using the format should have to pay them royalties.
>
>I'm no legal expert (far from it in fact) - so perhaps I'm making some
>huge assumptions - could someone clarify this for me?
>
>Stephen.
>
>--
>Stephen Wilson. BSc (hons), AMIEE.          [email-masked]
>The views and statements contained in this message are entirely those
>of the author and should not be considered as the opinion or policy
>of any other person or organisation.
>

From: "Linn, John" <[email-masked]>
To: [email-masked], [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: Padding Requirements for RSA signatures
Date: Tue, 28 Apr 1998 09:22:03 -0400
Sender: [email-masked]

Peter wrote, excerpting:

> PKCS #1 already handles OAEP from the SET work (rsaOAEPEncryptionSET, 1 2
> 840
> 113549 1 1 6, according to a different source within RSA this OID was once
> ripemd160WithRsaEncryption), but because there haven't been any updates
> released for several years this isn't generally known (perhaps one of the
> list
> members involved in SET, or someone from RSADSI, could comment on this).
>  
I've now checked the situation with others within RSA Labs who are involved
with PKCS #1, and understand the following:  While the SET work includes
OAEP support, the definition there is somewhat SET-specific.  More
generalized work on OAEP specification is underway (and considered likely
stable) within P1363; it's RSA Labs' intent to issue an update to PKCS #1
later this year including P1363-based OAEP. 

--John Linn, RSA Labs/East.

To: [email-masked]
Subject: Proposed change to OpenCDP proposal.
Date: Mon, 27 Apr 1998 17:36:42 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

Setting aside the "inverted OCSP semantics" debate for a second, as far as 
CRLs go I think OpenCDP is pretty good.

I think section 6 [the Revocation Issuer (RI) extension] needs to have some
text that emphasizes the need for a strong link between the entity named in
the extension and its key.  I proposed to Phill in a private message that the
following text be appended to the section:

  If the original signing key is not used to sign the CRL the client MUST
  ascertain that the signer (i.e. the RI) is trustable for that purpose.
  Clients MAY do this via some out-of-band process, or the CA MAY issue a
  certificate for the RI's key.  In the latter case, the RI SHOULD (MUST?)
  include its certificate in the CRL (using a TBD CRL extension) to prove
  that it has the authority to sign the CRL.

He thought the text was OK, and now we're bringing the dicussion to the list 
so everyone can have a kick at it.

The TBD CRL extension mentioned in the proposed text would simply contain the
certificate for the CRL signer:

	cRLSignerCertificate EXTENSION ::= {
		SYNTAX CRLSignerCertificate
		IDENTIFIED BY id-ce-cRLSignerCertificate
	}

	id-ce-cRLSignerCertificate OBJECT IDENTIFIER ::= {TBD}

	CRLSignerCertificate ::= Certificate

Thoughts?

		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

From: Yang Su Mi <[email-masked]>
Subject: ocsp implementation
To: [email-masked]
Date: Tue, 28 Apr 1998 09:26:34 +0900 (KST)
Sender: [email-masked]

Are any ocsp implementations available?

Thank you very much.
Yang, Soomi

From: [email-masked]
To: [email-masked]
cc: [email-masked]
Date: Mon, 27 Apr 1998 10:27:25 -0700
Subject: Re: CDP Alternative Proposal
Sender: [email-masked]

given that status of certificate is being checked ... then
all that is needed is the certificate id ... and ask whether
that certificate id is still acceptable (the CA signature
on the certificate should be sufficient regarding the
validity of the certificate). then status coming back
is a signed, time-stamped yes/no.

in aads, next step is validation of signed transaction ... where
there isn't a certificate ....  authority validates the
signature, signature status, transaction, and transaction
status (&/or approval).

in business world, hybrids may be possible ... relying party
may have account that provides authority ... but still wants an outside
service to maintain key status (i.e. certificate gives status
at time of manufacter ... as well as some binding between
key-pair and something(?) ... also at time of manufacter ...
question is what are the possible timeliness issues/status
required at time of use.

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Padding Requirements for RSA signatures
From: EKR <[email-masked]>
Date: 27 Apr 1998 08:55:11 -0700
Lines: 13
Sender: [email-masked]

[email-masked] (Peter Gutmann) writes:
> [Speaking of OAEP, has anyone benchmarked the overhead of the padding vs the
>  simpler PKCS #1 padding?  With all the hashing and mangling involved, it looks
>  like the padding could take about as long as the public-key operation]
It's insignificant. In my implementation, less than 2% of the overall
time to do an RSA public key encryption. (And correspondingly much
less of the decryption.)

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Mon, 27 Apr 1998 11:08:46 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: CDP Alternative Proposal
Sender: [email-masked]

> From: "Phillip M Hallam-Baker" <[email-masked]>
> 
> >P.S. The notion of 'inverted OCSP semantics' was/is well understood by
> >parties other than those involved in the CDP draft, just in case we may
> >have to obtain future royalty-free licenses on this 'original research'.
> 
> Oh I think you are quite right. I think we all understood that a CRL 
> would be used to verify the validity of a cert but somehow I had also
> framed this mental model of the relying parties processing CRLs
> to compile a blacklist and checking to see that the certificate
> was not on it. I had not progressed from the idea that a positive
> assertion was what was required to the idea that a positive
> assertion was something  the CRL could and should express.

Traditionally certificates exist to allow offline verification of
public keys/identities/privileges.  CRLs exist to allow certificates to
be constrained (i.e.  revoked) subsequent to their issuance, still
offline.

If one is going to do online verification of public keys ('inverted
OCSP semantics'), what is the point of OCSP in the first place?
It's just another layer of overhead for the poor thin client to
process.
Instead, one should just have the online server return a certificate
signed by the responder which is valid for the intended duration of the
response.  This is not an "Online Certificate Status Protocol", it is
online certification.

A new OCSP status format isn't needed, just use the online-generated
Certificate as the status.

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Padding Requirements for RSA signatures
Date: Mon, 27 Apr 1998 10:01:58 -0400
Sender: [email-masked]

>While there have been improed padding techniques proposed, I am unaware of
>any attacks against PKCS#1 signatures.  They are widely used and
implemented.

Sorry, what I was attempting to explain was the reason why
PKCS#1 is specified the was it is with constants in the
signature field. The substitution attack is an RSA issue that
PKCS#1 addresses not a feasible attack against PKCS#1 RSA.

Regardless this is not an area I think PKIX should venture.
If there is a serious vulnerability discovered then it would
make sense to deprecate an algorithm or packaging format
but the IETF is not in general a good place to develop
cryptographic mechanisms.

        Phill

Date: Sun, 26 Apr 1998 15:01:38 -0400
To: "Phillip M Hallam-Baker" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Padding Requirements for RSA signatures
Cc: [email-masked]
Sender: [email-masked]

While there have been improed padding techniques proposed, I am unaware of
any attacks against PKCS#1 signatures.  They are widely used and implemented.

Russ

At 01:37 PM 4/24/98 -0400, Phillip M Hallam-Baker wrote:
>This is from memory but I think the argument goes as follows.
>
>For signatures one important attack that has to be considered 
>is the substitution attack. Consider the case in which I might be 
>able to induce someone to sign a bit sequence which contained
>random bits that in one context were simply ignored but in another
>context might carry some semantic info.
>
>There is also the problem of using the same associative 
>properties Chaum uses to create blind cash to transform one
>signed message into another. Unless the unused bits have 
>some determinate value there is the risk that someone 
>would induce another to sign a value which when unblinded
>authenticated another document.
>
>
>There are better packaging formats than the PKCS#1 in 
>current use. Phil Rogaway has made a number of proposals
>in this area. I am not up to date on where they have reached
>although I remember commenting on them a year or two ago 
>when they were reviewed at MIT.
>
>I don't think we should attempt to develop cryptographic
>packaging in PKIX. That is an area where I think we need
>to leave it to other groups. In the specific case of RSA I
>think this is something we can reasonably expect RSA
>labs to take the lead noting of course that their work
>is subject to peer review through the academic litterature,
>discussion lists, conferences etc.
>
>It is a good point and the list should generally be aware 
>that the PKCS#1 standard may well be upgraded in
>the near future. But implementations still need to be 
>aware of the format currently in use.
>
>        Phill
>
>-----Original Message-----
>From: Andreas Berger <[email-masked]>
>To: pkix <[email-masked]>
>Date: Friday, April 24, 1998 9:13 AM
>Subject: Padding Requirements for RSA signatures
>
>
>>Hi,
>>
>>in Section 7.2.1 in the first part of PKIX the padding is fixed to the
>>methods stated in PKCS#1:
>>
>>"Padding conventions described in PKCS #1, section 8.1, must be used."
>>
>>Since fixed padding seems to have disadvantages when used in SmartCards
>>(i.e. Bellcore attack), a random component in the padding is usually
>>proposed for digital signature applications. German DIN (standards
>>organization) proposes exactly this for the cryptographic devices that
>>are to be supported with the German Signature Law. PKCS#1 is supported
>>as long as the Smartcards perform a double check before giving a reply
>>with the signature.
>>
>>Interesting enough, a random component is proposed in PKCS#1 for
>>encryption (in my understanding of 8.1).
>>
>>So my question is: is this requirement of the PKCS#1 style fixed padding
>>for signatures specifically intended? Is this gorup open to, let's say
>>one or two, other padding formats?
>>
>>Andreas
>>-- 
>>Erst kommt das Fressen, dann kommt die Moral
>> -- Bertolt Brecht
>>
> 

From: "Alexei V. Vopilov" <[email-masked]>
To: <[email-masked]>
Subject: Repost:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
Date: Mon, 27 Apr 1998 02:04:43 +0400
Sender: [email-masked]

Marc, here are my comments.
Basically I'm voting for all three (Revoked/Expired/Issued),
not because of possible clients fatness, but because I can free
a client from need to have the whole public certificate prior
to issue OCSP request on it.

Also, I don't think that OSCP must be only online CRL facility.
Although, the name OSCP claims to deliver something more than
a 'revoked' status the draft statements declare it _is_ for
checking a certificate when no proper CRL is available on client
side. At the same time other draft statements propose to provide
more information returned for a requestor.

Finally, it would be a good idea (IMO) to support in OCSP protocol
the case when a requestor will elect to _not_ use certificate until
OCSP responder returns all the statuses as per standard verification
procedure. Thus, regardless of certificate contents it is considered
as invalid presumably.

more comments follow...

-----Original Message-----
From: Marc Branchaud <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 16 ai?aey 1998 a. 21:06
Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate

[ . . .]

:> Revocation =  "NotAvailable" // cannot access to CRL information
:>               "UnknownCA"    // cannot access to unknown CA database
:
:Well, setting aside the issue of whether multi-valued responses are a good
:idea or not, I would argue that the above two cases are equivalent.
:
:If the responder can't access the proper CRL information, it's because it
:hasn't collected the CRLs from the CA and so it basically doesn't recognize
:the CA.  The same argument applies to responders with direct access to a
:CA's database.

ALX: Thus, you eliminate _any_ need for OSCP if a party has CRL, containing
ALX: "next_update" value < present time, right?

:Come to think of it, there could be a situation where a responder holds an
:expired CRL for which it has yet to receive a replacement.  One might argue
:that a "NotAvailable" response would be OK, but I think it would be better
:to provide a response based on the expired CRL, perhaps accompanied by some
:kind of warning.

ALX: Ok, make the response of bitmask type might work.
ALX: Unknown CA   = 0
ALX: Revoked      = 1
ALX: NotRevoked     = 2
ALX: NotAvaliable = Revoked|NotRevoked
ALX: It is the way to provide 'some kind of warning'

:> Expiration =  "NotAvailable" // cannot access to known CA database _contents_
:>               "UnknownCA"    // cannot access to unknown CA database
:
:Expiration is independent of the contents of a CA's database or even the
:recognition of the CA by the responder.  The only time the responder would
:reply with an "unknown" expiration value is if it doesn't actually perform
:the expiration calculation.  This calculation can be performed for _any_
:certificate, so whether an unknown response is made is really just a matter
:of how the responder is configured.
:So, once again, I think a single kind of "unknown" response is adequate
:here.

ALX: IMO, if an entry in CA database is the body of certificate for
ALX: requested status on, the _almost only_ way to check expiration
ALX: status is to have access to CA database entry (call it 'contents').
ALX: NOTE that OCSP v3 does not require for certificate body  be
ALX: present in the request and  even be available on the requestor side.

:> Issued     =  "NotAvailable" // cannot access to known CA database
_directory_
:>               "UnknownCA"    // cannot access to unknown CA database
:>
:
:This is where complexity is justified, because a responder using only CRLs
:can not know if an unrevoked certificate has ever been issued (revoked
:certs, on the other hand, are known to have been issued).  So I agree that
:these two kinds of "unknown" responses are a good thing.  The "NotAvailable"
:response would be given by responders that only have CRL information (for
:the given CA).  A responder with direct access to the CA's database shouldn't
:normally use the "NotAvailable" response.

ALX: Suppose, Responder has access to CA database. He _is_ able to
ALX: navigate using serial number and issuer info, but cannot grab the
ALX: certificate body. In that case it would specify
ALX: Expired = NotAvailable
ALX: Issued  = Issued

:> Having this a Responder implementation can support only part of
:> specification without interoperability problems.
:> Note there is the difference between "NotAvailable" semantic for
:> Expiration and Issued statuses.
:>
:> Note also that nothing (according to spec design)
:> prevents implementing an OCSP Responder by extending CRLs
:> issued by a CA (or by just ignoring them at all).
:>
:
:I'm not sure what you mean by this.  Could you elaborate?

ALX: OK, suppose my employees are using certificates from VeriXXX
ALX: issued in country XXX to complete transactions both
ALX: in XXX and my country (let it be YYY ;-). But 'good days' are
ALX: over and country XXX want to put all transactions in YYY down by
ALX: forcing VeriXXX to revoke all it YYY certificates.
ALX: But my business will not stop while I rely on OCSP that will just
ALX: ignore bother CRLs from VeriXXX.

:As for the bigger picture, I'm still not convinced either way about whether
:or not OCSP should have multi-valued responses.  I think the extra
:complexity is manageable, but I also see the appeal of a simpler protocol.
:It really depends on what people want to do with OCSP.  Are the issued/
:unissued and expired/unexpired values needed?

ALX: How many lines of code it would require for supporting all the
ALX: statuses, assuming an OSCP responder process _more_ than just
ALX: information from CRLs, i.e. direct CA database access?
ALX: IMO, 50% Requestors need status to be just "good/bad"
ALX: while other 50% need to know "why bad"? The second group
ALX: of requestors tends to be expanded by those from first one
ALX: who got "unknown" status.
ALX: If so, the support of just Revoked/NotRevoked/Unknown statuses
ALX: will (optimistically) serve probably 1% of requestors grabbed
ALX:  from both groups.

:I do think they're more marginal.  If the cert's signature verifies, then
:it's a good bet that the cert was issued.  As for expiration, a client would
:have to be pretty thin to not have a clock.

ALX: I would say yes, but the question is does Expiration and Issuing
ALX: Certificate Status protocols will never be the scope of PKIX?
ALX: If not, can OSCP manage the complexity to integrate this stuff in?
:Marc
regards,
--Alexei

Date: Sun, 26 Apr 1998 14:30:06 -0400
To: Stephen Samson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL Distribution Points Patent
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

I applaud this action.

This action obviously removes all of the issues associated with the CRL
Distribution Point extension.  However, the press release text does not
answer the question that I posted to the IETF-PKIX list in January. It is
not completely clear (at least to me) if this statement applies to all of
the Internet private extensions that were included in draft versions of
PKIX Part 1 while Warwick was employeed at Entrust.

Can we please be provided with a complete list of certificate extensions
that are covered by the patent and are now available royalty-free?  I would
like to see this list included in the Patent Statement from Nortel/Entrust
at the end of PKIX Part 1.

Russ

At 11:28 AM 4/23/98 -0400, Stephen Samson wrote:
>Members of the IETF community;
>
>In response to your concerns, Entrust Technologies is pleased to announce
>that rights in its US Patent 5,699,431 will be licensed on a royalty-free
>basis. The entire announcement can be found on the Entrust Technologies
>website, by following the attached link:
>
>http://www.entrust.com/news/1998/04_23_98.htm
>
>For more information, contact
>
>Steve Samson
>
>Entrust Technologies Inc.
>750 Heron Rd.,  8th Floor
>Ottawa, Ontario, Canada, K1V 1A7
>
>voice:			613-247-3725
>fax:			613-247-3412
>email:			[email-masked]
>Entrust Validation String:	SCKM-HQDL-X75G
> 

From: Santosh Chokhani <[email-masked]>
To: "[email-masked]'" <[email-masked]>, IETF-PXIX <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Key identifiers
Date: Fri, 24 Apr 1998 21:47:04 -0400
Sender: [email-masked]

I have two comments on Denis and Dave's interactions:

1.  The use of authority key identifier extension where the key idenfier
is a bit string (as opposed to DN(authority parent), serial number) will
NOT lead to a false rejection of a valid path.  Denis is incorrect in
that.

2.  We do have a full path development algorithm.  It works very well
for the hierarchies in terms of computational complexity).  It works
well (as optimized as can be with my knowledge of today's technology)
for network environment in terms of computational complexity.  It does
not have a great deal of software complexity.  In summer, to answer Dave
Kemp's question, we do have a certificate path development algorithm.

> -----Original Message-----
> From:	Denis Pinkas [SMTP:[email-masked]]
> Sent:	Thursday, April 23, 1998 7:14 PM
> To:	IETF-PXIX
> Subject:	Re: Key identifiers
> 
> > > = Denis Pinkas 
> >   = David P. Kemp
> 
> > > The reality is that for discovering a path, you might have to walk
> up
> > > and down, but the verification should only be done "walking down".
> This
> > > means that no digital signature verification should be done before
> > > getting one or more candidate paths down.
> > 
> > Part 1 Section 6 states that conforming implementations must perform
> > path validation in a manner which achieves identical results to the
> > given procedure, which takes as input a full cert path and works
> > from top to bottom.
> > 
> > But I don't see how following this procedure saves on signature
> > computations:  for every point at which there is a choice of
> issuers,
> > you need a disambiguator.  That is either a signature verification
> or
> > something which gives a shortcut answer without ever giving a false
> > reject.  Heuristics such as validity checking (against the target
> date
> > only, NOT for issuer-subject validity nesting!) might help in a very
> > few cases.
> 
> In most cases you will have the saving. The only case where you will
> not
> have the saving is when two CAs will have the same name (whether that
> name is a DN or an alternate name). This case should be very seldom
> but
> might exist. For that very seldom case, I do not think that we need
> additional mandatory parameters that every CA shall support and that
> takes some space in the certificate.  
> 
> >           AuthorityKeyIdentifier will allow you to reject all
> > inappropriate candidates, but it takes up space in the certs, as you
> > say.  Another, more radical, approach would be to define new
> > AlgorithmOIDs which include a one octet checkword in the signature
> > value, which could be compared against a specific high-entropy octet
> of
> > the authority public key.  This would eliminate 255/256 of the
> > unnecessary signature verifications.  NB: I'm not advocating this
> > approach, just using it as an illustration of a hack which could
> > improve pathbuilding efficiency without costing much space.
> > 
> > > > I have one problem with this approach: The verification path is
> not
> > > > fixed. Let us assume a CA gets certified by a set of other CAs.
> Some
> > > > users trust one of them, others some other CAs (which is why the
> CA
> > > > probably got this multiple certificates). When a user
> certificate
> > > > contains a reference to a single other CA, a user which does not
> trust a
> > > > specific CA will fail to verify the certificate, although there
> might be
> > > > a another path which would lead to a successful verification.
> > >
> > > I support this comment. This means that placing the key identifier
> will
> > > create failures in cases where successful verification could have
> be
> > > done applying a different approach.
> > 
> > I don't understand this comment.  If an entity has a certificate
> signed
> > by a particular issuer, that certificate will have the identifier of
> that
> > issuer's key.  A certificate from a different issuer will have a
> different
> > key identifier.  In what case will a key identifier cause a reject
> where
> > the signature would otherwise have verified correctly?
> 
> The problem is that the link is pointing *back* to a particular cert
> of
> a CA. A CA may have its signing public key signed by more than one CA.
> In that case the end-entity will point to only one of these certs
> which
> may end up to an intrusted point for the receiver. Using a different
> cert for the key of the CA could end up to a trusted point for the
> receiver. This is why you may end up with a reject.
> 
> > > > One question: Do we have an algorithm for a complete
> verification? There
> > > > is one that describes how to verify an existing FC path, but do
> we have
> > > > an algorithm on how to construct a path?
> > >
> > > We currently don't and we probably should define one.
> > 
> > Yes.  Santosh?
> > 
> > Dave Kemp
> 
> 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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Padding Requirements for RSA signatures
Reply-To: [email-masked]
Date: Sat, 25 Apr 1998 13:03:01 (NZST)
Sender: [email-masked]

>On the yea side is the argument that if the spec does not allow for a block
>padding format which gives the DIN a "warm fuzzy feeling", then there are
>potential problems reconciling PKIX with German Signature Law. On the nay side
>is the argument that it is outside the scope of the PKIX charter to define its
>own encryption block formats, and that people concerned with the quality of
>DIN's emotional experiences should lobby RSA Labs to include something similar
>to OAEP which should protect against low exponent attacks made popular by
>Coppersmith. (Of course, my personal opinion on this one is that PKCS#1 is
>fine, and if you're using a public exponent of 3, you get what you deserve.)
 
PKCS #1 already handles OAEP from the SET work (rsaOAEPEncryptionSET, 1 2 840
113549 1 1 6, according to a different source within RSA this OID was once
ripemd160WithRsaEncryption), but because there haven't been any updates
released for several years this isn't generally known (perhaps one of the list
members involved in SET, or someone from RSADSI, could comment on this).
 
At the moment there are three main padding choices:
 
1. PKCS #1 (signature or encryption).
2. ISO 9796 (signature).
3. OAEP (encryption).
 
The problem with moving away from PKCS #1 is that nothing of any significance
supports any of the alternatives, and unless you can persuade a large number of
vendors to add support for something which they may or may not perceive as
adding any value, changing the block padding will mean your certs fail to
verify with most software.
 
If either 9796 or OAEP are added, it'd be nice to have some fairly complete
test vectors for both available somewhere, with the complexity involved in
these padding types it's likely there'll be all sorts of interesting 
interpretations of the standard around once multiple vendors get into the act.
 
[Speaking of OAEP, has anyone benchmarked the overhead of the padding vs the
 simpler PKCS #1 padding?  With all the hashing and mangling involved, it looks
 like the padding could take about as long as the public-key operation]
 
Peter.

Date: Fri, 24 Apr 1998 15:24:08 -0700 (PDT)
From: Number Twenty-Three <[email-masked]>
Subject: Re: Padding Requirements for RSA signatures
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

<PRE>
At the risk of flogging a dead horse, let me add  my two cents to this
thread. It seems  to  me that  the  question is, "should PKIX  specify
encryption block formats?" On the yea side is the argument that if the
spec does not allow  for a block padding  format which gives the DIN a
"warm  fuzzy feeling", then  there  are potential problems reconciling
PKIX with  German Signature Law. On the  nay side is the argument that
it  is  outside  the  scope of  the PKIX  charter   to define  its own
encryption block formats, and  that people concerned with the  quality
of DIN's  emotional   experiences should  lobby RSA  Labs  to  include
something similar  to OAEP which  should protect  against low exponent
attacks  made popular by Coppersmith. (Of  course, my personal opinion
on  this  one is that PKCS#1   is fine, and  if  you're using a public
exponent of 3, you get what you deserve.)

I  would   propose that  somewhere in  the  family  of PKIX  drafts is
included a list   of "acceptable" block   formats. We  might even  say
something    like: "compliant   implementations  MUST  support  PKCS#1
formats,  and they  SHOULD (or  MAY)  support  OAEP."  I imagine  that
VeriSign's concern  is  that if the   standard mandates something like
OAEP, they (and  most likely GTE, Thawte,   [fill in the  name of your
favorite commercial CA  here], et al) will have  a bit of  recoding to
do. A concern that I can certainly understand.

I agree  with Phill  that DEFINING  new  block padding formats  may be
outside   the scope of    the PKIX charter.   However,  I  am somewhat
sympathetic to Andreas' concerns. I don't think it's outside the scope
of PKIX to list "acceptable" block padding formats.  Some might have a
problem with "acceptable",  in which  case the  word "known" might  be
substituted.

I propose   that buried  somewhere  in  one of  the  drafts  a list be
maintained similar to:

  * You MUST support PKCS#1 block type 1. (See PKCS#1)
  * You SHOULD support OAEP. (See X9.44, P1363, or SET)
  * You MAY support PKCS#1 block type 0. (See PKCS#1)

In  this way, the   standard addresses the concerns   of the DIN,  and
allows  those of us who can  live with PKCS#1 block  types to live our
lives in a state  of bliss, not having to  immediately add support for
OAEP to our products. Should someone wish  to implement a system which
is compatible with German signature law, they can include support OAEP
in thier application profile.

In the future, when RSA Labs includes OAEP, or something like OAEP
into PKCS#1, the spec can be ammended to include:

  * You SHOULD support PKCS#1 block type 3

Assuming that  block type 3 is  the OAEPish thing we're discussing. If
Labs is really working on this, then  the worst that  can happen is we
get  two definitions that overlap. If  they're not working on it, then
our friends in Germany get to use OAEP or  an OAEP-like padding scheme
that gives them a "warm fuzzy feeling" sometime this millenium.

The  next  question is where  are the  OIDs  for these things defined?
PKCS#1 block  format 1 is implied  in  the RSAWithMD5, RSAWithMD2, and
RSAWithSHA  OIDs defined   in the  RSA  OID  space. I'm  assuming that
there's an OAEP OID  lurking out there  somewhere, just waiting to  be
used. Or, if we're really masochistic, we could apply to IANA(?) for a
branch in OID space reserved for PKIX. This would, of course, probably
break every known current implementation, so maybe it's not THAT great
of an idea...

-- Alzo spracht Phillip M Hallam-Baker <[email-masked]>:
] This is from memory but I think the argument goes as follows.
] For signatures one important attack that has to be considered 
] is the substitution attack. Consider the case in which I might be 
] able to induce someone to sign a bit sequence which contained
] random bits that in one context were simply ignored but in another
] context might carry some semantic info.
] 
] There is also the problem of using the same associative 
] properties Chaum uses to create blind cash to transform one
] signed message into another. Unless the unused bits have 
] some determinate value there is the risk that someone 
] would induce another to sign a value which when unblinded
] authenticated another document.
] 
] 
] There are better packaging formats than the PKCS#1 in 
] current use. Phil Rogaway has made a number of proposals
] in this area. I am not up to date on where they have reached
] although I remember commenting on them a year or two ago 
] when they were reviewed at MIT.
] 
] I don't think we should attempt to develop cryptographic
] packaging in PKIX. That is an area where I think we need
] to leave it to other groups. In the specific case of RSA I
] think this is something we can reasonably expect RSA
] labs to take the lead noting of course that their work
] is subject to peer review through the academic litterature,
] discussion lists, conferences etc.
] 
] It is a good point and the list should generally be aware 
] that the PKCS#1 standard may well be upgraded in
] the near future. But implementations still need to be 
] aware of the format currently in use.
] 
]         Phill
] 
] -----Original Message-----
] From: Andreas Berger <[email-masked]>
] To: pkix <[email-masked]>
] Date: Friday, April 24, 1998 9:13 AM
] Subject: Padding Requirements for RSA signatures
] 
] 
] >Hi,
] >
] >in Section 7.2.1 in the first part of PKIX the padding is fixed to the
] >methods stated in PKCS#1:
] >
] >"Padding conventions described in PKCS #1, section 8.1, must be used."
] >
] >Since fixed padding seems to have disadvantages when used in SmartCards
] >(i.e. Bellcore attack), a random component in the padding is usually
] >proposed for digital signature applications. German DIN (standards
] >organization) proposes exactly this for the cryptographic devices that
] >are to be supported with the German Signature Law. PKCS#1 is supported
] >as long as the Smartcards perform a double check before giving a reply
] >with the signature.
] >
] >Interesting enough, a random component is proposed in PKCS#1 for
] >encryption (in my understanding of 8.1).
] >
] >So my question is: is this requirement of the PKCS#1 style fixed padding
] >for signatures specifically intended? Is this gorup open to, let's say
] >one or two, other padding formats?
] >
] >Andreas
] >-- 
] >Erst kommt das Fressen, dann kommt die Moral
] > -- Bertolt Brecht
] >
</PRE>

<br><HR SIZE=1><TABLE BORDER=0><TR><TD><IMG SRC="http://www.woc.org/public/Matthew-Hamrick/images/matt/matthumb.jpg" HEIGHT=160 WIDTH=120 ALT="[Matt]" LOWSRC="http://www.woc.org/public/Matthew-Hamrick/images/matt/matthumblo.gif" ALIGN="top"></TD><TD VALIGN=top><A HREF="http://www.woc.org/public/Matthew-Hamrick/index.html"><FONT SIZE=4><I>Matthew S. Hamrick</I></FONT></A><BR><FONT SIZE=2>[email-masked]</FONT><BR><FONT SIZE="1">Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.<BR>Iä! Shub-Niggurath! Narrathoth! Narrathoth! Narrathoth!</FONT></TD></TABLE>

<hr size=1><b>DO YOU YAHOO!?</b><br>Get your free @yahoo.com address at <a href="http://mail.yahoo.com">Yahoo! Mail</a>.<br>

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Pat Richard" <[email-masked]>
Cc: "Flanigan, Bill" <[email-masked]>, <[email-masked]>
Subject: Re: CDP Alternative Proposal
Date: Fri, 24 Apr 1998 16:13:31 -0400
Sender: [email-masked]

>P.S. The notion of 'inverted OCSP semantics' was/is well understood by
>parties other than those involved in the CDP draft, just in case we may
>have to obtain future royalty-free licenses on this 'original research'.
>
>:-)) 
>
>(okay, I admit that last paragraph was a bit harsh, but what am I
>supposed to beleive anymore ?)

Oh I think you are quite right. I think we all understood that a CRL 
would be used to verify the validity of a cert but somehow I had also
framed this mental model of the relying parties processing CRLs
to compile a blacklist and checking to see that the certificate
was not on it. I had not progressed from the idea that a positive
assertion was what was required to the idea that a positive
assertion was something  the CRL could and should express.

In other words the 'realisation' was that I personally had been 
thinking about the problem in the wrong way entirely. The 
realisation was PHB getting unwedged. I certainly did not
want to imply that everyone else was wedged in the first place.

I now think that the idea of putting the scope into the CRL is 
something that is actually quite fundamental. If we had sat
down to design X.509 from scratch when Phil Zimmerman
unwedged us from the strict hierarchy with the UN secretary
general as root type mindset I think scoping is something
we would have put in as entirely obvious.

Although my attention had been directed to the problem
by certain CDP issues I don't think that there is in fact a 
conflict. I see them as being complimentary, CDPs provide
the location of a CRL, scopes allow dynamic control of the 
CRL size.

The current draft was written before we knew the Entrust
patent might be available on acceptable terms and so there
are parts which are specifically drafted to avoid patent 
infringement. That was not the principle point of the draft 
however (although I admit it was sort of the point of the title).

I agree that we need to have another look at OCSP. But
even here I think the need for a local distribution point 
for status info in addition to CRLs has not been understood.

Think of OCSP as an Intranet resource along with the DNS 
server. The scoped CRL model means that it is quite
realistic to have a local OCSP responder pulling CRLs
from a distribution center as needed. Under the old
model OCSP still had the problem of being forced to be 
a pre-push system rather than a DNS-like on demand pull.

            Phill

Date: Fri, 24 Apr 1998 12:23:00 -0700
From: Pat Richard <[email-masked]>
To: Sharon Boeyen <[email-masked]>
CC: [email-masked], Jeff Schiller <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL D istribution Points Patent
Sender: [email-masked]

I guess I mean "more optional", as in "not in the draft going to last
call"...

:-))

There are alternatives to using distribution points - if their
functionality is critical to the system then we should work to define
alternative structures - and if it is not then we should remove it. I
thought we had all spent a lot of brainpower thinking about how to get
on without them....

-Pat

Sharon Boeyen wrote:
> 
> Pat, this  was an optional element in PKIX prior to L.A. as it also is in
> the base X.509 standard.
>

From: Sharon Boeyen <[email-masked]>
To: [email-masked], "'Pat Richard'" <[email-masked]>
Cc: Jeff Schiller <[email-masked]>
Subject: RE: Entrust Technologies Announces Royalty-free License for CRL D istribution Points Patent
Date: Fri, 24 Apr 1998 14:51:13 -0400
Sender: [email-masked]

Pat, this  was an optional element in PKIX prior to L.A. as it also is in
the base X.509 standard. 

> ----------
> From: 	Pat Richard[SMTP:[email-masked]]
> Sent: 	April 24, 1998 2:11 PM
> To: 	[email-masked]
> Cc: 	Jeff Schiller
> Subject: 	Re: Entrust Technologies Announces Royalty-free License for
> CRL Distribution Points Patent
> 
> Tim Polk wrote:
> ...
> >   As the patent encumbrances have been removed, I now
> > intend to leave these extensions in the specification.
> 
> 
> While I wholeheartedly champion the un-emcumbrance of the technology
> (which we all agreed to remove from the all the drafts at the LA
> meeting), I shudder that anyone wishing to comply with an RFC document
> will have to be an Entrust "licensee". This brings other questions to
> mind - even if you disregard the idea that you may want to not be an
> Entrust licensee - like what protection is there from a legal
> perspective surrounding protection from possible Entrust policy changes
> in the future (even if the license is "perpetual") ?
> 
> I suggest that since we have scoped the effort required to take it out,
> and some have already taken it out of their drafts, that we continue to
> do so, and make the use of distribution points completely and entirely
> optional.
> 
> 
> > Thanks,
> > 
> > Tim Polk
> 
> 

Date: Fri, 24 Apr 1998 11:21:41 -0700
From: Pat Richard <[email-masked]>
To: "Phillip M. Hallam-Baker" <[email-masked]>
CC: "Flanigan, Bill" <[email-masked]>, [email-masked]
Subject: Re: CDP Alternative Proposal
Sender: [email-masked]

Phillip M. Hallam-Baker wrote:
> ...
> 
> This is an Internet draft based on original research by Warwick and
> myself.
> 
> ...
> Last week we realised that the problem with CRLs was not
> issuing the revocation info but the implicit assertion each CRL contains
> that all other certificates are valid. 
> ....

To re-phrase the 'realization', the default assertion in the current
OCSP model is one of validity, or that certs are 'valid
unless proven invalid' (which is what the previous drafts implied,
perhaps not by intent, but implied).

In any case, IMHO a lot of the 'kludges' currently ongoing in the OCSP
space are relative to the initial intent of making the OCSP model an
online 'replica' (so to speak) of CRLs (perhaps by virtue of existing
CRL expertise), which, by nature, are inherently late and inherently
flawed (by the implicit assumption of status).

To get more to the point, at the LA IETF I specifically questioned the
interpretation of certificate validity in the OCSP model (where we
assume a cert is valid until provn invalid) and I suggested an inversion
in the default semantics of an OCSP response, which is to assume invalid
until proven valid (and we can control participation in either CRL
(pro-valid) or online (pro-invalid) models by policy - that when using a
CRL use the old semantics, that when using OCSP, use inverted
semantics).

In addition, the notion of 'invalid unless proven valid' has merit when
there is an ongoing dispute. In other words (as experienced by other
real-world protocol implementors)
in the case of a disputed response, where one responder to a query
returns true, and another of equal weight returns false, what is the
correct value? For implementors to follow the most basic, indirect,
non-policy burdened logic: In the 'valid unless proven invalid model',
TRUE is accepted. In the 'invalid unless proven valid' model, FALSE is
accepted. 

Where is the text that addresses this most basic issue ? We seem to keep
issuing more and more kludges to work around the most basic flaw in the
CRL model. Invert the semantics. Why not implement it properly from the
ground up ?

P.S. The notion of 'inverted OCSP semantics' was/is well understood by
parties other than those involved in the CDP draft, just in case we may
have to obtain future royalty-free licenses on this 'original research'.

:-)) 

(okay, I admit that last paragraph was a bit harsh, but what am I
supposed to beleive anymore ?)

-Pat

> 
> A simple solution to CRL partitioning therefore is to embed a
> statement in each CRL specifying the CRL population it relates to.
> The issuer is not bound to chose a particular partitioning scheme
> in advance. Indeed the issuer could decide to issue CRLs of a
> particular length, say 100 certificates and chose the scoping
> constraints accordingly.
> 
> We think this is a better approach than hardwiring distribution points
> into certificates as per the Entrust patent claims.
> 
> Given that the area director has told us to jettison the encumbered
> technology so that part 1 can go to the IESG I don't think there is any
> dispute about the importance of this issue.
> 
>         Phill

Date: Fri, 24 Apr 1998 11:11:32 -0700
From: Pat Richard <[email-masked]>
To: [email-masked]
CC: Jeff Schiller <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL Distribution Points Patent
Sender: [email-masked]

Tim Polk wrote:
...
>   As the patent encumbrances have been removed, I now
> intend to leave these extensions in the specification.

While I wholeheartedly champion the un-emcumbrance of the technology
(which we all agreed to remove from the all the drafts at the LA
meeting), I shudder that anyone wishing to comply with an RFC document
will have to be an Entrust "licensee". This brings other questions to
mind - even if you disregard the idea that you may want to not be an
Entrust licensee - like what protection is there from a legal
perspective surrounding protection from possible Entrust policy changes
in the future (even if the license is "perpetual") ?

I suggest that since we have scoped the effort required to take it out,
and some have already taken it out of their drafts, that we continue to
do so, and make the use of distribution points completely and entirely
optional.

> Thanks,
> 
> Tim Polk

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Andreas Berger" <[email-masked]>, "pkix" <[email-masked]>
Subject: Re: Padding Requirements for RSA signatures
Date: Fri, 24 Apr 1998 13:37:08 -0400
Sender: [email-masked]

This is from memory but I think the argument goes as follows.

For signatures one important attack that has to be considered 
is the substitution attack. Consider the case in which I might be 
able to induce someone to sign a bit sequence which contained
random bits that in one context were simply ignored but in another
context might carry some semantic info.

There is also the problem of using the same associative 
properties Chaum uses to create blind cash to transform one
signed message into another. Unless the unused bits have 
some determinate value there is the risk that someone 
would induce another to sign a value which when unblinded
authenticated another document.

There are better packaging formats than the PKCS#1 in 
current use. Phil Rogaway has made a number of proposals
in this area. I am not up to date on where they have reached
although I remember commenting on them a year or two ago 
when they were reviewed at MIT.

I don't think we should attempt to develop cryptographic
packaging in PKIX. That is an area where I think we need
to leave it to other groups. In the specific case of RSA I
think this is something we can reasonably expect RSA
labs to take the lead noting of course that their work
is subject to peer review through the academic litterature,
discussion lists, conferences etc.

It is a good point and the list should generally be aware 
that the PKCS#1 standard may well be upgraded in
the near future. But implementations still need to be 
aware of the format currently in use.

        Phill

-----Original Message-----
From: Andreas Berger <[email-masked]>
To: pkix <[email-masked]>
Date: Friday, April 24, 1998 9:13 AM
Subject: Padding Requirements for RSA signatures

>Hi,
>
>in Section 7.2.1 in the first part of PKIX the padding is fixed to the
>methods stated in PKCS#1:
>
>"Padding conventions described in PKCS #1, section 8.1, must be used."
>
>Since fixed padding seems to have disadvantages when used in SmartCards
>(i.e. Bellcore attack), a random component in the padding is usually
>proposed for digital signature applications. German DIN (standards
>organization) proposes exactly this for the cryptographic devices that
>are to be supported with the German Signature Law. PKCS#1 is supported
>as long as the Smartcards perform a double check before giving a reply
>with the signature.
>
>Interesting enough, a random component is proposed in PKCS#1 for
>encryption (in my understanding of 8.1).
>
>So my question is: is this requirement of the PKCS#1 style fixed padding
>for signatures specifically intended? Is this gorup open to, let's say
>one or two, other padding formats?
>
>Andreas
>-- 
>Erst kommt das Fressen, dann kommt die Moral
> -- Bertolt Brecht
>

Date: Fri, 24 Apr 1998 11:53:10 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked]
Subject: Re: Comment on PKIX-1 - cRLSign
Sender: [email-masked]

> From: "Simonetti David" <[email-masked]>
> 
> Section 4.2.1.3, Key Usage, includes a paragraph on page 25 describing
> the cRLSign bit, "This bit may only be asserted in CA certificates."
>
>   ...
> 
> I suggest the statement on page 25 be removed.

I agree that this sentence should be removed from the description of
the cRLSign bit, because it is desirable to allow revocation
authorities to be separate from certificate authorities, or to allow a
CA to use different keys to sign certificates (perhaps offline) and
revocation information (which happens more frequently, and presumably
online).

In addition, I hesitate to suggest a modification to the first sentence
if it would delay the publication of Part 1, but we may wish to
change:

  "The cRLSign bit is asserted when the subject public key is used for
   verifying a signature on CRLs."

to:
 
  "...
   verifying a signature on revocation information."

which would extend the use of this bit to enable signed OCSP responses
in addition to CRLs.

Date: Fri, 24 Apr 1998 10:41:01 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [IETF-PKIX] Comments on pkix-ipki-part1
Sender: [email-masked]

>>>>> "Peter" == Peter Gutmann <[email-masked]> writes:
>...
 Peter> There's no need to actually drop T61String.  All you need to
 Peter> do is say something like the following:
 
 Peter> "Where T61String is used it shall be restricted to contain
 Peter> only printable 8859-1 characters.  Shift and escape sequences
 Peter> and control codes shall not be used".

Sounds good.
 
 Peter> (it may be necessary to define "printable character" to "the
 Peter> range 0x20-0x7E and 0xA1-0xFE").

Yes, it's a good idea to define it -- but 0xFF is also a printable
character in 8859-1.

	paul

Date: Fri, 24 Apr 1998 09:13:16 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

> From: [email-masked]
> 
> You can't really avoid doing it.  If a CA issues CRL[n] which expires at
> time T, when is it supposed to issue CRL[n+1]?  At time T?  If so, then end
> systems won't have any valid revocation lists from time T until after
> whatever propagation delay the CRL distribution mechanism imposes (which
> may be dependent on directory replication schedules, HTTP proxy caching
> policy or any number of other things, many of which are outside the control
> of either the CA or the end-system).  So a CA really is forced to issue
> CRL[n+1] at some time before the previous CRL is set to expire.  So during
> that period, an end-system will have some uncertainty as to whether it has
> the absolute latest CRL.  But this is only a problem if verifiers have
> unrealistic expectations regarding what CRLs offer.

I agree with this analysis and the conclusion that CAs must routinely
issue CRL[n+1] at some time before nextUpdate of CRL[n].

I just wanted to point out that it is undesirable to base a system
on the assumption that CRLs can have long validity periods (say one
month) and may also support timely revocation (say 8 hours) by
issuing CRLs[n+1], [n+2], ... [n+k] while CRL[n] is still valid.

If the business requirement is for 8 hour freshness, then the CA's
policy should be something like issue CRLs with 8 hour validity every
4 hours.

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Stephen P. Wilson" <[email-masked]>, "Warwick Ford" <[email-masked]>
Cc: "Tim Polk" <[email-masked]>, <[email-masked]>, "Stephen Samson" <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for   CRL Distribution Points Patent
Date: Fri, 24 Apr 1998 09:20:33 -0400
Sender: [email-masked]

>Excuse my ignorance, it's quite possible I'm misunderstanding this (it
>is somewhat confusing to me...) - but, just because they are saying now
>that it's going to be royalty free, doesn't mean that it's always going
>to be royalty free, does it?
>
>Didn't something similar happen with .GIF files? - whereby, after being
>freely "use-able" for a long time, the company with the patent decided
>that anyone using the format should have to pay them royalties.
>
>I'm no legal expert (far from it in fact) - so perhaps I'm making some
>huge assumptions - could someone clarify this for me?

That is a very good point. Moreover there is an issue of precedent
here as well as the specifics of this claim. This issue is not whether
or not Entrust is trustworthy but whether a precedent is set which
might be raised by a more malicious party.

I am just reading through a patent application which has on the
'Inventor' list an MIT professor. The patent essentially claims the
core technologies of Lotus Notes replication system, Kerberos
and proxy gateway and has a filing date of 1995.

The assignee of that particular patent has recently been issue 
other patents with similarly broad claims. Now forgive me if
I am a tired old cynic but I for one would not be willing to accept
license terms which forced me to license all my technology 
in return for access to the patents already issued. If I were say
IBM and I did so I would have unilaterally disarmed and would 
have no recourse were the other patent to be issued.

Fortunately International patents have to be published before
they are issued and I for one will be informing the alledged
inventors of a substantial quantity of prior art. 

The Entrust situation is very different, but even so the question 
the IESG is likely to consider as most important is precedence.

This is not really the place to have a general discussion of
the inequities of the US patent system however. Until the
Entrust terms are known there is not much usefull discussion
to be had on the subject.

        Phill

Date: Fri, 24 Apr 1998 15:02:25 +0200
From: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
To: pkix <[email-masked]>
Subject: Padding Requirements for RSA signatures
Sender: [email-masked]

Hi,

in Section 7.2.1 in the first part of PKIX the padding is fixed to the
methods stated in PKCS#1:

"Padding conventions described in PKCS #1, section 8.1, must be used."

Since fixed padding seems to have disadvantages when used in SmartCards
(i.e. Bellcore attack), a random component in the padding is usually
proposed for digital signature applications. German DIN (standards
organization) proposes exactly this for the cryptographic devices that
are to be supported with the German Signature Law. PKCS#1 is supported
as long as the Smartcards perform a double check before giving a reply
with the signature.

Interesting enough, a random component is proposed in PKCS#1 for
encryption (in my understanding of 8.1).

So my question is: is this requirement of the PKCS#1 style fixed padding
for signatures specifically intended? Is this gorup open to, let's say
one or two, other padding formats?

Andreas
-- 
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Date: Fri, 24 Apr 1998 09:41:25 +0100
From: "Stephen P. Wilson" <[email-masked]>
Organization: Defence Evaluation & Research Agency.
To: Warwick Ford <[email-masked]>
CC: Tim Polk <[email-masked]>, [email-masked], Stephen Samson <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for  CRL Distribution Points Patent
Sender: [email-masked]

Warwick Ford wrote:
> 
> I also am very pleased to see this move by Entrust.  When can we see 
> the full statement of licensing terms?  Royalty-free is good, but we 
> need to be sure that there are no other problematic terms or 
> conditions associated with the license.

Excuse my ignorance, it's quite possible I'm misunderstanding this (it
is somewhat confusing to me...) - but, just because they are saying now
that it's going to be royalty free, doesn't mean that it's always going
to be royalty free, does it?

Didn't something similar happen with .GIF files? - whereby, after being
freely "use-able" for a long time, the company with the patent decided
that anyone using the format should have to pay them royalties.

I'm no legal expert (far from it in fact) - so perhaps I'm making some
huge assumptions - could someone clarify this for me?

Stephen.

-- 
Stephen Wilson. BSc (hons), AMIEE.          [email-masked] 
The views and statements contained in this message are entirely those 
of the author and should not be considered as the opinion or policy 
of any other person or organisation.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: [IETF-PKIX] Comments on pkix-ipki-part1
Reply-To: [email-masked]
Date: Fri, 24 Apr 1998 16:25:08 (NZST)
Sender: [email-masked]

[This is a collection of several messages into one]
 
>Peter Gutmann wrote:
>>4.2.1.2.
>>
>>This gives the subject key identifier as the hash of the
>>subjectPublicKeyInfo *without* the tag and length.
>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.
 
I think Nada Cicovic summed up the point I was trying to make very well:
 
>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.
 
The public key is already encoded as an ASN.1 structure (usually a sequence), 
so all that removing the tag + length from the start does is create an awkward 
special-case requirement and add complexity to the spec.
 
[The RFC 2247 issue]
 
>Since we have a rfc which deals with using internet domain names within a
>distinguished name, it would seem rather strange that a subsequent IETF
>standard would exclude the use of this rfc on the grounds of what names the
>ITU support. From my simple perspective all we have to do is add domain
>component to the list of supported attributes in a general name.
 
I've seen an equal balance of messages either way, so I'll add my own $0.02 to 
try and tip the balance against DN components.  Since there's already a 
mechanism for encoding any type of Internet-related name (a GeneralName), 
there's no need for DN components, because all they are is a means of stuffing 
what's normally contained in a UR{I|L} into a DN.  GeneralNames provide the 
ability to encode more than just a DNS name, don't require breaking it up into 
components, and don't pollute the DN.  The only argument I can see for DN 
components is when you're being forced to use X.509v1 which doesn't support 
extensions with GeneralNames.
 
[And now the big one...]
 
>The TeletexString and UniversalString are included for backward compatibility,
>and should not be used for certificates for new subjects.
 
I think deprecating T61String entirely (presumably based on my long "it 
doesn't work" posting of a few weeks back) is throwing out the baby with the 
bathwater. You can make it work provided you constrain the way it's used.  
There are several problems with dropping T61String:
 
1. PrintableString has such a severaly crippled character set that even many
   normal ASCII strings (this sentence, for example) can't be encoded in it.
   By dropping T61String, a lot of ASCII strings are unnecessarily blown out to
   two-byte BMPStrings.
 
2. Most of Europe will be negatively affected by this change, since killing
   T61String means they're virtually forced to use BMPString in all their
   certs, even though it's not really necessary.
 
   (A chorus of harrumphing from European list members would be appropriate
    here).
 
3. By forcing people to BMPString, you might end up causing more problems than
   you solve.  Everything on earth (even DOS, with the right codepage) supports
   8859-1.  Support for BMPString/Unicode is still very patchy, will never
   happen for a great many OS's which are still widely used but no longer
   supported by vendors (Windows 3.x, any older version of Unix, etc), and
   apparently has uncertain support in HTML and HTML tools (how would you
   display a BMPString from a cert on a web page?).
 
There's no need to actually drop T61String.  All you need to do is say
something like the following:
 
"Where T61String is used it shall be restricted to contain only printable
 8859-1 characters.  Shift and escape sequences and control codes shall not be
 used".
 
(it may be necessary to define "printable character" to "the range 0x20-0x7E
and 0xA1-0xFE").
 
This means you can automatically assume that a T61String is 8859-1, which gets 
you automatic support in pretty much any OS, all web browsers, and most other 
situations where it's likely to be useful.  Detecting non-conformance is also 
relatively easy, just check for anything funny which falls outside the 
acceptable range.
 
Peter.

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: FW: [IETF-PKIX] Subject/Issuer Name Population
Date: Thu, 23 Apr 1998 18:41:57 -0700
Sender: [email-masked]

My apologies -- I sent this to the wrong list.  That'll teach me to just
do a "reply" during mailing list transitions.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

> -----Original Message-----
> From:	Blake Ramsdell 
> Sent:	Thursday, April 23, 1998 6:13 PM
> To:	'IETF X.509-based public key infrastructure mailing list'
> Subject:	RE: [IETF-PKIX] Subject/Issuer Name Population
> 
> On Friday, April 17, 1998 7:42 AM, Tim Polk [SMTP:[email-masked]]
> wrote:
> > Please take the time to review the text.
> 
> I may have missed something in this, so I apologize if this is a dumb
> question.
> 
> The encoding rules for DirectoryString from 4.1.2.4 in your proposed
> text are:
> 
> >      (a) if the character set is sufficient, the string will be
> >      represented as a PrintableString;
> >
> >      (b) failing (a), if the BMPString character set is sufficient
> the
> >      string shall be represented as a BMPString; and
> >
> >      (c) failing (a) and (b), the string shall be represented as a
> >      UTF8String.
> 
> Is the assumption that a PKIX application is more likely to understand
> BMPString before UTF8String?  It seems like a waste to have to go to
> BMPString just because you want to encode something outside of
> PrintableString, but if it's for compatibility then I can understand
> the rationale.
> 
> If it's not for compatibility, then I suggest that we go ahead with
> UTF8String unless I missed something.
> 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> 

From: "Todd Glassey" <[email-masked]>
To: "Warwick Ford" <[email-masked]>, "Tim Polk" <[email-masked]>, <[email-masked]>, "Stephen Samson" <[email-masked]>, "Robert Moskowitz" <[email-masked]>
Cc: "poised WG" <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for   CRL Distribution Points Patent
Date: Thu, 23 Apr 1998 15:52:12 -0700
Sender: [email-masked]

This is a multi-part message in MIME format.

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

This effort is very commendable and addresses this specific issue but not
the policy that is the root cause of the problem.  While this is a clear
statement from Entrust that they want to play by the verbally agreed rules
it does not inhibit or eliminate the potential problem.

If the IETF is to continue being what it has been, that is a standards
agency that promotes leading edge-rather vision than lagging-edge
implementations and PKIX in particular), like some of the other major
standards bodies, this issue of IP management needs to be addressed. The
IETF (Through the Poised WG) needs to have a specific and exact policy for
dealing with IP issues, a policy that is much less ambiguous to current IP
laws and Processes. It, this updated policy, needs to be publicly stated and
agreed upon by all developers submitting to the IETF for comments or
standardization.

I would actually suggest that the submitters of drafts, rfc's or standards
proposals, by submitting them convey a limited power of attorney in the
matter of the technology and maybe we create a new class of standards to
appease the corporate "parents". I personally believe that this
arms-distance approach is necessary to further cement and solidify the
ISOC's position through the efforts of its disconnected children, the IESG
and its IETF. IMHO - A statement from the IETF regarding its vision and the
need for a policy like this to indemnify the ISOC/IESG/IETF itself are very
much in order

Todd

-----Original Message-----
From: Robert Moskowitz <[email-masked]>
To: Warwick Ford <[email-masked]>; Tim Polk <[email-masked]>;
[email-masked] <[email-masked]>; Stephen Samson
<[email-masked]>
Date: Thursday, April 23, 1998 11:04 AM
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL
Distribution Points Patent

>At 01:04 PM 4/23/98 -0700, Warwick Ford wrote:
>
>I spoke with John Ryan about this directly yesterday.  I don't think we
>will need much to get the exact wording of terms out.  I am right now
>testing out a few IPsec products that specifically care about this, so stay
>tuned...
>
>>I also am very pleased to see this move by Entrust.  When can we see the
>>full statement of licensing terms?  Royalty-free is good, but we need to
be
>>sure that there are no other problematic terms or conditions associated
>>with the license.
>>
>>Assuming that turns out all clear, then the profile can certainly proceed
>>immediately to Proposed Standard with CDPs and the other extensions and
>>policy qualifiers reinstated.
>>
>>We would also like to continue study of OpenCDP on the ietf-pkix list --
>>there are some features here that look very valuable and that we may want
>>to include in a follow-up standard.
>>
>>Warwick
>>
>>
>>At 11:57 AM 4/23/98 -0400, Tim Polk wrote:
>>>
>>>I was delighted to see Steve's email.  Perhaps we can put patents and
>>>politics behind us and move on to building and deploying security
>>>solutions.  In that light:
>>>
>>>At the LA meeting, I proposed to remove two certificate extensions (crl
>>>distribution points and authority info access) and two crl extensions
>>>(issuing distribution point and certificate issuer) from the profile
>>>forwarded to the IESG.  This decision was based entirely on IP issues,
not
>>>technical merit.  As the patent encumbrances have been removed, I now
>>>intend to leave these extensions in the specification.
>>>
>>>Thanks,
>>>
>>>Tim Polk
>>>
>>>At 11:28 AM 4/23/98 -0400, you wrote:
>>>>Members of the IETF community;
>>>>
>>>>In response to your concerns, Entrust Technologies is pleased to
announce
>>>>that rights in its US Patent 5,699,431 will be licensed on a
royalty-free
>>>>basis. The entire announcement can be found on the Entrust Technologies
>>>>website, by following the attached link:
>>>>
>>>>http://www.entrust.com/news/1998/04_23_98.htm
>>>>
>>>>For more information, contact
>>>>
>>>>Steve Samson
>>>>
>>>>Entrust Technologies Inc.
>>>>750 Heron Rd.,  8th Floor
>>>>Ottawa, Ontario, Canada, K1V 1A7
>>>>
>>>>voice: 613-247-3725
>>>>fax: 613-247-3412
>>>>email: [email-masked]
>>>>Entrust Validation String: SCKM-HQDL-X75G
>>>>
>>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>>[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>>---------------------------------------------------------------------
>>
>>
>Robert Moskowitz
>ICSA
>Security Interest EMail: [email-masked]
>

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

------=_NextPart_000_013D_01BD6ECF.C811FE70--

Date: Thu, 23 Apr 1998 12:04:00 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: [IETF-PKIX] Subject/Issuer Name Population
Sender: [email-masked]

At 09:20 AM 4/23/98 -0400, [email-masked] wrote:
>i)  This may invalidate certificates that are currently deployed.
>Since printableString is such a limited character set (a..z,
>A..Z, 0..9 plus a few punctuation characters, not including
>"@", "!" or "_"), many deployed certificates will currently
>use either teletexString or universalString, but since X.520
>matching rules are supposed to be in effect, there is no
>reason to suppose that equivalent names in existing
>certificates will match under a binary comparison.

I haven't looked at the X.520 matching rules, but I wonder how they could
cover universalString. The character set for universalString is ISO 10646
in UCS-4 mode (4 bytes per character). I don't believe that ISO 10646
defines case-matching rules, nor does it have a list of spacing characters,
so doing case-folding and space stripping would have to use local rules,
meaning lack of interoperability. Note that case mapping and spaces are
defined in Unicode, but only in non-normative tables, so we can't even look
there for guidance.

>ii)  The preferred ordering of printableString, bmpString and
>utf8String is problematic.  Since almost anything that might
>ever appear in a name attribute is going to reside within the
>BMP character-set, utf8String will hardly ever be used, so this
>really comes down to a choice between printableString and
>bmpString; utf8String will never actually be used if this
>ordering is used.  This is a pity, since utf8String is
>actually a very implementation-friendly codeset, in that
>it's identical to 7-bit ASCII for characters that can be
>represented in 7-bit ASCII, it doesn't use embedded null
>octets, so code can use regular null-terminated C-strings to
>store and manipulate it, it is designed so that it won't
>break 8-bit clean code that scans for 7-bit ASCII values,
>and it's efficient in terms of the number of octets used
>to encode a given string.

I agree fully, except for that last part. UTF8String is not efficient for
all characters; in specific, it takes 3 bytes to encode all Indic and Asian
scripts, which can be encoded in 2 bytes in BMPString. On the whole,
however, I also support UTF8String over BMPString for the other factors you
list.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Stephen Samson <[email-masked]>
To: [email-masked]
Subject: FW: Entrust Technologies Announces Royalty-free License for  CRL  Distribution Points Patent
Date: Thu, 23 Apr 1998 14:38:38 -0400
Sender: [email-masked]

Details of non-financial license terms will be made public next week.

> ----------
> From: 	Warwick Ford[SMTP:[email-masked]]
> Sent: 	23 April, 1998 4:04 PM
> To: 	Tim Polk; [email-masked]; Stephen Samson
> Subject: 	Re: Entrust Technologies Announces Royalty-free License for
> CRL Distribution Points Patent
> 
> I also am very pleased to see this move by Entrust.  When can we see the
> full statement of licensing terms?  Royalty-free is good, but we need to
> be
> sure that there are no other problematic terms or conditions associated
> with the license.
> 
> Assuming that turns out all clear, then the profile can certainly proceed
> immediately to Proposed Standard with CDPs and the other extensions and
> policy qualifiers reinstated.
> 
> We would also like to continue study of OpenCDP on the ietf-pkix list --
> there are some features here that look very valuable and that we may want
> to include in a follow-up standard.
> 
> Warwick
> 
> 
> At 11:57 AM 4/23/98 -0400, Tim Polk wrote:
> >
> >I was delighted to see Steve's email.  Perhaps we can put patents and
> >politics behind us and move on to building and deploying security
> >solutions.  In that light:
> > 
> >At the LA meeting, I proposed to remove two certificate extensions (crl
> >distribution points and authority info access) and two crl extensions
> >(issuing distribution point and certificate issuer) from the profile
> >forwarded to the IESG.  This decision was based entirely on IP issues,
> not
> >technical merit.  As the patent encumbrances have been removed, I now
> >intend to leave these extensions in the specification.
> >
> >Thanks,
> >
> >Tim Polk
> >
> >At 11:28 AM 4/23/98 -0400, you wrote:
> >>Members of the IETF community;
> >>
> >>In response to your concerns, Entrust Technologies is pleased to
> announce
> >>that rights in its US Patent 5,699,431 will be licensed on a
> royalty-free
> >>basis. The entire announcement can be found on the Entrust Technologies
> >>website, by following the attached link:
> >>
> >>http://www.entrust.com/news/1998/04_23_98.htm
> >>
> >>For more information, contact
> >>
> >>Steve Samson
> >>
> >>Entrust Technologies Inc.
> >>750 Heron Rd.,  8th Floor
> >>Ottawa, Ontario, Canada, K1V 1A7
> >>
> >>voice:			613-247-3725
> >>fax:			613-247-3412
> >>email:			[email-masked]
> >>Entrust Validation String:	SCKM-HQDL-X75G
> >>
> >>
> >
> >
> 
> ---------------------------------------------------------------------
> Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
> [email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
> ---------------------------------------------------------------------
>  
> 

Date: Thu, 23 Apr 1998 13:59:28 -0400
To: Warwick Ford <[email-masked]>, Tim Polk <[email-masked]>, [email-masked], Stephen Samson <[email-masked]>
From: Robert Moskowitz <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for   CRL Distribution Points Patent
Sender: [email-masked]

At 01:04 PM 4/23/98 -0700, Warwick Ford wrote:

I spoke with John Ryan about this directly yesterday.  I don't think we
will need much to get the exact wording of terms out.  I am right now
testing out a few IPsec products that specifically care about this, so stay
tuned...

>I also am very pleased to see this move by Entrust.  When can we see the
>full statement of licensing terms?  Royalty-free is good, but we need to be
>sure that there are no other problematic terms or conditions associated
>with the license.
>
>Assuming that turns out all clear, then the profile can certainly proceed
>immediately to Proposed Standard with CDPs and the other extensions and
>policy qualifiers reinstated.
>
>We would also like to continue study of OpenCDP on the ietf-pkix list --
>there are some features here that look very valuable and that we may want
>to include in a follow-up standard.
>
>Warwick
>
>
>At 11:57 AM 4/23/98 -0400, Tim Polk wrote:
>>
>>I was delighted to see Steve's email.  Perhaps we can put patents and
>>politics behind us and move on to building and deploying security
>>solutions.  In that light:
>> 
>>At the LA meeting, I proposed to remove two certificate extensions (crl
>>distribution points and authority info access) and two crl extensions
>>(issuing distribution point and certificate issuer) from the profile
>>forwarded to the IESG.  This decision was based entirely on IP issues, not
>>technical merit.  As the patent encumbrances have been removed, I now
>>intend to leave these extensions in the specification.
>>
>>Thanks,
>>
>>Tim Polk
>>
>>At 11:28 AM 4/23/98 -0400, you wrote:
>>>Members of the IETF community;
>>>
>>>In response to your concerns, Entrust Technologies is pleased to announce
>>>that rights in its US Patent 5,699,431 will be licensed on a royalty-free
>>>basis. The entire announcement can be found on the Entrust Technologies
>>>website, by following the attached link:
>>>
>>>http://www.entrust.com/news/1998/04_23_98.htm
>>>
>>>For more information, contact
>>>
>>>Steve Samson
>>>
>>>Entrust Technologies Inc.
>>>750 Heron Rd.,  8th Floor
>>>Ottawa, Ontario, Canada, K1V 1A7
>>>
>>>voice:			613-247-3725
>>>fax:			613-247-3412
>>>email:			[email-masked]
>>>Entrust Validation String:	SCKM-HQDL-X75G
>>>
>>>
>>
>>
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>---------------------------------------------------------------------
> 
>
Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Date: Thu, 23 Apr 1998 13:04:39 -0700
To: Tim Polk <[email-masked]>, [email-masked], Stephen Samson <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for  CRL Distribution Points Patent
Sender: [email-masked]

I also am very pleased to see this move by Entrust.  When can we see the
full statement of licensing terms?  Royalty-free is good, but we need to be
sure that there are no other problematic terms or conditions associated
with the license.

Assuming that turns out all clear, then the profile can certainly proceed
immediately to Proposed Standard with CDPs and the other extensions and
policy qualifiers reinstated.

We would also like to continue study of OpenCDP on the ietf-pkix list --
there are some features here that look very valuable and that we may want
to include in a follow-up standard.

Warwick

At 11:57 AM 4/23/98 -0400, Tim Polk wrote:
>
>I was delighted to see Steve's email.  Perhaps we can put patents and
>politics behind us and move on to building and deploying security
>solutions.  In that light:
> 
>At the LA meeting, I proposed to remove two certificate extensions (crl
>distribution points and authority info access) and two crl extensions
>(issuing distribution point and certificate issuer) from the profile
>forwarded to the IESG.  This decision was based entirely on IP issues, not
>technical merit.  As the patent encumbrances have been removed, I now
>intend to leave these extensions in the specification.
>
>Thanks,
>
>Tim Polk
>
>At 11:28 AM 4/23/98 -0400, you wrote:
>>Members of the IETF community;
>>
>>In response to your concerns, Entrust Technologies is pleased to announce
>>that rights in its US Patent 5,699,431 will be licensed on a royalty-free
>>basis. The entire announcement can be found on the Entrust Technologies
>>website, by following the attached link:
>>
>>http://www.entrust.com/news/1998/04_23_98.htm
>>
>>For more information, contact
>>
>>Steve Samson
>>
>>Entrust Technologies Inc.
>>750 Heron Rd.,  8th Floor
>>Ottawa, Ontario, Canada, K1V 1A7
>>
>>voice:			613-247-3725
>>fax:			613-247-3412
>>email:			[email-masked]
>>Entrust Validation String:	SCKM-HQDL-X75G
>>
>>
>
>

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

Date: Thu, 23 Apr 1998 12:35:16 -0400
From: "Simonetti David" <[email-masked]>
Organization: BAH
To: Tim Polk <[email-masked]>, IETF-PKIX <[email-masked]>
Subject: Comment on PKIX-1 - cRLSign
Sender: [email-masked]

Section 4.2.1.3, Key Usage, includes a paragraph on page 25 describing
the cRLSign bit, "This bit may only be asserted in CA certificates."

The draft OpenCDP includes an extension, REVOCATION ISSUER EXTENSION,
used by a CA to indicate that it has delegated authority to one or more
other entities to issue and sign CRLs or sign OCSP responses on its
behalf.  Additionally, the ill-fated issuingDistributionPoint extension
allowed a CRL issuer other than a CA.

I suggest the statement on page 25 be removed.
-- 
David Simonetti, Booz·Allen & Hamilton Inc.

Date: Thu, 23 Apr 1998 11:57:29 -0400
To: [email-masked], Stephen Samson <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: Re: Entrust Technologies Announces Royalty-free License for CRL Distribution Points Patent
Cc: Jeff Schiller <[email-masked]>, Steve Kent <[email-masked]>, Warwick Ford <[email-masked]>, [email-masked], "Housley, Russ" <[email-masked]>
Sender: [email-masked]

I was delighted to see Steve's email.  Perhaps we can put patents and
politics behind us and move on to building and deploying security
solutions.  In that light:
 
At the LA meeting, I proposed to remove two certificate extensions (crl
distribution points and authority info access) and two crl extensions
(issuing distribution point and certificate issuer) from the profile
forwarded to the IESG.  This decision was based entirely on IP issues, not
technical merit.  As the patent encumbrances have been removed, I now
intend to leave these extensions in the specification.

Thanks,

Tim Polk

At 11:28 AM 4/23/98 -0400, you wrote:
>Members of the IETF community;
>
>In response to your concerns, Entrust Technologies is pleased to announce
>that rights in its US Patent 5,699,431 will be licensed on a royalty-free
>basis. The entire announcement can be found on the Entrust Technologies
>website, by following the attached link:
>
>http://www.entrust.com/news/1998/04_23_98.htm
>
>For more information, contact
>
>Steve Samson
>
>Entrust Technologies Inc.
>750 Heron Rd.,  8th Floor
>Ottawa, Ontario, Canada, K1V 1A7
>
>voice:			613-247-3725
>fax:			613-247-3412
>email:			[email-masked]
>Entrust Validation String:	SCKM-HQDL-X75G
>
>

From: Stephen Samson <[email-masked]>
To: [email-masked]
Cc: Jeff Schiller <[email-masked]>, Steve Kent <[email-masked]>, Tim Polk <[email-masked]>, Warwick Ford <[email-masked]>
Subject: Entrust Technologies Announces Royalty-free License for CRL Distr ibution Points Patent
Date: Thu, 23 Apr 1998 11:28:12 -0400
Sender: [email-masked]

Members of the IETF community;

In response to your concerns, Entrust Technologies is pleased to announce
that rights in its US Patent 5,699,431 will be licensed on a royalty-free
basis. The entire announcement can be found on the Entrust Technologies
website, by following the attached link:

http://www.entrust.com/news/1998/04_23_98.htm

For more information, contact

Steve Samson

Entrust Technologies Inc.
750 Heron Rd.,  8th Floor
Ottawa, Ontario, Canada, K1V 1A7

voice:			613-247-3725
fax:			613-247-3412
email:			[email-masked]
Entrust Validation String:	SCKM-HQDL-X75G

Date: Thu, 23 Apr 1998 11:24:24 -0400
From: "Simonetti David" <[email-masked]>
Organization: BAH
To: IETF-PKIX <[email-masked]>
Subject: Entrust® Technologies Offers Free License of Patented Technology
Sender: [email-masked]

Does this have an affect on the current efforts on Part 1?

Press release at http://www.entrust.com/news/1998/04_23_98.htm

-- 
David Simonetti, Booz·Allen & Hamilton Inc.

From: [email-masked]
To: [email-masked]
Date: Thu, 23 Apr 1998 10:50:14 -0400
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

[email-masked] (David P. Kemp) wrote:

>Carl Ellison has a colorful description of CRLs which are not
>required by the verifier: wandering anti-matter which may or
>may not happen to collide with the revoked certificates in
>time to prevent them from being used.  PKIX should not
>encourage the "statistical revocation" approach, and should
>point out the dangers of using it, as Paul has done in his
>Security Considerations text.

>Mike left out the obvious solution to the problem: just don't do it.
>PKIX does not prohibit CAs from issuing CRLs before the nextUpdate of a
>prior CRL, but the policy of individual CAs should take into account
>the trustworthiness and reliability of the distribution mechanism when
>deciding how to set nextUpdate and whether to ever issue interim CRLs.
>The no-brainer approach is to assume that revocation distribution is
>completely untrustworthy and expire the revocation information often
>enough that there is no motivation to issue interim information.

You can't really avoid doing it.  If a CA issues CRL[n] which expires at
time T, when is it supposed to issue CRL[n+1]?  At time T?  If so, then end
systems won't have any valid revocation lists from time T until after
whatever propagation delay the CRL distribution mechanism imposes (which
may be dependent on directory replication schedules, HTTP proxy caching
policy or any number of other things, many of which are outside the control
of either the CA or the end-system).  So a CA really is forced to issue
CRL[n+1] at some time before the previous CRL is set to expire.  So during
that period, an end-system will have some uncertainty as to whether it has
the absolute latest CRL.  But this is only a problem if verifiers have
unrealistic expectations regarding what CRLs offer.

The thisUpdate and nextUpdate fields should be viewed as a policy statement
by the CA that certificates revoked after the thisUpdate time may still be
verifiable by some end systems until nextUpdate.  That doesn't prohibit the
CA from issuing an updated CRL earlier, particularly if it knows that a
compromise has occurred (indeed, I would expect a CA to do so - it
corresponds to the real world concept of making a good-faith attempt to
notify subscribers to the CA of the compromise).  It simply means that it
can't provide any assurance that the new revocation list will supersede the
current one for all end-systems until after the current CRL's nextUpdate.

John

Date: Thu, 23 Apr 1998 16:40:06 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Andreas Berger <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: [IETF-PKIX] Subject/Issuer Name Population
Sender: [email-masked]

Andreas Berger wrote:

> Tim Polk wrote:

> > I have attached proposed text for the issuer and subject name sections.
> >
> > Highlights:
> >
> > (1) issuer name is required (that is, may not be an empty SEQUENCE).

> Do we need this or can we loosen it a little? I am thinking of CAs that
> just have DNS name (which is also hierarchical and unique and thus
> similar to a DN)? Should we say that the name should be globally unique
> and that only on alternative name should be present if the DN is empty?

I support this approach.

> > (2) subject name is required for CA certs.  (This means you never chain off
> > altnames!)

> see above.

The same.

(further text deleted)

Regards,

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

From: [email-masked]
To: [email-masked]
Date: Thu, 23 Apr 1998 09:20:18 -0400
Subject: Re: [IETF-PKIX] Subject/Issuer Name Population
Sender: [email-masked]

---------------------- Forwarded by John Wray/Iris on 04/23/98 09:17 AM
---------------------------

John Wray
04/22/98 10:43 AM

To:   "IETF X.509-based public key infrastructure mailing list"
      <[email-masked]>
cc:
Subject:  Re: [IETF-PKIX] Subject/Issuer Name Population  (Document link
      not converted)

Tim Polk <[email-masked]> on 04/17/98 10:42:00 AM,  wrote:

>I have attached proposed text for the issuer and subject name sections.
>
>Highlights:
>
>(1) issuer name is required (that is, may not be an empty SEQUENCE).
>(2) subject name is required for CA certs.  (This means you never chain
off
>altnames!)
>(3) Name comparison rules are greatly relaxed from the X.520 text.  Binary
>comparison of attribute values is permitted for everything except
>PrintableString. That is, no white space compression or case conversion in
>BMP or UTF8.
>
>(Rationale for PrintableString:  It has already been implemented, and is
>used in practically all certificates.  Upper and lowercase country codes,
>etc. will break if we don't support it.)

(1) and (2) above are fine.  However, the proposed text for (3) has
several problems.

Restatement of the proposal:

   A DirectoryString is now permitted to be a choice of printableString,
   teletexString, universalString, utf8String and bmpString, and PKIX
   implementations have to be able to understand certificates whose
   names use any of these syntaxes.   When generating certificates,
   use printableString if the string to be encoded fits in the
   printableString character-set, otherwise use bmpString if the
   string fits in the bmpString charset, otherwise use utf8String.

   Also, instead of X.520 matching rules (which depend on the attribute
   type, not the string syntax chosen, although for almost all reasonable
   attributes they turn out to be caseIgnoreString), define new matching
   rules based on the string syntax, such that attribute values encoded
   using printableString shall use caseIgnoreString matching rules, whereas
   attribute values using any other string syntax shall use binary
   matching.
   Attribute values that use different string syntaxes shall never match,
   regardless of their contents.

I have several issues with this.

i)  This may invalidate certificates that are currently deployed.
Since printableString is such a limited character set (a..z,
A..Z, 0..9 plus a few punctuation characters, not including
"@", "!" or "_"), many deployed certificates will currently
use either teletexString or universalString, but since X.520
matching rules are supposed to be in effect, there is no
reason to suppose that equivalent names in existing
certificates will match under a binary comparison.  This
will be even worse if we decide to throw out strings that would
otherwise match, simply because two CAs chose to use different
stringSyntaxes for encoding a given name.  I know of at least
one CA implementation that, if a name won't fit into the
printableString character-set, goes straight to universalString.
Certificates issued by this implementation will not be useful
in a PKIX infrastructure if the proposed text is adopted (or at
least, such certificates cannot appear in the same certificate
chain as PKIX-compliant certificates).

ii)  The preferred ordering of printableString, bmpString and
utf8String is problematic.  Since almost anything that might
ever appear in a name attribute is going to reside within the
BMP character-set, utf8String will hardly ever be used, so this
really comes down to a choice between printableString and
bmpString; utf8String will never actually be used if this
ordering is used.  This is a pity, since utf8String is
actually a very implementation-friendly codeset, in that
it's identical to 7-bit ASCII for characters that can be
represented in 7-bit ASCII, it doesn't use embedded null
octets, so code can use regular null-terminated C-strings to
store and manipulate it, it is designed so that it won't
break 8-bit clean code that scans for 7-bit ASCII values,
and it's efficient in terms of the number of octets used
to encode a given string.  It is also the standard codeset
for communicating between Java and other languages via the
Java native method interface.  Instead of this codeset, any
string that falls outside the printableString character-set
will be forced by this recommendation to use the 16-bit
bmpString codeset, with all the overhead (and potential
for byte-order bugs) that implies.

iii) If the restriction that attribute values have to use
the same syntax in order to be compared were to be dropped,
the only implication for PKIX implementations would be that
they would have to be able to convert from one string syntax
to another during chain processing.  However, this ability is
already required of a PKIX CA, by the requirement that a PKIX
implementation must choose the most restrictive syntax
that can represent a given attribute, so it's not an
great additional burden to put it in the chain processing
code as well (particularly as it's trivial to do for all the
allowed codesets except for the deprecated teletexString).
However, if an implementation _does_ have the ability to
convert between syntaxes, the rationale for using the most
restrictive syntax really goes away (since if the
implementation can convert, it shouldn't matter what syntax
a name is actually encoded with inside a certificate).
Given this, the PKIX profile should go for simplicity
(which to me as an implementor means removing choice wherever
possible), and simply specify the use of utf8String for all
names.  For the printableString character-set, the encoding
of a utf8String value is identical to the same value encoded
as a printableString - the only effect of using printableString
vs. utf8String is that they have different tags in the BER,
so there's no overhead in terms of code complexity or string
storage size.  The only effect would be to get rid of the
requirement on the implementation to dynamically pick a
preferred code-set by scanning the string;  instead it can
always use utf8.

iv) The specification of binary matching for all codesets
other than printable string doesn't really seem to buy
that much.  Consider an end-system E1, wishing to initiate a
secure communication with another end-system E2.  Assume that
the end-system retrieves certificates from a directory.
To initiate the connection, E1 will want to retrieve E2's
certificate.  Presumably, E2's name will have been provided
to E1 by a user, and it is unlikely that the user will know
the exact capitalization and spacing that E2's CA used when
binding E2's name into its certificate.  Instead, E1 will
likely take whatever name is provided, and use that to do
an directory retrieval.  The directory (which can be assumed
to understand X.520 matching rules) will return E2's
certificate, but before E1 can use the certificate it must
ensure that the subject name in the certificate actually
corresponds to E2 (since the directory isn't trusted).
So E1 has to be able to perform an X.520-style comparison
here, even if we specify binary matching in the certificate
chain processing.  So we haven't actually saved any code by
using binary matching - all we've done is to cause a PKIX
implementation to appear overly fussy about capitalization
and spacing.

In summary, now that the arcane teletexString syntax has
been deprecated, and we have utf8 as a compact universal
codeset that also happens to be ASCII-friendly, much of
the complexity of name comparisons has already been
eliminated.  The proposed PKIX restrictions on syntaxes
and comparisons don't simplify the implemention (and
in some cases they add complexity), while in almost all
cases they reduce functionality.

John

Date: Thu, 23 Apr 1998 16:25:40 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Re: OCSP Status Information on a Certificate
Sender: [email-masked]

Note: I am not sure that this message sent on Monday reached the list.
Sorry if this is a duplicate.
==================================================================

Slava,

Thanks for joining us.

(...)

> >  I fully agree. That's why I'm I don't think that issued/not issued
> >  should be a MAY: I think it has to be a MUST. We can be sure that 
> >  some clients will blow the comparison unless they are always told 
> >  whether or not the cert was even issued.

> Are we talking about fat OCSP client here ?
> Does the OCSP client in this case have full certificate chain ?
> Can we safely assume that fat OCSP client will need to verify signatures
> on the chain first, validity and other X509v3 constraints and only then
> submit OCSP request for status of every certificate in the chain ?

You are asking the right questions. 

> If this is so then, essentially, OCSP client is already in the possession
> of the well-formed certificate signed by the (indirectly or directly) 
> trusted CA key. In these circumstances receiving an anwer "not issued"
> may only mean that CA key is compromised and "unathorized" certificate 
> has been signed. But if someone has the CA key and can sign anything 
> with it (including "unathorized" certificates) then that someone can 
> also make sure that "unathorized" certificate has the same serial number
> as one of "authorized" and as long as we only send serial number to 
> identify a certificate in OCSP request the substitution of the 
> "authorized" cert with "unathorized" one will be unnoticed. This makes 
> "never issued" somewhat useless for fat OCSP clients.

> Is this reasoning wrong ?

The reasoning is correct. However I believe that your reasoning is also
valid for the other cases, i.e. I do not see how it is possible to take
a decision to accept a certificate without having that certificate in
hands, and as you correcly indicate you need anyway to verify signatures
on the chain first, validity and other X509v3 constraints. 

> Also since CA archiving capacity is always finite and we also talking
> about allowing "historical" OCSP queries "never issued" will have 
> to be replaced with "info unavailable" at least in some cases. This 
> further redices the value of "never issued" status.

 ... which is useless.

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

Date: Thu, 23 Apr 1998 16:21:19 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Michael Myers <[email-masked]>
CC: "Pkix List (E-mail)" <[email-masked]>
Subject: Re: OCSP Response Values and Structure
Sender: [email-masked]

Michael Myers wrote:
> 
> In reviewing comments to date so that we can move forward on the OCSP
> editing task,  the rough consensus appears to be as follows regarding OCSP
> response structure:
> 
> revocationStatus     {revoked, notRevoked, . . . }
> expirationStatus     {notYetValid, expired,  . . . }
> issuedStatus         {issued, notIssued, . . . }

Mike,

I do not think that your recap express the rough concensus. Look again
at the thread.

Several people have indicated which status (singular) should be
mandatory and which (plural) might be optional. There have been
questions raised and not answered.

For the optional status no argument has been given about their real
usefulness. In particular there has been no story to say if (and in the
case of if, how) an OCSP requester could make a path validation without
having access to the certificates of the path itself.

Regards,

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

Date: Thu, 23 Apr 1998 16:13:37 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Re: Key identifiers
Sender: [email-masked]

> > = Denis Pinkas 
>   = David P. Kemp

> > The reality is that for discovering a path, you might have to walk up
> > and down, but the verification should only be done "walking down". This
> > means that no digital signature verification should be done before
> > getting one or more candidate paths down.
> 
> Part 1 Section 6 states that conforming implementations must perform
> path validation in a manner which achieves identical results to the
> given procedure, which takes as input a full cert path and works
> from top to bottom.
> 
> But I don't see how following this procedure saves on signature
> computations:  for every point at which there is a choice of issuers,
> you need a disambiguator.  That is either a signature verification or
> something which gives a shortcut answer without ever giving a false
> reject.  Heuristics such as validity checking (against the target date
> only, NOT for issuer-subject validity nesting!) might help in a very
> few cases.

In most cases you will have the saving. The only case where you will not
have the saving is when two CAs will have the same name (whether that
name is a DN or an alternate name). This case should be very seldom but
might exist. For that very seldom case, I do not think that we need
additional mandatory parameters that every CA shall support and that
takes some space in the certificate.  

>           AuthorityKeyIdentifier will allow you to reject all
> inappropriate candidates, but it takes up space in the certs, as you
> say.  Another, more radical, approach would be to define new
> AlgorithmOIDs which include a one octet checkword in the signature
> value, which could be compared against a specific high-entropy octet of
> the authority public key.  This would eliminate 255/256 of the
> unnecessary signature verifications.  NB: I'm not advocating this
> approach, just using it as an illustration of a hack which could
> improve pathbuilding efficiency without costing much space.
> 
> > > I have one problem with this approach: The verification path is not
> > > fixed. Let us assume a CA gets certified by a set of other CAs. Some
> > > users trust one of them, others some other CAs (which is why the CA
> > > probably got this multiple certificates). When a user certificate
> > > contains a reference to a single other CA, a user which does not trust a
> > > specific CA will fail to verify the certificate, although there might be
> > > a another path which would lead to a successful verification.
> >
> > I support this comment. This means that placing the key identifier will
> > create failures in cases where successful verification could have be
> > done applying a different approach.
> 
> I don't understand this comment.  If an entity has a certificate signed
> by a particular issuer, that certificate will have the identifier of that
> issuer's key.  A certificate from a different issuer will have a different
> key identifier.  In what case will a key identifier cause a reject where
> the signature would otherwise have verified correctly?

The problem is that the link is pointing *back* to a particular cert of
a CA. A CA may have its signing public key signed by more than one CA.
In that case the end-entity will point to only one of these certs which
may end up to an intrusted point for the receiver. Using a different
cert for the key of the CA could end up to a trusted point for the
receiver. This is why you may end up with a reject.

> > > One question: Do we have an algorithm for a complete verification? There
> > > is one that describes how to verify an existing FC path, but do we have
> > > an algorithm on how to construct a path?
> >
> > We currently don't and we probably should define one.
> 
> Yes.  Santosh?
> 
> Dave Kemp

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ocdp-00.txt
Date: Thu, 23 Apr 1998 09:54:45 -0400
Sender: [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  
                          OPEN CRL DISTRIBUTION PROCESS (OpenCDP)
	Author(s)	: W. Ford, P. Hallam-Baker
	Filename	: draft-ietf-pkix-ocdp-00.txt
	Pages		: 4
	Date		: 22-Apr-98
	
This Internet Draft specifies mechanisms for determining if a public-key
certificate is valid or revoked, using CRL partitions.  These mechanisms
are considered superior to the CRL Distribution Points (CDP) mechanism
defined in ISO/IEC 9504-8/ITU-T Rec. X.509 for several reasons.
In particular, OpenCDP:

(a) accommodates dynamic partitioning as opposed to fixed partitioning;
(b) better supports use of certificates in multiple environments
    with different CRL stores;
(c) includes a means for improving cachability and timeliness
    characteristics with CRLs;  and
(d) is believed not to be encumbered by the patent claims applying to CDPs.
 
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-ocdp-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocdp-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: ftp.ietf.org
	
	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-ocdp-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-ocdp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocdp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "Flanigan, Bill" <[email-masked]>, <[email-masked]>
Subject: Re: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 16:28:45 -0400
Sender: [email-masked]

>Hello Phillip,
>
> Eminence?  Not an issue, at least not for me.  Prose?  Same.
>Acknowledgements?  Don't see these folks mentioned in the draft (but nice
to
>hear about their contributions).  And, thank you for the background on the
>draft.

The acknowledgements appear immediately after the IETF draft
disclaimer rather than at the end. I think Warwick wanted to make
sure they got noticed rather than tucking them away at the end.

        Phill

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "Phillip M. Hallam-Baker" <[email-masked]>, "Flanigan, Bill" <[email-masked]>, <[email-masked]>
Subject: Re: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 16:14:26 -0400
Sender: [email-masked]

OK, sorry about the sarcasm level in response to Bill's query. Bill probably
didn't intend the insult.

The last time someone suggested adding authors names to one of my drafts was
when Jeff Hostetler and myself propsed digest authentication in HTTP. The
RFC ended up with about 7 names, many of which had been added in the hope
that certain companies would support it (they didn't).

Having worked in particle physics I know all about being on an author list
that takes three pages. I always thought that rather ridiculous.

        Phill

From: "Flanigan, Bill" <[email-masked]>
To: [email-masked]
Subject: RE: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 16:05:03 -0400
Sender: [email-masked]

Hello Phillip,

	Eminence?  Not an issue, at least not for me.  Prose?  Same.
Acknowledgements?  Don't see these folks mentioned in the draft (but nice to
hear about their contributions).  And, thank you for the background on the
draft.

Bill

> -----Original Message-----
> From:	Phillip M. Hallam-Baker [SMTP:[email-masked]]
> Sent:	Wednesday, April 22, 1998 3:08 PM
> To:	Flanigan, Bill; [email-masked]
> Subject:	Re: CDP Alternative Proposal
> 
> >Before I spend any time wading through this much less submitting any 
> >suggested improvements or comments, I would like to see additional 
> >co-authors from other organizations be added.  Comments?
> 
> 
> 
> I am sorry that Bill does not find Warwick and myself sufficiently 
> emminent to make his reading list. Perhaps if we had persuaded
> Frederick Forsythe and Gabbriel Garcia Marquez to run over the
> prose rather than Brian LaMacchia, Barbara Fox and Jeff
> Weinstein we would have stood a better chance.
> 
> 
> This is an Internet draft based on original research by Warwick and
> myself.
> 
> As with all Internet drafts it is an individual submission by the authors.
> Authorship does not imply any endorsement by any organisation nor
> does it necessarily mean that other people did not make substantial
> contributions.
> 
> 
> Last week we realised that the problem with CRLs was not
> issuing the revocation info but the implicit assertion each CRL contains
> that all other certificates are valid. This lead to the idea that the only
> problem of partitioning CRLs was that one could only know a
> certificate was implicitly valid if one had the all the CRLs in which it
> might appear.
> 
> A simple solution to CRL partitioning therefore is to embed a
> statement in each CRL specifying the CRL population it relates to.
> The issuer is not bound to chose a particular partitioning scheme
> in advance. Indeed the issuer could decide to issue CRLs of a
> particular length, say 100 certificates and chose the scoping
> constraints accordingly.
> 
> 
> We think this is a better approach than hardwiring distribution points
> into certificates as per the Entrust patent claims.
> 
> Given that the area director has told us to jettison the encumbered 
> technology so that part 1 can go to the IESG I don't think there is any
> dispute about the importance of this issue. 
> 
> 
>         Phill
> 
> 
> 
> 

From: WHenry <[email-masked]>
To: "'Flanigan, Bill'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 15:38:58 -0400
Sender: [email-masked]

  I see no reason to add a long list of co-authors to the document.

 Bill Henry
 Performance Engineering Corporation
 3949 Pender Drive
 Fairfax, VA 22030
 Internet: [email-masked]

> -----Original Message-----
> From:	Flanigan, Bill [SMTP:[email-masked]]
> Sent:	Wednesday, April 22, 1998 2:16 PM
> To:	[email-masked]
> Subject:	RE: CDP Alternative Proposal
> 
> Before I spend any time wading through this much less submitting any 
> suggested improvements or comments, I would like to see additional 
> co-authors from other organizations be added.  Comments?
> 
> Bill
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> William F. Flanigan, Jr., Ph.D.       Voice:           (703) 735-3305
> Defense Information Systems Agency      DSN:                      653
> Strategic Planning Office (JEBA)        Fax:            (703)735-3255
> 10701 Parkridge Boulevard        Voice Mail:            (703)735-3305 
> Reston, VA 20191-4357              Internet:  <[email-masked]>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
> 
> > -----Original Message-----
> > From:	Warwick Ford [SMTP:[email-masked]]
> > Sent:	Wednesday, April 22, 1998 2:11 AM
> > To:	[email-masked]
> > Subject:	CDP Alternative Proposal
> > 
> > We have today submitted the attached Internet Draft entitled "Open CRL
> > Distribution Process (OpenCDP)" as <draft-ietf-pkix-ocdp-00.txt>.
> > 
> > While this work was initially motivated by the IETF and IESG desire that
> > the PKIX drafts not contain encumbered technology, we believe that the
> > result also has significant technical advantages over the CDP mechanism.
> > 
> > Given interest in this proposal, we suggest that the PKIX Cert and CRL
> > Profile (with CDPs expressly forbidden as per LA) progress to proposed
> > standard as soon as possible, allowing dependent application standards
> > (e.g., CMS) to progress as well.  PKIX may wish to also consider
> adopting
> > the OpenCDP specification as the basis of a follow-up adjunct standard.
> > 
> > Warwick and Phillip
> > 
> > 

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "Flanigan, Bill" <[email-masked]>, <[email-masked]>
Subject: Re: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 15:08:21 -0400
Sender: [email-masked]

>Before I spend any time wading through this much less submitting any 
>suggested improvements or comments, I would like to see additional 
>co-authors from other organizations be added.  Comments?

I am sorry that Bill does not find Warwick and myself sufficiently 
emminent to make his reading list. Perhaps if we had persuaded
Frederick Forsythe and Gabbriel Garcia Marquez to run over the
prose rather than Brian LaMacchia, Barbara Fox and Jeff
Weinstein we would have stood a better chance.

This is an Internet draft based on original research by Warwick and
myself.

As with all Internet drafts it is an individual submission by the authors.
Authorship does not imply any endorsement by any organisation nor
does it necessarily mean that other people did not make substantial
contributions.

Last week we realised that the problem with CRLs was not
issuing the revocation info but the implicit assertion each CRL contains
that all other certificates are valid. This lead to the idea that the only
problem of partitioning CRLs was that one could only know a
certificate was implicitly valid if one had the all the CRLs in which it
might appear.

A simple solution to CRL partitioning therefore is to embed a
statement in each CRL specifying the CRL population it relates to.
The issuer is not bound to chose a particular partitioning scheme
in advance. Indeed the issuer could decide to issue CRLs of a
particular length, say 100 certificates and chose the scoping
constraints accordingly.

We think this is a better approach than hardwiring distribution points
into certificates as per the Entrust patent claims.

Given that the area director has told us to jettison the encumbered 
technology so that part 1 can go to the IESG I don't think there is any
dispute about the importance of this issue. 

        Phill

From: "Flanigan, Bill" <[email-masked]>
To: [email-masked]
Subject: RE: CDP Alternative Proposal
Date: Wed, 22 Apr 1998 14:15:59 -0400
Sender: [email-masked]

Before I spend any time wading through this much less submitting any 
suggested improvements or comments, I would like to see additional 
co-authors from other organizations be added.  Comments?

Bill

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           (703) 735-3305
Defense Information Systems Agency      DSN:                      653
Strategic Planning Office (JEBA)        Fax:            (703)735-3255
10701 Parkridge Boulevard        Voice Mail:            (703)735-3305 
Reston, VA 20191-4357              Internet:  <[email-masked]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	Warwick Ford [SMTP:[email-masked]]
> Sent:	Wednesday, April 22, 1998 2:11 AM
> To:	[email-masked]
> Subject:	CDP Alternative Proposal
> 
> We have today submitted the attached Internet Draft entitled "Open CRL
> Distribution Process (OpenCDP)" as <draft-ietf-pkix-ocdp-00.txt>.
> 
> While this work was initially motivated by the IETF and IESG desire that
> the PKIX drafts not contain encumbered technology, we believe that the
> result also has significant technical advantages over the CDP mechanism.
> 
> Given interest in this proposal, we suggest that the PKIX Cert and CRL
> Profile (with CDPs expressly forbidden as per LA) progress to proposed
> standard as soon as possible, allowing dependent application standards
> (e.g., CMS) to progress as well.  PKIX may wish to also consider adopting
> the OpenCDP specification as the basis of a follow-up adjunct standard.
> 
> Warwick and Phillip
> 
> 

Date: Wed, 22 Apr 1998 10:52:38 +0300
From: Moshe Litvin <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 11:26 AM 4/21/98 +0300, Moshe Litvin wrote:
> >The problem you describe is inherent to CRL and not to the distribution
> >method.
> 
> I disagree. If I send a request to a CA for the latest CRL, and I might get
> an old response if I use HTTP but am sure to get a current response if I
> use FTP, then the problem is in the distribution method.
> 

But this can happen also in FTP and LDAP:

1. Someone can write the old CRL back in place of the newer CRL in the
LDAP directory or the FTP server.

2. The LDAP directory could be a replicating one and the replication
hasn't occurred yet.

Do you have some sort of CRL distribution method that is immune to this
problem?

Moshe

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

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

Date: Tue, 21 Apr 1998 23:10:42 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: CDP Alternative Proposal
Sender: [email-masked]

We have today submitted the attached Internet Draft entitled "Open CRL
Distribution Process (OpenCDP)" as <draft-ietf-pkix-ocdp-00.txt>.

While this work was initially motivated by the IETF and IESG desire that
the PKIX drafts not contain encumbered technology, we believe that the
result also has significant technical advantages over the CDP mechanism.

Given interest in this proposal, we suggest that the PKIX Cert and CRL
Profile (with CDPs expressly forbidden as per LA) progress to proposed
standard as soon as possible, allowing dependent application standards
(e.g., CMS) to progress as well.  PKIX may wish to also consider adopting
the OpenCDP specification as the basis of a follow-up adjunct standard.

Warwick and Phillip
-----------------------------------------

PKIX Working Group                            P. Hallam-Baker (VeriSign)
Internet Draft                                        W. Ford (VeriSign)
                                                           
expires in six months                                     April 21, 1998

                Internet X.509 Public Key Infrastructure

                 OPEN CRL DISTRIBUTION PROCESS (OpenCDP)

                     <draft-ietf-pkix-ocdp-00.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).

   Copyright (C) The Internet Society (date). All Rights Reserved.

Abstract

This Internet Draft specifies mechanisms for determining if a public-key
certificate is valid or revoked, using CRL partitions.  These mechanisms
are considered superior to the CRL Distribution Points (CDP) mechanism
defined in ISO/IEC 9504-8/ITU-T Rec. X.509 for several reasons.  In
particular, OpenCDP:
(a) accommodates dynamic partitioning as opposed to fixed partitioning;
(b) better supports use of certificates in multiple environments with
different CRL stores;
(c) includes a means for improving cachability and timeliness
characteristics with CRLs;  and
(d) is believed not to be encumbered by the patent claims applying to CDPs.

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

Acknowledgments

The following individuals made significant contributions to the development
of this proposal:  Arn Schaeffer, Mahi de Silva, Michael Myers, and Alex
Deacon of VeriSign, Brian LaMacchia and Barbara Fox of Microsoft, and Jeff
Weinstein of Netscape.

1. PRINCIPLES

A certification authority may issue distinct CRLs for different subsets of
its certificate population.  The partitioning may be based on various
requirements, such as the need to partition evenly for pure performance
purposes, the need to produce separate CRLs on the basis of revocation
reason, or the need to group together revocation information for related
entities, e.g., all the servers or clients of one organization.

CRL partitioning involves two functions:

(a)  a CRL location function, which allows for a certificate-using system
to find a CRL applicable to a given certificate;
(b)  a certificate-CRL validation function, which provides for the
certificate-using system to confirm that a CRL to hand is indeed an
applicable CRL for the certificate under consideration.

The CDP mechanism merged these two functions into one mechanism.  In
contrast, the OpenCDP mechanism separates these two functions and thereby
achieves various benefits.  

First, the location function becomes a non-security-critical function, in
that location information does not need to be embedded into a certificate
and signed by the CA.  Among other benefits, this helps reduce certificate
sizes.

Second, the certificate-CRL validation function can be made a dynamic
mapping relationship, as opposed to the static relationship afforded by
CDPs.  For example, this function can be based on such certificate
population characteristics as subject name structures, certificate serial
number ranges, or date ranges.  Such CRL partition definitional criteria
can be changed dynamically by the CA if needed, without affecting the
issued certificate base.

Third, because the location information is not in the certificate, it is
possible to change that information for use of the certificate in different
environments, e.g., change it to point to a different CRL store when
traversing a firewall.

Fourth, given the provision of an attribute external to a certificate for
conveying CRL location information, the same attribute can convey other
useful revocation information such as a pointer to an OCSP server.

The OpenCDP mechanism employs a single X.509 CRL extension and two
attribute types for use in directories or in protocol construction.  No
certificate extensions are needed except that, if indirectCRLs are to be
implemented, there is a need for a new revocationIssuer extension to
implement the function of the cRLIssuer element of the
cRLDistributionPoints extension (which is no longer used in PKIX) - see
later section on Revocation Issuer Extension.

2. CRL LOCATION FUNCTION

A certificate-using system that uses partitioned CRLs needs to locate an
appropriate CRL for a given certificate.  Information on CRL location does
not need to be inside a certificate. Furthermore, it can be advantageous
not to have such information within certificates, in order to allow for
changing of the partition configuration or storage locations after
certificates are issued.  Therefore, OpenCDP explicitly forbids the
inclusion of location information within certificates.

CRL location will not always require standardized protocol features, since
it can often be handled by local logic, e.g., a CRL "map" (or pointer
thereto) for an enterprise, based on user names, might be incorporated into
a configuration file in end-user products of that enterprise.  

However, it is advantageous to have a standard format for specifying such
information, for use in protocols and directory entries.  This
specification therefore defines a standard attribute type for holding
revocation information, including CRL location information.  This attribute
type and typical ways of using it are described below under Revocation
Information Attribute.

This specification also defines another mechanism for locating CRLs.  This
involves a list of CRLs stored in the CA's directory entry.  This mechanism
is described below under the CRL List Attribute.

3. CERTIFICATE-CRL VALIDATION FUNCTION

The scope of a CRL partition can be defined by specifying ranges on any of
the fields in a certificate.  For Internet (PKIX) purposes, it is proposed
that the scoping be limited to the following criteria or any combination
thereof:

(a)  A certificate serial number range;
(b)  A subject key identifier range;
(c)  One or more subject name subtrees;
(d)  A time range for certificate issuance (more precisely, for the
notBefore time in the certificate);
(e)  End-user certificate vs CA-certificate.

Examples of CRL partition scopes are:

(1)  All of the certificates of a CA with serial numbers between 10,000 and
19,999 inclusive.
(2)  All of the certificates of a CA with subject names commencing: "C=US,
O=foobar, ..."
(3)  All of the certificates of a CA with subject DNS names
"<anything>.foobar.com".
(4)  All of the certificates of a CA for the subject "C=US, O=foo, OU=bar,
CN=myname".
(5)  All of the certificates of a CA with a notBefore date in April, 1998.

The scope of a CRL is indicated within that CRL using the following CRL
extension:

cRLScope EXTENSION ::= {
        SYNTAX  CRLScopeSyntax
        IDENTIFIED BY   { <oid tbd> } }

CRLScopeSyntax ::= SEQUENCE {
        serialNumberRange       [0] NumberRange OPTIONAL,
        subjectKeyIdRange       [1] NumberRange OPTIONAL,
        nameSubtrees            [2] GeneralNames OPTIONAL,
        notBeforeRange          [3] NotBeforeRange OPTIONAL,
        onlyContainsUserCerts   [4] BOOLEAN DEFAULT FALSE,
        onlyContainsCACerts     [5] BOOLEAN DEFAULT FALSE,
        onlySomeReasons         [6] ReasonFlags OPTIONAL,
        indirectCRL             [7] BOOLEAN DEFAULT FALSE }

NumberRange ::= SEQUENCE {
        startingNumber          INTEGER,
        endingNumber            INTEGER,
        modulus                 INTEGER OPTIONAL }

notBeforeRange ::= SEQUENCE {
        startingNotBeforeTime   GeneralizedTime,
        endingNotBeforeTime     GeneralizedTime }

The serialNumberRange element, if present, is used as follows.  When a
modulus value is present, the serial number is reduced modulo the given
value before checking for presence in the range.  Then, certificates with a
(reduced) serial number equal to or greater than startingNumber and less
than endingNumber are considered to be within scope of the CRL.

The subjectKeyId range element, if present, is interpreted the same as
serialNumberRange, except that the number used is the value in the
certificate's subjectKeyIdentifier extension, interpreted as an unsigned
integer.

Conventions for the nameSubtrees option are the same as for the Name
Constraints extension.  

If the notBeforeRange element is present, certificates with a notBefore
time equal to or greater than startingNotBeforeTime and less than
endingNotBeforeTime are considered to be within scope of the CRL.

The fields onlyContainsUserCerts, onlyContainsCACerts, onlySomeReasons and
indirectCRL are used as described for the X.509 issuingDistributionPoint
extension.  (Note that the issuingDistributionPoint extension and cRLScope
extension conflict with each other -- the issuingDistributionPoint
extension is not permitted in a CRL which contains a cRLScope extension.)

When a certificate-using system uses a CRL to check status of a
certificate, it should check that the CRL scope includes the certificate,
as follows:

(a)  If the CRL contains an issuingDistributionPoint extension, then such
CRL is inconsistent with PKIX and should not be used.
(b)  If the CRL contains a cRLScope extension, then the certificate-using
system must check that the certificate falls within the scope indicated by
the intersection of the serialNumberRange, subjectKeyIdRange, nameSubtrees,
and notBeforeRange scopes, and is consistent with onlyContainsUserCerts and
onlyContainsCACerts if present.
(c)  If the CRL contains neither an issuingDistributionPoint nor cRLScope
extension, then the scope is the entire scope of the CA, and the CRL may be
used for any certificate from that CA.

4.  REVOCATION INFORMATION ATTRIBUTE

Attributes of this type are used to hold CRL location information or other
information pertaining to revocation status of a certificate.  Ways of
using this attribute type include the following:

(a)  In a directory entry that holds a certificate.  The revocation
information is stored in an attribute accompanying the certificate
attribute and when anyone retrieves a certificate they can also retrieve
the revocation information. [Note: This attribute type needs to be included
in the PKIX LDAP schema.]

(b)  When a certificate is transported by CMS (or any other PKCS#7-based
protocol), the corresponding revocation information can be conveyed in an
unauthenticated attribute.

(c)  When a certificate is transported by ISAKMP, the corresponding
revocation information can be conveyed as an ISAKMP payload.

(d)  When a certificate is transported as part of a TLS/HTTP exchange, the
corresponding revocation information can be conveyed in a HTTP header.

(e)  When a certificate is issued using CRMF or PKCSReq (see [CRMF] or
[CMMF] respectively), the corresponding revocation information can be
conveyed as an unauthenticated attribute in the "response" field of a
CertRep message body (see [CMMF] for details on CertRep syntax.)

As new IETF protocols are defined, it is anticipated that the protocols
will make explicit provision for conveying revocation information along
with certificates.

Note that there may be circumstances in which an intermediary (e.g.,
firewall) may change revocation information, such as CRL location pointers,
in transit.

Following is the definition of the Revocation Information attribute type:

revocInfo ATTRIBUTE ::= {
  	WITH SYNTAX RevocInfo
  	ID <oid tbd> }

RevocInfo ::= SEQUENCE {
     certIssuer              GeneralNames,
     certSerialNumber        INTEGER,
     infoLocations           [0] SEQUENCE SIZE (1..MAX) OF InfoLocation
                             OPTIONAL,
     extensions              [1] SEQUENCE OF INSTANCE OF 
                             TYPE-IDENTIFIER OPTIONAL }

InfoLocation ::= SEQUENCE {
     locator                 GeneralNames,
     infoType                InfoType DEFAULT crl,
     reasons                 ReasonFlags OPTIONAL }

InfoType ::= ENUMERATED {
     crl                     (0),
     oCSPServer              (1) }

ReasonFlags ::= BIT STRING {
     unused                  (0),
     keyCompromise           (1),
     cACompromise            (2),
     affiliationChanged      (3),
     superseded              (4),
     cessationOfOperation    (5),
     certificateHold         (6) }

For the semantics of the reasons field, see the definition of the CRL
Distribution Points certificate extension in X.509.

Certification authorities that are conformant to OpenCDP must not insert a
revocation information attribute within a certificate.

5. CRL LIST ATTRIBUTE

This optional attribute type is for use by a CA in presenting a list of
available CRLs to certificate-users.  This list can be stored in the CA's
directory entry.  (That entry can be determined from issuer name or an
issuerAltName value.)

The list is signed and there is provision for inclusion of a last-update
time/date for every CRL.  A CA is able to use this mechanism as follows.  A
new CRL list is reissued periodically, typically with a relatively high
reissue frequency (in comparison with CRL reissue frequencies).  A
certificate user, on obtaining this list, can quickly determine if cached
copies of CRLs are still up-to-date.  This eliminates much unnecessary
retrieval of CRLs.  Furthermore, by using this mechanism, certificate users
become aware of CRLs issued by the CA between its usual update cycle,
thereby improving the timeliness of the CRL system.

Following is the definition of the CRL List attribute type:

cRLList ATTRIBUTE ::= {
  	WITH SYNTAX CRLList
  	ID <oid tbd> }

CRLList ::= SIGNED { SEQUENCE {
     signature               AlgorithmIdentifier,
     issuer                  GeneralNames,
     thisUpdate              GeneralizedTime,
     nextUpdate              GeneralizedTime  OPTIONAL,
     cRLLocators             CRLLocators }}

CRLLocators ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE  {
     locator                 GeneralName,
     cRLScope                CRLScopeSyntax,
     lastUpdate              GeneralizedTime OPTIONAL }

The signature, issuer, thisUpdate, and nextUpdate fields are interpreted
similarly as to in a CRL.  The lastUpdate field is the value of the
thisUpdate field in the most-recently issued referenced CRL.

6.  REVOCATION ISSUER EXTENSION

This noncritical certificate extension is used by a CA to indicate that it
has delegated authority to one or more other entities to issue and sign
CRLs or sign OCSP responses on its behalf.

revocationIssuer EXTENSION ::= {
        SYNTAX  GeneralNames
        IDENTIFIED BY   { <oid tbd> } }

7.  INTELLECTUAL PROPERTY STATEMENT

The authors have no knowledge of any pending or granted patents covering
the techniques described.  

Author Addresses:

   Phillip Hallam-Baker
   VeriSign, Inc.
   301 Edgewater Place, Suite 210
   Wakefield, MA 01880
   USA
   [email-masked]

   Warwick Ford
   VeriSign, Inc.
   301 Edgewater Place, Suite 210
   Wakefield, MA 01880
   USA
   [email-masked]

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

Date: Tue, 21 Apr 1998 14:35:28 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

After talking to David Kemp, I'd like to propose an additional paragraph to
the one I had already proposed for the security section:

If a CA issues one or more CRLs before the nextUpdate time
of a previous CRL, a requestor has no way of ensuring that a CRL
received from that CA is the most current one available.  Caching,
repository updating, and man-in-the-middle attacks may all result in
a valid but outdated CRL being accepted by the requestor without the
requestor knowing that a newer CRL is available.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 21 Apr 1998 13:12:17 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

> From: Mike Smith <[email-masked]>
> 
> Isn't the off-schedule CRL considered a delta-CRL (even if it
> contains the complete set of records)?  If so, then doesn't the reply
> also have to include the last "full" CRL produced in its response as
> well?

Nope and nope.  A delta CRL will have the deltaCRLIndicator extension
present.  The extension contains the BaseCRLNumber to which the delta
applies.  A CRL without the extension is not a delta CRL.

If a full base CRL had to be transmitted along with every delta CRL,
then there would be no reason to use delta CRLs.  The assumption is
that the verifier already has a locally-cached copy of the base CRL,
or is responsible for fetching it separately.

To: [email-masked]
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http 
Date: Tue, 21 Apr 1998 09:55:47 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

"Bob Jueneman" <[email-masked]> scrawled:
> 
> Michael, I'm not entirely sure I agree with your semantics. 
> Maybe I've missed something, but I always interpreted 
> the traditional CRL nextUpdate semantics to mean "if you 
> haven't gotten an new CRL by this time, you are potentially 
> missing something", not "I'm not going to have another 
> word to say on this subject until this time, even if the world 
> is about to come to an end."
> 
> In other words, I believe that a CA (at least some CAs) 
> would feel that they are allowed, and perhaps even 
> compelled, to issue a CRL PRIOR to the time of the 
> nextUpdate, especially in the event of a known key 
> compromise. Certainly I would take my business elsewhere 
> if a CA or repository would not provide me that service.
> 
> I haven't followed the OCSP discussion that closely, 
> I'm afraid, but surely the semantics haven't changed
> all that much?
>
> bob
> 

I'd say that the semantics have never been too clear.  I even find the way
you've described them a bit confusing.  You say that a CRL's nextUpdate means
that "if you haven't gotten an new CRL by this time, you are potentially
missing something" but you also say that a CA should be allowed to issue a 
CRL prior to nextUpdate.

So, basically, regardless of whether nextUpdate has passed or not, an RP may 
potentially be missing something.  nextUpdate doesn't really tell the RP 
anything.

The best interpretation of nextUpdate I've seen is something I inferred from
a post David Kemp put up about a week ago.  He said that a CA needs a certain
amount of time to process a revocation, and it needs a way to relay that
revocation-lag information to RPs.

That kind of information is far more useful to RPs than some guesstimate 
about the frequency of CRL publishing.  nextUpdate might be used to carry 
that information.  It makes sense within OCSP to say "Here is the 
cartificate's status NOW, and if a revocation were to occur NOW it would 
take X seconds for it be processed."  So if an RP waited X seconds and did 
another check, it would know the cert's status at NOW.  Another way to think 
of it is "this was the cert's status X seconds ago."

For CRLs, though, making nextUpdate adopt these semantics only makes sense if
the CRLs are published at most every X seconds (and never sooner).  That is,
there would be no CRLs published until nextUpdate.  This is because the CRL
would be saying "These are the revoked certificates as of NOW and since it
takes me (the CA) X seconds to process a revocation there will be _no_
updates to this list until NOW + X."  That is, nextUpdate = NOW + X.

I think this is a new spin on CRLs.  If not, it certainly hasn't been clear
to me until now (and so I'd say that the standards have inadequately 
explained the issue).  The implication is that if a CA wants to be able to 
boast of a fast revocation response time, say 10 seconds, then it has to 
publish a CRL every 10 seconds (or use OCSP).

                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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-webcap-00.txt
Date: Tue, 21 Apr 1998 12:55:18 -0400
Sender: [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		: WEB based Certificate Access Protocol-- WebCAP/1.0
	Author(s)	: S. Reddy
	Filename	: draft-ietf-pkix-webcap-00.txt
	Pages		: 26
	Date		: 20-Apr-98
	
   This document describes the Internet X.509 Public Key Infrastructure
   (PKI) Certificate Access 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].
 
   This document specifies a set of methods, headers, and content-types
   ancillary to HTTP/1.1 to publish, retrieve X.509 certificates and
   Certificate Revocation Lists. This protocol also facilitates
   determining current status of a digital certificate without the use
   of CRLs.  This protocol defines new methods, request and response
   bodies, error codes to HTTP/1.1 protocol for securely publishing,
   retrieving, and validation certificates across a firewalls.

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-webcap-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-webcap-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: ftp.ietf.org
	
	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-webcap-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-webcap-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-webcap-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 21 Apr 1998 12:42:38 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
> 
> At 11:26 AM 4/21/98 +0300, Moshe Litvin wrote:
> >The problem you describe is inherent to CRL and not to the distribution
> >method.
> 
> I disagree. If I send a request to a CA for the latest CRL, and I might get
> an old response if I use HTTP but am sure to get a current response if I
> use FTP, then the problem is in the distribution method.

I agree completely with Mike on this one.  The CA signature on a CRL
(or OCSP response) allows the use of unreliable repositories.  FTP is
no more or less reliable a protocol than HTTP, it's just that the
use of caching proxies is more prevalent with HTTP (caching FTP
proxies do exist).  In addition to inadvertent errors due to caching,
one must also consider deliberate manipulation of repository contents,
which could result in a superceded-but-still-valid CRL being used.

Mike left out the obvious solution to the problem: just don't do it.
PKIX does not prohibit CAs from issuing CRLs before the nextUpdate of a
prior CRL, but the policy of individual CAs should take into account
the trustworthiness and reliability of the distribution mechanism when
deciding how to set nextUpdate and whether to ever issue interim CRLs.
The no-brainer approach is to assume that revocation distribution is
completely untrustworthy and expire the revocation information often
enough that there is no motivation to issue interim information.

Carl Ellison has a colorful description of CRLs which are not required
by the verifier: wandering anti-matter which may or may not happen to
collide with the revoked certificates in time to prevent them from being
used.  PKIX should not encourage the "statistical revocation" approach,
and should point out the dangers of using it, as Paul has done in his
Security Considerations text.

  Dave Kemp

Date: Tue, 21 Apr 1998 09:01:50 -0700
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Michael Myers <[email-masked]>
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Bob,

Semantics of nextUpdate in OCSP and in CRLs are identical.  Implementors
should support an update to a CRL prior to expiration of nextUpdate on a
current CRL.

Mike

At 07:21 PM 4/20/98 -0600, Bob Jueneman wrote:
>Michael, I'm not entirely sure I agree with your semantics. 
>Maybe I've missed something, but I always interpreted 
>the traditional CRL nextUpdate semantics to mean "if you 
>haven't gotten an new CRL by this time, you are potentially 
>missing something", not "I'm not going to have another 
>word to say on this subject until this time, even if the world 
>is about to come to an end."
>
>In other words, I believe that a CA (at least some CAs) 
>would feel that they are allowed, and perhaps even 
>compelled, to issue a CRL PRIOR to the time of the 
>nextUpdate, especially in the event of a known key 
>compromise. Certainly I would take my business elsewhere 
>if a CA or repository would not provide me that service.
>
>I haven't followed the OCSP discussion that closely, 
>I'm afraid, but surely the semantics haven't changed
>all that much?
>
>bob
>
>>>> "Michael Myers" <[email-masked]> 04/20 5:36 PM >>>
>Paul,
>
>One the primary reasons a CRL is signed in the first place is to relieve any
>repository containing them of security requirements.  A certificate
>processing system determines that a CRL is expired by examining nextUpdate.
>This value is protected by CA signature, not by presumptions of the
>functional correctness or assurances provided by the security architecture
>of the repository.
>
>If a repository provides an old CRL instead of a new CRL, then one of two
>cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
>with respect to the current system time of the certificate processing
>software or it isn't.  If it is, an exception condition should be raised.
>If not, the information in the old CRL is still reliable.
>
>Mike
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On Behalf
>> Of Paul Hoffman / IMC
>> Sent: Monday, April 20, 1998 3:11 PM
>> To: [email-masked] 
>> Subject: Security section of draft-ietf-pkix-opp-ftp-http
>>
>>
>> Russ' "how to get certs and CRLs over FTP and HTTP" draft seems fine, but
>> the Security section is incomplete. Specifically, it doesn't mention the
>> hidden security problems that HTTP proxy caches can introduce. I propose
>> that the following be added to the Security section:
>>
>> The HTTP 1.1 protocol specifically allows HTTP proxies to cache responses
>> for repeated requests for URLs. Although RFC 2068 carefully specifies how
>> HTTP proxies should work, there are many non-conformant proxies in use on
>> the Internet. A non-conformant HTTP proxy can have serious security
>> implications for requesting CRLs. If a new CRL is issued before the
>> nextUpdate time in a CRL, but an HTTP proxy incorrectly gives the
>> requestor
>> an older CRL, the requestor will get wrong revocation information and will
>> have no way of knowing that the information is out of date. CRL
>> distributors following this specification have no way of forcing
>> the latest
>> CRL through to a requestor.
>>
>>
>> --Paul Hoffman, Director
>> --Internet Mail Consortium
>>
>
>
>
>

Date: Tue, 21 Apr 1998 08:53:36 -0700
To: Marc Branchaud <[email-masked]>, "Pkix List (E-mail)" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject: Re: OCSP Response Values and Structure 
Sender: [email-masked]

Other values relevant to a given category, e.g. onHold and unknownCA for
revocationStatus.

At 06:29 PM 4/20/98 -0700, Marc Branchaud wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>Content-Type: text/plain; charset=us-ascii
>
>
>"Michael Myers" <[email-masked]> scrawled:
>> 
>> In reviewing comments to date so that we can move forward on the OCSP
>> editing task,  the rough consensus appears to be as follows regarding OCSP
>> response structure:
>> 
>> revocationStatus     {revoked, notRevoked, . . . }
>> expirationStatus     {notYetValid, expired,  . . . }
>> issuedStatus         {issued, notIssued, . . . }
>> 
>
>What do the ellipses stand for?
>
>                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
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQB1AwUBNTv2llrdFXNdDxPlAQF7GQMAjz+3rEbpbtnVkcCsz9BjjHvpPgEzjQRw
>bl2Nrco6xrbg3cH/dfRyCJhoNuzhBieqmgmZ+9itUpoJpPJ8aihLXF/B904YAQZ9
>F9Z5Qt1L3Nh5HeoFLPtBTYVhRWEvEl3/
>=x9Az
>-----END PGP SIGNATURE-----
>
>

Date: Tue, 21 Apr 1998 07:58:58 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

At 11:26 AM 4/21/98 +0300, Moshe Litvin wrote:
>The problem you describe is inherent to CRL and not to the distribution
>method.

I disagree. If I send a request to a CA for the latest CRL, and I might get
an old response if I use HTTP but am sure to get a current response if I
use FTP, then the problem is in the distribution method.

>If a CA issues a CRL before the nextUpdate there is no way it
>can make sure that all the relying parties will use it.

Correct.

>It can be
>because of a non-conformant HTTP proxy, a malicious HTTP proxy,  someone
>who managed to put write the old CRL back in the directory, or someone
>who managed to block the communication between the CA and the directory
>at the relevant time to the distribution of the new CRL.

All true, and they show the problem I'm addressing. If we have a protocol
for asking for a CRL (or OCSP response), and that protocol might return
out-of-date information, and the user has no way to know if it is out of
date, it is a security problem that needs to be discussed in the security
section of the relevant document. For protocols for which this won't
happen, we don't need to bring it up.

>It is a genuine problem but it's place is in PKIX part 1.

I don't think so. It only appears after a request from a user for the CRL,
and only appears in one protocol, HTTP (and only appears in broken
implementations of it, of which there are many). That is, the problem does
not appear until a requestor asks a CA for the latest CRL and gets
something different.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 21 Apr 1998 08:32:50 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

One assumption was that a CA acting as its own responder for OCSP would be able to give spontaneous certificate status even if that status was not yet reflected on a published CRL - kind of searching its pre-CRL building store or a database where status was linked to each cert.  In a case of a CA supporting OCSP-only, CRLs were not even necessary, since the status could be tied to each cert, for real-time responses and no need for ZCRL processing at all.  I do not know the status of that model.

Michael

>>> <[email-masked]> 04/21/98 02:41AM >>>
I get the feeling that we're somehow going in circles with this issue.

In order to solve the inherent problems with CRLs (off-line distribution),
OCSP was introduced. Now the relying party could check the status
of a certificate at any time by a direct question to the CA.

Why then bother with issuing of new CRLs before the old one has
expired? It doesn't sound wise to me. What legal implications will
that have given the situation where a relying party have accepted
a certificate on the basis of a current (but old) CRL? I would say that
this is also a policy issue.

And on top of this, I've also noted a new draft on how to cache OCSP
messages...

Will the circle (ever) be unbroken?

I'm afraid that we'll end up in a situation where every single information
exchanged on the Internet needs a time stamp.

Lars Johansson
Sweden Post

----------
[email-masked] wrote:
>
> At 04:36 PM 4/20/98 -0700, Michael Myers wrote:
> >One the primary reasons a CRL is signed in the first place is to relieve any
> >repository containing them of security requirements.  A certificate
> >processing system determines that a CRL is expired by examining nextUpdate.
> >This value is protected by CA signature, not by presumptions of the
> >functional correctness or assurances provided by the security architecture
> >of the repository.
>
> Absolutely true. And completely unrelated to the security issue I brought up.
>
> >If a repository provides an old CRL instead of a new CRL, then one of two
> >cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
> >with respect to the current system time of the certificate processing
> >software or it isn't.  If it is, an exception condition should be raised.
> >If not, the information in the old CRL is still reliable.
>
> Reliable, but probably incomplete. There are three cases, not just the two
> you describe. The third case, which I describe in my suggested wording for
> the draft, is that a CA has issued a new CRL at a time before the
> nextUpdate of the previous CRL. If the CA issued a new CRL before the
> nextUpdate time of the previous one, it is probably due to additions to the
> list. That is expressly allowed by PKIX part 1.
>
> Let me try this graphically:
>
> CRL(cRLNumber=42, thisUpdate=5/10/98, nextUpdate=6/10/98) has 300 
names on it.
> CRL(cRLNumber=43, thisUpdate=5/15/98, nextUpdate=6/10/98) has 310 
names on it.
>
> A bad HTTP proxy that has a request for the CRL has cached CRL 42. On
> 5/20/98, a request for the CRL comes in, and the proxy sends back CRL 42
> without checking with the main server. The requestor doesn't find the
> desired cert on the list and assumes it hasn't been revoked. However, that
> cert is among the 10 new certs on the list. The nextUpdate is in the
> future, so they have no reason to think that this CRL is stale.
>
> This situation has the same result as the requestor saying "hmm, since the
> nextUpdate on the CRL is in the future, I must have the current CRL," which
> is the wrong interpretation of nextUpdate, as we all know. It won't happen
> if the proxy cache does the right thing, or if there is no proxy cache, but
> if a bad proxy cache does this, there is absolutely no way for the
> requestor to find out about it. Thus, the security warning.
>
> And, yes, this is the same problem with OCSP responses in a bad proxy cache.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

Date: Tue, 21 Apr 1998 08:24:51 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Bob:

Isn't the off-schedule CRL considered a delta-CRL (even if it contains the complete set of records)?  If so, then doesn't the reply also have to include the last "full" CRL produced in its response as well?

If the "nextUpdate" can not be relied on for the next update, then its meaning is not to be relied on.

Michael

>>> "Bob Jueneman" <[email-masked]> 04/20/98 07:21PM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************

Date: Tue, 21 Apr 1998 12:14:42 +0200
From: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
To: pkix <[email-masked]>
Subject: Re: [IETF-PKIX] Subject/Issuer Name Population
Sender: [email-masked]

Tim Polk wrote:
> 
> I have attached proposed text for the issuer and subject name sections.
> 
> Highlights:
> 
> (1) issuer name is required (that is, may not be an empty SEQUENCE).
Do we need this or can we loosen it a little? I am thinking of CAs that
just have DNS name (which is also hierarchical and unique and thus
similar to a DN)? Should we say that the name should be globally unique
and that only on alternative name should be present if the DN is empty?

> (2) subject name is required for CA certs.  (This means you never chain off
> altnames!)
see above.

> (3) Name comparison rules are greatly relaxed from the X.520 text.  Binary
> comparison of attribute values is permitted for everything except
> PrintableString. That is, no white space compression or case conversion in
> BMP or UTF8.
> 
> (Rationale for PrintableString:  It has already been implemented, and is
> used in practically all certificates.  Upper and lowercase country codes,
> etc. will break if we don't support it.)
> 
> Please take the time to review the text.
Regarding the subject name in end entity certificates:

   Where it is non-null, the subject name field shall contain an X.500
   distinguished name (DN). The DN must be unique for each subject
   entity certified by the one CA as defined by the issuer name field.
   (A CA may issue more than one certificate with the same DN to the
   same subject entity.)

I think we should not make requirements for the DN stored in the subject
field, since too many implementations out there use the DN
(subject/issuer) with any kind of semantic they want.

Question:

Isn't the alternative name field "directoryName" the right place to
state that "This is a Distinguished Name in the X.500 sense, additional
information about the subject can be found here".

A different question:

Has anybody "real world" solutions for identifying subject of
certificate (i.e. end-entities). I am thinking of the following cases:

- a person with a company affiliation (most of X.500 seems to be fixed
on this).
Problems: Name ambiguities, do we give people a number...?

- a person with no company affiliation, but with place and date of
birth. While the generic attributes of DNames can be (somewhat hard)
pressed to store this kind of information, I do not think this is a
satisfactory solution

- a person with an address. Same problems as above.

- a person with an address and an addtional qualifier (such as medical
doctor).

The lowest common denominator between implementations usually is the
subject name (display to the user) and hopefully the PKIX alternative
names. So when specific application domains want to be compatible with
the generic PKIX structure, most of the information probably needs to go
into the subject name. So it is (other than in closed user groups) not
advisable to extend the alternative name construct to contain important
information.

Example:

We are working on a specification for certificates that are to be used
with the German Signature Law. The X.509 profile for this application
should be compatible with PKIX requirements (we are trying to do this).
This would allow people to use their Signature certificate with all
applications, especially electronic mail. This implies that PKIX
implementations should be able to verify signatures associated with SigG
(Signature Law) certificates.

Our solution so far is to give examples of how to construct the subject
Distinguished Name to contain the necessary attributes. The goal here is
that the information about the subject is similar to information used in
the physical world (i.e. street address). This information is - in the
technical sense - not unique (cannot be used as a DN in X.500). But for
all practical purposes, it is.

Andreas
-- 
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Date: Tue, 21 Apr 1998 11:40:54 +0200
From: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
To: pkix <[email-masked]>
Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 08:48 AM 4/17/98 -0700, you wrote:
> >And in the event a client receives {is revoked, not issued}, which
> >dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
> >is no problem.
> 
> To the client, "not issued" is always more important than revoked or not
> revoked. We can put that in the OCSP spec.
> 
> >As soon as OCSP clients are out there in any volume, there
> >are those who will seek to determine the client's behavior in fringe cases.
> 
> I fully agree. That's why I'm I don't think that issued/not issued should
> be a MAY: I think it has to be a MUST. We can be sure that some clients
> will blow the comparison unless they are always told whether or not the
> cert was even issued.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
Paul, I disagree.

The issued/not issued flag can only be answered by a small set of OCSP
responders. Let's take - for example - a company that operates an OCSP
responder of some of the most frequently used CAs in the world. It load
their CRLs to reduce communication cost and offers these "CRLs on-line"
to the internal client software (thus lowering the maintainance cost to
distribute CRLs to all clients). Given a specific certificate, such an
OCSP responder can only answer the question of revocation (revoked/not
revoked) on the basis of the CRL (so revoked is: on the list, not
revoked is: not on the list).

So probably we need some kind of "don't know" of the OCSP responder.

Regarding the question above: when a certificate was "not issued" this
is a no-go for the verification process. I think that we could drop any
other answers if the certificate was never issued. This is different for
"issued: don't know" and "issued: yes".

Andreas
-- 
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

From: [email-masked]
Date: Tue, 21 Apr 1998 10:41:42 +0200
Subject: RE: Security section of draft-ietf-pkix-opp-ftp-http
TO: [email-masked], [email-masked]
Sender: [email-masked]

I get the feeling that we're somehow going in circles with this issue.

In order to solve the inherent problems with CRLs (off-line distribution),
OCSP was introduced. Now the relying party could check the status
of a certificate at any time by a direct question to the CA.

Why then bother with issuing of new CRLs before the old one has
expired? It doesn't sound wise to me. What legal implications will
that have given the situation where a relying party have accepted
a certificate on the basis of a current (but old) CRL? I would say that
this is also a policy issue.

And on top of this, I've also noted a new draft on how to cache OCSP
messages...

Will the circle (ever) be unbroken?

I'm afraid that we'll end up in a situation where every single information
exchanged on the Internet needs a time stamp.

Lars Johansson
Sweden Post

----------
[email-masked] wrote:
>
> At 04:36 PM 4/20/98 -0700, Michael Myers wrote:
> >One the primary reasons a CRL is signed in the first place is to relieve any
> >repository containing them of security requirements.  A certificate
> >processing system determines that a CRL is expired by examining nextUpdate.
> >This value is protected by CA signature, not by presumptions of the
> >functional correctness or assurances provided by the security architecture
> >of the repository.
>
> Absolutely true. And completely unrelated to the security issue I brought up.
>
> >If a repository provides an old CRL instead of a new CRL, then one of two
> >cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
> >with respect to the current system time of the certificate processing
> >software or it isn't.  If it is, an exception condition should be raised.
> >If not, the information in the old CRL is still reliable.
>
> Reliable, but probably incomplete. There are three cases, not just the two
> you describe. The third case, which I describe in my suggested wording for
> the draft, is that a CA has issued a new CRL at a time before the
> nextUpdate of the previous CRL. If the CA issued a new CRL before the
> nextUpdate time of the previous one, it is probably due to additions to the
> list. That is expressly allowed by PKIX part 1.
>
> Let me try this graphically:
>
> CRL(cRLNumber=42, thisUpdate=5/10/98, nextUpdate=6/10/98) has 300 
names on it.
> CRL(cRLNumber=43, thisUpdate=5/15/98, nextUpdate=6/10/98) has 310 
names on it.
>
> A bad HTTP proxy that has a request for the CRL has cached CRL 42. On
> 5/20/98, a request for the CRL comes in, and the proxy sends back CRL 42
> without checking with the main server. The requestor doesn't find the
> desired cert on the list and assumes it hasn't been revoked. However, that
> cert is among the 10 new certs on the list. The nextUpdate is in the
> future, so they have no reason to think that this CRL is stale.
>
> This situation has the same result as the requestor saying "hmm, since the
> nextUpdate on the CRL is in the future, I must have the current CRL," which
> is the wrong interpretation of nextUpdate, as we all know. It won't happen
> if the proxy cache does the right thing, or if there is no proxy cache, but
> if a bad proxy cache does this, there is absolutely no way for the
> requestor to find out about it. Thus, the security warning.
>
> And, yes, this is the same problem with OCSP responses in a bad proxy cache.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

Date: Tue, 21 Apr 1998 11:26:32 +0300
From: Moshe Litvin <[email-masked]>
To: [email-masked]
Subject: Re: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Paul,

The problem you describe is inherent to CRL and not to the distribution
method. If a CA issues a CRL before the nextUpdate there is no way it
can make sure that all the relying parties will use it. It can be
because of a non-conformant HTTP proxy, a malicious HTTP proxy,  someone
who managed to put write the old CRL back in the directory, or someone
who managed to block the communication between the CA and the directory
at the relevant time to the distribution of the new CRL.

It is a genuine problem but it's place is in PKIX part 1.

Moshe

Paul Hoffman / IMC wrote:
> 
> Russ' "how to get certs and CRLs over FTP and HTTP" draft seems fine, but
> the Security section is incomplete. Specifically, it doesn't mention the
> hidden security problems that HTTP proxy caches can introduce. I propose
> that the following be added to the Security section:
> 
> The HTTP 1.1 protocol specifically allows HTTP proxies to cache responses
> for repeated requests for URLs. Although RFC 2068 carefully specifies how
> HTTP proxies should work, there are many non-conformant proxies in use on
> the Internet. A non-conformant HTTP proxy can have serious security
> implications for requesting CRLs. If a new CRL is issued before the
> nextUpdate time in a CRL, but an HTTP proxy incorrectly gives the requestor
> an older CRL, the requestor will get wrong revocation information and will
> have no way of knowing that the information is out of date. CRL
> distributors following this specification have no way of forcing the latest
> CRL through to a requestor.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

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

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

Date: Tue, 21 Apr 1998 10:03:21 +0300
From: Moshe Litvin <[email-masked]>
To: Ian Roberts <[email-masked]>
CC: [email-masked]
Subject: Re: [IETF-PKIX] Key Identifiers
Sender: [email-masked]

Robert,

A little math: Assume that we are talking about 512 bits RSA keys, the
number of prime number < n is about n/ln n. So the number of prime
number of 256 bits is about 2^256/ln 256 > 2^248. Even if we take only
the primes that are exactly 256 bits it is  > 2^246, which means that
the number of RSA keys of 512 bits is > 2^492. 

Now what are the chances of key collision?

Moshe

Ian Roberts wrote:
> 
> >From: [email-masked]
> >To: Ian Roberts
> >Subject: Re: [IETF-PKIX] Key Identifiers
> >Date: 20 April 1998 15:01
> >
> >>>>>> "Ian" == Ian Roberts <[email-masked]> writes:
> >
> > Ian> The discussion on Key Identifiers lead me down the following
> > Ian> chain of thought;
> >
> > Ian> If the Key Identifier is useful for building a path, then it
> > Ian> would be useful to be able to query a directory server for
> > Ian> certificates containing keys with a given key identifier.
> >
> > Ian> If directory servers become sufficiently large (for example, the
> > Ian> size of the Altavista search engine) then a lookup of a large
> > Ian> number of certificates by Key Identifier should be possible
> > Ian> within a couple of seconds (with many occurring concurrently).
> >
> > Ian> If the directory server contained 200 million certificates, then
> > Ian> a possible attack would be to generate key sets and then query
> > Ian> the directory server for matches.  This would give someone with
> > Ian> a fairly low-spec machine the ability to search several hundred
> > Ian> million keys per second.
> >
> >Ian,
> >
> >It sounds like you're thinking about some sort of attack on
> >something.  But I can't figure out what you're attacking and how.
> >
> >    paul
> >
> >
> 
> Sorry, from where I was standing it looked clear, but then these odd
> thoughts always do :-)
> 
> Conventional key search attacks focus a lot of CPU power toward cracking a
> single key set.  It is the cost of this CPU time that is the deterrent and
> hopefully stops low-budget individuals from using this method.
> 
> However, where someone has access to a large directory server, where
> certificate retrievals can be done by Key Identifier (where the key
> identifier is the SHA-1 hash of the public key), then a low power CPU can be
> use to generate key sets (slowly) and the key identifier, and then use the
> directory server to see if any certificates exist with the same Key
> Identifier - any which are found can then be compared for public key
> equality.  For any match you have then discovered the private key for that
> certificate.
> 
> This technique would not aid anyone in cracking a particular key, but could
> be used in an attempt to crack any key held in a directory.
> 
> For example
> 
> With a single budget PC you could generate a key set, say every 5 seconds,
> they can then use the directory server to see if that key set matches any of
> the (say) 200 million certificates on the server (on a server the size of
> Altavista, in a couple of seconds), thus they can in effect try 40 million
> keys per second, using someone else's CPU power.  The key identifier is not
> unique, but a check for quality of public would soon show if you have
> discovered someone's key set.
> 
> Hope this is clearer,
> 
> Ian Roberts
> 
> --
> Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
> Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
> Website:  http://www.zergo.com

Date: Mon, 20 Apr 1998 22:32:23 -0700 (PDT)
From: Surendra Reddy <[email-masked]>
To: [email-masked]
Subject: Web based Certificate Access Protocol - WebCAP
Sender: [email-masked]

I have submitted "Web based Certificate Access Protocol - WebCAP" as an
I-D. It is now available at 
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-webcap-00.txt. This
is a sketchy version and objective of this draft is to come up with
a single protocol that meets PKIX Certicate Management Protocol
requirements in highly scalable and distributed environment. 

All the work/discussions done on OCSP can be integrated
into this protocol and we can merge OCSP and WebCAP into a single
proposal.

My next version of this document will cover all aspects
of PKIX Certificate Management Protocol. 

- Surendra
.......................................................
Surendra K Reddy		phone:  +1(650) 506 5441
Development Manager		mobile: +1(650) 867 4757
Internet Applications Division  email(oracle): [email-masked]	
Oracle Corporation		email(inet)  : [email-masked]

To: "Pkix List (E-mail)" <[email-masked]>
Subject: Re: OCSP Response Values and Structure 
Date: Mon, 20 Apr 1998 18:29:58 -0700
From: Marc Branchaud <[email-masked]>
Sender: [email-masked]

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

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

"Michael Myers" <[email-masked]> scrawled:
> 
> In reviewing comments to date so that we can move forward on the OCSP
> editing task,  the rough consensus appears to be as follows regarding OCSP
> response structure:
> 
> revocationStatus     {revoked, notRevoked, . . . }
> expirationStatus     {notYetValid, expired,  . . . }
> issuedStatus         {issued, notIssued, . . . }
> 

What do the ellipses stand for?

                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

Date: Mon, 20 Apr 1998 19:21:16 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Michael, I'm not entirely sure I agree with your semantics.=20
Maybe I've missed something, but I always interpreted=20
the traditional CRL nextUpdate semantics to mean "if you=20
haven't gotten an new CRL by this time, you are potentially=20
missing something", not "I'm not going to have another=20
word to say on this subject until this time, even if the world=20
is about to come to an end."

In other words, I believe that a CA (at least some CAs)=20
would feel that they are allowed, and perhaps even=20
compelled, to issue a CRL PRIOR to the time of the=20
nextUpdate, especially in the event of a known key=20
compromise. Certainly I would take my business elsewhere=20
if a CA or repository would not provide me that service.

I haven't followed the OCSP discussion that closely,=20
I'm afraid, but surely the semantics haven't changed
all that much?

bob

>>> "Michael Myers" <[email-masked]> 04/20 5:36 PM >>>
Paul,

One the primary reasons a CRL is signed in the first place is to relieve =
any
repository containing them of security requirements.  A certificate
processing system determines that a CRL is expired by examining nextUpdate.=

This value is protected by CA signature, not by presumptions of the
functional correctness or assurances provided by the security architecture
of the repository.

If a repository provides an old CRL instead of a new CRL, then one of two
cases will occur.  Either the old CRL is expired (as defined by nextUpdate)=

with respect to the current system time of the certificate processing
software or it isn't.  If it is, an exception condition should be raised.
If not, the information in the old CRL is still reliable.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Paul Hoffman / IMC
> Sent: Monday, April 20, 1998 3:11 PM
> To: [email-masked]=20
> Subject: Security section of draft-ietf-pkix-opp-ftp-http
>
>
> Russ' "how to get certs and CRLs over FTP and HTTP" draft seems fine, =
but
> the Security section is incomplete. Specifically, it doesn't mention the
> hidden security problems that HTTP proxy caches can introduce. I propose
> that the following be added to the Security section:
>
> The HTTP 1.1 protocol specifically allows HTTP proxies to cache =
responses
> for repeated requests for URLs. Although RFC 2068 carefully specifies =
how
> HTTP proxies should work, there are many non-conformant proxies in use =
on
> the Internet. A non-conformant HTTP proxy can have serious security
> implications for requesting CRLs. If a new CRL is issued before the
> nextUpdate time in a CRL, but an HTTP proxy incorrectly gives the
> requestor
> an older CRL, the requestor will get wrong revocation information and =
will
> have no way of knowing that the information is out of date. CRL
> distributors following this specification have no way of forcing
> the latest
> CRL through to a requestor.
>
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

Date: Mon, 20 Apr 1998 17:25:51 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

At 04:36 PM 4/20/98 -0700, Michael Myers wrote:
>One the primary reasons a CRL is signed in the first place is to relieve any
>repository containing them of security requirements.  A certificate
>processing system determines that a CRL is expired by examining nextUpdate.
>This value is protected by CA signature, not by presumptions of the
>functional correctness or assurances provided by the security architecture
>of the repository.

Absolutely true. And completely unrelated to the security issue I brought up.

>If a repository provides an old CRL instead of a new CRL, then one of two
>cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
>with respect to the current system time of the certificate processing
>software or it isn't.  If it is, an exception condition should be raised.
>If not, the information in the old CRL is still reliable.

Reliable, but probably incomplete. There are three cases, not just the two
you describe. The third case, which I describe in my suggested wording for
the draft, is that a CA has issued a new CRL at a time before the
nextUpdate of the previous CRL. If the CA issued a new CRL before the
nextUpdate time of the previous one, it is probably due to additions to the
list. That is expressly allowed by PKIX part 1.

Let me try this graphically:

CRL(cRLNumber=42, thisUpdate=5/10/98, nextUpdate=6/10/98) has 300 names on it.
CRL(cRLNumber=43, thisUpdate=5/15/98, nextUpdate=6/10/98) has 310 names on it.

A bad HTTP proxy that has a request for the CRL has cached CRL 42. On
5/20/98, a request for the CRL comes in, and the proxy sends back CRL 42
without checking with the main server. The requestor doesn't find the
desired cert on the list and assumes it hasn't been revoked. However, that
cert is among the 10 new certs on the list. The nextUpdate is in the
future, so they have no reason to think that this CRL is stale.

This situation has the same result as the requestor saying "hmm, since the
nextUpdate on the CRL is in the future, I must have the current CRL," which
is the wrong interpretation of nextUpdate, as we all know. It won't happen
if the proxy cache does the right thing, or if there is no proxy cache, but
if a bad proxy cache does this, there is absolutely no way for the
requestor to find out about it. Thus, the security warning.

And, yes, this is the same problem with OCSP responses in a bad proxy cache.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Michael Myers" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, <[email-masked]>
Subject: RE: Security section of draft-ietf-pkix-opp-ftp-http
Date: Mon, 20 Apr 1998 16:36:12 -0700
Importance: Normal
Sender: [email-masked]

Paul,

One the primary reasons a CRL is signed in the first place is to relieve any
repository containing them of security requirements.  A certificate
processing system determines that a CRL is expired by examining nextUpdate.
This value is protected by CA signature, not by presumptions of the
functional correctness or assurances provided by the security architecture
of the repository.

If a repository provides an old CRL instead of a new CRL, then one of two
cases will occur.  Either the old CRL is expired (as defined by nextUpdate)
with respect to the current system time of the certificate processing
software or it isn't.  If it is, an exception condition should be raised.
If not, the information in the old CRL is still reliable.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Paul Hoffman / IMC
> Sent: Monday, April 20, 1998 3:11 PM
> To: [email-masked]
> Subject: Security section of draft-ietf-pkix-opp-ftp-http
>
>
> Russ' "how to get certs and CRLs over FTP and HTTP" draft seems fine, but
> the Security section is incomplete. Specifically, it doesn't mention the
> hidden security problems that HTTP proxy caches can introduce. I propose
> that the following be added to the Security section:
>
> The HTTP 1.1 protocol specifically allows HTTP proxies to cache responses
> for repeated requests for URLs. Although RFC 2068 carefully specifies how
> HTTP proxies should work, there are many non-conformant proxies in use on
> the Internet. A non-conformant HTTP proxy can have serious security
> implications for requesting CRLs. If a new CRL is issued before the
> nextUpdate time in a CRL, but an HTTP proxy incorrectly gives the
> requestor
> an older CRL, the requestor will get wrong revocation information and will
> have no way of knowing that the information is out of date. CRL
> distributors following this specification have no way of forcing
> the latest
> CRL through to a requestor.
>
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

From: "Michael Myers" <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: OCSP Response Values and Structure
Date: Mon, 20 Apr 1998 16:14:04 -0700
Importance: Normal
Sender: [email-masked]

In reviewing comments to date so that we can move forward on the OCSP
editing task,  the rough consensus appears to be as follows regarding OCSP
response structure:

revocationStatus     {revoked, notRevoked, . . . }
expirationStatus     {notYetValid, expired,  . . . }
issuedStatus         {issued, notIssued, . . . }

Date: Mon, 20 Apr 1998 15:11:04 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Security section of draft-ietf-pkix-opp-ftp-http
Sender: [email-masked]

Russ' "how to get certs and CRLs over FTP and HTTP" draft seems fine, but
the Security section is incomplete. Specifically, it doesn't mention the
hidden security problems that HTTP proxy caches can introduce. I propose
that the following be added to the Security section:

The HTTP 1.1 protocol specifically allows HTTP proxies to cache responses
for repeated requests for URLs. Although RFC 2068 carefully specifies how
HTTP proxies should work, there are many non-conformant proxies in use on
the Internet. A non-conformant HTTP proxy can have serious security
implications for requesting CRLs. If a new CRL is issued before the
nextUpdate time in a CRL, but an HTTP proxy incorrectly gives the requestor
an older CRL, the requestor will get wrong revocation information and will
have no way of knowing that the information is out of date. CRL
distributors following this specification have no way of forcing the latest
CRL through to a requestor.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject:  pkix subject \ issuer names and RFC2247
Date: Mon, 20 Apr 1998 14:27:35 -0700
Sender: [email-masked]

Dave,
Since we have a rfc which deals with using internet domain names within a
distinguished name, it would seem rather strange that a subsequent IETF
standard would exclude the use of this rfc on the grounds of what names the
ITU support. From my simple perspective all we have to do is add domain
component to the list of supported attributes in a general name.
Trevor

Date: Mon, 20 Apr 1998 13:45:42 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [IETF-PKIX] Key Identifiers
Sender: [email-masked]

Well, 3DES is considered extremely secure against exhaustive search, with =
only 2^128 bits of key. So 2^10124 bits would be one hell of a lot better!

It's more effective as a time waster at the server, unless, of course, a =
flaw in the key geneatin code generates non-random keys.

Bob

>>> Tony Bartoletti <[email-masked]> 04/20 11:59 AM >>>
At 11:02 AM 4/20/98 -0600, Bob Jueneman wrote:
>Ian,
>
>I assume that you are not attacking the public keys directly, but rather
hoping that someone used a poor random number generator in generating =
them?
 Even so, this siounds more like a denial of service attack than a
cryptanalytic attack.
>
>Bob=20

Bob,

I think Ian is saying that if one generates a key-pair, and given a Key-ID
is a hash or otherwise deterministic function of the public key, one could
query the universe of certified keys and perhaps, by chance, come across
a certificate (perhaps your certificate) with matching key-ID and public
key, and thereby deduce that they have your private key.

Personally, I believe (hope?) that the space of possible key-pairs is
so very large that even 200 million is a very minute fraction of the
space, too sparce to hope for a random match.  But then, I haven't done
the math yet.

I don't see the lookup as a denial of service, (it amazes me how search-
engines have done such efficient pre-indexing that they can quickly repond
with "1,254,867 documents matched you query.  Next 10 matches?")

Of course, if I have your private key, it is compromised.  So I could send
a signed "revoke this key" message to the CA.  I suppose that would be a
charitable form of denial of service.

___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

Date: Mon, 20 Apr 1998 10:59:03 -0700
To: "Bob Jueneman" <[email-masked]>, [email-masked], [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: [IETF-PKIX] Key Identifiers
Sender: [email-masked]

At 11:02 AM 4/20/98 -0600, Bob Jueneman wrote:
>Ian,
>
>I assume that you are not attacking the public keys directly, but rather
hoping that someone used a poor random number generator in generating them?
 Even so, this siounds more like a denial of service attack than a
cryptanalytic attack.
>
>Bob 

Bob,

I think Ian is saying that if one generates a key-pair, and given a Key-ID
is a hash or otherwise deterministic function of the public key, one could
query the universe of certified keys and perhaps, by chance, come across
a certificate (perhaps your certificate) with matching key-ID and public
key, and thereby deduce that they have your private key.

Personally, I believe (hope?) that the space of possible key-pairs is
so very large that even 200 million is a very minute fraction of the
space, too sparce to hope for a random match.  But then, I haven't done
the math yet.

I don't see the lookup as a denial of service, (it amazes me how search-
engines have done such efficient pre-indexing that they can quickly repond
with "1,254,867 documents matched you query.  Next 10 matches?")

Of course, if I have your private key, it is compromised.  So I could send
a signed "revoke this key" message to the CA.  I suppose that would be a
charitable form of denial of service.

___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

Date: Mon, 20 Apr 1998 11:02:45 -0600
From: "Bob Jueneman" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [IETF-PKIX] Key Identifiers
Sender: [email-masked]

Ian,

I assume that you are not attacking the public keys directly, but rather =
hoping that someone used a poor random number generator in generating =
them?  Even so, this siounds more like a denial of service attack than a =
cryptanalytic attack.

Bob=20

>>> Ian Roberts <[email-masked]> 04/20 10:21 AM >>>

>From: [email-masked]=20
>To: Ian Roberts
>Subject: Re: [IETF-PKIX] Key Identifiers
>Date: 20 April 1998 15:01
>
>>>>>> "Ian" =3D=3D Ian Roberts <[email-masked]> writes:
>
> Ian> The discussion on Key Identifiers lead me down the following
> Ian> chain of thought;
>
> Ian> If the Key Identifier is useful for building a path, then it
> Ian> would be useful to be able to query a directory server for
> Ian> certificates containing keys with a given key identifier.
>
> Ian> If directory servers become sufficiently large (for example, the
> Ian> size of the Altavista search engine) then a lookup of a large
> Ian> number of certificates by Key Identifier should be possible
> Ian> within a couple of seconds (with many occurring concurrently).
>
> Ian> If the directory server contained 200 million certificates, then
> Ian> a possible attack would be to generate key sets and then query
> Ian> the directory server for matches.  This would give someone with
> Ian> a fairly low-spec machine the ability to search several hundred
> Ian> million keys per second.
>
>Ian,
>
>It sounds like you're thinking about some sort of attack on
>something.  But I can't figure out what you're attacking and how.
>
>    paul
>
>

Sorry, from where I was standing it looked clear, but then these odd=20
thoughts always do :-)

Conventional key search attacks focus a lot of CPU power toward cracking =
a=20
single key set.  It is the cost of this CPU time that is the deterrent =
and=20
hopefully stops low-budget individuals from using this method.

However, where someone has access to a large directory server, where=20
certificate retrievals can be done by Key Identifier (where the key=20
identifier is the SHA-1 hash of the public key), then a low power CPU can =
be=20
use to generate key sets (slowly) and the key identifier, and then use =
the=20
directory server to see if any certificates exist with the same Key=20
Identifier - any which are found can then be compared for public key=20
equality.  For any match you have then discovered the private key for =
that=20
certificate.

This technique would not aid anyone in cracking a particular key, but =
could=20
be used in an attempt to crack any key held in a directory.

For example

With a single budget PC you could generate a key set, say every 5 =
seconds,=20
they can then use the directory server to see if that key set matches any =
of=20
the (say) 200 million certificates on the server (on a server the size =
of=20
Altavista, in a couple of seconds), thus they can in effect try 40 =
million=20
keys per second, using someone else's CPU power.  The key identifier is =
not=20
unique, but a check for quality of public would soon show if you have=20
discovered someone's key set.

Hope this is clearer,

Ian Roberts

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com=20

From: Ian Roberts <[email-masked]>
Date: Mon, 20 Apr 1998 17:02:09 +0000
To: [email-masked]
Subject: Certificate Paths
Sender: [email-masked]

When attempting to build a certificate path in order to validate a=20
certificate I am looking at the following approach

Given two sets, F, U where the initial state is F is the empty set and U=20
contains the certificate you wish to validate=2E

1) While U is not empty;

2) Select a Certificate, C,  from U=2E  Remove C from U and add to F=2E

3) Fetch all of the certificates belonging to the issuer (set P)

4) Reduce P by removing all certificates from P that are not valid in=20
themselves (date, key usage etc)=2E

5) Reduce P by removing all certificates from P that are already in F=2E

6) Reduce P to contain only those certificates which contain a public key=20
that verifies C=2E

7) Add P to U=2E

8) Wend=2E

If intersection of the set F with the set of explicitly trusted (usually=20
root CA) certificates is not empty then we were able to build one or more=20
validation path(s)=2E

I believe that this will work with cross certification=2E

Following the discussion on Key Identifiers I looked at optimising this=20
using key identifiers=2E

The most obvious solution is to include an additional Reduction of P

5b) If C contains a AuthorityKeyIdentifier, Reduce P by removing all=20
certificates which contain a KeyIdentifier which does not match=2E

This however does not address the comment Denis=2EPinkas@bull=2Enet made

>As said above, no verification of digital signature should be done
>before getting a full path=2E This saves signature checks (as requested by
>Paul Koning) without the need to overload the certificate by additional
>mandatory extensions (that take memory place when the certificate is
>stored in a smart card)=2E

since 6 would still require potentially spurious verifies=2E

All the other solutions I have looked at involve the fetching of=20
certificates which are not required by the solution above since deferring=20
(6) always has the potential to increase the size of P=2E  However,=20
certificate fetches (e=2Eg=2E via LDAP, approx 90ms to our local directory=20
server) may be more expensive than a verify (appox 20ms in our current=20
implementation)=2E

aberger@DARMSTADT=2EGMD=2EDE wrote:
> One question: Do we have an algorithm for a complete verification? There
> is one that describes how to verify an existing FC path, but do we have
> an algorithm on how to construct a path?

I agree that we need such an algorithm, however I think that it should be=20
expressed as simply as possible and optimizations be left to the implemento=
r=20
(they can decide if certificate fetches are more expensive than verifies)=2E

The algorithm above does not build a single path, it collects all=20
certificate from the subject up to all self-signed certificates that could=20
form valid paths (you can work back down from any trusted root certificate=20
in the final intersection  to build a path)=2E

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants=2E RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www=2Ezergo=2Ecom

Date: Mon, 20 Apr 1998 08:45:16 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: I-D ACTION:draft-ietf-pkix-ocsp-caching-00.txt
Sender: [email-masked]

[[It appears that the Internet Drafts editor does not have the right
mailing address
for the mailing list. So, I'm copying it here from the IETF-Announce list.
--Paul Hoffman]]

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ocsp-caching-00.txt
Date: Mon, 20 Apr 1998 09:48:26 -0400
Sender: [email-masked]
:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group 
of the IETF.

	Title		: Internet Public Key Infrastructure Caching the 
                          Online Certificate Status Protocol
	Author(s)	: M. Branchard
	Filename	: draft-ietf-pkix-ocsp-caching-00.txt
	Pages		: 27
	Date		: 17-Apr-98
	
   The Online Certificate Status Protocol [OCSP] specifies how a client
   process may obtain certificate status information online from a
   server.  In order for OCSP to scale beyond small communities of
   users, a method to cache certificate status information at
   intermediary servers is required.
 
   This document describes the requirements of and assumptions behind
   OCSP caching, and defines the mechanisms through which such caching
   can be accomplished.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-ocsp-caching-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-caching-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: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ocsp-caching-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.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ocsp-caching-00.txt

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-caching-00.txt>

From: Ian Roberts <[email-masked]>
Date: Mon, 20 Apr 1998 16:21:54 +0000
To: [email-masked]
Subject: Re: [IETF-PKIX] Key Identifiers
Sender: [email-masked]

>From: pkoning@xedia=2Ecom
>To: Ian Roberts
>Subject: Re: [IETF-PKIX] Key Identifiers
>Date: 20 April 1998 15:01
>
>>>>>> "Ian" =3D=3D Ian Roberts <iroberts@ZERGO=2ECOM> writes:
>
> Ian> The discussion on Key Identifiers lead me down the following
> Ian> chain of thought;
>
> Ian> If the Key Identifier is useful for building a path, then it
> Ian> would be useful to be able to query a directory server for
> Ian> certificates containing keys with a given key identifier=2E
>
> Ian> If directory servers become sufficiently large (for example, the
> Ian> size of the Altavista search engine) then a lookup of a large
> Ian> number of certificates by Key Identifier should be possible
> Ian> within a couple of seconds (with many occurring concurrently)=2E
>
> Ian> If the directory server contained 200 million certificates, then
> Ian> a possible attack would be to generate key sets and then query
> Ian> the directory server for matches=2E  This would give someone with
> Ian> a fairly low-spec machine the ability to search several hundred
> Ian> million keys per second=2E
>
>Ian,
>
>It sounds like you're thinking about some sort of attack on
>something=2E  But I can't figure out what you're attacking and how=2E
>
>    paul
>
>

Sorry, from where I was standing it looked clear, but then these odd=20
thoughts always do :-)

Conventional key search attacks focus a lot of CPU power toward cracking a=20
single key set=2E  It is the cost of this CPU time that is the deterrent an=
d=20
hopefully stops low-budget individuals from using this method=2E

However, where someone has access to a large directory server, where=20
certificate retrievals can be done by Key Identifier (where the key=20
identifier is the SHA-1 hash of the public key), then a low power CPU can b=
e=20
use to generate key sets (slowly) and the key identifier, and then use the=20
directory server to see if any certificates exist with the same Key=20
Identifier - any which are found can then be compared for public key=20
equality=2E  For any match you have then discovered the private key for tha=
t=20
certificate=2E

This technique would not aid anyone in cracking a particular key, but could=
=20
be used in an attempt to crack any key held in a directory=2E

For example

With a single budget PC you could generate a key set, say every 5 seconds,=20
they can then use the directory server to see if that key set matches any o=
f=20
the (say) 200 million certificates on the server (on a server the size of=20
Altavista, in a couple of seconds), thus they can in effect try 40 million=20
keys per second, using someone else's CPU power=2E  The key identifier is n=
ot=20
unique, but a check for quality of public would soon show if you have=20
discovered someone's key set=2E

Hope this is clearer,

Ian Roberts

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants=2E RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www=2Ezergo=2Ecom

Date: Mon, 20 Apr 1998 16:31:26 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Re: OCSP Status Information on a Certificate
Sender: [email-masked]

Slava,

Thanks for joining us.

(...)

> >  I fully agree. That's why I'm I don't think that issued/not issued
> >  should be a MAY: I think it has to be a MUST. We can be sure that 
> >  some clients will blow the comparison unless they are always told 
> >  whether or not the cert was even issued.

> Are we talking about fat OCSP client here ?
> Does the OCSP client in this case have full certificate chain ?
> Can we safely assume that fat OCSP client will need to verify signatures
> on the chain first, validity and other X509v3 constraints and only then
> submit OCSP request for status of every certificate in the chain ?

You are asking the right questions. 

> If this is so then, essentially, OCSP client is already in the possession
> of the well-formed certificate signed by the (indirectly or directly) 
> trusted CA key. In these circumstances receiving an anwer "not issued"
> may only mean that CA key is compromised and "unathorized" certificate 
> has been signed. But if someone has the CA key and can sign anything 
> with it (including "unathorized" certificates) then that someone can 
> also make sure that "unathorized" certificate has the same serial number
> as one of "authorized" and as long as we only send serial number to 
> identify a certificate in OCSP request the substitution of the 
> "authorized" cert with "unathorized" one will be unnoticed. This makes 
> "never issued" somewhat useless for fat OCSP clients.

> Is this reasoning wrong ?

The reasoning is correct. However I believe that your reasoning is also
valid for the other cases, i.e. I do not see how it is possible to take
a decision to accept a certificate without having that certificate in
hands, and as you correcly indicate you need anyway to verify signatures
on the chain first, validity and other X509v3 constraints. 

> Also since CA archiving capacity is always finite and we also talking
> about allowing "historical" OCSP queries "never issued" will have 
> to be replaced with "info unavailable" at least in some cases. This 
> further redices the value of "never issued" status.

 ... which is useless.

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

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: OCSP Relay
Date: Sat, 18 Apr 1998 11:25:04 -0700
Importance: Normal
Sender: [email-masked]

The assumption that an OCSP requestor is in possession of the certificate in
question potentially precludes chaining of requests.  Consider that it might
be useful to aggregate OCSP requests at the enterprise boundary.  Some of
those certificates may be internally issued, some externally issued.  In the
case of the latter, the corporate OCSP responder could issue a request to
the external CA to acquire that CA's signed response.

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of SGalperin
> Sent: Friday, April 17, 1998 10:54 AM
> To: [email-masked]
> Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
>
>
> In a message dated 98-04-17 12:31:04 EDT, you write:
>
> >
> >  At 08:48 AM 4/17/98 -0700, you wrote:
> >  >And in the event a client receives {is revoked, not issued}, which
> >  >dominates?  Similarly, {not revoked, not issued}.  I remain
> unconvinced
> > this
> >  >is no problem.
> >
> >  To the client, "not issued" is always more important than
> revoked or not
> >  revoked. We can put that in the OCSP spec.
> >
> >  >As soon as OCSP clients are out there in any volume, there
> >  >are those who will seek to determine the client's behavior in fringe
> cases.
> >
> >  I fully agree. That's why I'm I don't think that issued/not
> issued should
> >  be a MAY: I think it has to be a MUST. We can be sure that some clients
> >  will blow the comparison unless they are always told whether or not the
> >  cert was even issued.
> >
>
> Are we talking about fat OCSP client here ?
> Does the OCSP client in this case have full certificate chain ?
> Can we safely assume that fat OCSP client will need to verify
> signatures on
> the chain first, validity and other X509v3 constraints and only
> then submit
> OCSP request for status of every certificate in the chain ?
>
> If this is so then, essentially, OCSP client is already in the
> possession of
> the well-formed certificate signed by the (indirectly or
> directly) trusted CA
> key. In these circumstances receiving an anwer "not issued" may
> only mean that
> CA key is compromised and "unathorized" certificate has been
> signed. But if
> someone has the CA key and can sign anything with it (including
> "unathorized"
> certificates) then that someone can also make sure that "unathorized"
> certificate has the same serial number as one of "authorized" and
> as long as
> we only send serial number to identify a certificate in OCSP request the
> substitution of the "authorized" cert with "unathorized" one will be
> unnoticed. This makes "never issued" somewhat useless for fat
> OCSP clients.
>
> Is this reasoning wrong ?
>
> Also since CA archiving capacity is always finiteand we also talking about
> allowing "historical" OCSP queries "never issued" will have to be replaced
> with "info
> unavailable" at least in some cases. This further redices the
> value of "never
> issued" status.
>
> --Slava Galperin
>

From: "Pawluk, Jean" <[email-masked]>
To: [email-masked]
Subject: FW: Archives and IETF-PKIX handoff.
Date: Fri, 17 Apr 1998 20:45:42 -0500
Sender: [email-masked]

   Howdy to all,

> Now's my chance to finally say a few things on this about to this list
> besides who owns the strange
> email addresses causing so many list error messages.
> 
> I am happy to pass off ownership of this list to Paul and IMC and go
> on a well deserved combination
> of a business/vacation trip for a couple of weeks.
> 
> I have ALL of the archives for the past 2 years on my personal
> machines but since I'm leaving in
> an hour I ask that you co-operate with Paul and help him get the info
> he needs.If there are problems that take a while to figure out with
> the list to send both of us a message so that we can get any of these
> problems worked out.
> 
> Now that I'm not the list owner expect to hear a lot more from Tandem
> on IETF and PKIX,
> 
> Regards
> 
> Jeanne
> 
>  Jean Pawluk 
>  Manager,  Security and Directory Technology Products
>   
>  Tandem Computers,
>  10501 N. Tantau Avenue , Loc 201-1
>  Cupertino, California 95014-0728
>  
>  office (408) 285-2450    fax  (408) 285-2380  pager (408)699-5940    
>  [email-masked]  
> 
> 

Date: Fri, 17 Apr 1998 20:52:50 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Re: New location for the mailing list
Sender: [email-masked]

On behalf of the PKIX Co-Chairs and membership, let me take this
opportunity to express our appreciation to Tandem for all their volunteer
efforts over the past 4 years in hosting the ietf-pkix list.  They have
supported us well since the inception of the PKIX WG.  In particular, let
me thank Jeanne Pawluk for her efforts as the most recent list
administrator.  Supporting a list this size, with very limited resources,
is undoubtedly a major challenge and all to often a thankless effort.

At the same time, let me thank IMC and Paul Hoffman for volunteering to now
take over the list administration.  We greatly appreciate this gesture, and
thank Paul, in particular, for managing such a smooth transition.

Warwick

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

Date: Fri, 17 Apr 1998 17:37:04 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: You don't have to resubscribe
Sender: [email-masked]

Sorry for not being clearer in my earlier message: you do *not* need to
resubscribe. The sysadmin at Tandem got me the current list just before he
shut off subscription processing at Tandem. I had to massage the list (a
lot), but do not think I lost anyone. 

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 17 Apr 1998 17:07:04 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Filling in the archives
Sender: [email-masked]

If you've looked on <http://www.imc.org/ietf-pkix/>, you'll see that we
have the old archives kept by Tandem, which end on 9/15/97, and new ones
that were being kept by IMC starting 3/1/98. If you have an archive for all
of the dates between those, and you're quite sure that it is complete,
please send me a message (not on the list). I'd like to fill in the missing
messages and make the archive complete. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 17 Apr 1998 15:57:29 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New location for the mailing list
Sender: [email-masked]

Greetings, PKIX folk. Because of the many problems that the list has been
experiencing, the WG chairs have moved the PKIX mailing list to IMC. The
new address for messages for the mailing list is:
     [email-masked]

To subscribe and unsubscribe, send a message to:
     [email-masked]
with the single word "subscribe" or "unsubscribe" in the body of the
message. The mailing list is being run by Majordomo, if that means anything
to you.

There is a Web page for the mailing list at
<http://www.imc.org/ietf-pkix/>. We'll start working on getting a full
archive available soon.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Fri, 17 Apr 1998 14:01: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

I agree with David Kemp's analysis and take back my suggestion that
wasIssued be mandatory.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 17 Apr 1998 13:23:39 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
Comments: To: [email-masked], [email-masked]
To: [email-masked]

It would be desirable if keyIDs were globally unique, but that
isn't absolutely essential, and the addtional space required for a
full SHA-1 hash might not be worth it. Standard hash (classical sense)
table collision resolution techniques could be used.

Of course, if you are looking things up in a directory, insisting on
a globally uniq keyID would be very nice.

Bob

>>> Rich Ankney <[email-masked]> 04/17 12:28 PM >>>
Key IDs are only guaranteed to be unique within the given subject
name, not globally (see X.509 etc.).  If one uses the SHA-1 hash
of the public key, there's a good chance it's globally unique, but
use of the hash is not a requirement of PKIX.

Regards,
Rich

----------
> From: Ian Roberts <[email-masked]>
> To: [email-masked]
> Subject: Re: [IETF-PKIX] Key Identifiers
> Date: Friday, April 17, 1998 11:45 AM
>
> The discussion on Key Identifiers lead me down the following chain of
> thought;
>
> If the Key Identifier is useful for building a path, then it would be
useful
> to be able to query a directory server for certificates containing keys
with
> a given key identifier.
>
> If directory servers become sufficiently large (for example, the size of
the
> Altavista search engine) then a lookup of a large number of certificates
by
> Key Identifier should be possible within a couple of seconds (with many
> occurring concurrently).
>
> If the directory server contained 200 million certificates, then a
possible
> attack would be to generate key sets and then query the directory server
for
> matches.  This would give someone with a fairly low-spec machine the
ability
> to search several hundred million keys per second.
>
> Ian Roberts
> --
> Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
> Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
> Website:  http://www.zergo.com

Approved-By:  Russ Housley <[email-masked]>
Date:         Fri, 17 Apr 1998 14:40:51 -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: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

Steve:

I must disagree.  I do not think that it is a large burden to mandate the
issuer DN.  Client code is greatly simplified for applications if they are
present.

1.  Certificate path development.  In an environment where there is a
directory, DNs are very useful to obtain the certificates.  Given the
increasing iterest in LDAP, I expect more and more evironments to iclude
directoriy systems.

2.  CRLs.  If issuer DNs are included, the alternative name extension is
not required to determine if a particular certificate is being revoked.  If
DNs are not included, the issuer alt name plus the serial number need to be
checked.

3.  S/MIME v2 and S/MIME v3 both reference certificates by issuered DN plus
serial number.

4.  TLS also reference certificates by issuered DN plus serial number.

Perhaps none of these by itself is sufficient to mandate the presence of
issuer DN, but taken together, Ithik that they offer a strong argument.
Especially since it is not onerous for a CA.

Russ

At 07:02 PM 4/16/98 -0400, Stephen Kent wrote:
>Tim,
>
>>At 12:11 PM -0400 4/9/98, Tim Polk wrote:
>>>For those who weren't in the LA meeting, this proposal was requested by the
>>>S/MIME working group.  An empty issuer name wreaks general havoc with their
>>>protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
>>>an important consideration.
>>
>>I will point out that TLS (née SSL) has a similar requirement, as it uses a
>>list of Distinguished Names to specify supported CAs when requesting client
>>certificates.
>
>
>I think the problem we see here is that some applications have a legitimate
>interest in requiring DNs for issuers, but not all application share this
>need. Thus it may be inappropriate to rerquire that ALL PKIX certs contain
>an Issuer DN, rather than allowing a null Issuer DN if an IssuerAltName is
>present. Even in your example, its not clear that the list of CA names sent
>in SSL/TLS be DNs, other than for historic reasons.  TLS could choose to
>mandate use of GeneralNames for CAs in this context, as another minor
>deviation from SSL that would make it more general.
>
>Denis pointed out that use of the NameConstraints extension is problematic
>when the Issuer and Subject name types differ, although that problem might
>be mitigated.  What if we if we specify that a subjectAltName is validated
>against an IssuerAltName when both are present, and if the Subject name is
>null?  I do worry though that this might lead to confusion since the Issuer
>and IssuerAltName might differ under such circumstances.
>
>Steve
>

Approved-By:  Rich Ankney <[email-masked]>
Date:         Fri, 17 Apr 1998 14:28:43 -0400
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] Key Identifiers
To: [email-masked]

Key IDs are only guaranteed to be unique within the given subject
name, not globally (see X.509 etc.).  If one uses the SHA-1 hash
of the public key, there's a good chance it's globally unique, but
use of the hash is not a requirement of PKIX.

Regards,
Rich

----------
> From: Ian Roberts <[email-masked]>
> To: [email-masked]
> Subject: Re: [IETF-PKIX] Key Identifiers
> Date: Friday, April 17, 1998 11:45 AM
>
> The discussion on Key Identifiers lead me down the following chain of
> thought;
>
> If the Key Identifier is useful for building a path, then it would be
useful
> to be able to query a directory server for certificates containing keys
with
> a given key identifier.
>
> If directory servers become sufficiently large (for example, the size of
the
> Altavista search engine) then a lookup of a large number of certificates
by
> Key Identifier should be possible within a couple of seconds (with many
> occurring concurrently).
>
> If the directory server contained 200 million certificates, then a
possible
> attack would be to generate key sets and then query the directory server
for
> matches.  This would give someone with a fairly low-spec machine the
ability
> to search several hundred million keys per second.
>
> Ian Roberts
> --
> Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
> Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
> Website:  http://www.zergo.com

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 17 Apr 1998 14:19:20 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] pkix subject \ issuer names and RFC2247
To: [email-masked]

> From: Trevor Freeman <[email-masked]>
>
> In the list of attribute types for subject and issuer names, I do not see
> support for RFC2247. I think this needs to be added to the list of supported
> attributes.

Trevor,
I agree.

However, X.509 (and by extension, PKIX) has gone down the path of
defining and encouraging the use of GeneralName, instead of defining
and encouraging the use of DN attributes for the various name forms.

I don't know how successful you will be in reversing this trend,
but I wish you luck.

Dave Kemp

Approved-By: [email-masked]
Date:         Fri, 17 Apr 1998 10:44: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: Surendra Reddy <[email-masked]>
Subject:      [IETF-PKIX] PKIX - Operational Protocols through WebCAP
To: [email-masked]

I have just completed a simple/HTTP based Certificate Access
Protocol with XML encoding to transport service requests and
responses. This protocol is completely HTTP based and extensible
through XML DTDs. I am sending this as a ID. I am glad to invite
authors of HTTP/FTP operational protocol and OCSP documents
to be co-authors of this document, so that we can converge on
various issues that had already been discussed and resolved.

Here is an Abstract of this protocol draft:

                Web based Certificate Access Protocol
                Surendra Reddy([email-masked])

Abstract
   Web based Certificate Access Protocol is a set of extensions to HTTP/1.1
   with service requests as XML document DTDs.  WebCAP protocol provides a
   highly scalable and distributed architecture. Since HTTP is widely deployed
   protocol on the internet, deploying the PKI infrastructure
   on HTTP servers through WebCAP extensions provides more flexibility,
   all internet users can use it even if the site they belong has a
   firewall against intruders.  The WEBCAP provides some useful facilities
   for PKI; an information caching by both a proxy server and client software,
   a secure transport layer service for confidentiality, a flexible request
   forwarding which can be used in CA and CA communication.

   WebCAP protocol supports:

     o    registration - whereby a user establishes its identity to CA
          prior to that CA issuing a certificate or certificates for
          that user.

     o    initialization - initialization of necessary key materials
          into the client system.

     o    certification - issues certificates to a user's public key and
          returns that certificate to the client system

     o    revocation - performs certification revocation by authorized
          users.

     o    queries - supports basic queries for certificate retrieval,
          validation.

     o    cross certification - exchange information between CAs to
          establish a cross certifications.

   In HTTP/1.1, method parameter information was exclusively encoded in
   HTTP headers. Unlike HTTP/1.1, WebCAP, encodes method parameter
   information either in an Extensible Markup Language (XML) [Bray,
   Paoli, Sperberg-McQueen, 1998] request entity body, or in an HTTP
   header.  The use of XML to encode method parameters was motivated by
   the ability to add extra XML elements to existing structures,
   providing extensibility, and by XML's ability to encode information
   in ISO 10646 character sets, providing internationalization support.
   As a rule of thumb, parameters are encoded in XML entity bodies when
   they have unbounded length, or when they may be shown to a human
   user and hence require encoding in an ISO 10646 character set.
   Otherwise, parameters are encoded within HTTP headers.

   In addition to encoding method parameters, XML is used in WebCAP to
   encode the responses from methods, providing the extensibility and
   internationalization advantages of XML for method output, as well as
   input.

   The XML namespace extension is also used in this specification in order
   to allow for new XML elements to be added without fear of colliding with
   other element names.

.......................................................
Surendra K Reddy                phone:  +1(650) 506 5441
Development Manager             mobile: +1(650) 867 4757
Internet Applications Division  email(oracle): [email-masked]
Oracle Corporation              email(inet)  : [email-masked]

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Fri, 17 Apr 1998 10:56:36 -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: Trevor Freeman <[email-masked]>
Subject:      [IETF-PKIX] pkix subject \ issuer names and RFC2247
To: [email-masked]

In the list of attribute types for subject and issuer names, I do not see
support for RFC2247. I think this needs to be added to the list of supported
attributes.

Importance: Normal
Approved-By:  "S.Reddy Virtual Office" <[email-masked]>
Date:         Fri, 17 Apr 1998 10:59:29 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "S.Reddy Virtual Office" <[email-masked]>
Subject:      [IETF-PKIX] PKIX Operational protocols through WebCAP
To: [email-masked]

Date: 17 Apr 98 10:44:57 -0700
From: Surendra Reddy <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: PKIX - Operational Protocols through WebCAP

I have just completed a simple/HTTP based Certificate Access
Protocol with XML encoding to transport service requests and
responses. This protocol is completely HTTP based and extensible
through XML DTDs. I am sending this as a ID. I am glad to invite
authors of HTTP/FTP operational protocol and OCSP documents
to be co-authors of this document, so that we can converge on
various issues that had already been discussed and resolved.

Here is an Abstract of this protocol draft:

                Web based Certificate Access Protocol
                Surendra Reddy([email-masked])

Abstract
   Web based Certificate Access Protocol is a set of extensions to HTTP/1.1
   with service requests as XML document DTDs.  WebCAP protocol provides a
   highly scalable and distributed architecture. Since HTTP is widely
deployed
   protocol on the internet, deploying the PKI infrastructure
   on HTTP servers through WebCAP extensions provides more flexibility,
   all internet users can use it even if the site they belong has a
   firewall against intruders.  The WEBCAP provides some useful facilities
   for PKI; an information caching by both a proxy server and client
software,
   a secure transport layer service for confidentiality, a flexible request
   forwarding which can be used in CA and CA communication.

   WebCAP protocol supports:

     o    registration - whereby a user establishes its identity to CA
          prior to that CA issuing a certificate or certificates for
          that user.

     o    initialization - initialization of necessary key materials
          into the client system.

     o    certification - issues certificates to a user's public key and
          returns that certificate to the client system

     o    revocation - performs certification revocation by authorized
          users.

     o    queries - supports basic queries for certificate retrieval,
          validation.

     o    cross certification - exchange information between CAs to
          establish a cross certifications.

   In HTTP/1.1, method parameter information was exclusively encoded in
   HTTP headers. Unlike HTTP/1.1, WebCAP, encodes method parameter
   information either in an Extensible Markup Language (XML) [Bray,
   Paoli, Sperberg-McQueen, 1998] request entity body, or in an HTTP
   header.  The use of XML to encode method parameters was motivated by
   the ability to add extra XML elements to existing structures,
   providing extensibility, and by XML's ability to encode information
   in ISO 10646 character sets, providing internationalization support.
   As a rule of thumb, parameters are encoded in XML entity bodies when
   they have unbounded length, or when they may be shown to a human
   user and hence require encoding in an ISO 10646 character set.
   Otherwise, parameters are encoded within HTTP headers.

   In addition to encoding method parameters, XML is used in WebCAP to
   encode the responses from methods, providing the extensibility and
   internationalization advantages of XML for method output, as well as
   input.

   The XML namespace extension is also used in this specification in order
   to allow for new XML elements to be added without fear of colliding with
   other element names.

.......................................................
Surendra K Reddy                phone:  +1(650) 506 5441
Development Manager             mobile: +1(650) 867 4757
Internet Applications Division  email(oracle): [email-masked]
Oracle Corporation              email(inet)  : [email-masked]

Approved-By:  SGalperin <[email-masked]>
Date:         Fri, 17 Apr 1998 13:54:27 EDT
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: SGalperin <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

In a message dated 98-04-17 12:31:04 EDT, you write:

>
>  At 08:48 AM 4/17/98 -0700, you wrote:
>  >And in the event a client receives {is revoked, not issued}, which
>  >dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced
> this
>  >is no problem.
>
>  To the client, "not issued" is always more important than revoked or not
>  revoked. We can put that in the OCSP spec.
>
>  >As soon as OCSP clients are out there in any volume, there
>  >are those who will seek to determine the client's behavior in fringe
cases.
>
>  I fully agree. That's why I'm I don't think that issued/not issued should
>  be a MAY: I think it has to be a MUST. We can be sure that some clients
>  will blow the comparison unless they are always told whether or not the
>  cert was even issued.
>

Are we talking about fat OCSP client here ?
Does the OCSP client in this case have full certificate chain ?
Can we safely assume that fat OCSP client will need to verify signatures on
the chain first, validity and other X509v3 constraints and only then submit
OCSP request for status of every certificate in the chain ?

If this is so then, essentially, OCSP client is already in the possession of
the well-formed certificate signed by the (indirectly or directly) trusted CA
key. In these circumstances receiving an anwer "not issued" may only mean that
CA key is compromised and "unathorized" certificate has been signed. But if
someone has the CA key and can sign anything with it (including "unathorized"
certificates) then that someone can also make sure that "unathorized"
certificate has the same serial number as one of "authorized" and as long as
we only send serial number to identify a certificate in OCSP request the
substitution of the "authorized" cert with "unathorized" one will be
unnoticed. This makes "never issued" somewhat useless for fat OCSP clients.

Is this reasoning wrong ?

Also since CA archiving capacity is always finiteand we also talking about
allowing "historical" OCSP queries "never issued" will have to be replaced
with "info
unavailable" at least in some cases. This further redices the value of "never
issued" status.

--Slava Galperin

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Fri, 17 Apr 1998 10:52: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

Hi Paul,
    If a responder is working off CRLs, it can't tell whether a
certificate
was ever issued or not. So I would strongly oppose making issued a
mandatory field (except if you allow it to have a dontKnow value).

    Again, I do question why the client can't figure out for itself
whether
that certificate was issued or not.

Ambarish

Paul Hoffman / IMC wrote:
>
> At 08:48 AM 4/17/98 -0700, you wrote:
> >And in the event a client receives {is revoked, not issued}, which
> >dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
> >is no problem.
>
> To the client, "not issued" is always more important than revoked or not
> revoked. We can put that in the OCSP spec.
>
> >As soon as OCSP clients are out there in any volume, there
> >are those who will seek to determine the client's behavior in fringe cases.
>
> I fully agree. That's why I'm I don't think that issued/not issued should
> be a MAY: I think it has to be a MUST. We can be sure that some clients
> will blow the comparison unless they are always told whether or not the
> cert was even issued.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 17 Apr 1998 13:31: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
>
> To the client, "not issued" is always more important than revoked or not
> revoked. We can put that in the OCSP spec.
>
> >As soon as OCSP clients are out there in any volume, there
> >are those who will seek to determine the client's behavior in fringe cases.
>
> I fully agree. That's why I'm I don't think that issued/not issued should
> be a MAY: I think it has to be a MUST. We can be sure that some clients
> will blow the comparison unless they are always told whether or not the
> cert was even issued.

I disagree that an Issued bit should be a MUST.  For that matter, I
don't see that it even needs to be a MAY in OCSP, but others seem to
want it for some reason.

If you have a certificate for which the signature verifies, you have
prima facie evidence that:
  1) the certificate was issued, or
  2) the CA's private key was compromised, or
  3) the signature algorithm is broken.
In the latter two cases, all bets are off and OCSP isn't going to
help -- why would you trust a signed OCSP response any more than a
signed certificate?
In the first case, you know the answer before you even ask the
question.

If you have a certificate for which the signature does not verify,
what are you going to do with it, regardless of OCSP's claim that
it has or has not been issued?

And if you don't have a certificate and are just trolling the OCSP
server by issuer/serial, subject name, or some other search criteria,
why should it feel obliged to disclose which guesses are valid?

Dave Kemp

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 17 Apr 1998 12:54:32 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

> From: Michael Myers <[email-masked]>
>
> And in the event a client receives {is revoked, not issued}, which
> dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
> is no problem.  As soon as OCSP clients are out there in any volume, there
> are those who will seek to determine the client's behavior in fringe cases.

No doubt.  But I don't see dominance of one bit over the other as an
issue.  I'd suggest that clients treat the responses as follows:

Revoked  Issued   Valid?
-------  ------   ------
  F        n/a    Accept
  F        T      Accept
  F        F      Reject

  T        n/a    Reject
  T        T      Reject
  T        F      Reject

In other words, a certificate which is revoked is rejected, and
a certificate which was never issued is rejected.  Sound reasonable?

If the Issued bit is always present (not OPTIONAL in the ASN.1), then
OCSP responders which do not support the Issued function should set the
bit to True.  If the bit is OPTIONAL, then the responder is able to
report Issued, Not-issued, or don't-know.

I don't have a preference for whether the don't-know state is supported
in the OCSP syntax, since Issued is not used at all as an input to the
X.509 and PKIX path validation function.

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Fri, 17 Apr 1998 09:52: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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

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

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

Michael Myers <[email-masked]> scrawled:
>
> And in the event a client receives {is revoked, not issued}, which

I think you mean {is revoked, issued} here...

> dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
> is no problem.  As soon as OCSP clients are out there in any volume, there
> are those who will seek to determine the client's behavior in fringe cases.
>

I agree that the implications are not trivial.  For one thing, as I've said,
a responder working solely with CRL information can not determine a
certificate's existance if the cert has not been revoked.  One bit is not
enough to capture the semantics.

                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, 17 Apr 1998 10:39:54 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
Comments: To: [email-masked]
To: [email-masked]

I haven't been following this thread in minute detail, but I wanted to
mention one thought, to see how it fits.

I'm going to suggest that we provide THREE type of certificate/key identifiers:
(1) a short hash of the key as a keyID, AND
(2) a URI to the issuer's certificate repository, where the
subject's certificate  can be found, AND
(3) a certificate serial number or other pointer to the exact certificate
within that repository.

DISCUSSION:

About a month ago, I proposed an algorithm for processing certs
in a cross-certified envionment that involved both a top-down and
bottom-up search.

In order to be precise about the terminology, I'll assume two
domains -- the relying party's domain (R), and the signer's domain (S).

The signer's domain, S, is a conventional hiearchy, with a top
level CA whose certificate is self-signed.  Importantly, the chain
from the TLCA to the signer's own certificate works in both
directions, from Issuer to Subject top-down, and from Subject to
Issuer, bottom-up, using whatever naming, keyID, serial, etc.,
conventions we choose to implement.  In particular, I am
assuming that it is possible to start with the signer's certificate
and actually FIND all of the rest of the certificates in the signer's
chain, all the way to the top, using some kind of certificate locator
that is similar to the now deprecated CRL distribution point scheme,
i.e., a URI that is contained within each certificate that points to
the location of the Issuer's certificate, via LDAP, HTTP, or whatever.

The relying party's domain is constructed similarly.  However, the RP
already know the TLCA in his domain, and can reasonably process all
(or at least most) of the certificates issued by his TLCA on a top-down
basis, as they are received, perhaps using a local directory or cache.

Now, somewhere between the top and the bottom of the RP's chain, there
exists one or more unidirectional cross-certificates to some CA in the signer's
domain.  The trick is to discover and process it.

To do this, the RP examines the signer's digital signature to see if he
recognizes that key. If so, it was already in his directory/cache of
known keys/certificates, and the first part of the process is done.

If not, he finds the signer's certificate somehow, perhaps from an explicit
link in S/MIME or other container, and he can now provisionally validate
the signer's signature. Then he checks the public key of the Issuer (ifthat is
identified somehow) to see if he recognizes that key, and if he does the first
of the process is complete.  In this manner, the RP steadily climbs the
SIGNER's certificate chain, searching for a key he recognizes. If he hits the
TLCA in the signer's chain and still hasn't recognized a key he trusts, then
the digital signature does not validate, and the singer's certificate is rejected.

However, if the key was recognized, it was presumably because of the
existence of the cross-certificate, which contaid the same public key as
that contained in a certificate issued by a CA in the signer's domain.

O course this process can be carried out locally, without any clues being
contained in the certificate itself as to a keyID or hash of the key used to sign
the certificate, i.e., the Issuer's key, but equally obviously the process could
be facilitated if these kints were already present.  In particular, since the public
key of the issuer isn't contained in the subject's certificate, but only the digital
signature that is based on it, without a keyID of some sort it would be
necessary to jump up a level in the signer's chain in order to identify the
key, and then search for that key in the local directory or cache.

In order to make this process work in the cross-certified case, it has to be
an identifier that is associated with the key itself. Something like certIssuerName
and certSerial won't work, because that is tied to the certificate, not to the key.
so we need a keyID, probably a hash of the key.  However, the hash
doesn't have to be a full MD-5 or SHA-1 message digerst -- it would be more than
good enough to use even a 16 bit hash, followed by standard hash table
collision procedures to resolve which key it really was.

On the other hand, we've been through discussions ad nauseam about the
possibility of having two certificates within a given domain with the same
key. Maybe it matters and maybe it doesn't matter -- I don't want to rat hole
on that discussion again -- but in any case it would probably be desirable to have
a unique indicator for what certificate was intended as well.

to recap, therfore, what I am suggesting, is that we need a
short hash of the key as a keyID, AND a uri to the issuer's
certificate repository, AND a certificate serial number or
other pointer to the exact certificate within that repository.

Bob

>Andreas, Tim, John, Peter, Kevin and Paul,
>
>Let me jump into this thread. I will use the E-mail from Andreas to
>comment but will attempt to address the other E-mails as well.
>
>Generally speaking, I do not support the idea of making the
>AuthorityKeyidentifier or the keyidentifier mandatory. It might even be
>better to deprecate its use. After this initial statement let us see the
>details.
>
>> Some comments on the key identifier / authority identifier issue that
>> was recently discussed on this list:
>>
>> Let's assume I have a certificate of someone on my system that is about
>> to be verified. Usually I would begin by retrieving all certificates of
>> authority described by the issuer and the issuer alternative name (the
>> exact process is outside the scope of this discussion). The result is a
>> set of certificates.
>
>This might be one way to proceed, but I see another way. Basically we
>have not defined a way to walk *up* a path or *down* a path. We might
>need to define one. You suggest to walk UP a path while I would suggest
>to walk DOWN a path. You have some trust points and the question is
>whether you can, from one of these trust points go DOWN to the
>certificate you want to verify. In this way you may make sure that
>naming is unambiguous from the trust point and you may apply naming
>constraints. Otherwise, you can't do it easily.
>
>The reality is that for discovering a path, you might have to walk up
>and down, but the verification should only be done "walking down". This
>means that no digital signature verification should be done before
>getting one or more candidate paths down.
>
>> Now I have to find out, which Authority Certificate was used to sign the
>> User Certificate I am currently holding. I can do this by using all
>> public keys in the Authority Certificates an trying to verify the User
>> Certificate's signature. For any attempt that fails, I can rule out all
>> Authority Certificates which contain the same public key that I have
>> just tried. This process leaves me with a set of certificates which all
>> contain the same public key and this key was used to sign the User
>> Certificate. Key Identifiers can help me with this process so that I do
>> not have to make a series of signature verifications, those a reduced to
>> an octet string comparison. Question: is it worth the effort to save
>> these verification steps? How many different public keys do we expect a
>> CA to have? more that a handful (let's say 10)? Only if the number of
>> keys held by the same CA is large the key identifier will help.
>
>As said above, no verification of digital signature should be done
>before getting a full path. This saves signature checks (as requested by
>Paul Koning) without the need to overload the certificate by additional
>mandatory extensions (that take memory place when the certificate is
>stored in a smart card).
>
>> Now for the Authority Identifier. Again, I am at the point where I have
>> just retrieved the set of certificates. Given the issuer and serial of
>> the signing authority for that CA, I can quickly identify the single
>> certificate that should be used for verification. In fact, it is would
>> be possible to retrieve just this single certificate and not retrieving
>> the complete set.
>>
>> I have one problem with this approach: The verification path is not
>> fixed. Let us assume a CA gets certified by a set of other CAs. Some
>> users trust one of them, others some other CAs (which is why the CA
>> probably got this multiple certificates). When a user certificate
>> contains a reference to a single other CA, a user which does not trust a
>> specific CA will fail to verify the certificate, although there might be
>> a another path which would lead to a successful verification.
>
>I support this comment. This means that placing the key identifier will
>create failures in cases where successful verification could have be
>done applying a different approach.
>
>There are additional problems if we keep the keyidentifier that have not
>been mentioned. The key of a CA is supposed to change, let us say every
>two years. We have left undefined the strategy to adopt when the CA
>changes its key. There are two possibilities: the validity period of the
>CA keys overlap during let us say 6 months or there are contiguous. The
>later case is not very nice if a user wants to register one week prior
>the expiration of the CA key, since two certificates will have to be
>provided to him during a two weeks period. For the first case, we will
>have two certificates signing keys for the same CA during 6 months and
>the question is to know which one to use. Some people are going to say:
>use the key identifier. However there is another solution that does not
>mandate the use of the key identifier. Comparing the date "not before"
>of the user certificate with the date "not before" of the CA certificate
>(or self-signed certificate when we end-up to a point of trust) allows
>to make the difference.
>
>Remember what 4.2.1.1 currently says about the Authority key identifier:
>" This extension would be used where an issuer has multiple signing keys
>(either due to multiple concurrent key pairs or due to changeover)."
>
>> This situation can be solved, if we define that: an application may
>> first try the specific certificate defined and then defaults back to the
>> "try and search" algorithm.
>>
>> One question: Do we have an algorithm for a complete verification? There
>> is one that describes how to verify an existing FC path, but do we have
>> an algorithm on how to construct a path?
>
>We currently don't and we probably should define one.
>
>> Shouldn't the path be constructed and verified from bottom up?
>
>I would rephrase the sentence as:
>
>Shouldn't the candidate paths be constructed forwards and backwards and
>then verified from the top to the bottom ?
>
>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

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:  Paul Hoffman / IMC <[email-masked]>
Date:         Fri, 17 Apr 1998 09:29: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

At 08:48 AM 4/17/98 -0700, you wrote:
>And in the event a client receives {is revoked, not issued}, which
>dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
>is no problem.

To the client, "not issued" is always more important than revoked or not
revoked. We can put that in the OCSP spec.

>As soon as OCSP clients are out there in any volume, there
>are those who will seek to determine the client's behavior in fringe cases.

I fully agree. That's why I'm I don't think that issued/not issued should
be a MAY: I think it has to be a MUST. We can be sure that some clients
will blow the comparison unless they are always told whether or not the
cert was even issued.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Fri, 17 Apr 1998 09:22:10 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

All:

Tim has done a marvelous job of wording these sections. I believe that this
will lead to less confusion on implementor's parts and will get us a very
high level of interoperability in cert chaining.

I agree with all the new wording, but would propose a small change to one
part of the new 4.2.1.4 to make it clearer. Where it now says:

      (b) attribute values in string types other than PrintableString
      are case sensitive (this permits matching of attribute values as
      binary objects);

change to:

      (b) attribute values in string types other than PrintableString
      are matched as binary objects;

I propose this change because BMPString and UTF8String also have the
concept of "spaces", and someone reading Tim's version would wonder whether
or not to do the kind of space elimination mandated for PrintableString in
(d) later in the list. My suggested wording says "don't touch it at all,
compare as is".

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Sean Turner <[email-masked]>
Date:         Fri, 17 Apr 1998 12:18:46 -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: Sean Turner <[email-masked]>
Organization: IECA, Inc.
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Ian,

X.509 defines a matching rule for use in the directory to search for certs based on the following fields:

Serial Number, Issuer, Subject Key Identifier, Authority Key Identifier, Validity Period, Private Key Validity, Subject Public Key Algorithm Identifier, Key Usage, Subject Alternative Name, Certificate policy, and Path to Name.

Cheers,

Ian Roberts wrote:
>
> The discussion on Key Identifiers lead me down the following chain of
> thought;
>
> If the Key Identifier is useful for building a path, then it would be useful
> to be able to query a directory server for certificates containing keys with
> a given key identifier.
>
> If directory servers become sufficiently large (for example, the size of the
> Altavista search engine) then a lookup of a large number of certificates by
> Key Identifier should be possible within a couple of seconds (with many
> occurring concurrently).
>
> If the directory server contained 200 million certificates, then a possible
> attack would be to generate key sets and then query the directory server for
> matches.  This would give someone with a fairly low-spec machine the ability
> to search several hundred million keys per second.
>
> Ian Roberts
> --
> Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
> Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
> Website:  http://www.zergo.com

--
Sean Turner - IECA, Inc.

Importance: Normal
Approved-By:  Michael Myers <[email-masked]>
Date:         Fri, 17 Apr 1998 08:48:15 -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 Status Information on a Certificate
To: [email-masked]

And in the event a client receives {is revoked, not issued}, which
dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
is no problem.  As soon as OCSP clients are out there in any volume, there
are those who will seek to determine the client's behavior in fringe cases.

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of David P. Kemp
> Sent: Friday, April 17, 1998 8:14 AM
> To: [email-masked]
> Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
>
>
> > From: Denis Pinkas <[email-masked]>
> >
> > More exactly:
> >
> > it MUST issue one booolean  : certificate is revoked / is not revoked
> > it MAY issue another boolean: certificate was issued / was not issued
>
>
> I agree with Denis.
>

Approved-By: [email-masked]
Date:         Fri, 17 Apr 1998 10:27:05 -0400
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-opp-ftp-http-03.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
                          Operational Protocols: FTP and HTTP
        Author(s)       : R. Housley
        Filename        : draft-ietf-pkix-opp-ftp-http-03.txt
        Pages           : 5
        Date            : 16-Apr-98

 The protocol conventions described in this document satisfy some of
 the operational requirements of the Internet Public Key
 Infrastructure (PKI). This document specifies the conventions for
 using the File Transfer Protocol (FTP) and the Hypertext Transfer
 Protocol (HTTP) to obtain certificates and certificate revocation
 lists (CRLs) from PKI repositories. Additional mechanisms addressing
 PKIX operational requirements are specified in separate documents.

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

Internet-Drafts are available by anonymous FTP.  Login 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-opp-ftp-http-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-opp-ftp-http-03.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: ftp.ietf.org

        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:      [email-masked].  In the body type:
        "FILE /internet-drafts/draft-ietf-pkix-opp-ftp-http-03.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-opp-ftp-http-03.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-pkix-opp-ftp-http-03.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--OtherAccess--

--NextPart--

Importance: Normal
Approved-By:  Michael Myers <[email-masked]>
Date:         Fri, 17 Apr 1998 08:42: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 at IETF
To: [email-masked]

I agree.  In fact, I had some archive language in an earlier draft.  So
shall it be written--as an optional extension.

> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:[email-masked]]On Behalf Of Jeff Weinstein
> Sent: Friday, April 17, 1998 1:58 AM
> To: [email-masked]
> Subject: Re: [IETF-PKIX] OCSP at IETF
>
>
> I strongly agree with Stephen on this.  One great value that OCSP
> services could add would be to provide historical as well as current
> revocation information.
>
>         --Jeff
>
> Stephen Farrell wrote:
> >
> > Hi Mike,
> >
> > Not sure if this needs a change, but...
> >
> > Part 1 now has a time input to the cert validation
> > algorithm (the time at which the cert should have been/be
> > valid).
> >
> > If OCSP is to fit seamlessly into this algorithm then you'll
> > need an extension to the request so that the response doesn't
> > refer to the current time, but to the time which was input
> > to the cert validation alg.
> >
> > Regards,
> > Stephen.
>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 17 Apr 1998 11:14:02 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

> From: Denis Pinkas <[email-masked]>
>
> More exactly:
>
> it MUST issue one booolean  : certificate is revoked / is not revoked
> it MAY issue another boolean: certificate was issued / was not issued

I agree with Denis.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Fri, 17 Apr 1998 11:09:58 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

> From: Denis Pinkas <[email-masked]>
>
> The reality is that for discovering a path, you might have to walk up
> and down, but the verification should only be done "walking down". This
> means that no digital signature verification should be done before
> getting one or more candidate paths down.

Part 1 Section 6 states that conforming implementations must perform
path validation in a manner which achieves identical results to the
given procedure, which takes as input a full cert path and works
from top to bottom.

But I don't see how following this procedure saves on signature
computations:  for every point at which there is a choice of issuers,
you need a disambiguator.  That is either a signature verification or
something which gives a shortcut answer without ever giving a false
reject.  Heuristics such as validity checking (against the target date
only, NOT for issuer-subject validity nesting!) might help in a very
few cases.  AuthorityKeyIdentifier will allow you to reject all
inappropriate candidates, but it takes up space in the certs, as you
say.  Another, more radical, approach would be to define new
AlgorithmOIDs which include a one octet checkword in the signature
value, which could be compared against a specific high-entropy octet of
the authority public key.  This would eliminate 255/256 of the
unnecessary signature verifications.  NB: I'm not advocating this
approach, just using it as an illustration of a hack which could
improve pathbuilding efficiency without costing much space.

> > I have one problem with this approach: The verification path is not
> > fixed. Let us assume a CA gets certified by a set of other CAs. Some
> > users trust one of them, others some other CAs (which is why the CA
> > probably got this multiple certificates). When a user certificate
> > contains a reference to a single other CA, a user which does not trust a
> > specific CA will fail to verify the certificate, although there might be
> > a another path which would lead to a successful verification.
>
> I support this comment. This means that placing the key identifier will
> create failures in cases where successful verification could have be
> done applying a different approach.

I don't understand this comment.  If an entity has a certificate signed
by a particular issuer, that certificate will have the identifier of that
issuer's key.  A certificate from a different issuer will have a different
key identifier.  In what case will a key identifier cause a reject where
the signature would otherwise have verified correctly?

> > One question: Do we have an algorithm for a complete verification? There
> > is one that describes how to verify an existing FC path, but do we have
> > an algorithm on how to construct a path?
>
> We currently don't and we probably should define one.

Yes.  Santosh?

Dave Kemp

Approved-By:  Ian Roberts <[email-masked]>
Date:         Fri, 17 Apr 1998 15:45:26 +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: Ian Roberts <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

The discussion on Key Identifiers lead me down the following chain of
thought;

If the Key Identifier is useful for building a path, then it would be useful
to be able to query a directory server for certificates containing keys with
a given key identifier.

If directory servers become sufficiently large (for example, the size of the
Altavista search engine) then a lookup of a large number of certificates by
Key Identifier should be possible within a couple of seconds (with many
occurring concurrently).

If the directory server contained 200 million certificates, then a possible
attack would be to generate key sets and then query the directory server for
matches.  This would give someone with a fairly low-spec machine the ability
to search several hundred million keys per second.

Ian Roberts
--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com

Approved-By:  Tim Polk <[email-masked]>
Date:         Fri, 17 Apr 1998 10:42:00 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

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

I have attached proposed text for the issuer and subject name sections.

Highlights:

(1) issuer name is required (that is, may not be an empty SEQUENCE).
(2) subject name is required for CA certs.  (This means you never chain off
altnames!)
(3) Name comparison rules are greatly relaxed from the X.520 text.  Binary
comparison of attribute values is permitted for everything except
PrintableString. That is, no white space compression or case conversion in
BMP or UTF8.

(Rationale for PrintableString:  It has already been implemented, and is
used in practically all certificates.  Upper and lowercase country codes,
etc. will break if we don't support it.)

Please take the time to review the text.
--=====================_892838520==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="name_text.txt"

4.1.2.4  Issuer Name

   The issuer name identifies the entity who has signed (and issued the
   certificate).  The issuer identity must be carried in the issuer name
   field. The issuer name field shall contain an X.500 distinguished
   name (DN).  The issuer field is defined as the X.501 type Name.  Name
   is defined by the following ASN.1 structures:

   Name ::= CHOICE {
     RDNSequence }

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   RelativeDistinguishedName ::=
     SET OF AttributeTypeAndValue

   AttributeTypeAndValue ::= SEQUENCE {
     type     AttributeType,
     value    AttributeValue }

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY DEFINED BY AttributeType

   DirectoryString ::= CHOICE {
         teletexString           TeletexString (SIZE (1..MAX)),
         printableString         PrintableString (SIZE (1..MAX)),
         universalString         UniversalString (SIZE (1..MAX)),
         utf8String              UTF8String (SIZE (1.. MAX)),
         bmpString               BMPString (SIZE (1..MAX))        }

   The Name describes a hierarchical name composed of attributes, such
   as country name, and corresponding values, such as US.  The type of
   the component AttributeValue is determined by the AttributeType; in
   general it will be a DirectoryString.

   The DirectoryString type is defined as a choice of PrintableString,
   TeletexString, BMPString UTF8String and UniversalString.  When creat-
   ing a distinguished name, including their own, conforming CAs shall
   choose from these options as follows:

      (a) if the character set is sufficient, the string will be
      represented as a PrintableString;

      (b) failing (a), if the BMPString character set is sufficient the
      string shall be represented as a BMPString; and

      (c) failing (a) and (b), the string shall be represented as a
      UTF8String.

   The TeletexString and UniversalString are included for backward com-
   patibility, and should not be used for certificates for new subjects.
   However, these types may be used in certificates where the name was
   previously established.  Certificate users should be prepared to
   receive certificates with these string types.

   Standard sets of attributes have been defined in the X.500 series of
   specifications.  Where CAs issue certificates with X.501 type names,
   it is recommended that these attributes types be used.

   Certificate users must be prepared to process the issuer dis-
   tinguished name and subject distinguished name (Section 4.1.2.6)
   fields to perform name chaining for certification path validation
   (see Section 7.) Name chaining is performed by matching the issuer
   distinguished name in one certificate with the subject name in
   another.

   This specification requires only a subset of the name comparison
   functionality specified in X.501. The requirements for conforming
   implementations are as follows:

      (a) attribute values encoded in different string types (e.g.,
      PrintableString and BMPString) may be assumed to represent dif-
      ferent strings;

      (b) attribute values in string types other than PrintableString
      are case sensitive (this permits matching of attribute values as
      binary objects);

      (c) attribute values in PrintableString are not case sensitive
      (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and

      (d) attribute values in PrintableString are compared after remov-
      ing leading and trailing white space and converting internal
      strings of one or more consecutive white space characters to a
      single space.

   These name comparison rules permit a certificate user to validate
   certificates issued using languages or encodings unfamiliar to the
   certificate user.

4.1.2.5  Validity

        (UNCHANGED)

4.1.2.6  Subject Name

   The subject name identifies the entity associated with the public key
   stored in the subject public key field. The subject identity may be
   carried in the subject field and/or the subjectAltName extension.  If
   the subject is a certification authority (e.g., the basic constraints
   extension [see 4.2.1.10] is present and the value of cA is TRUE,)
   then the subject identity must be carried in the subject field.  If
   identity information is present only in the subjectAltName extension
   (e.g., a key bound only to an email address or URI), then the subject
   name must be an empty sequence and the subjectAltName extension must
   be critical.

   Where it is non-null, the subject name field shall contain an X.500
   distinguished name (DN). The DN must be unique for each subject
   entity certified by the one CA as defined by the issuer name field.
   (A CA may issue more than one certificate with the same DN to the
   same subject entity.)

   The subject name field is defined as the X.501 type Name, and shall
   follow the encoding rules for the issuer name field (see 4.1.2.4).
   When encoding strings as the type PrintableString, conforming CAs
   should use mixed case but should not include leading or trailing
   white space and should limit internal white space to substrings of a
   single space.

   Implementations of this specification should be prepared to receive
   following X.501 attribute types: country, organization,
   organizational-unit, title, locality, state or province name, common
   name (e.g., "Tim Polk"), surname, given name, initials, and genera-
   tionqualifier (e.g., "Junior" or "IV".  The syntax and associated
   object identifiers for these attribute types are provided in the
   ASN.1 modules in Appendices A. and B.

   Legacy implementations exist where an RFC 822 name is embedded in the
   subject distinguished name as a PKCS #9 e-mail attribute, which has
   the ASN.1 type EmailAddress [PKCS #9]. Conforming implementations
   shall not generate new certificates with this attribute, but should
   be prepared to receive them.  (New certificates must use the
   rfc822Name in the subject alternative name field (see 4.2.1.7) to
   describe such identities.)

   The ASN.1 syntax for EmailAddress and the corresponding OID are sup-
   plied below.

   EmailAddress ::= IA5String

   pkcs-9 OBJECT IDENTIFIER ::=
          { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 9 }

   emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 }

--=====================_892838520==_--

Approved-By: [email-masked]
Date:         Fri, 17 Apr 1998 11:08:56 +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: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
Comments: To: [email-masked]
To: [email-masked]

Denis Pinkas wrote:
>
> Ambarish Malpani wrote:
>
> > Here is a list of the different kinds of status information that an OCSP
> > responder may want to return:
> >
> > 1. Revocation status of a certificate
> >     - revoked
> >     - on hold
> >     - not revoked
> >     - don't know about this CA
> >     - know about this CA, but not about this cert (??? I am not sure I
> >         think this state should ever be returned, but this corresponds
> >         to the state where the responder is looking up the CA's database
> >         and can't find this entry in the database. Mike, I believe you
> >         think this is an important state - is that correct?)
>
> The later would mean that the OCSP responder has access to more
> information than just  the CRL. I do not think that this response
> usefull for the client. If there were good arguments for keeping it (I
> have not been convinced by the arguments from Paul), then this status
> should be optional (no guarantee to get it back at any time).
Sorry that I bring that up again: the answer about knowing about a CA
but not about the referenced certificate would be a good one for use of
OCSP in the German Signature Law, where such a service is required.

Short overview: When asking a CA for the status of a certificate, it
answer with two booleans: certificate was issued / was not issued and
certifcate is revoked / is not revoked (the latter only when the
certificate was issued). The signature key is related to the CA but is
not the CAs certifcate signing key.

What we then need is a clarification between "not revoked": Let us
assume that an OCSP responder answers with "not revoked" based on a
decision of a CRLs where the certificate is NOT listed. This is a
different answer from "not revoked and I know about the certificate",
perhaps looked up on a CA database (see 3).

> > 2. Expiration status of a certificate
> >     - not yet valid (will be valid in the future)
> >     - valid (in its validity period)
> >     - expired
> >     - don't know about the expiration status
I think we have to rephrase that: not yet valid - certificate validity
period begins after the designated point in time.

>
> > 3. Issued status of the certificate
> >     - never issued (no cert with this serial number was ever issued by
> >       this CA)
> >     - issued
> >     - don't know if it was ever issued
>
> > My take on this issue: I believe OCSP is just a revocation status
> > protocol, so we should restrict the return status to just revoked,
> > onHold, notRevoked, and dontKnowAboutThisCA. This would leave the
> > syntax of the protocol simple and the semantics very clear - OCSP
> > basically returns the same information that you would get if you
> > had a CRL from the CA at the  instant of the response (NOTE: I am
> > NOT implying that a CRL is ever issued).
>
> Agreed. Let us keep it simple.

I think we should not restrict OCSP in its semantics to CRL like
semantics.

Andreas
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Fri, 17 Apr 1998 14:26:09 -0700
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 Status Information on a Certificate
Comments: To: Andreas Berger <[email-masked]>
To: [email-masked]

Andreas,

Your conclusion is:

" I think we should not restrict OCSP in its semantics to CRL like
  semantics."

I may agree with this. However, I think we should not mandate more than
what is available by access to CRL information only. This means that we
have to distinguish between a set of mandatory status and a set of
optional status.

> > Ambarish Malpani wrote:
> >
> > > Here is a list of the different kinds of status information that an OCSP
> > > responder may want to return:
> > >
> > > 1. Revocation status of a certificate
> > >     - revoked
> > >     - on hold
> > >     - not revoked
> > >     - don't know about this CA
> > >     - know about this CA, but not about this cert (??? I am not sure I
> > >         think this state should ever be returned, but this corresponds
> > >         to the state where the responder is looking up the CA's database
> > >         and can't find this entry in the database. Mike, I believe you
> > >         think this is an important state - is that correct?)
> >
> > The later would mean that the OCSP responder has access to more
> > information than just  the CRL. I do not think that this response
> > usefull for the client. If there were good arguments for keeping it (I
> > have not been convinced by the arguments from Paul), then this status
> > should be optional (no guarantee to get it back at any time).
>
> Sorry that I bring that up again: the answer about knowing about a CA
> but not about the referenced certificate would be a good one for use of
> OCSP in the German Signature Law, where such a service is required.

As long as this is optional.

> Short overview: When asking a CA for the status of a certificate, it
> answer with two booleans: certificate was issued / was not issued and
> certifcate is revoked / is not revoked (the latter only when the
> certificate was issued). The signature key is related to the CA but is
> not the CAs certifcate signing key.

More exactly:

it MUST issue one booolean  : certificate is revoked / is not revoked
it MAY issue another boolean: certificate was issued / was not issued

> What we then need is a clarification between "not revoked": Let us
> assume that an OCSP responder answers with "not revoked" based on a
> decision of a CRLs where the certificate is NOT listed. This is a
> different answer from "not revoked and I know about the certificate",
> perhaps looked up on a CA database (see 3).
>
> > > 2. Expiration status of a certificate
> > >     - not yet valid (will be valid in the future)
> > >     - valid (in its validity period)
> > >     - expired
> > >     - don't know about the expiration status
>
> I think we have to rephrase that: not yet valid - certificate validity
> period begins after the designated point in time.

We will have to support some date as originally requested by Stephen.

> > > 3. Issued status of the certificate
> > >     - never issued (no cert with this serial number was ever issued by
> > >       this CA)
> > >     - issued
> > >     - don't know if it was ever issued
> >
> > > My take on this issue: I believe OCSP is just a revocation status
> > > protocol, so we should restrict the return status to just revoked,
> > > onHold, notRevoked, and dontKnowAboutThisCA. This would leave the
> > > syntax of the protocol simple and the semantics very clear - OCSP
> > > basically returns the same information that you would get if you
> > > had a CRL from the CA at the  instant of the response (NOTE: I am
> > > NOT implying that a CRL is ever issued).
> >
> > Agreed. Let us keep it simple.
>
> I think we should not restrict OCSP in its semantics to CRL like
> semantics.
>
> Andreas

See above.

Regards,

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:         Fri, 17 Apr 1998 12:36:04 -0700
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 at IETF
To: [email-masked]

Jeff Weinstein wrote:
>
> I strongly agree with Stephen on this.  One great value that OCSP
> services could add would be to provide historical as well as current
> revocation information.
>
>         --Jeff

I strongly agree with both Stephen and Jeff on this.

Denis

> Stephen Farrell wrote:
> >
> > Hi Mike,
> >
> > Not sure if this needs a change, but...
> >
> > Part 1 now has a time input to the cert validation
> > algorithm (the time at which the cert should have been/be
> > valid).
> >
> > If OCSP is to fit seamlessly into this algorithm then you'll
> > need an extension to the request so that the response doesn't
> > refer to the current time, but to the time which was input
> > to the cert validation alg.
> >
> > Regards,
> > Stephen.

--
      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:         Fri, 17 Apr 1998 11:54:48 -0700
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] Key Identifiers
To: [email-masked]

Andreas, Tim, John, Peter, Kevin and Paul,

Let me jump into this thread. I will use the E-mail from Andreas to
comment but will attempt to address the other E-mails as well.

Generally speaking, I do not support the idea of making the
AuthorityKeyidentifier or the keyidentifier mandatory. It might even be
better to deprecate its use. After this initial statement let us see the
details.

> Some comments on the key identifier / authority identifier issue that
> was recently discussed on this list:
>
> Let's assume I have a certificate of someone on my system that is about
> to be verified. Usually I would begin by retrieving all certificates of
> authority described by the issuer and the issuer alternative name (the
> exact process is outside the scope of this discussion). The result is a
> set of certificates.

This might be one way to proceed, but I see another way. Basically we
have not defined a way to walk *up* a path or *down* a path. We might
need to define one. You suggest to walk UP a path while I would suggest
to walk DOWN a path. You have some trust points and the question is
whether you can, from one of these trust points go DOWN to the
certificate you want to verify. In this way you may make sure that
naming is unambiguous from the trust point and you may apply naming
constraints. Otherwise, you can't do it easily.

The reality is that for discovering a path, you might have to walk up
and down, but the verification should only be done "walking down". This
means that no digital signature verification should be done before
getting one or more candidate paths down.

> Now I have to find out, which Authority Certificate was used to sign the
> User Certificate I am currently holding. I can do this by using all
> public keys in the Authority Certificates an trying to verify the User
> Certificate's signature. For any attempt that fails, I can rule out all
> Authority Certificates which contain the same public key that I have
> just tried. This process leaves me with a set of certificates which all
> contain the same public key and this key was used to sign the User
> Certificate. Key Identifiers can help me with this process so that I do
> not have to make a series of signature verifications, those a reduced to
> an octet string comparison. Question: is it worth the effort to save
> these verification steps? How many different public keys do we expect a
> CA to have? more that a handful (let's say 10)? Only if the number of
> keys held by the same CA is large the key identifier will help.

As said above, no verification of digital signature should be done
before getting a full path. This saves signature checks (as requested by
Paul Koning) without the need to overload the certificate by additional
mandatory extensions (that take memory place when the certificate is
stored in a smart card).

> Now for the Authority Identifier. Again, I am at the point where I have
> just retrieved the set of certificates. Given the issuer and serial of
> the signing authority for that CA, I can quickly identify the single
> certificate that should be used for verification. In fact, it is would
> be possible to retrieve just this single certificate and not retrieving
> the complete set.
>
> I have one problem with this approach: The verification path is not
> fixed. Let us assume a CA gets certified by a set of other CAs. Some
> users trust one of them, others some other CAs (which is why the CA
> probably got this multiple certificates). When a user certificate
> contains a reference to a single other CA, a user which does not trust a
> specific CA will fail to verify the certificate, although there might be
> a another path which would lead to a successful verification.

I support this comment. This means that placing the key identifier will
create failures in cases where successful verification could have be
done applying a different approach.

There are additional problems if we keep the keyidentifier that have not
been mentioned. The key of a CA is supposed to change, let us say every
two years. We have left undefined the strategy to adopt when the CA
changes its key. There are two possibilities: the validity period of the
CA keys overlap during let us say 6 months or there are contiguous. The
later case is not very nice if a user wants to register one week prior
the expiration of the CA key, since two certificates will have to be
provided to him during a two weeks period. For the first case, we will
have two certificates signing keys for the same CA during 6 months and
the question is to know which one to use. Some people are going to say:
use the key identifier. However there is another solution that does not
mandate the use of the key identifier. Comparing the date "not before"
of the user certificate with the date "not before" of the CA certificate
(or self-signed certificate when we end-up to a point of trust) allows
to make the difference.

Remember what 4.2.1.1 currently says about the Authority key identifier:
" This extension would be used where an issuer has multiple signing keys
(either due to multiple concurrent key pairs or due to changeover)."

> This situation can be solved, if we define that: an application may
> first try the specific certificate defined and then defaults back to the
> "try and search" algorithm.
>
> One question: Do we have an algorithm for a complete verification? There
> is one that describes how to verify an existing FC path, but do we have
> an algorithm on how to construct a path?

We currently don't and we probably should define one.

> Shouldn't the path be constructed and verified from bottom up?

I would rephrase the sentence as:

Shouldn't the candidate paths be constructed forwards and backwards and
then verified from the top to the bottom ?

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:  Jeff Weinstein <[email-masked]>
Date:         Fri, 17 Apr 1998 01:57:54 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Jeff Weinstein <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP at IETF
To: [email-masked]

I strongly agree with Stephen on this.  One great value that OCSP
services could add would be to provide historical as well as current
revocation information.

        --Jeff

Stephen Farrell wrote:
>
> Hi Mike,
>
> Not sure if this needs a change, but...
>
> Part 1 now has a time input to the cert validation
> algorithm (the time at which the cert should have been/be
> valid).
>
> If OCSP is to fit seamlessly into this algorithm then you'll
> need an extension to the request so that the response doesn't
> refer to the current time, but to the time which was input
> to the cert validation alg.
>
> Regards,
> Stephen.

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 16 Apr 1998 17:17:27 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

At 07:02 PM 4/16/98 -0400, Stephen Kent wrote:
>I think the problem we see here is that some applications have a legitimate
>interest in requiring DNs for issuers, but not all application share this
>need. Thus it may be inappropriate to rerquire that ALL PKIX certs contain
>an Issuer DN, rather than allowing a null Issuer DN if an IssuerAltName is
>present.

It is only inappropriate to require it if we have a clear, unambiguous way
of doing cert path validation that includes IssuerAltNames. I don't think
we have one.

>What if we if we specify that a subjectAltName is validated
>against an IssuerAltName when both are present, and if the Subject name is
>null?  I do worry though that this might lead to confusion since the Issuer
>and IssuerAltName might differ under such circumstances.

That is an excellent example of confusion, and one that led me to believe
that we're not going to get reliable chaining with those kinds of
decisions. Let me give you another: there are plenty of kinds of AltNames
that might not be distinguished. I'm not talking about the malicious case
where BadCA tries to impersonate GoodCA. I'm talking about some of the many
kinds of names in GeneralNames that GoodCAEast might take and GoodCAWest
might take and have name collision without knowing it.

I have no love for DNs, but it seems much harder to have an accidental name
collision in the DN space than in many of the spaces in the AltNames.

And, let me bring up a topic again that no one responded to before: when
validating chains on AltNames, is it the AND of all the items in the
GeneralNames sequence, or is it the OR of them? If my IssuerAltName is a
SEQUENCE of three rfc822Names, and you're comparing against a cert that has
just one of those names, does the comparison pass or fail? In asking people
in the hallways in LA, I got about a 50/50 split of what people thought it
was. This alone should scare us away from using AltNames and expecting
people writing validating code to get it right.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Stephen Kent <[email-masked]>
Date:         Thu, 16 Apr 1998 19:02:15 -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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

Tim,

>At 12:11 PM -0400 4/9/98, Tim Polk wrote:
>>For those who weren't in the LA meeting, this proposal was requested by the
>>S/MIME working group.  An empty issuer name wreaks general havoc with their
>>protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
>>an important consideration.
>
>I will point out that TLS (née SSL) has a similar requirement, as it uses a
>list of Distinguished Names to specify supported CAs when requesting client
>certificates.

I think the problem we see here is that some applications have a legitimate
interest in requiring DNs for issuers, but not all application share this
need. Thus it may be inappropriate to rerquire that ALL PKIX certs contain
an Issuer DN, rather than allowing a null Issuer DN if an IssuerAltName is
present. Even in your example, its not clear that the list of CA names sent
in SSL/TLS be DNs, other than for historic reasons.  TLS could choose to
mandate use of GeneralNames for CAs in this context, as another minor
deviation from SSL that would make it more general.

Denis pointed out that use of the NameConstraints extension is problematic
when the Issuer and Subject name types differ, although that problem might
be mitigated.  What if we if we specify that a subjectAltName is validated
against an IssuerAltName when both are present, and if the Subject name is
null?  I do worry though that this might lead to confusion since the Issuer
and IssuerAltName might differ under such circumstances.

Steve

Approved-By:  "Flanigan, Bill" <[email-masked]>
Date:         Thu, 16 Apr 1998 14:52:57 -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: "Flanigan, Bill" <[email-masked]>
Subject:      Re: [IETF-PKIX] Unencumbered PKIX Minutes (Was: RE: [IETF-PKIX] D raft LA Minutes)
To: [email-masked]

Hello Warwick,

        I rest my case!

Bill

> -----Original Message-----
> From: Warwick Ford [SMTP:[email-masked]]
> Sent: Wednesday, April 15, 1998 10:29 PM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Unencumbered PKIX Minutes (Was: RE:
> [IETF-PKIX] Draft LA Minutes)
>
> Bill:
>
        [snip]

> We like the minutes to ...[snip]...just be an invention.
>
> Warwick
>
>
>

Approved-By: [email-masked]
Date:         Thu, 16 Apr 1998 10:22: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: Tim Dierks <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

At 12:11 PM -0400 4/9/98, Tim Polk wrote:
>For those who weren't in the LA meeting, this proposal was requested by the
>S/MIME working group.  An empty issuer name wreaks general havoc with their
>protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
>an important consideration.

I will point out that TLS (née SSL) has a similar requirement, as it uses a
list of Distinguished Names to specify supported CAs when requesting client
certificates.

 - Tim

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Thu, 16 Apr 1998 09:58:50 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

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

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

"Alexei V. Vopilov" <[email-masked]> scrawled:
>
> =======Marc Branchaud posted:
> [. . .]
> :
> :One thing this exercise has showed me is that "unknown cert" is really a
> :useless response value, since it is either bogus or subsumed by other values
> :(like "unknown CA").
>
> Should "unknown" statuses be read as followed?
>
> Revocation =  "NotAvailable" // cannot access to CRL information
>               "UnknownCA"    // cannot access to unknown CA database

Well, setting aside the issue of whether multi-valued responses are a good
idea or not, I would argue that the above two cases are equivalent.

If the responder can't access the proper CRL information, it's because it
hasn't collected the CRLs from the CA and so it basically doesn't recognize
the CA.  The same argument applies to responders with direct access to a
CA's database.

Come to think of it, there could be a situation where a responder holds an
expired CRL for which it has yet to receive a replacement.  One might argue
that a "NotAvailable" response would be OK, but I think it would be better
to provide a response based on the expired CRL, perhaps accompanied by some
kind of warning.

> Expiration =  "NotAvailable" // cannot access to known CA database _contents_
>               "UnknownCA"    // cannot access to unknown CA database

Expiration is independent of the contents of a CA's database or even the
recognition of the CA by the responder.  The only time the responder would
reply with an "unknown" expiration value is if it doesn't actually perform
the expiration calculation.  This calculation can be performed for _any_
certificate, so whether an unknown response is made is really just a matter
of how the responder is configured.

So, once again, I think a single kind of "unknown" response is adequate
here.

> Issued     =  "NotAvailable" // cannot access to known CA database _directory_
>               "UnknownCA"    // cannot access to unknown CA database
>

This is where complexity is justified, because a responder using only CRLs
can not know if an unrevoked certificate has ever been issued (revoked
certs, on the other hand, are known to have been issued).  So I agree that
these two kinds of "unknown" responses are a good thing.  The "NotAvailable"
response would be given by responders that only have CRL information (for
the given CA).  A responder with direct access to the CA's database shouldn't
normally use the "NotAvailable" response.

> Having this a Responder implementation can support only part of
> specification without interoperability problems.
> Note there is the difference between "NotAvailable" semantic for
> Expiration and Issued statuses.
>
> Note also that nothing (according to spec design)
> prevents implementing an OCSP Responder by extending CRLs
> issued by a CA (or by just ignoring them at all).
>

I'm not sure what you mean by this.  Could you elaborate?

As for the bigger picture, I'm still not convinced either way about whether
or not OCSP should have multi-valued responses.  I think the extra
complexity is manageable, but I also see the appeal of a simpler protocol.
It really depends on what people want to do with OCSP.  Are the issued/
unissued and expired/unexpired values needed?

I do think they're more marginal.  If the cert's signature verifies, then
it's a good bet that the cert was issued.  As for expiration, a client would
have to be pretty thin to not have a clock.

                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:  John Hughes <[email-masked]>
Date:         Thu, 16 Apr 1998 17:49:47 +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: John Hughes <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
Comments: To: [email-masked]
To: [email-masked]

Denis,

I concurr - as a "user" I would much prefer RFC822 names.

John

At 17:20 16/04/98 -0700, Denis Pinkas wrote:
>Tim,
>
>When I came backfrom LA I found 313 messages waiting for me (I was
>surely not the single person in that situation). Today, I reviewed the
>messages that I skipped and I find this one pretty important:
>
>> For those who weren't in the LA meeting, this proposal was requested by the
>> S/MIME working group.  An empty issuer name wreaks general havoc with their
>> protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
>> an important consideration.
>>
>> In addition, implementors have identified name chaining as a specific
>> difficulty in PKIX implementations.  Prohibiting empty issuer names greatly
>> simplifies path building and validation.
>>
>> When the issue was discussed in the meeting, no requirement for empty
>> issuer names was identified.  The original author of that section agreed
>> that empty subject names in end-entity certificates was sufficient for his
>> purposes.
>>
>> Response at the meeting indicated general support (I don't recall any
>> objectsions) for requiring issuer names in all certificates.  Of course,
>> this decision requires validation by the list.
>
>The topic was mentionned along many others and no one dared to interrupt
>the speaker. On one hand, you say : "this decision requires validation
>by the list" but on the other hand you are already assuming general
>consensus, just the day after the initial posting was made. So let us
>wait a second and discuss this issue (and don't rush to make the
>changes!)
>
>> Assuming general consensus, John has done an excellent job of identifying
>> the changes that are required in the document.  I will make sure they are
>> all implemented.
>>
>> Tim Polk
>>
>> At 07:23 PM 4/8/98 -0400, John Pawling wrote:
>> >All,
>> >
>> >Based on the disussion at the recent PKIX meetings, propose that the
>> >following text should be added to the PKIX X.509 Certificate and CRL
>> >Profile, Issuer Name section (4.1.2.4) and Subject Name section (4.1.2.6):
>> >"All subject and issuer names MUST be populated (i.e. not an empty
SEQUENCE)
>> >in PKIX-compliant X.509 certificates, except that the subject name in a
>> >user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in which
case
>> >the subjectAltName extension will include the subject's identifier and
MUST
>> >be marked as critical."
>
>The argumentation for this has been pretty short. More explanations
>would be needed about the rational. Shortly speaking and as I
>understood, "since applying naming constraints on non-DN names for CAs
>might be difficult, let us mandate DN names for CAs". This would mean
>imposing Full Distinguished Names( i.e. conforming to X.521) for CAs.
>
>One of the MAJOR benefits that we have been advocating when the PKIX
>group was formed was that our standards will allow to support other
>types of names (e.g. rfc822 names) which are more user-friendly than
>names like :</S=xxx/PRMD=Internet/ADMD=Atlas/C=FR>.
>
>I do like name formats like " person@domain_name " where the domain name
>is formed of hierarchical components. Imposing X.521 name formats does
>not seem to be appropriate.
>
>Beyond this point there are other arguments :
>
>1) If the end-entity at the end of a leaf is not mandated to use DNs,
>how can we easily apply naming constraints ?
>
>2) X.521 names should be deprecated because they take more place in a
>certificate, and if I wish to carry my own certificate in my smart card,
>it has better to be the shortest.
>
>I think this is not a minor point but an important matter and, up to
>now, only Tim and John have expressed their opinion, so let us ask for
>other opinions.
>
>Denis
>
>> >This following text should be deleted from the Issuer Name section
>> >(4.1.2.4): "The issuer identity may be carried in the issuer name field
>> >and/or the issuerAltName extension.  If identity information is present
only
>> >in the issuerAltName extension, then the issuer name may be an empty
>> >sequence and the issuerAltName extension must be critical."
>> >
>> >In the Issuer Name section (4.1.2.4), the phrase "Where it is non-null"
>> >should be deleted from "Where it is non-null, the issuer name field shall
>> >contain an X.500 distinguished name (DN)."
>> >
>> >In the Certificate Extensions section (4.2), the following text should be
>> >deleted: "If the CA issues certificates with an empty sequence for the
>> >issuer field, the CA must support the issuerAltName extension."
>> >
>> >In the Issuer Alternative Name section (4.2.1.8), the following text
should
>> >be deleted: "If the only issuer identity included in the certificate is an
>> >alternative name form (e.g., an electronic mail address), then the issuer
>> >distinguished name shall be empty (an empty sequence), and the
issuerAltName
>> >extension shall be present. If the subject field contains an empty
sequence,
>> >the issuerAltName extension shall be marked critical."
>> >
>> >The CRL Issuer Name section (5.1.2.3) should be changed to read as
follows:
>> >"The issuer name identifies the entity who has signed (and issued the
CRL).
>> >The issuer name field shall contain an X.500 distinguished name (DN).  The
>> >issuer name field is defined as the X.501 type Name, and shall follow the
>> >encoding rules for the issuer name field in the certificate (see
4.1.2.4)."
>> >
>> >In section 5.1.2.6  Revoked Certificates, the phrase "or issuer altrnative
>> >name" should be delted from: "Certificates are uniquely identified by the
>> >combination of the issuer name or issuer alternative name along with the
>> >user certificate serial number."
>> >
>> >In section 5.2.2 Issuer Alternative Name, the following text should be
>> >deleted: "Further, if the only issuer identity included in the CRL is an
>> >alternative name form (e.g., an electronic mail address), then the issuer
>> >distinguished name should be empty (an empty sequence), the issuerAltName
>> >extension should be used, and the issuerAltName extension must be marked
>> >critical."
>> >
>> >In section 6, Certificate Path Validation, the following text should be
>> >deleted: "(If the certificate has an empty sequence in the name field,
name
>> >chaining will use the critical subjectAltNames and issuerAltNames
fields.)"
>> >
>> >================================
>> >John Pawling, [email-masked]
>> >J.G. Van Dyke & Associates, Inc.
>> >www.jgvandyke.com
>> >================================
>> >
>> >
>
>--
>      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
>
>

 -------------------------------------------------------------------
| 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: [email-masked]
Date:         Thu, 16 Apr 1998 11:55:34 +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: Stephen Farrell <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP at IETF
Comments: cc: [email-masked]
To: [email-masked]

Hi Mike,

Not sure if this needs a change, but...

Part 1 now has a time input to the cert validation
algorithm (the time at which the cert should have been/be
valid).

If OCSP is to fit seamlessly into this algorithm then you'll
need an extension to the request so that the response doesn't
refer to the current time, but to the time which was input
to the cert validation alg.

Regards,
Stephen.

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Thu, 16 Apr 1998 17:20:24 -0700
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] Subject/Issuer Name Population
To: [email-masked]

Tim,

When I came backfrom LA I found 313 messages waiting for me (I was
surely not the single person in that situation). Today, I reviewed the
messages that I skipped and I find this one pretty important:

> For those who weren't in the LA meeting, this proposal was requested by the
> S/MIME working group.  An empty issuer name wreaks general havoc with their
> protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
> an important consideration.
>
> In addition, implementors have identified name chaining as a specific
> difficulty in PKIX implementations.  Prohibiting empty issuer names greatly
> simplifies path building and validation.
>
> When the issue was discussed in the meeting, no requirement for empty
> issuer names was identified.  The original author of that section agreed
> that empty subject names in end-entity certificates was sufficient for his
> purposes.
>
> Response at the meeting indicated general support (I don't recall any
> objectsions) for requiring issuer names in all certificates.  Of course,
> this decision requires validation by the list.

The topic was mentionned along many others and no one dared to interrupt
the speaker. On one hand, you say : "this decision requires validation
by the list" but on the other hand you are already assuming general
consensus, just the day after the initial posting was made. So let us
wait a second and discuss this issue (and don't rush to make the
changes!)

> Assuming general consensus, John has done an excellent job of identifying
> the changes that are required in the document.  I will make sure they are
> all implemented.
>
> Tim Polk
>
> At 07:23 PM 4/8/98 -0400, John Pawling wrote:
> >All,
> >
> >Based on the disussion at the recent PKIX meetings, propose that the
> >following text should be added to the PKIX X.509 Certificate and CRL
> >Profile, Issuer Name section (4.1.2.4) and Subject Name section (4.1.2.6):
> >"All subject and issuer names MUST be populated (i.e. not an empty SEQUENCE)
> >in PKIX-compliant X.509 certificates, except that the subject name in a
> >user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in which case
> >the subjectAltName extension will include the subject's identifier and MUST
> >be marked as critical."

The argumentation for this has been pretty short. More explanations
would be needed about the rational. Shortly speaking and as I
understood, "since applying naming constraints on non-DN names for CAs
might be difficult, let us mandate DN names for CAs". This would mean
imposing Full Distinguished Names( i.e. conforming to X.521) for CAs.

One of the MAJOR benefits that we have been advocating when the PKIX
group was formed was that our standards will allow to support other
types of names (e.g. rfc822 names) which are more user-friendly than
names like :</S=xxx/PRMD=Internet/ADMD=Atlas/C=FR>.

I do like name formats like " person@domain_name " where the domain name
is formed of hierarchical components. Imposing X.521 name formats does
not seem to be appropriate.

Beyond this point there are other arguments :

1) If the end-entity at the end of a leaf is not mandated to use DNs,
how can we easily apply naming constraints ?

2) X.521 names should be deprecated because they take more place in a
certificate, and if I wish to carry my own certificate in my smart card,
it has better to be the shortest.

I think this is not a minor point but an important matter and, up to
now, only Tim and John have expressed their opinion, so let us ask for
other opinions.

Denis

> >This following text should be deleted from the Issuer Name section
> >(4.1.2.4): "The issuer identity may be carried in the issuer name field
> >and/or the issuerAltName extension.  If identity information is present only
> >in the issuerAltName extension, then the issuer name may be an empty
> >sequence and the issuerAltName extension must be critical."
> >
> >In the Issuer Name section (4.1.2.4), the phrase "Where it is non-null"
> >should be deleted from "Where it is non-null, the issuer name field shall
> >contain an X.500 distinguished name (DN)."
> >
> >In the Certificate Extensions section (4.2), the following text should be
> >deleted: "If the CA issues certificates with an empty sequence for the
> >issuer field, the CA must support the issuerAltName extension."
> >
> >In the Issuer Alternative Name section (4.2.1.8), the following text should
> >be deleted: "If the only issuer identity included in the certificate is an
> >alternative name form (e.g., an electronic mail address), then the issuer
> >distinguished name shall be empty (an empty sequence), and the issuerAltName
> >extension shall be present. If the subject field contains an empty sequence,
> >the issuerAltName extension shall be marked critical."
> >
> >The CRL Issuer Name section (5.1.2.3) should be changed to read as follows:
> >"The issuer name identifies the entity who has signed (and issued the CRL).
> >The issuer name field shall contain an X.500 distinguished name (DN).  The
> >issuer name field is defined as the X.501 type Name, and shall follow the
> >encoding rules for the issuer name field in the certificate (see 4.1.2.4)."
> >
> >In section 5.1.2.6  Revoked Certificates, the phrase "or issuer altrnative
> >name" should be delted from: "Certificates are uniquely identified by the
> >combination of the issuer name or issuer alternative name along with the
> >user certificate serial number."
> >
> >In section 5.2.2 Issuer Alternative Name, the following text should be
> >deleted: "Further, if the only issuer identity included in the CRL is an
> >alternative name form (e.g., an electronic mail address), then the issuer
> >distinguished name should be empty (an empty sequence), the issuerAltName
> >extension should be used, and the issuerAltName extension must be marked
> >critical."
> >
> >In section 6, Certificate Path Validation, the following text should be
> >deleted: "(If the certificate has an empty sequence in the name field, name
> >chaining will use the critical subjectAltNames and issuerAltNames fields.)"
> >
> >================================
> >John Pawling, [email-masked]
> >J.G. Van Dyke & Associates, Inc.
> >www.jgvandyke.com
> >================================
> >
> >

--
      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:  David Boyce <[email-masked]>
Date:         Thu, 16 Apr 1998 16:16: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: David Boyce <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Comments: cc: Tim Polk <[email-masked]>
To: [email-masked]

Tim Polk writes:

>Part 1: Hashing DNs
>
> There is a major problem with substituting the hash of an issuer's DN for
>the DN itself.  First, the X.501 string matching rules ignore leading and
>trailing white space, and compress consecutive white space characters into
>a single white space character.  In addition, many of the X.501 Name
>subtypes are defined with "caseIgnoreMatch" and "caseIgnoreSubstringsMatch"
>.  The result is, c=us matches c=US matches c=uS.

While recognising the intent of your example, 'countryName' is a
particularly poor attribute to choose as an example of this, since many
applications only partially implement the ASN.1 annotation in X.520
(which defines the attribute) which states that it should be (two
character) values of ISO 3166, overlooking the fact that all the values
defined there have only one case (UPPER).  Arguably c=us and c=uS should
be rejected as invalid AVAs (I'd appreciate feedback on this point of
view.)

>This means that the hash of two DNs may be different, but the DNs may
>match.  You need to send the DN.

Another approach would be to define a canonicalised encoding of a DN
which deals with these issues (e.g. compress whitespace, force to
uppercase where appropriate) so that the X.501 string matching rules are
satisfied by a straight comparison.  This version of the DN could then
be hashed and used in place of the above Issuer DN hash.  (I belatedly
notice that Jeff Weinstein has also suggested this.)

It may even be sensible to emit such canonicalised DNs in Certificates
etc., but receiving applications should never assume that such
canonicalisation has been used.  I suppose PKIX *could* define it so
that receiving applications could expect canonicalised DNs, but it would
lock a lot of implementations out.

--
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:  Carlisle Adams <[email-masked]>
Date:         Thu, 16 Apr 1998 10:51:44 -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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Draft LA Minutes
To: [email-masked]

Hi Warwick,

> ----------
> From:         Warwick Ford[SMTP:[email-masked]]
> Sent:         Saturday, April 11, 1998 7:36 PM
> To:   [email-masked]
> Subject:      [IETF-PKIX] Draft LA Minutes
>
> Here are Draft LA Minutes for review and comment.
>
> Warwick
>
A couple of minor typos.  [Forgive me if someone has already pointed these
out, but I've been out of the office for over a week and may have missed
it...]

> CRMF, CMMC AND CMC
>
> (1) CMRF describes the certificate request message of choice for PKIX. CMC
> specifies an alternate format as "mandatory to implement". The sense of
> the
> group was that CMRF should be the mandatory request format for CMC.
>
Both instances of "CMRF" above should be "CRMF".

> (2) Carlisle Adams noted that secure initialization is not a feature of
> CMC. After some discussion, there was a straw poll. The sense of the group
> was that secure initialization should be feature of CMS and should be
> mandatory to implement. This requirement can be supported using the CRMF
> message format discussed above.
>
"CMS" above should be "CMC" (a small, but important, distinction).

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

Approved-By:  [email-masked]
Date:         Thu, 16 Apr 1998 10:34:22 -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: John Wray <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]

Tim Polk <[email-masked]> wrote:

>NOTE: I am drafting new text for the PKIX profile to limit the string
>matching burden. The proposed text will limit the pain for implementors by
>permitting binary comparison of two strings encoded as UTF8String or
>BMPString. It will also relieve implementors of the obligation to map
>character sets and match strings encoded as different types.  This limits
>the ugliness (ignoring case and compressing white space) to processing
>PrintableString. (As I understand it, implementors have already conquered
>this piece.) I will distribute that text SOON, on a new thread on this
list.

I guess I should really wait to see the proposed text, and I may have
misunderstood
your intent, but this sounds like the wrong thing to do.  PrintableString
is a
crippled code-set, in that characters that are quite common aren't
permitted in it
(e.g. underscores and accented characters).  If what you are proposing is a
set of
canonicalization rules that are to be applied to the Unicode encodings (BMP
& UTF8)
before they are placed in certificates to allow binary comparisons between
certificate names to give the same results as the X.501 rules would between
their
non-canonical equivalents, that will mean that names that stray outside the
limited printableString character set will lose the ability to be expressed
(in certificates) in the way the owner of that name prefers (e.g. with
appropriate capitalization).

If you do intend that the PKIX profile should require that names in
certificates
are represented in canonical form when encoded in Unicode-derived codesets,
I
think the same restriction should apply to printableString too (actually,
I'm
not sure why we need to keep printableString around at all, since the
encoding
of every printableString character is identical to the encoding of that
character in UTF8.  The only thing that the printableString option buys is
the
freedom to choose a different tag in the BER encoding, which seems
more of a liability than an advantage.  I can see the utility of keeping
printableString for things like C=xy, where <xy> is required to be within
the
printableString character-set, but I don't see any benefits to allowing an
attribute value to be expressed as a CHOICE { printableString, UTF8String,
... }).

I don't believe that restricting names in certificates will actually free
up
applications from having to deal with non-canonical names anyway, since the
entity
that initiates path validation is likely to be interacting with a human at
some
stage, and at that point any names should be expressed in "owner-preferred
form"
as opposed to canonical form.

I'm all for the PKIX profile specifying an algorithm to convert a string
(in _any_
permitted codeset, not just UTF8 and BMP) into a canonical form (actually,
that should
be one algorithm for each X.501 matching rule), but I don't think we should
constrain
the names in certificates to be stored in that canonical form.

John

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Thu, 16 Apr 1998 15:09:00 -0700
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] INFOSEC'COM 98
To: [email-masked]

INFOSEC'COM 98

                        International Congress
          on Information Systems and Telecommunications Security

           4 - 5 June 1998 - CNIT Paris-La Defense - FRANCE

The International Congress on Information Systems and Telecommunications
Security presents the state of the art, innovations, prospects and new
openings in the fields of information systems and telecommunications
security. The information presented is novel and the presentations by
the speakers are both diversified and of a high standard. As such, they
are mostly intended for specialists in the field (information systems
security managers, computer manufacturers, software publishers,
consultants, etc).

This Congress will take place in Paris (CNIT La Defense) alongside the
INFOSEC trade fair (from June 3 to June 5) where the exhibitors will
demonstrate their know-how in the area of information systems security
products and services.

To make things even more attractive, June happens to be the most
pleasant period of the year to visit Paris.

Thursday June, 4 1998

Opening session

General Strategy in terms of information systems security
General Jean-Louis DESVIGNES, SCSSI

Trusted Third Parties
Chairman : Jean-Philippe JOUAS - President of CLUSIF

* The use of PKIX profiles to support various application paradigms
  John HUGHES - ENTEGRITY SOLUTIONS (UK)
* Questions raised by key escrow systems
  Valerie SEDAILLIAN - Attorney (F)
* Certificate Authority System and e-comm project
  Pierre CHASSIGNEUX - GEMPLUS (F)

Evaluation
Chairman : Michel DUPUY - France Telecom

* Smartcard integrated circuit protection profile overview
  Jean-Paul THOMASSON - SGS-THOMSON Microelectronics (F)
* Protection profile for a European certification architecture
  Jean-Pierre LACOMBE - SETICS (F)
* Common criteria
  Carlos MARTIN - SCSSI Certification Center (F)

Networks
Chairman : Serge SAGHROUNE - Groupe ACCOR

* Secured connection of nomad stations :
  Dassault Electronique's experience
  Yves MEYER - DASSAULT ELECTRONIQUE (F)
* Tentative classification of digital attacks and Internet incidents
  Didier GRAS - XP Conseil - LEFEBVRE Consultants (F)
* Protection of transfering medical on the Internet :
  an application of the Montpellier University Hospital
  Stephane NATKIN - CESIR (F)
* Firewalls for ATM Networks
  Uwe ELLERMANN - HAMBURG UNIVERSITY (D)
* Security in electronic commerce
  Pascal LAGARDE - Industry Minister, Postal Telecommunication
  - SERICS (F)

Friday June 5, 1998

Entreprise
Chairman : Andre GRISSONNANCHE - AGC

* Information systems security networks in major
  compagnies : a new function, a new job, career development prospects
  Rene HANOUZ - CLUSIF (F)
* Risk management of contracted activities
  Gerard REMY - ALCATEL TELECOM (F)
* Management of crise situations : both a necessity and an opportunity
  Andre GRISSONNANCHE - AGC (F)
* Security flaws in a Year 2000 project : a case study
  Pascal LOINTIER - CIGNA (F)
* ROUND TABLE : The future of the security market
  Facilitator : Philippe ROSE - LE MONDE INFORMATIQUE
  Herve SCHAUER - HSC (F) / Andre GRISSONNANCHE - AGC (F) /
  Pierre-Luc REFALO - CEGETEL (F) /
  Jean-Luc JAMAUX - LA FRANCAISE DES JEUX (F)

Digital documents
Chairman : Benoit TIRARD - SYLAB FRANCE (F)

* Document marking legal value
* Electronic documents : the guarantee of integrity
* Protection of digital works on the web
* The sealing functionality : identification and tracking
  of the works in the market
Participants : Nicole TORTELLO, Editions Albin Michel, Representative of
the National Union of Publishers (F) - Bruno COUDERC, BJC Consultants,
Representative of APROGRED, association of professionals in electronic
document management (F)

Viruses
Chairman : Pascal LOINTIER - CIGNA (F)

* Virus writers / Enterprises / Anti-virus software
  publishers : dangerous liaisons
  Danielle KAMINSKY - Investigative Journalist (F)
* The new technology to replace anti-virus systems
  Eyal DOTAN - TEGAM International (US)

GENERAL INFORMATION

Schedules : from 9:00 AM to 6:00 PM
Simultaneous translation French / English and English / French
Registration Fee: 4.980 French Francs (VAT inc.)

For more information, please contact : M.C.I.
19, Rue d'Athenes - 75009 PARIS - FRANCE
Tel : +33 1.44.53.72.20 - Fax : +33 1.44.53.72.22
or the CLUSIF by email : [email-masked]

http://www.clusif.asso.fr/

--
      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:         Thu, 16 Apr 1998 10:04:42 -0700
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] Draft LA Minutes
To: [email-masked]

Warwick,

Two "minor" modifications :-)

> IETF-PKIX MINUTES - APRIL 1, 1998
>
> CERTIFICATE AND CRL PROFILE
>
> Tim Polk summarized the status and outstanding issues on Draft 07 of the
> profile.  It is essential that this document be progressed quickly since
> several other standards are waiting on it.  New additions to 07 include the
> addition of UTF-8 in accordance with IETF Best Practices, correction of the
> path processing algorithm to align with X.509, and removal of semantics for
> wildcards in alternative names.  A few other minor fixes have been noted
> but not yet published.  The S/MIME group has requested that issuer DN be
> required.  The TLS group has requested that wildcards not be forbidden.
>
> Beyond these minor issues, the document is currently stuck in last call
> owing to patent issues resulting from an Entrust patent issued in December.

In this last sentence, I would prefer that we delete the word "minor"
since the last two items that are mentionned might not be "minor". So
the corrected sentence would be:

" Beyond these issues, the document is currently stuck in last call
owing to patent issues resulting from an Entrust patent issued in
December."

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:  "Alexei V. Vopilov" <[email-masked]>
Date:         Thu, 16 Apr 1998 01:38:13 +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: "Alexei V. Vopilov" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

=======Marc Branchaud posted:
[. . .]
:
:One thing this exercise has showed me is that "unknown cert" is really a
:useless response value, since it is either bogus or subsumed by other values
:(like "unknown CA").

Should "unknown" statuses be read as followed?

Revocation =  "NotAvailable" // cannot access to CRL information
              "UnknownCA"    // cannot access to unknown CA database
Expiration =  "NotAvailable" // cannot access to known CA database
_contents_
              "UnknownCA"    // cannot access to unknown CA database
Issued     =  "NotAvailable" // cannot access to known CA database _directory_
              "UnknownCA"    // cannot access to unknown CA database

Having this a Responder implementation can support only part of
specification without interoperability problems.
Note there is the difference between "NotAvailable" semantic for
Expiration and Issued statuses.

Note also that nothing (according to spec design)
prevents implementing an OCSP Responder by extending CRLs
issued by a CA (or by just ignoring them at all).

--Alexei

Approved-By:  Warwick Ford <[email-masked]>
Date:         Wed, 15 Apr 1998 19:29:28 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Unencumbered PKIX Minutes (Was: RE: [IETF-PKIX] Draft LA Minutes)
To: [email-masked]

Bill:

The FINAL minutes get published in the Proceedings.  These are DRAFT
minutes circulated to the list to give participants the opportunity to
review and correct.  We like the minutes to reflect what actually happened
rather than just be an invention.

Warwick

At 05:47 PM 4/15/98 -0400, Flanigan, Bill wrote:
>Hello Warwick,
>
>        Why post this to the list?  Why not to the IETF Web site for
>Proceedings <http://www.ietf.org/proceedings/directory.html>?  Or is there a
>pending patent or trademark involved?  I prefer my own unencumbered (now and
>forever) PKIX minutes.
>
>Bill Flanigan
>
>> -----Original Message-----
>> From: Warwick Ford [SMTP:[email-masked]]
>> Sent: Saturday, April 11, 1998 7:37 PM
>> To:   [email-masked]
>> Subject:      [IETF-PKIX] Draft LA Minutes
>>
>> Here are Draft LA Minutes for review and comment.
>>
>> Warwick
>> ---------------------------------
>>
>        [snip]
>
>
>> ---------------------------------------------------------------------
>> Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>> [email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>> ---------------------------------------------------------------------
>
>

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

Approved-By:  "Flanigan, Bill" <[email-masked]>
Date:         Wed, 15 Apr 1998 17:47:36 -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: "Flanigan, Bill" <[email-masked]>
Subject:      [IETF-PKIX] Unencumbered PKIX Minutes (Was: RE: [IETF-PKIX] Draft LA Minutes)
To: [email-masked]

Hello Warwick,

        Why post this to the list?  Why not to the IETF Web site for
Proceedings <http://www.ietf.org/proceedings/directory.html>?  Or is there a
pending patent or trademark involved?  I prefer my own unencumbered (now and
forever) PKIX minutes.

Bill Flanigan

> -----Original Message-----
> From: Warwick Ford [SMTP:[email-masked]]
> Sent: Saturday, April 11, 1998 7:37 PM
> To:   [email-masked]
> Subject:      [IETF-PKIX] Draft LA Minutes
>
> Here are Draft LA Minutes for review and comment.
>
> Warwick
> ---------------------------------
>
        [snip]

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

Approved-By:  Jeff Weinstein <[email-masked]>
Date:         Wed, 15 Apr 1998 14:07:24 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Jeff Weinstein <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]

Tim Polk wrote:
> Part 1: Hashing DNs
>
>  There is a major problem with substituting the hash of an issuer's DN for
> the DN itself.  First, the X.501 string matching rules ignore leading and
> trailing white space, and compress consecutive white space characters into
> a single white space character.  In addition, many of the X.501 Name
> subtypes are defined with "caseIgnoreMatch" and "caseIgnoreSubstringsMatch"
> .  The result is, c=us matches c=US matches c=uS.
>
> This means that the hash of two DNs may be different, but the DNs may
> match.  You need to send the DN.

Can't you just canonicalize the DNs before hashing?

> Part 2. DN collisions
>
> >    Some people have argued that if DNs clash, everything in PKIX
> >breaks.
>
> Those people are WRONG. The security of PKIX implementations does *not*
> rely on the name space. The performance will be degraded by DN collisions,
> but implementations will not fail as a result.
>
> Path validation always relies on signatures.  There is no direct security
> implication to having n CAs with the same name (say "X").  Certificates
> bind a name AND KEY.  If the name is right, but the key is wrong, path
> validation will fail.  The impliciations are in the areas of performance,
> procedures, and jurisprudence.

  I do agree that security is not compromised.  However if you are saying
that the result is not "broken", then I strongly disagree.

> The key identifiers do help this situation.  They help the software to find
> useful paths quickly.
>
> A final addendum to your story.  Non-aligned country Z's CA (called "Z")
> issues certificates to East and West X's CAs, which are using the same name
> ("X"), with different constraints.  The path validation routines should
> work, whether or not the keyidentifers are in use.  East and West X use
> different key pairs, so everything works.  (Especially the path validation
> software, which works overtime to sort it all out.)

  Lets say that I am trying to validate an end-entity cert that is issued
by west-"X", but I only have CA cert for east-"X" available locally.  I will
try to validate the end-entity cert and get a signature failure.  At this
point there is no way for me to know that a cert for west-"X" even exists,
much less how to get it.  I don't consider this a degradation in performance,
but rather an avoidable failure.

  In the example you presented the CA "Z" clearly did the wrong thing by
issuing certs to two different entities with the same identifying
information.  In the case of two independent roots using the same
name, things get muddier.

        --Jeff

Date:         Wed, 15 Apr 1998 17:39:44 -0700
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] Types of OCSP Responders
To: [email-masked]

Ambarish,

Another response to one of the threads.

> I believe there are three types of OCSP responders:
>
> - CA Responders
>     Where a CA signs OCSP responses - either with the same key as it
> used to sign certificates, or with a different key (one reserved
> for OCSP responses)

Using the same key, as you mention later should be deprecated;
If it is a different key, then you are in the case 3 (CA Designated
Responders)

> - Client-Trusted Responders
>     Where a particular client decides to trust a particular OCSP
> responder to sign all/some OCSP responses for it. The client
> establishes this trust in a out of band(OOB) method and uses that
> same OOB method to check for revocation, change of public key of
> responder, etc.

This works fine but is not scalable.

> - CA Designated Responders
>     Where a CA assigns a special certificate to another entity (which
> could be controlled by the CA itself), to allow it to issue OCSP
> responses on its behalf.
>
>     The first two cases are non-controverial. Not sure they need to be
> discussed in great detail. The third case is more interesting.
>
> My take on CA Designated Responders:
>      I believe that this is actually the most important way in which
> OCSP responders  will be set up. Most people I talked to, didn't want
> the CA to use its private key to sign OCSP responses. I am not sure
> too many CAs have set up separate keys for signing certs and OCSP
> responses. This means that a CA would need to designate another
> name/public key to create legitimate OCSP responses on its behalf.

Agreed in principle.

>      Ofcourse, it is possible for all clients to set up OOB trust in
> these non-CA responders, but that is basically punting on the difficult
> problem of figuring out how to set up that trust.

>      I believe this protocol should specify how a CA designates another
> entity as its OCSP responder and how one deals with revocation of that
> entity.

Yes.

> Once again, my take on this issue, is that the CA should issue a
> certificate with a particular extension to say that the hold of the
> specified certificate (public key) is a legitimate OCSP responder for
> it.

This would be fine. I hope this is not patented  :-)

> That OCSP responder's certificate should ideally have a short
> validity period and the CA should ensure that the responder's key
> is atleast as well protected as its own. Again, IMHO, I think we
> should NOT specify a CRL based method for checking the responders
> cert for revocation - this method is unlikely to be used by most
> client and makes revocation checking very expensive. Rather,
> I would like to specify up front that a responder's cert can't be
> revoked, so a CA should be VERY, VERY careful in issuing
> responder certificates.

I disagree on this point. Checking that the CA or the OCSP responder is
not revoked would have to be done by checking CRLs. We should only allow
the OSCP responder to be placed on an ARL (Authority Revocation List)
since an ARL is very short (most of the time empty). In order to ease
that local verification we should allow the client to query that ARL
from the OCSP responder.

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:         Wed, 15 Apr 1998 17:17:33 -0700
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 Status Information on a Certificate
To: [email-masked]

Ambarish Malpani wrote:

> Here is a list of the different kinds of status information that an OCSP
> responder may want to return:
>
> 1. Revocation status of a certificate
>     - revoked
>     - on hold
>     - not revoked
>     - don't know about this CA
>     - know about this CA, but not about this cert (??? I am not sure I
>         think this state should ever be returned, but this corresponds
>         to the state where the responder is looking up the CA's database
>         and can't find this entry in the database. Mike, I believe you
>         think this is an important state - is that correct?)

The later would mean that the OCSP responder has access to more
information than just  the CRL. I do not think that this response
usefull for the client. If there were good arguments for keeping it (I
have not been convinced by the arguments from Paul), then this status
should be optional (no guarantee to get it back at any time).

> 2. Expiration status of a certificate
>     - not yet valid (will be valid in the future)
>     - valid (in its validity period)
>     - expired
>     - don't know about the expiration status

> 3. Issued status of the certificate
>     - never issued (no cert with this serial number was ever issued by
>       this CA)
>     - issued
>     - don't know if it was ever issued

> My take on this issue: I believe OCSP is just a revocation status
> protocol, so we should restrict the return status to just revoked,
> onHold, notRevoked, and dontKnowAboutThisCA. This would leave the
> syntax of the protocol simple and the semantics very clear - OCSP
> basically returns the same information that you would get if you
> had a CRL from the CA at the  instant of the response (NOTE: I am
> NOT implying that a CRL is ever issued).

Agreed. Let us keep it simple.

(text deleted)

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:         Wed, 15 Apr 1998 16:52:35 -0700
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: Method of Identifying Certificates
To: [email-masked]

Ambarish,

Here is an answer to one of the many threads that you opened:

> There have been three proposals for identifying certificates:
>
>     1. Hash(Issuer's DN) and the certificate's serial number
>     2. Hash(Issuer's DN and Issuer's Public Key) and the certificate's
>         serial number
>     3. Issuer's DN, Hash(Issuer's Public Key) and the certificate's
>        serial number
>
>     There are two main issues here:
>
>     a. Does the query need to include information about the issuer's
>        public key?
>     b. Should we send the whole Issuer DN, or just it's hash?
>
>     The second issue is a relatively simple one - how important
> is it to save bytes in the query - sending the hash of the issuer's DN
> is much smaller than sending the full DN. However, if we just send
> the hash of the DN, the responder may not be able to reconstruct
> the full DN, so querying a database that is indexed by anything other
> than the hash of the DN might be impossible.

Indeed. So we should send the whole issuer name (which may or may not be
a DN).

>     The first issue is more interesting: I contend that there is
> no way to enforce uniqueness of DN's across the whole world.
> However, public keys better be unique (otherwise you have broken
> the basic premise of public key cryptography).

(text deleted)

>     Fortunately, there is an easy way out of this problem - if we
> include the hash of the issuer's public key as a means of identifying
> the CA, clashes of DNs don't affect OCSP. Also, given that the
> AuthorityKeyIdentifier is going to be mandatory in PKIX, client's
> don't even need to do an additional hashing operation to provide
> this information.

Wait a second, the current definition of AuthorityKeyIdentifier is:

AuthorityKeyIdentifier ::= SEQUENCE {
     keyIdentifier             [0] KeyIdentifier           OPTIONAL,
     authorityCertIssuer       [1] GeneralNames            OPTIONAL,
     authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL

with

   KeyIdentifier ::= OCTET STRING

Which of the three optional fields is going to be mandatory ???
If it is the first one, the content is simply an octet string which may
or *may not* be a hash. What is/was the argument to have this field
mandatory ?

(text deleted)

>     Enough from me. What is the feeling on this issue in this group?
> Should  we include the hash of the issuer's public key to uniquely
> identify the issuer?

We should have that hash as an OPTIONAL element. This hash should be
composed of the hash algo and the hash value.

I originally proposed to have the hash of the certificate itself, i.e.
not the hash of the issuer's public key. This also allows to make the
distinction ... but this would mandate some OCSP responders to have
access to every end-user certificate to make the check. Having access to
the issuer's public key only is easy. If an OCSP responder relies on
CRLs, it needs the issuer's public key anyway, i.e. to check the CRL. So
computing a hash of it is not a big deal.

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:  Tim Polk <[email-masked]>
Date:         Wed, 15 Apr 1998 09:51:33 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
Comments: cc: Ambarish Malpani <[email-masked]>
To: [email-masked]

This response has two parts... if you're bored by the first, please skip
down to see if part 2 is of interest.  Thanks!

Part 1: Hashing DNs

 There is a major problem with substituting the hash of an issuer's DN for
the DN itself.  First, the X.501 string matching rules ignore leading and
trailing white space, and compress consecutive white space characters into
a single white space character.  In addition, many of the X.501 Name
subtypes are defined with "caseIgnoreMatch" and "caseIgnoreSubstringsMatch"
.  The result is, c=us matches c=US matches c=uS.

This means that the hash of two DNs may be different, but the DNs may
match.  You need to send the DN.

NOTE: I am drafting new text for the PKIX profile to limit the string
matching burden. The proposed text will limit the pain for implementors by
permitting binary comparison of two strings encoded as UTF8String or
BMPString. It will also relieve implementors of the obligation to map
character sets and match strings encoded as different types.  This limits
the ugliness (ignoring case and compressing white space) to processing
PrintableString. (As I understand it, implementors have already conquered
this piece.) I will distribute that text SOON, on a new thread on this list.

Part 2. DN collisions

>    Some people have argued that if DNs clash, everything in PKIX
>breaks.

Those people are WRONG. The security of PKIX implementations does *not*
rely on the name space. The performance will be degraded by DN collisions,
but implementations will not fail as a result.

Path validation always relies on signatures.  There is no direct security
implication to having n CAs with the same name (say "X").  Certificates
bind a name AND KEY.  If the name is right, but the key is wrong, path
validation will fail.  The impliciations are in the areas of performance,
procedures, and jurisprudence.

Don't get me wrong.  It will be extraordinarily confusing, and path
building software will have a difficult task (n-1 out of n paths
rejected!), but the certificate user won't accept bad paths as a result fo
the name clash.  Of course, if one of the user's trusted CAs has the name
"X" they will have a very difficult time figuring which is the CA X they
want to trust.  That's ugly! And deterimining which CA X is the one to
cross certifiy with would be a nightmare.

The key identifiers do help this situation.  They help the software to find
useful paths quickly.

A final addendum to your story.  Non-aligned country Z's CA (called "Z")
issues certificates to East and West X's CAs, which are using the same name
("X"), with different constraints.  The path validation routines should
work, whether or not the keyidentifers are in use.  East and West X use
different key pairs, so everything works.  (Especially the path validation
software, which works overtime to sort it all out.)

Of course, if the CAs for East and West X both have a copy of the old
private key and both use it, we are up a serious creek. And nothing to
carve a paddle out of either.

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 14 Apr 1998 18:02:03 -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:      [IETF-PKIX] Definition of Secure Initialization
To: [email-masked]

All,

At 10:28 AM 4/14/98 -0700, Warwick wrote:
>>(2) Carlisle Adams noted that secure initialization is not a feature of
>>CMC. After some discussion, there was a straw poll. The sense of the group
>>was that secure initialization should be feature of CMS and should be
>>mandatory to implement. This requirement can be supported using the CRMF
>>message format discussed above.

Recall that we had defined secure initialization as the combination of two
mechanisms: out of band distribution of a trusted public key and out of
band distribution of a pre-authentication token.

As a consequence of some discussions and further thought on our L.A.
discussion, it's clear that latter is overly specific.  It is a mechanism,
not a requirement.  What is required is a high degree of confidence that
the attributes claimed by a certificate applicant are indeed held by that
applicant.

There are three mechanisms by which this assurance can be provided:

1. Use of a pre-authentication token as noted.

2. Use of an LRA's digital signature.

3. Correlation of claimed identity with externally reliable identification
information (two photo IDs, reference

The first two involve technical mechanisms of the protocol.  The third
mechanism is purely operational.

Comments anyone?  Otherwise I'm inclined to require a response to the
requirement as stated but leave the choice of mechanism optional.

The obvious observation is:  We need at least one to ensure
interoperability.  But how do we chose which one, assuming all are equally
responsive mechanisms to the requirement?  One way of making that decision
is to weigh the ease of implementation and deployment.

Approved-By:  "Phillip M. Hallam-Baker" <[email-masked]>
Date:         Tue, 14 Apr 1998 19:30:20 -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: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
To: [email-masked]

>And by the way, wouldn't a simple fix for this  be to amend the standards
>process so that NO standard under consideration may progress past the RFC
>stage until...
>    -    the one year anniversary is exceeded and no patent is applied for,
>    -    or a patent is applied for and licensing rights compliant to some
>"public usage" mode are instituted [This might be an interesting   project
>for some of our mutual ABA friends to look at, the drafting of  the legal
>language for the "public-usage" rights model.]
>    -    or the patent is assigned into the public domain  [ Also another
>project for our ABA friends to draft something for...].

Various people who should know (but may be wrong) tell me that the
one year rule may be about to disappear as a result of the GATT
treaty. No other country has this rule (as far as I am aware) and when
they signed GATT they insisted the US conform to common practice.

I think that what needs to happen is for this to be looked at with
a view to both fixing the loophole and the more general problem
that the premise of IETF process is that we are jointly developing
a standard as 'common property'. The IETF is not going to work
well in the long term if ten people sit round a table contributing
their work for free and afterwards one person demands payment
for the part they contributed.

If I were a member of the IESG my concern here would not
be the specifics of the case but the precedent set. To give an
example I am a member of the Oxford Union which is a
debating society which is regularly addressed by speakers
such as Presidents Carter, Regan, Henry Kissenger etc.
Despite the fact that speakers in that class generally expect
speaking fees in the tens of thousands the President of the
Union is prohibited from paying any speaker (except for travel
expenses) under any circumstances. The rationale being that
the moment you pay one you have to pay everyone and nobody
will do it for free.

The IETF agreement to the PKP license (RSA, D-H) terms was
never intended to set a wider precedent as to the acceptability
of encumbered technology. It was a matter of there being very
little choice, people wanted to use public key cryptography and
the consensus at the time was that access to the PKP patents
(and in particular D-H) was essential if there was to be any
secure email protocol.

Usefull though they may be I don't see that there is a need to
see the patent holder prosper in this case. In the first place
close reading of the patent suggests that the effect we want
may be achievable through mechanisms not covered by the
specific claims. If this proves not to be the case I would much
rather sink several million into solving the problem with hardware
than pay for license fees under these circumstances.

I think that Jeff Schiller is right that the problem is getting
that message to the right people in Nortel/Entrust.

"Millions for defense but not one cent in tribute"

        Phill

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 15:29: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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

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

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

Michael Myers <[email-masked]> scrawled:
>
> A related question:
>
> Given Marc's proposal for separate fields, should we provide guidance
> towards the uniform resolution of ambiguous states in a multi-valued
> response?  I'm concerned about this protocol otherwise introducing into
> clients exploitable behavior caused by less than full coverage of error
> cases.
>

That's a valid concern, and I believe some guidance is required.  As a start,
it might help to list those combinations which should be considerd as
malformed.  First, recall the three status vectors:

    Revocation Status     Expiration Status     Issued Status
    -----------------     -----------------     -------------
    revoked               not yet valid         issued
    on hold               valid                 never issued
    not revoked           expired               unknown
    unknown CA            unknown
    unknown cert

 - If Issued Status is "never issued" then the revocation status MUST be
"unknown cert" and the expiration status MUST be "unknown", otherwise the
response is malformed.  If the responder knows that the cert was never
issued, then the other values are indeterminable.  Note that a responder
can't determine if a certificate was never issued using only CRLs, so a
responder working with CRLs only will never create a "never issued"
response.

 - If Issued Status is "unknown" then the response is well-formed only if the
revocation status is either "not revoked" or "unknown CA".  This is because
if the cert is "revoked" or "on hold" then it is listed in a CRL, and so the
responder knows the cert was issued regardless of whether it is using CRLs or
has direct access to the CA's database.

Also, if Issued Status is "unknown" then "unknown cert" implies "unknown
CA".  Either the responder couldn't find a CRL or database for the cert's
CA, or the responder has a CRL from the CA but the cert isn't listed (so
it's really "not revoked").

 - If Issued Status is "issued" then use the following table to determine if
the response is malformed ("bad") or acceptable ("OK").

  Revocation   ||----------------- Expiration status ---------------
  status       ||  not yet valid  |  valid  |  expired  |  unknown
  =============||=================|=========|===========|===========
  revoked      || OK              | OK      | OK        | OK
  on hold      || bad             | OK      | OK        | OK
  not revoked  || OK              | OK      | OK        | OK
  unknown CA   || bad             | bad     | bad       | bad
  unknown cert || bad             | bad     | bad       | bad

The only way for a responder to know with any certainty that a cert has been
issued is if it has direct access to the CA's database or if the cert is
listed on a CRL.  In either case, responding with "unknown CA" or "unknown
cert" would be wrong.  "Unknown cert" would really mean "never issued" (if
the responder had direct access to a CA's database) or "not revoked" (if the
responder were using CRLs).

Also, I don't believe that a cert would be marked "on hold" before it became
valid.  Either it wouldn't appear on a CRL, or it wouldn't be marked as "on
hold" in the CA's database.  Hence the single "bad" entry in the "on hold"
row.  I'm willing to admit I'm wrong, though.  "On hold" has always been a
semantic riddle to me...

All of this is only to determine if the client should reject a response out
of hand.  The behaviour of a client upon accepting a response -- whether or
not it should accept the cert -- is a matter for the client's local
policies.

One thing this exercise has showed me is that "unknown cert" is really a
useless response value, since it is either bogus or subsumed by other values
(like "unknown CA").

                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:  [email-masked]
Date:         Tue, 14 Apr 1998 14:42:03 -0700
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] Draft LA Minutes
Comments: To: [email-masked]
To: [email-masked]

>Hence the (perceived) need to remove URIs.  But in thinking about this, it
>seems to me that almost anything in a cert can be used to form a network
>operation.  In particular, I'm thinking about the DN itself:  If the presence
>or absence of a cert in a directory is an indication of its status (I think
>Netscape works this way) then can using the DN to look up the cert be
>considered an infringement of the patent?

There's also RFC 2247, which covers encoding a DNS name as a DN.  It's only a
few months old, but it's possible the drafts date back a lot longer (although I
don't know if they go back a year).  Apart from that there's the obvious prior
art like the netscape-X-url attributes which have been in use for awhile.

Where did they file for patents?  Is it the usual US+Canada, or does it cover
other countries as well?

Peter (currently located at least 5000km from the nearest country with software
       patents :-)

Approved-By:  Slava Galperin <[email-masked]>
Date:         Tue, 14 Apr 1998 14:06:16 -0700
Reply-To: [email-masked], [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 Status Information on a Certificate
To: [email-masked]

My responses below is slightly edited and expanded repost of the
original message sent in private exchange with OCSP draft co-authors.

In my analysis below I will refer to the OCSP client classification
outlined in previous messages on OCSP usage scenarios.

On a general note, I do not seem to be able to find examples that would
require different course of action taken by PKI clients for various
negative OCSP responses. Course of action taken by the code in all those
cases is likely to be the same: reject the operation and inform human
operator  for troubleshooting and auditing purpose by either logging or
displaying particular error message. Differentiating between, for
example, revoked and expired(or not yet valid) in OCSP response seems to
only benefit thin clients, since fat clients have validity information
directly from the certificate and OCSP proxy(OCSP responder as a client
in Ambarish's post) do not care at all (more
on this below). I would be certainly interested to hear about practical
examples that do not fall into this category.

Ambarish Malpani wrote:
>
> Here is a list of the different kinds of status information that an OCSP
> responder may want to return:
>
> 1. Revocation status of a certificate
>     - revoked
>     - on hold
>     - not revoked
>     - don't know about this CA
>     - know about this CA, but not about this cert (??? I am not sure I
>         think this state should ever be returned, but this corresponds
>         to the state where the responder is looking up the CA's database
>         and can't find this entry in the database. Mike, I believe you
>         think this is an important state - is that correct?)
>

These status values are the only ones that can be reliably produced by a
responder that only has access to the revocation list (I do not mean
X509 CRL but any data source that contains information about ALL
currently revoked certificates, including those "on hold")
If OCSP definition clearly states that "not revoked" does not assume
"ever issued" or any other validity-related status then it should not be
a problem from OCSP responder liability perspective.

> 2. Expiration status of a certificate
>     - not yet valid (will be valid in the future)
>     - valid (in its validity period)
>     - expired
>     - don't know about the expiration status

Looks like only thin OCSP clients will be able to benefit from this
which means that it should be mandatory OCSP feature only if we find
"thin" clients to be an interesting class.Also validity status has to be
specified relative to some GeneralizedTime value (presumably
producedAt?) in OCSP response  which may not be the same as cleint's
local time. This means that instead of comparing certificate validity
period aginst local time a (thin) client will still have to check the
time from OCSP response and apply necessary logic (the only reasonable
case I can think of is when thin client uses nonce to guarantee response
freshness and does not pay attention to any time-based fields in the
OCSP response). This does not seem to be better than checking the cert
validity in the first place. Having one definition of validity seems to
be better than having two.

>
> 3. Issued status of the certificate
>     - never issued (no cert with this serial number was ever issued by
> this CA)
>     - issued
>     - don't know if it was ever issued

Again looks like only thin OCSP clients will be able to benefit from
this which means that it should be mandatory OCSP feature only if we
find "thin" clients to be an interesting class.
Also This could be easily combined with "Expiration status" above by
extending it with neverIssued value. (Also see below)

>
> My take on this issue: I believe OCSP is just a revocation status
> protocol,
> so we should restrict the return status to just revoked, onHold,
> notRevoked
> and dontKnowAboutThisCA. This would leave the syntax of the protocol
> simple and the semantics very clear - OCSP basically returns the same
> information that you would get if you had a CRL from the CA at the
> instant of the response (NOTE: I am NOT implying that a CRL is ever
> issued).
>
> However, if the consensus of the group is that it is important that all
> three types of states be returned, I would prefer there to be 3
> separate state fields, one for each of the different statii. This would
> allow us to add more states in the future (e.g. whether this certificate
> can be used for a specific kind of operation, or maybe some information
> about the CA of this cert) without affecting these basic status fields.
>
> What do the rest of you on the list feel about this issue:
>     - Should OCSP support one or more of these statuses?
>     - If we support multiple of these states, should we define separate
>         fields, or should we merge all states into one field?
>

Although I am personally in favor of only supporting revoked,
notRevoked, onHold and unknown statuses, I would like to propose the
following response structure which will accomodate both revocation (as
mandatory) and validity(as optional) status and will
put minimal overhead both in terms of size and implementation difficulty
for implementer that only wants to support the revocation status:

CertStatus ::= SEQUENCE {
    revocationStatus   RevocationStatus,
    validityStatus    ValidityStatus OPTIONAL
}

RevocationStatus ::= CHOICE {
        unknown      [0] IMPLICIT UnknownInfo,
        notRevoked   [1] IMPLICIT NULL,
        revoked      [2] IMPLICIT RevokedInfo,
        onHold       [3] IMPLICIT OnHoldInfo, -- revoked and
}

UnknownInfo ::= NULL -- this can be replaced with an enumeration
                     -- for various specific reasons such as doNotKnowAboutCA etc.

RevokedInfo ::= GeneralizedTime -- this could be extended to include
revocation reason or other relevant info
                                -- in this case also "revoked" can be combined with "onHold"

OnHoldInfo ::= NULL

ValidityStatus ::= ENUMERATED {
    unknown           (0),  --certificate information is not available
    neverIssued       (1)   --certificate was never issued
    notYetValid       (2),  --Cert is not yet valid as of producedAt
    valid             (3),  --Cert is valid as of producedAt (NOTE this
does not imply notRevoked !)
    expired           (4),  --Cert is expired as of producedAt
}

Note that here I am using discriminating context-specific tags in CHOICE
for RevocationStatus as a substitute for the ENUMERATED status values
which should satisfy both implmentation simplicity and extensibility.
This also elimiminates the need to specify constraints on values that
carry additional status-specific data because it is recorded directly in
the ASN.1
type structure.

I would be very interested in your feedback on this.

-- Slava

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Tue, 14 Apr 1998 13:54: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

>Once again:
>
>nextUpdate - a GeneralizedTime, which specifies when newer information
>        will be available from this CA. Has the same semantics as the
>        nextUpdate time in CRLs. There is a nextUpdate field with every
>        cert whose status is known. There is no guarantee that
>        revocation information will not be updated before nextUpdate
>        (just as there is no guarantee that a CRL will not be issued
>        before nextUpdate).
>
>Do you agree with this statement?

Yes, that seems fine. It matches PKIX part 1, which is what we should be
doing.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 13:29:30 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] Draft LA Minutes
To: [email-masked]

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

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

Bob Jueneman <[email-masked]> scrawled:
>
> I want to make sure that we are not throwing the baby out with the bath in
> retaliation against Entrust.
>
> In particular, I strongly object to the removal of the URI semantics for
> altnames,
> which might very well have many other valid uses, not the least of which
> might be an http, ftp, or ldap pointer to the issuer's certificate.
>

The question of why URIs are affected was raised at the meeting.  If I
remember right, the patent is broad enough that it may cover _any_ pointer in
a cert that may entail a network operation to retrieve the cert's status.
The patent's abstract says "[The method] is also applied more generally to
update any field in a certificate by reference to a secondary source of
authenticated information."  So it may apply to any network operation
derived from the contents of a certificate (of course, IANAL).

Hence the (perceived) need to remove URIs.  But in thinking about this, it
seems to me that almost anything in a cert can be used to form a network
operation.  In particular, I'm thinking about the DN itself:  If the
presence or absence of a cert in a directory is an indication of its status
(I think Netscape works this way) then can using the DN to look up the cert
be considered an infringement of the patent?

Obviously, there's some prior art here that makes the idea ludicrous.  But
since the IETF isn't into challenging belligerent patents, perhaps it needs
to consider its willingness to use certificates at all.  After all, a DN is
really just a special form of URI.

Just stirrin' the feces...  :)

                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:  "David P. Kemp" <[email-masked]>
Date:         Tue, 14 Apr 1998 15:11:13 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

> From: Marc Branchaud <[email-masked]>
>
> I do have a problem with something that even resembles and "expiration time"
> though, so if your concerns aren't addressed by the draft I'll be happy to
> revisit the issue.

I'll certainly reserve judgement until seeing the draft.  But at a
general level, I'll note that if the CA response contains only a
response creation time, then that leaves the RP without any guidance
as to what freshness threshold to use.  Some may think that is a
reasonable situation - after all, the RP is ultimately in charge of
whom he trusts and for what.

However, not providing a nextUpdate or expiration field in the response
allows a CA to claim "We support online status checking" but leaves
quality of service completely unspecified.  The CA could generate
status responses hourly or every 8 or 24 hours, and if RPs choose not
to be satisfied with the freshness of those responses, tough luck.

Goods on supermarket shelves are marked with expiration dates.  It
would have been far less helpful to mark them with manufacture dates,
leaving it entirely to the consumer to determine the point at which
they become too stale.

Similarly, one CA's CPS may guarantee 15 minute revocation response
time and another might guarantee 24 hours.  How is that information
communicated to RP software?  Sure, it might in theory be possible to
map Certificate Policies into quality-of-service parameters which are
then configured into the RP software, but that sounds like a management
nightmare.  It would be far more straightforward for the expiration
time to be included in the OCSP response.  That way, the software knows
exactly what it's getting without involving error-prone human
configuration.  An expiration field forces the CA to explicitly declare
it's response time claims in a form that can easily be verified.
This, IMHO, is a Good Thing.

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 11:50:35 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

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

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

Ambarish Malpani <[email-masked]> scrawled:
>
> We are proposing that OCSP responses have the following fields:
>
>     producedAt - a GeneralizedTime that indicates the time at which this
>         response was produced/signed. There is only one producedAt time
>         in the response (irrespective of how many certs are included in
>         the response)

I don't think that having only one producedAt time in a response is the right
way to go.  Suppose an OCSP server is an aggregate for two CAs. Further,
suppose that the server has direct access to one CA's database, while it
receives CRLs from the other.  To make things even more obvious, let's say
that when it receives a CRL, it pre-processes "revoked" responses for all the
listed certs (thus setting a producedAt time for each response derived from
the CRL).

Now a client may make a single request specifying two certificates, one from
each CA.  The server then has to choose which producedAt time to use, but
neither time is correct for both certs.

The solution is to either have a producedAt for each cert in a response, or
to allow multiple responses to a single request (which would require some
kind of message ID).  I'll have to think a bit more before deciding which one
I like best.

                 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:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 11:36:53 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

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

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

Ambarish Malpani <[email-masked]> scrawled:
>
>     nextUpdate - a GeneralizedTime, which specifies when newer information
>         will be available from this CA. Has the same semantics as the
>         nextUpdate time in CRLs. There is a nextUpdate field with every
>         cert whose status is known. There is no guarantee that revocation
>         information will not be updated before nextUpdate (just as there is
>         no guarantee that a CRL will not be issued before nextUpdate).
>
>     There has been some argument that by providing nextUpdate, a
> responder is dictating caching policy. I disagree. Clients/caches may
> decide to use or not use nextUpdate when considering caching policy.
> Just as nextUpdate is simply a hint in CRLs of when a new CRL is expected,
> nextUpdate is a hint in OCSP responses of when new revocation data is
> expected from this CA.
>

I'm really not a fan of nextUpdate...  :)

nextUpdate is being touted as a "definitely check after" time.  I contend
that the value is either meaningless or dangerous to a relying party.

It is especially meaningless when status information is obtained directly
from the CA database.  It's been suggested that such responders set
nextUpdate = thisUpdate = producedAt, but that seems terribly wasteful.

But even when status is based on CRLs (or some other periodic method),
nextUpdate is more like data than information.  It can provide RPs with a
false sense of security, leading them to believe that they won't have to
check status until nextUpdate.

As Dave Kemp implied, what the RP really needs is an idea of how fresh the
response is.  Savvy RPs that have read & understood the spec will basically
ignore nextUpdate in favour of their idea of the response's freshness.
Ignorant RPs will blindly accept nextUpdate as some formal kind of guideline,
and some will inevitably get burned.

In the first case, nextUpdate is useless, extraneous data.  In the second,
it's dangerous and misleading.  For these reasons, I think nextUpdate
shouldn't be used at all.

Paul Hoffman suggested that a formally-defined nextUpdate could be used to
get around broken HTTP caches.  There are other ways around this problem,
such as using POST.  Also, adding nextUpdate solely to fix broken HTTP
caching is really taking the protocol-independence out of OCSP.

Finally, I'd like to note that the ideas behind thisUpdate and nextUpdate
are taken directly from CRLs, and CRLs are considered by many to be an
unacceptable way of handling revocation.  Also, with the removal of CRL
distributions points, how effectively PKIX can support CRLs is even more
questionable.  My point is that there's no indication that CRLs will become
the normal way of revoking a certificate.  If that's the case, then forcing
OCSP to always use these mostly-ignored fields is a bad thing to do.

Yes, I am essentially saying that all OCSP really needs is producedAt.

                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:  Michael Myers <[email-masked]>
Date:         Tue, 14 Apr 1998 11:35:52 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

A related question:

Given Marc's proposal for separate fields, should we provide guidance
towards the uniform resolution of ambiguous states in a multi-valued
response?  I'm concerned about this protocol otherwise introducing into
clients exploitable behavior caused by less than full coverage of error cases.

For example, given the following hypothetical responses:

{revoked, not issued}
{revoked, not found}
{revoked, issued}
{revoked}

is the requester behavior upon receipt identical in all cases?  Some of
these are clearly bogus but are nonetheless producible.

At 10:24 AM 4/14/98 -0700, Marc Branchaud wrote:
>>     - If we support multiple of these states, should we define separate
>>         fields, or should we merge all states into one field?
>>
>
>Separate fields.  Using something like notRevoked == exists is just too
>confusing, and isn't always true either.
>
>                Marc

Approved-By:  Slava Galperin <[email-masked]>
Date:         Tue, 14 Apr 1998 11:28:44 -0700
Reply-To: [email-masked], [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 Usage Scenarios
To: [email-masked]

Ambarish Malpani wrote:
>
> Steve (Kent) had requested a description of the ways in which OCSP
> would be used. Here are the scenarios I can think of:
>
>     I see the following types of OCSP responders:
>
<snip>

I guess this classification can be expressed in more compact terms:

- type of certificate information a responder has access to (full
certificate state history or recent revocation data(not necessarily
X.509 CRL) only)
- type of trust model assumed (what key is used to sign OCSP
response(same as CA signing or different) and how client's trust to that
key is established (by trusting the key directly in client's local trust
policy or by delegation using some sort of certificate chain))

>
>     OCSP Clients:

OCSP client classification presented here is an edited version from my
original message sent in a private exchange with OCSP draft co-authors.
I feel that editing had left out some important (IMHO) details (and
questions) from the original text. I decided to include the full quote
to get feedback to my questions from a wider audience.

<SLIGHTLY MODIFIED QUOTE>
I guess from pragmatical perspective it would be more productive to
focus first on the classifications of OCSP clients and then on OCSP
responders
in this section. Once we agree upon classes of clients it will be
clearer what classes of responders and what kind of trust model is
necessary to support these clients.

I can count the following client classes

        fat PKI client
                this client has full access to certificate chain and
local trust
policy (which includes necessary trusted public keys in raw or X.509
certificate form) and performs full certificate validation logic
including signature verification and validity checks. This client only
needs up-to-date revocation status of every certificate in the
chain(preferrably retrieved in ONE network round-trip)

        thin PKI client
                this client also has full access to certificate chain
but is limited
in certificate validation capabilites, instead it delegates non-trivial
certificate validation logic to trusted server. However it has to
minimally be able to verify signatures on OCSP responses (including
time-stamps or nonce verification) and have rudimentary local trust
policy (at least trusted public key for OCSP provider). I am not sure
how large is this class of clients (embedded systems like VPN boxes ?)
and how interesting it is to support

        OCSP proxy
                untrusted enterprise-local transponder that consolidates
OCSP traffic
and configuration and provides local caching facility. This does not
necessarily has access to the entire certificate, but it does not seem
to be required to interpret requests and responses other than doing
superficial matching and freshness calculations

What else is missing ?
</SLIGHTLY MODIFIED QUOTE>

>
>     - Fat client
>         A client that understands certificates, signatures and time. It can
> check the certificate by itself and mainly wants a responder to specify
> the
> revocation status of a certificate
>
>     - Thin client
>         Understands signature verification. Doesn't necessarily understand
> time.
> Would like the OCSP responder to indicate whether the certificate has
> expired
> or not (which raises the question of how this client verifies the times
> on an
> OCSP response).
>
>     - OCSP responder as a client
>         An OCSP responder forwards an OCSP query to another responder.
>
>

Approved-By:  Paul Koning <[email-masked]>
Date:         Tue, 14 Apr 1998 13:53: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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

>>>>> "Andreas" == Andreas Berger <[email-masked]> writes:

 Andreas> Some comments on the key identifier / authority identifier
 Andreas> issue that was recently discussed on this list:

 Andreas> Let's assume I have a certificate of someone on my system
 Andreas> that is about to be verified. Usually I would begin by
 Andreas> retrieving all certificates of authority described by the
 Andreas> issuer and the issuer alternative name (the exact process is
 Andreas> outside the scope of this discussion). The result is a set
 Andreas> of certificates.

 Andreas> Now I have to find out, which Authority Certificate was used
 Andreas> to sign the User Certificate I am currently holding. I can
 Andreas> do this by using all public keys in the Authority
 Andreas> Certificates an trying to verify the User Certificate's
 Andreas> signature. For any attempt that fails, I can rule out all
 Andreas> Authority Certificates which contain the same public key
 Andreas> that I have just tried. This process leaves me with a set of
 Andreas> certificates which all contain the same public key and this
 Andreas> key was used to sign the User Certificate. Key Identifiers
 Andreas> can help me with this process so that I do not have to make
 Andreas> a series of signature verifications, those a reduced to an
 Andreas> octet string comparison. Question: is it worth the effort to
 Andreas> save these verification steps? How many different public
 Andreas> keys do we expect a CA to have? more that a handful (let's
 Andreas> say 10)? Only if the number of keys held by the same CA is
 Andreas> large the key identifier will help.

Given the cost of signature check, I would say that key identifiers
are valuable if they save just ONE signature check.  In other words,
I should have enough information such that I get zero signature check
failures in verifying a valid certificate chain.  Anything less is
unreasonable from a performance point of view.

(Another argument is that check failure can otherwise come from two
causes: corrupt/invalid certificate, and wrong key.  The former is
serious, the latter is not in the scenario you gave; how would I
decide what error to log if I cannot tell the difference between these
two causes?)

        paul

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Tue, 14 Apr 1998 10:53:53 -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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP Usage Scenarios
To: [email-masked]

Marc Branchaud wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Content-Type: text/plain; charset=us-ascii
>
> A good list, but how is a "Revocation Aggregator" any different from a
> "Mirror of a Responder"?  The mirror is just a special case of the
> aggregator.
>
>                 Marc
>

Hi Marc,
    The scenarios were not meant to be significantly different - just
wanted a description of all the different ways in which OCSP could
be used, so that when we come up with the spec, we make sure all the
cases are addressed.

Anyway, the "Mirror of Responder" might just collect revocation data
for a single CA, while an aggregator would collect revocation info
from varous CAs.

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:  Ambarish Malpani <[email-masked]>
Date:         Tue, 14 Apr 1998 10:48:51 -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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

Hi Paul,
    My mail about the description of nextUpdate doesn't contain the
word "hint" any more. In my set of mails, I tried to reflect the
issues as they currently stand - the spec is a little old. I would
like to be able to gauge peoples feelings on various issues (hopefully
over the next two weeks), before we come out with the next version of
the spec.

Once again:

nextUpdate - a GeneralizedTime, which specifies when newer information
        will be available from this CA. Has the same semantics as the
        nextUpdate time in CRLs. There is a nextUpdate field with every
        cert whose status is known. There is no guarantee that
        revocation information will not be updated before nextUpdate
        (just as there is no guarantee that a CRL will not be issued
        before nextUpdate).

Do you agree with this statement?

Regards,
Ambarish

Paul Hoffman / IMC wrote:
>
> At 06:50 PM 4/13/98 -0700, Ambarish Malpani wrote:
> >Just as
> >nextUpdate
> >is simply a hint in CRLs of when a new CRL is expected, nextUpdate is a
> >hint in OCSP responses of when new revocation data is expected from this
> >CA.
>
> I strongly disagree with the word "hint". In both the CRL and OCSP case,
> the nextUpdate is the time at which it is guaranteed that a new response
> will be issued. If you go to the primary CRL or OCSP distributor and it is
> issuing responses with nextUpdate before the current time, they are
> non-conformant. That's not a hint, it's a mandate.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

--
---------------------------------------------------------------------
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:         Tue, 14 Apr 1998 13:06:31 +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: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      Re: [IETF-PKIX] LDAP v2 schema - object classes for users and CAs
To: [email-masked]

Sean Turner wrote:

> Why weren't the object classes strongAuthenticationUser and
> certificationAuthority (from X.521) used for storing user and CA certs in the directory?
>
> In the case of the pkiUser, the object class is the same as strongAuthenticationUser,
> except for the name and oid.  So, couldn't we just reuse the object class from X.521?

I think that strongAuthenticationUser is more appropriate to designate a
"user that uses strong authentication *to communication with the
directory*" and should not necessarily be used to store certificates for
any other purpose. Specifically, the strongAuthenticationUser needs a
certificate that has a DN that matches the entry, since DNs are most
appropriate to describe a directory entry. A PKIX Certificate can have
just an eMail address and that cannot be easily mapped onto a directory
DN.

I think that we need attributes that hold certificates for various
purposes and strongAuthenticationUser is too narrow for that purpose.

Andreas
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Tue, 14 Apr 1998 10:28:26 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Draft LA Minutes
To: [email-masked]

A few important changes to the draft minutes.

>The S/MIME group has requested that issuer DN be
>required.

That's not true, and I don't think that's what Tim said. Some people, who
happen to also work on S/MIME, discovered a logic problem with chaining
through
AltNames. The problem completely goes away when we require CAs (not end
entities) to have filled-in subject names and that they chain through their
issuer names.

>Ambarish Galpani

Make that "Ambarish Malpani".

>Paul Hoffman raised the question of possible pending patents impacting CRMF
>and CMC, and suggested that the Chairs try to get commitments from authors
>that there are no patent encumbrances.

I explicitly said "no current or anticipated patent encumbrances." This is to
prevent the problem of a draft author or a chair knowing that a relevant
patent
application had been filed but not yet issued. I can understand how the
minutes
taker might have missed this distinction, but I think it is an important one.

>(2) Carlisle Adams noted that secure initialization is not a feature of
>CMC. After some discussion, there was a straw poll. The sense of the group
>was that secure initialization should be feature of CMS and should be
>mandatory to implement. This requirement can be supported using the CRMF
>message format discussed above.

I also brought up the idea that CMC and CMP should both offer CAs the same
services so that a CA vendor doesn't have to implement both in order to get
all
the services needed by their application. If we as a WG want to come out with
two parallel protocols to do the same thing, we should be real sure they do
the
same thing.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 10:24: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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

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

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

Ambarish Malpani <[email-masked]> scrawled:
>
>     - Should OCSP support one or more of these statuses?

I'm indifferent here.  I can see good points for revocation-only or
multi-status responses.

>     - If we support multiple of these states, should we define separate
>         fields, or should we merge all states into one field?
>

Separate fields.  Using something like notRevoked == exists is just too
confusing, and isn't always true either.

                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:  Marc Branchaud <[email-masked]>
Date:         Tue, 14 Apr 1998 10:20:42 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Usage Scenarios
To: [email-masked]

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

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

A good list, but how is a "Revocation Aggregator" any different from a
"Mirror of a Responder"?  The mirror is just a special case of the
aggregator.

                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: [email-masked]
Date:         Tue, 14 Apr 1998 16:39:42 +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: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Some comments on the key identifier / authority identifier issue that
was recently discussed on this list:

Let's assume I have a certificate of someone on my system that is about
to be verified. Usually I would begin by retrieving all certificates of
authority described by the issuer and the issuer alternative name (the
exact process is outside the scope of this discussion). The result is a
set of certificates.

Now I have to find out, which Authority Certificate was used to sign the
User Certificate I am currently holding. I can do this by using all
public keys in the Authority Certificates an trying to verify the User
Certificate's signature. For any attempt that fails, I can rule out all
Authority Certificates which contain the same public key that I have
just tried. This process leaves me with a set of certificates which all
contain the same public key and this key was used to sign the User
Certificate. Key Identifiers can help me with this process so that I do
not have to make a series of signature verifications, those a reduced to
an octet string comparison. Question: is it worth the effort to save
these verification steps? How many different public keys do we expect a
CA to have? more that a handful (let's say 10)? Only if the number of
keys held by the same CA is large the key identifier will help.

Now for the Authority Identifier. Again, I am at the point where I have
just retrieved the set of certificates. Given the issuer and serial of
the signing authority for that CA, I can quickly identify the single
certificate that should be used for verification. In fact, it is would
be possible to retrieve just this single certificate and not retrieving
the complete set.

I have one problem with this approach: The verification path is not
fixed. Let us assume a CA gets certified by a set of other CAs. Some
users trust one of them, others some other CAs (which is why the CA
probably got this multiple certificates). When a user certificate
contains a reference to a single other CA, a user which does not trust a
specific CA will fail to verify the certificate, although there might be
a another path which would lead to a successful verification.

This situation can be solved, if we define that: an application may
first try the specific certificate defined and then defaults back to the
"try and search" algorithm.

One question: Do we have an algorithm for a complete verification? There
is one that describes how to verify an existing FC path, but do we have
an algorithm on how to construct a path? Shouldn't the path be
constructed and verified from bottom up?

Andreas
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  Michael Myers <[email-masked]>
Date:         Tue, 14 Apr 1998 10:06:54 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP at IETF
To: [email-masked]

All,

We are aiming to accumulate comments these comments and produce a new draft
in roughly two weeks' time.  Your prompt response would be appreciated to
help us develop a sense of the group's consensus.

Mike

At 05:36 PM 4/13/98 -0700, Ambarish Malpani wrote:
>Hi All,
>     Great meeting a whole bunch of you at IETF.
>
>     I am going to post a set of emails about the issues raised about
>OCSP, to start a set of threads on topics in OCSP.
>
>Here is a summary of the topics that will be covered in the mails to
>follow:
>
>    - OCSP Usage Scenarios (as requested by Steve Kent)
>    - Status Information on a Certificate
>    - Types of OCSP Responders
>    - Method of identifying certs
>    - Semantics of thisUpdate, nextUpdate, producedAt
>    - Extended error states in responses
>    - Caching
>
>If you have input on any of these topics, please do the the mailing
>list know, so that we can address those concerns ASAP, reach a
>concensus about OCSP and finish up this project.
>
>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:  Bob Jueneman <[email-masked]>
Date:         Tue, 14 Apr 1998 10:49:25 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Draft LA Minutes
Comments: To: [email-masked]
To: [email-masked]

>
>Beyond these minor issues, the document is currently stuck in last call
>owing to patent issues resulting from an Entrust patent issued in December.
> Tim proposed that all text relating to unresolved issues be removed to a
>separate I-D, and the rest of the document be progressed immediately to
>Proposed Draft.  This means removing CRL distribution points, authority
>access info, and some policy qualifiers, and removing URI semantics from
>altnames.  (Sections impacted: Policy Qualifiers, CRL Distribution Points,
>and Issuing Distribution Points.)  Steve Kent reported that the Area
>Director had agreed with this approach.  A straw poll of those present
>indicated strong support for and no support against this approach.

I want to make sure that we are not throwing the baby out with the bath in
retaliation against Entrust.

In particular, I strongly object to the removal of the URI semantics for altnames,
which might very well have many other valid uses, not the least of which
might be an http, ftp, or ldap pointer to the issuer's certificate.

Bob

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 13 Apr 1998 19:20: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

At 06:50 PM 4/13/98 -0700, Ambarish Malpani wrote:
>Just as
>nextUpdate
>is simply a hint in CRLs of when a new CRL is expected, nextUpdate is a
>hint in OCSP responses of when new revocation data is expected from this
>CA.

I strongly disagree with the word "hint". In both the CRL and OCSP case,
the nextUpdate is the time at which it is guaranteed that a new response
will be issued. If you go to the primary CRL or OCSP distributor and it is
issuing responses with nextUpdate before the current time, they are
non-conformant. That's not a hint, it's a mandate.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 13 Apr 1998 19:08:33 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

At 06:04 PM 4/13/98 -0700, Ambarish Malpani wrote:
>    - know about this CA, but not about this cert (??? I am not sure I
>        think this state should ever be returned, but this corresponds
>        to the state where the responder is looking up the CA's database
>        and can't find this entry in the database. Mike, I believe you
>        think this is an important state - is that correct?)

I can think of many reasons to return this. The database is down but is
expected to come up in the future. The responder got an internal error from
its database query. There is a network problem between the database and the
responder. This response says "if you try again later, you'll probably get
one of the other response types." In the email world, we have found this
kind of response very valuable.

>    - Should OCSP support one or more of these statuses?

All three.

>    - If we support multiple of these states, should we define separate
>        fields, or should we merge all states into one field?

Separate.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 13 Apr 1998 19:15:11 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]

Good story, and a believable one. I think including some information about
the issuer's public key in the request is very important, possibly crucial.

>    1. Hash(Issuer's DN) and the certificate's serial number
>    2. Hash(Issuer's DN and Issuer's Public Key) and the certificate's
>        serial number
>    3. Issuer's DN, Hash(Issuer's Public Key) and the certificate's
>serial
>        number

1 won't work for the case you're worried about. Assuming that the OCSP
responder has a limited number of CAs for whom it is responding, either 2
or 3 should work fine. The choice is smaller number of bytes sent (2 would
be better) or smaller number of bytes over which the hash is computerd (3
would be better). I'm sure others have at least one opinion about these two
choices.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Mon, 13 Apr 1998 18:51: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP: Extended Error States in Responses
To: [email-masked]

OCSP as currently defined, defines a bunch of extended error
responses,
including things like CA's cert revoked etc. I think a responder should
NOT provide information about the CA at all. It is being asked about a
particular certificate and that is what it should respond about. It is
possible that a CA is certified by two other CA's, in addition to being
self-certified - in that case, saying a CA is revoked would really
depend
on the chain the client is interested in, which is not specified in a
given
request. If a client wants to check a chain, it should check a each
level
of the chain.
    I believe the responses for the revocation status of a cert should
be:
revoked, onHold, notRevoked, dontKnowAboutThisCA

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, 13 Apr 1998 18:50:45 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP: Semantics of thisUpdate, nextUpdate, producedAt
To: [email-masked]

We are proposing that OCSP responses have the following fields:

    producedAt - a GeneralizedTime that indicates the time at which this
        response was produced/signed. There is only one producedAt time
        in the response (irrespective of how many certs are included in
        the response)
    thisUpdate - a GeneralizedTime, which specifies the time at which
the
        response was known to be current - basically the time at which
        the CA's database was looked up. It may or may not have the same
        value as producedAt. There is a thisUpdate field with every cert
        whose status is known. Corresponds to the thisUpdate in a CRL.
    nextUpdate - a GeneralizedTime, which specifies when newer
information
        will be available from this CA. Has the same semantics as the
        nextUpdate time in CRLs. There is a nextUpdate field with every
        cert whose status is known. There is no guarantee that revocation
        information will not be updated before nextUpdate (just as there is
        no guarantee that a CRL will not be issued before nextUpdate).

    There has been some argument that by providing nextUpdate, a
responder
is dictating caching policy. I disagree. Clients/caches may decide to
use
or not use nextUpdate when considering caching policy. Just as
nextUpdate
is simply a hint in CRLs of when a new CRL is expected, nextUpdate is a
hint in OCSP responses of when new revocation data is expected from this
CA.

Comments?

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, 13 Apr 1998 18:06: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP: Method of Identifying Certificates
To: [email-masked]

There have been three proposals for identifying certificates:

    1. Hash(Issuer's DN) and the certificate's serial number
    2. Hash(Issuer's DN and Issuer's Public Key) and the certificate's
        serial number
    3. Issuer's DN, Hash(Issuer's Public Key) and the certificate's
serial
        number

    There are two main issues here:
    a. Does the query need to include information about the issuer's
public
        key?
    b. Should we send the whole Issuer DN, or just it's hash?

    The second issue is a relatively simple one - how important is it to
save bytes in the query - sending the hash of the issuer's DN is much
smaller than sending the full DN. However, if we just send the hash of
the
DN, the responder may not be able to reconstruct the full DN, so
querying
a database that is indexed by anything other than the hash of the DN
might
be impossible.

    The first issue is more interesting: I contend that there is not way
to enforce uniqueness of DN's across the whole world. However, public
keys
better be unique (otherwise you have broken the basic premise of public
key cryptography).
    Consider the following (slightly long winded) story:

    Once upon a time, there was a country X, which has a famous CA,
CA of X. One year, it had a revolution, which resulted in the country
being divided into East X and West X. The U.S. supported West X, while
China supported East X. Ofcourse, both nations wanted to retain the name
CA of X, since it was well known across the world. Neither of them
continued to use the same public key (since both sides knew the
corresponding
private key), but both wanted to use the original DN.
    The issue of who would be allowed to retain the original DN was
taken
to the International Court in the Hague, but in the meantime,
Switzerland,
which was running a global OCSP responder, needed to figure out which
country's CA of X it would support.

    Fortunately, there is an easy way out of this problem - if we
include
the hash of the issuer's public key as a means of identifying the CA,
clashes of DNs don't affect OCSP. Also, given that the
AuthorityKeyIdentifier
is going to be mandatory in PKIX, client's don't even need to do an
additional hashing operation to provide this information.

    Some people have argued that if DNs clash, everything in PKIX
breaks. I
would like to make the following points:
    - Just because something else breaks, you shouldn't design your
        protocols with the same weaknesses.
    - In most of PKIX, along with a name, you also have a signature.
This
        signature implicitly identifies the public key associated with that
        name.
    - It is quite possible that even if issuer DNs clash, most domains
        will never see that clash, because they only trust one of the issuers
        with that DN. The only person who sees that clash might be an OCSP
        responder that tries to collect revocation data from all issuers.

    Enough from me. What is the feeling on this issue in this group?
Should
we include the hash of the issuer's public key to uniquely identify the
issuer?

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, 13 Apr 1998 18:05: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] Types of OCSP Responders
To: [email-masked]

I believe there are three types of OCSP responders:

- CA Responders
    Where a CA signs OCSP responses - either with the same key as it
used to
sign certificates, or with a different key (one reserved for OCSP
responses)

- Client-Trusted Responders
    Where a particular client decides to trust a particular OCSP
responder
to sign all/some OCSP responses for it. The client establishes this
trust
in a out of band(OOB) method and uses that same OOB method to check for
revocation, change of public key of responder, etc.

- CA Designated Responders
    Where a CA assigns a special certificate to another entity (which
could be controlled by the CA itself), to allow it to issue OCSP
responses
on its behalf.

    The first two cases are non-controverial. Not sure they need to be
discussed in great detail. The third case is more interesting.

My take on CA Designated Responders:
     I believe that this is actually the most important way in which
OCSP responders  will be set up. Most people I talked to, didn't want
the
CA to use its private key to sign OCSP responses. I am not sure too many
CAs have set up separate keys for signing certs and OCSP responses. This
means that a CA would need to designate another name/public key to
create
legitimate OCSP responses on its behalf.
     Ofcourse, it is possible for all clients to set up OOB trust in
these
non-CA responders, but that is basically punting on the difficult
problem
of figuring out how to set up that trust.
     I believe this protocol should specify how a CA designates another
entity as its OCSP responder and how one deals with revocation of that
entity. Once again, my take on this issue, is that the CA should issue a
certificate with a particular extension to say that the hold of the
specified certificate (public key) is a legitimate OCSP responder for
it. That OCSP responder's certificate should ideally have a short
validity
period and the CA should ensure that the responder's key is atleast as
well
protected as its own. Again, IMHO, I think we should NOT specify a CRL
based method for checking the responders cert for revocation - this
method
is unlikely to be used by most client and makes revocation checking very
expensive. Rather, I would like to specify up front that a responder's
cert can't be revoked, so a CA should be VERY, VERY careful in issuing
responder certificates.

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, 13 Apr 1998 18:04:14 -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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP Status Information on a Certificate
To: [email-masked]

Here is a list of the different kinds of status information that an OCSP
responder may want to return:

1. Revocation status of a certificate
    - revoked
    - on hold
    - not revoked
    - don't know about this CA
    - know about this CA, but not about this cert (??? I am not sure I
        think this state should ever be returned, but this corresponds
        to the state where the responder is looking up the CA's database
        and can't find this entry in the database. Mike, I believe you
        think this is an important state - is that correct?)

2. Expiration status of a certificate
    - not yet valid (will be valid in the future)
    - valid (in its validity period)
    - expired
    - don't know about the expiration status

3. Issued status of the certificate
    - never issued (no cert with this serial number was ever issued by
this CA)
    - issued
    - don't know if it was ever issued

My take on this issue: I believe OCSP is just a revocation status
protocol,
so we should restrict the return status to just revoked, onHold,
notRevoked
and dontKnowAboutThisCA. This would leave the syntax of the protocol
simple and the semantics very clear - OCSP basically returns the same
information that you would get if you had a CRL from the CA at the
instant of the response (NOTE: I am NOT implying that a CRL is ever
issued).

However, if the consensus of the group is that it is important that all
three types of states be returned, I would prefer there to be 3
separate state fields, one for each of the different statii. This would
allow us to add more states in the future (e.g. whether this certificate
can be used for a specific kind of operation, or maybe some information
about the CA of this cert) without affecting these basic status fields.

What do the rest of you on the list feel about this issue:
    - Should OCSP support one or more of these statuses?
    - If we support multiple of these states, should we define separate
        fields, or should we merge all states into one field?

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, 13 Apr 1998 18:01: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP Usage Scenarios
To: [email-masked]

Steve (Kent) had requested a description of the ways in which OCSP
would be used. Here are the scenarios I can think of:

    I see the following types of OCSP responders:

    - Revocation Aggregator
        Certain people could aggregate revocation information from various
CAs and provide OCSP responses for those CAs. The aggregator could rely
on CRLs for revocation data or use some other means to get that
information
from various CAs.

    - Next-to-CA Responder
        An OCSP responder could run next to the CA, where is imports
revocation information from the CA and provides it to requestors as OCSP
responses. There are two models here:
        a. The responder can read the CAs database directly, so that it
knows as much as the CA about the status of a certificate - whether it
was
ever issued, whether it has expired, or is not yet valid etc.
        b. The responder can't read the CAs database directly and relies
on the CA shipping it the information as either a CRL or in some other
format.

    - Mirror of a Responder
        For huge enterprises, with offices in say Korea and California,
the enterprise might want to have one responder next the the CA in
Korea, with
a second responder in California, to allow fast access to the data in
California. Once again, the California responder might need to
periodically
get updates from the responder/CA in Korea about the latest revocation
information.

    - Fetching Responder
        Some enterprises may choose to run an OCSP responder which is capable
of querrying other OCSP responders/CRLs for revocation status. If a
response
is received from another OCSP responder, it might ship that response as
is, or might use the original responder's response to create its own
response.
The second scenario would require a client to only trust a single OCSP
responder.

It is possible for a single responder to act in all of the above modes
at
one time.

    OCSP Clients:

    - Fat client
        A client that understands certificates, signatures and time. It can
check the certificate by itself and mainly wants a responder to specify
the
revocation status of a certificate

    - Thin client
        Understands signature verification. Doesn't necessarily understand
time.
Would like the OCSP responder to indicate whether the certificate has
expired
or not (which raises the question of how this client verifies the times
on an
OCSP response).

    - OCSP responder as a client
        An OCSP responder forwards an OCSP query to another responder.

A single client could send requests to one or more OCSP responders or
types of
OCSP responders.

Hopefully these scenarios cover the different ways in which people might
want to run/use OCSP responders. If anybody has some additional
scenarios
that a materially different, or if you think one or more of these
scenarios
can't happen, please share it with this list.

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, 13 Apr 1998 17:36: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP at IETF
To: [email-masked]

Hi All,
     Great meeting a whole bunch of you at IETF.

     I am going to post a set of emails about the issues raised about
OCSP, to start a set of threads on topics in OCSP.

Here is a summary of the topics that will be covered in the mails to
follow:

    - OCSP Usage Scenarios (as requested by Steve Kent)
    - Status Information on a Certificate
    - Types of OCSP Responders
    - Method of identifying certs
    - Semantics of thisUpdate, nextUpdate, producedAt
    - Extended error states in responses
    - Caching

If you have input on any of these topics, please do the the mailing
list know, so that we can address those concerns ASAP, reach a
concensus about OCSP and finish up this project.

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: [email-masked]
Date:         Mon, 13 Apr 1998 17:19:22 -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: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
Comments: To: [email-masked]
To: [email-masked]

Timing of responses:  what happens if a responder is sending "old" responses from its cache (with the "old" time?) saying that the cert is not revoked at the time of the "new" request?  Or do we assume that caching responders will synchronize all requests and not process delta CRLs or other interim status request?  Does this processing synchronization then become part of the minimum interoperability standards for responders that are then "allowed" to cache responses?

Michael

>>> Paul Hoffman / IMC <[email-masked]> 04/13/98 04:30PM >>>
At 02:21 PM 4/13/98 -0700, Michael Myers wrote:
>Could you expand on what you meant by "trusted" in the following?
>
>>I would very much like to take OCSP caching out of HTTP proxy
>>caches and put them in a trusted place. I look forward to your draft and
>>hope that, if the group likes it, we can use it instead of the HTTP portion
>>of the current OCSP draft.

Trusted = bound to the OCSP responder. HTTP proxy caches may be controlled
by the OCSP requestor, the OCSP responder, or someone else. The latter case
leads to problems of the requestor getting the most recent information.

I think that Marc means that his OCSP proxy cache will be controllable only
by the OCSP responder. This would let OCSP responders offload
previously-issued replies to the OCSP proxy cache and only request that are
not in the cache, or ones that require signing of the nonce, would make it
back to the responder. This maximizes the scalability of the responder by
giving it caching flexibility on an outside host, the OCSP cache.

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

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Mon, 13 Apr 1998 15:58:14 -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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

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

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

David,

I agree that freshness information is an absolute must, and the draft
protocol provides exactly that.  I know it's unfair of me to make such
claims about something that nobody's seen yet, so I'll just leave it at that
until everyone's had an opportunity to go over the draft.

I do have a problem with something that even resembles and "expiration time"
though, so if your concerns aren't addressed by the draft I'll be happy to
revisit the issue.

                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

"David P. Kemp" <[email-masked]> scrawled:
>
> > From: Marc Branchaud <[email-masked]>
> >
> > It's my hope that the draft will provide a focus (and solution) for the
> > caching issue, which has yet to be dealt with in any depth.  However,
> > nextUpdate is really a separate issue:  It firmly belongs in the realm of
> > OCSP-based-on-CRLs.  OCSP caching is a much broader issue.
>
> Marc,
>
>   I look forward to seeing the draft.  However, my inclination is to
> believe that nextUpdate (or more generally, "expirationTime") is crucial
> for OCSP-direct-to-the-CA, and is not limited to just OCSP-based-on-CRLs.
>
> The CA must have some finite delay between the time a revocation is
> requested by the subscriber and the time it is reflected in status
> responses as received by the RP, whether the responses are communicated
> by direct OCSP or by CRLs.  If the CA advertises response information
> current to within 5 minutes, then the relying party needs to know that
> the OCSP response it is currently processing came from the horse's
> mouth not more than 5 minutes ago, regardless of how many caches it has
> flowed through or what cache control strategies are in use.  Any
> solution to the caching issue must provide freshness information that
> the RP can use to verify that the CA is living up to it's performance
> claims, otherwise you might as well take the O out of OCSP.
>
> Dave Kemp

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 13 Apr 1998 15:30:00 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

At 02:21 PM 4/13/98 -0700, Michael Myers wrote:
>Could you expand on what you meant by "trusted" in the following?
>
>>I would very much like to take OCSP caching out of HTTP proxy
>>caches and put them in a trusted place. I look forward to your draft and
>>hope that, if the group likes it, we can use it instead of the HTTP portion
>>of the current OCSP draft.

Trusted = bound to the OCSP responder. HTTP proxy caches may be controlled
by the OCSP requestor, the OCSP responder, or someone else. The latter case
leads to problems of the requestor getting the most recent information.

I think that Marc means that his OCSP proxy cache will be controllable only
by the OCSP responder. This would let OCSP responders offload
previously-issued replies to the OCSP proxy cache and only request that are
not in the cache, or ones that require signing of the nonce, would make it
back to the responder. This maximizes the scalability of the responder by
giving it caching flexibility on an outside host, the OCSP cache.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Warwick Ford <[email-masked]>
Date:         Mon, 13 Apr 1998 18:11: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: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

At 02:25 PM 4/13/98 -0600, Bob Jueneman wrote:
>What/where is the "poised" list, what is its charter, and how does one
subscribe?

See the "Process for Organization of Internet StandardS ONg (poisson)" WG -
details on the IETF Web site.

Warwick

---------------------------------------------------------------------
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, 13 Apr 1998 14:21: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 and HTTP proxy caching
To: [email-masked]

Paul,

Could you expand on what you meant by "trusted" in the following?

Mike

At 01:57 PM 4/13/98 -0700, Paul Hoffman / IMC wrote:
>I would very much like to take OCSP caching out of HTTP proxy
>caches and put them in a trusted place. I look forward to your draft and
>hope that, if the group likes it, we can use it instead of the HTTP portion
>of the current OCSP draft.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>
>

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Mon, 13 Apr 1998 13:57: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

At 12:11 PM 4/13/98 -0700, Marc Branchaud wrote:
>An OCSP server is not necessarily a CRL-processing engine.

Quite right, and I hope I didn't sound like I believed that to be the case.

>  In many cases,
>certificate status can be served without using CRLs at all (like when the
>OCSP server has direct access to a CA's certificate store).  In these
>situations, "nextUpdate" has no meaning at all.

It has a meaning, but a weak one, and (I hope) the same weak one that
exists in CRLs. It means "the time that the {CA|OCSP server} guarantees to
give a new response".

>Instead of requiring nextUpdate, the solution is to make caching an explicit
>part of OCSP.  I'm working on a draft that does just this, and I'm in the
>process of running it by a couple of people before submitting it to the
>list.  I hope to have it out by (or before) Friday.

Excellent! I would very much like to take OCSP caching out of HTTP proxy
caches and put them in a trusted place. I look forward to your draft and
hope that, if the group likes it, we can use it instead of the HTTP portion
of the current OCSP draft.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 13 Apr 1998 14:25:52 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
To: [email-masked]

Warwick,

What/where is the "poised" list, what is its charter, and how does one subscribe?

I think these questions are very, very important. But so long as the IETF does not
require individual contributors to "join" anything more than a mailing list, and
does not require any legal assignment of IP rights by contributors to the IETF,
I think these issues are going to come up again and again. Even if I had ever
read RFC 2028 (and I haven't yet, although I'm going to), I never signed anything
that would bind me to such principles, either legally or morally. I didn't even know
that it existed -- I certainly haven't read every RFC that has ever been published.

In my own case, for example, I learned of a Novell patent that might
conceivably apply in this area after someone else mentioned it. Not
withstanding the fact that it was filed by someone who sits about 20 feet
away from me, the invention was developed before I joined Novell, and the
patent was only awarded recently, and without any internal fanfair. I therefore
could have fallen into the same trap Warwick fell into, quite innocently. And
anyone who thinks that everyone who is, or at one time might have been,
an employee or contractor for a large comporation, must therefore be aware of
all of the decisions that might be made regarding patents and their applicability,
no matter where they might be processed within the company, is somewhat
out of touch with reality, I believe. It simply isn't possible. Ask IBM, or Microsoft,
or General Motors.

Other organizations, for example the Key Recovery Alliance, and I believe
the Open Group, do require corporate membership, and an explicit
assignment of rights for work developed in a group setting to the organization
for precisely these reasons.  Without such an agreement, I think the
rights issue is quite murky, especially given the US patent law with its
emphasis on first to invent, vs. most of the rest of the world's first to file precedence.

Bob

>>> Warwick Ford <[email-masked]> 04/10 8:48 PM >>>
Perry:

I am not arguing the reasonableness of that action.  Having now seen how
unexpected subsequent actions can lead to a clearly unreasonable outcome
overall, I cannot disagree with you.  But in fairness to all, I think we
need to recognize that there is a misalignment in different people's
understandings and expectations.  Therefore, I am suggesting that we move
to better align and document understandings and expectations for the
future.  Like add some more precision to RFC 2028...

Also, in the interests of eliminating duplication, might I suggest that
this thread now be pursued only on the poised list where it most properly
belongs?

Warwick

At 11:59 AM 4/10/98 -0400, Perry E. Metzger wrote:
>I'm very angry about this sort of thing. I realize that you feel that
>it was reasonable for Nortel to file a patent on an idea already
>presented to the IETF, but I do not think this was reasonable
>behavior. The open standards process depends on people being fully
>informed of all the encumberances on technology they are
>considering.

(Disclaimer: These comments are my own and do not necessarily reflect
positions of VeriSign, Inc.)

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

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 13 Apr 1998 15:58: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

> From: Marc Branchaud <[email-masked]>
>
> It's my hope that the draft will provide a focus (and solution) for the
> caching issue, which has yet to be dealt with in any depth.  However,
> nextUpdate is really a separate issue:  It firmly belongs in the realm of
> OCSP-based-on-CRLs.  OCSP caching is a much broader issue.

Marc,

  I look forward to seeing the draft.  However, my inclination is to
believe that nextUpdate (or more generally, "expirationTime") is crucial
for OCSP-direct-to-the-CA, and is not limited to just OCSP-based-on-CRLs.

The CA must have some finite delay between the time a revocation is
requested by the subscriber and the time it is reflected in status
responses as received by the RP, whether the responses are communicated
by direct OCSP or by CRLs.  If the CA advertises response information
current to within 5 minutes, then the relying party needs to know that
the OCSP response it is currently processing came from the horse's
mouth not more than 5 minutes ago, regardless of how many caches it has
flowed through or what cache control strategies are in use.  Any
solution to the caching issue must provide freshness information that
the RP can use to verify that the CA is living up to it's performance
claims, otherwise you might as well take the O out of OCSP.

Dave Kemp

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 13 Apr 1998 13:53:53 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
To: [email-masked]

Bill, I think you make some good points.

And although you addressed your note to the PKIX list, you also serve as
Chair to the Federal PKI group, where the issue of patents, and conformance
to standards, is likely to be much more acute.

I think it might be useful to run this up the flagpole with NIST's and/or DoD's
IP lawyers, and see what the consequences might be of requiring conformance
to an IETF standard during some procurement if valid patents are excluded
as a matter of principle by a recognized(?) standards body.

Bob

>At 10:46 PM 4/9/98 -0700, Warwick Ford wrote:
>>I totally support the spirit behind the key clause in RFC 2028 regarding
>>intellectual property and the IETF.  However, this clause may warrant some
>>reconsideration ... taking into account the circumstances surrounding
>>Nortel Patent 5699431 (PKIX and CRL distribution points).
>>
>>   To ensure a fair and open process, participants in the IETF and its
>>   Working Groups must be able to disclose, and must disclose to the
>>   Working Group chairs any relevant current or pending intellectual
>>   property rights that are reasonably and personally known to the
>>   participant if they participate in discussions about a specific
>>   technology.
>>
>
>Like Warwick, I like the spirit of this rule.
>
>However, Article II of the United States Constitution specifically empowers
>Congress to:
>
> "promote the progress of science and useful arts, by securing for limited
>times to authors and inventors the exclusive right to their respective
>writings and discoveries;"
>
>Congress, therefore, gets to say what the rights of inventors are in the
>patent laws.  My questions are:
>
>1. Does the US patent law create a statutory right of inventors to maintain
>the secrecy their invention, if they choose, while a patent application is
>pending?  I thought perhaps it did.
>
>2. If so, may the IETF properly impose obligations on inventors that run
>counter to these rights, when they participate in IETF deliberations?
>
>3. If not, is the IETF exposing itself or its participants to possible
>damages from inventors whose rights have been abrogated by this rule?
>
>4. Has this rule been vetted by IETF legal counsel?
>
>Needless to say, I am not a lawyer, but I would want to know the answers to
>these questions before I pushed this patent disclosure issue too far, or
>attempted to punish those who may violate the patent clause in RFC 2028.
>Regards,
>
>Bill Burr

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 13 Apr 1998 13:40:41 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
Comments: To: [email-masked]
To: [email-masked]

Russ,. I think that is going way too far.

It is one thing to say that a standard should not mandate or be dependent
upon the use of a patented technique, but it is quite something else to
say that a conformant implementation MAY NOT use such a technique.

It would be acceptable to point out the possible interoperability problems that may
result from such a usage, but some applications, perhaps those used within a
closed user group, may be perfectly willing to use a superior technique that is
outside of the minimally compliant subset, even if some royalties are required.

I continue to be quite concerned by the obvious anti-intellectual property bias
of the IETF, of which this is the latest example. I fear that such an approach
may lead many vendors to realize that within the IETF innovation is to be punished,
and patents are the kiss of death, and they will begin to withdraw from such efforts
and adopt de facto or proprietary standards instead.

In addition to the possibility that inventors would not be able to reap the fruits of their
labor, I am also concerned that some misguided individuals or companies might
attempt to file a patent on techniques that are already in the public domain, jor
might be obvious to those skilled in the art, just to try to preempt or delay
someone else from using such a technique. (Note that I am specifically not making
any allegations about anyone in particular in this regard, specifically including Entrust/Nortel.)

As far as I am concerned, the only acceptable way of phrasing the comment about
a "removed" attribute would be something like the following:

"Applications making use of this attribute or extension without a license MAY
be infringing upon a patent held or filed by XYZ Corp., but until such claims
have been upheld in litigation this 'fact' cannot be necessarily be taken for
granted. The advice of a competent patent attorney in this matter may be
appropriate."

"In the interest of interoperability, applications conforming to this profile
generally SHOULD NOT issue certificates [or CRLs] that contain this
extension.  If this extension is present and marked non-critical
in a certificate [or CRL], conforming applications MAY ignore this
non-critical extension if they choose not to implement the option.
If this extension is present and marked critical in a certificate [or CRL],
conforming applications must reject the certificate [or CRL] containing
this critical extension if they choose not to implement the option. However,
conforming applications, including CAs, MAY issue certificates containing
the option if they choose to do so if they recognize (or intend) the possible
interoperability consequences, and conforming applications which
choose to implement the option may also support such extensions when
marked Critical."

Bob

>At the PKIX meeting in LA, Tim Polk gave a presentation on the extensions that
>will be removed from PKIX Part 1 to remove any dependance on recently issued
>patents.  A straw poll confirmed overwhelming support for this approach,
>and we
>are making the changes to remove the extensions.
>
>Many, many months ago, we decided that PKIX Part 1 should say something about
>every extension in X.509.  Keeping with this philosophy, I propose the
>following words for the extensions that are being "removed:"
>CAs conforming to this profile must not issue certificates [or CRLs] that
>contain this extension.  If this extension is present and marked non-critical
>in a certificate [or CRL], conforming applications must ignore this
>non-critical extension.  If this extension is present and marked critical in a
>certificate [or CRL], conforming applications must reject the certificate [or
>CRL] containing this critical extension.
>Russ

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:  Marc Branchaud <[email-masked]>
Date:         Mon, 13 Apr 1998 12:11:24 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

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

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

Paul,

I agree with you that HTTP caching muddies the OCSP waters considerably.  I
also agree that giving the relying party as much information as possible is
preferable to forbidding caching entirely.

However, relying on nextUpdate for that information is not the way to go.

An OCSP server is not necessarily a CRL-processing engine.  In many cases,
certificate status can be served without using CRLs at all (like when the
OCSP server has direct access to a CA's certificate store).  In these
situations, "nextUpdate" has no meaning at all.

Instead of requiring nextUpdate, the solution is to make caching an explicit
part of OCSP.  I'm working on a draft that does just this, and I'm in the
process of running it by a couple of people before submitting it to the
list.  I hope to have it out by (or before) Friday.

It's my hope that the draft will provide a focus (and solution) for the
caching issue, which has yet to be dealt with in any depth.  However,
nextUpdate is really a separate issue:  It firmly belongs in the realm of
OCSP-based-on-CRLs.  OCSP caching is a much broader issue.

                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:         Mon, 13 Apr 1998 12:59:00 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
Comments: To: [email-masked]
To: [email-masked]

Tony,

I am sometimes (perhaps justifiably) criticised for taking too legalistic a view
of some of these issues, byut to my way of thinking, the primary purpose
of a Critical flag is to force a particular extension to be brought to the
attention of the relying party.

If the relying party chooses to ignore the warning, etc., so be it -- any
loss that might result from him ignoring that warning pretty clearly falls
on his own head if the matter goes to court and the issue of "commercially
reasonable reliance" comes up.

If the user chooses to check "don't warn me again", I would hope that the
software would at least keep track of the particular VALUE of some
extension that was to be ignored.

The particular semantics associated with an extension that is marked
with a Critical flag should be carefully defined (now there's a novel
concept!), and the action required by any compliant implementation
should be spelled out.  But clearly, it must be acceptable to inform the user/
relying party and ask her what she wants to do -- after all, just as they
are allowed to read unsigned text, they are free to ignore
a digital signature that doesn't check, and also to ignore an invalid
certificate chain, just like I ignore all PGP-signatures, if they so desire.
Caveat Emptor!

In other words, the semantics of a Critical extension cannot be enforced
at gunpoint, not even by the IETF.  They are a warning, and do not carry
the force of law.

(However, I will concede that I am thinking about this primarily from a
digital signature standpoint. If an extension were to say, "Don't decrypt any
message encrypted using this certificate unless you agree to honor the following
constraints," then that might constitute an contract, and might be enforceable.)

Bob

>>> Tony Bartoletti <[email-masked]> 04/08 3:33 PM >>>
Bob,

At 08:06 AM 4/8/98 -0600, you wrote:

[tony snip here]

>More to the point, if an implementation "enforces" such a constraint, what
do they
>do if the formal validation fails?  I would generally expect that a
reasonable
>implementation would simply buck the decision up to the human user "The
>xxx constraint is violated by certificate yyy. Do you want to accept the
>certificate anyway?"  What is the norm for most implementations?
>
>Bob

Like an "harmonic convergence", your paragraph above mirrors my question in
the "Criticality of extensions" thread.  By extension (no pun intended) what
if, for certain "common" extensions, the window pops-up with the additional
check-box labeled "Don't warn me again"?  (I.e., henceforth always accept
the cert if this particular constraint fails.)  I suppose this is perfectly
legal, but is contrary to what many "expect" by "enforces constraints."

____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:  "Perry E. Metzger" <[email-masked]>
Date:         Mon, 13 Apr 1998 10:32:52 -0400
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] RFC 2028 and Nortel Patent 5699431
To: [email-masked]

Tony Rutkowski writes:
> That's an affiliation.  This is an old story...eventually it
> will probably happen.  The IETF should have legal personality
> and it can only acquire that by incorporation.

Gee, and this from a lawyer?

Unincorporated organizations have just as much reality as incorporated
ones. One of the largest investment banks in NYC, Goldman Sachs, is
not incorporated, and never has been. So is Brown Brothers Harriman,
for that matter, and lots of other ones.

There are, in fact, lots of real world organizations that, for one
reason or another, are not incorporated.

The major difference is, of course, that unincorporated organizations
have more personal liability for their participants, but they are
fully capable of functioning. People generally incorporate to reduce
liability, but it doesn't make the organization less real.

Perry

Approved-By: [email-masked]
Date:         Sat, 11 Apr 1998 22:06:57 -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: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

At 03:15 AM 4/4/98 -0800, Peter Gutmann wrote:

>A while back someone made the comment that "It's good that <large vendor>
>always puts the name of the MUA in their mail headers, because it allows you
>to bypass <vendor>-specific bugs".  This leads to a second type of extension,
>implementationWhichCreatedThis, which may be even more useful than the one
>described above.  As it is, it's already possible to identify certain
>implementations just by the bugs in the certificates they produce, but being
>able to make a positive ID would be really useful because by knowing how they
>(mis)interpret certain fields, your implementation could follow the same
>interpretation.

I agree that adding this attribute effectively raises the flag of surrender
in PKI standardization. It may be pragmatic, but it sends the wrong message.

I also suspect that if done, sooner or later some vendor would decide to
discriminate for or against certs generated by a certain vendor's software.
 This would lead to lying by the cert creation software.  This scenario has
already happened with browsers.

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:  Warwick Ford <[email-masked]>
Date:         Sat, 11 Apr 1998 16:36: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: Warwick Ford <[email-masked]>
Subject:      [IETF-PKIX] Draft LA Minutes
To: [email-masked]

Here are Draft LA Minutes for review and comment.

Warwick
---------------------------------

IETF-PKIX MINUTES - APRIL 1, 1998

CERTIFICATE AND CRL PROFILE

Tim Polk summarized the status and outstanding issues on Draft 07 of the
profile.  It is essential that this document be progressed quickly since
several other standards are waiting on it.  New additions to 07 include the
addition of UTF-8 in accordance with IETF Best Practices, correction of the
path processing algorithm to align with X.509, and removal of semantics for
wildcards in alternative names.  A few other minor fixes have been noted
but not yet published.  The S/MIME group has requested that issuer DN be
required.  The TLS group has requested that wildcards not be forbidden.

Beyond these minor issues, the document is currently stuck in last call
owing to patent issues resulting from an Entrust patent issued in December.
 Tim proposed that all text relating to unresolved issues be removed to a
separate I-D, and the rest of the document be progressed immediately to
Proposed Draft.  This means removing CRL distribution points, authority
access info, and some policy qualifiers, and removing URI semantics from
altnames.  (Sections impacted: Policy Qualifiers, CRL Distribution Points,
and Issuing Distribution Points.)  Steve Kent reported that the Area
Director had agreed with this approach.  A straw poll of those present
indicated strong support for and no support against this approach.

OCSP

Mike Myers described the current status.  Recent changes included adoption
of ASN.1 notation and transport independence.  It is also proposed that the
following changes be made.  Clients and servers SHALL support basic
response. Make clear that CRLs not be required to implement OCSP.  The
response is modified to only send back certID.  The "certificate data
required" response will be kept.  The policy ID extension will be deleted.
The CRL inclusion extension exceeds the scope, therefore the "noCRL"
response should be deleted.  Nobody raised objections to any of these.

With regards to specification of non-CA responders' certificates, it is
proposed that we define an extension to enable clients to specify which key
to use to sign responses.  It is also proposed to define an extension to
enable clients to specify the key they are currently relying on.  (The
responder only sends its certificate back if different.)  Re caching of
responses, it is proposed that a separate draft be produced on transport
mechanisms to address caching.  The reference to authority information
access will also be removed for patent reasons.

The possibility of using CMS to protect OCSP was raised.  This will be
considered.

Ambarish Galpani briefed the group on the following open issues:  What
types of responders to OCSP requests will be supported:  CA, client-trusted
responder, CA-designated responder?  Also the issue of the semantics of
thisUpdate, nextUpdate, and producedAt.  (Descriptions need to be tightened
up.)  Also the method of identification of certificates - should it include
a hash of the public key of the issuer?

Mike Myers raised some issues of response semantics:  Does notRevoked imply
that the certificate exists?  Should there be multiple status bits
returned, e.g., one bit for expired, one for revoked?  (General feeling:
Yes.)  What should the response be for a certificate known to have not been
issued?  It was also pointed out that there may be a patent by Silvio
Micali covering OCSP.  The authors were asked to explore.

IPSEC SUPPORT

Rodney Thayer described IPSEC PKI requirements, and work to prepare an
IPSEC specification for use of PKI and PKIX.  Issues include subject names
(and altnames), cross-certification, off-line operations, hard limits
(e.g., on hierarchy depth), identity vs. address vs. usage, and extended
key usage.  For cross-certificates, there is a need for an optional
nameConstraint containing DNSname, RFC822name, or IPaddress.  For IPaddress
Rodney proposed to use an address plus mask.  This is not yet resolved.

PKIX MINUTES - APRIL 2, 1998

LDA PROFILE AND SCHEMA

Pat Richard reported that the LDAP v2 profile had been rejected by the IESG
because of some security issues (subsequently fixed in a revised draft),
the absence of a schema, the need for a section on "acceptable searches",
and the fact that LDAP v2 rather than v3 is used.  A new schema draft has
been produced - the profile will not be approved by the IESG without
simultaneous approval of this schema.  Re v2/v3 there are various options.
Tim Howes reported that work is still under way on some v3 extensions
(access control, referrals, replication), but this probably does not impact
PKIX.  There are two choices on how to proceed: (1) produce v2 profile and
schema then make them informational when v3 is developed, and (2) stop work
on v2 and start work on just v3.  On a show of hands, there was
substantially more support for (1) than (2).  This will also be referred to
the list.

CRMF, CMMC AND CMC

Mike Myers outlined the status of these projects.  CRMF defines a standard
format for a certificate request.  CMMF defines message formats for other
certificate management functions.  CMC defines a protocol for carrying CRMF
and CMMF messages over CMS, to support certification of a public key,
querying status of certificate requests, and certificate/CRL retrieval.

Some comments were received on CRMF, regarding public-key MAC, registration
control, PKI archive options, the definition of dhMAC, and ASN.1
imports/exports.  These will be addressed in an updated draft of CRMF.

Paul Hoffman raised the question of possible pending patents impacting CRMF
and CMC, and suggested that the Chairs try to get commitments from authors
that there are no patent encumbrances.  Attention was also drawn to RFC
2028 which spells out expectations regarding intellectual property
disclosures by IETF participants.

Mike also presented a list of open issues (most submitted by Jim Schaad)
for CMMF and CMC. Some of the issues require discussion on the list before
resolution. The following significant issues were discussed:

(1) CMRF describes the certificate request message of choice for PKIX. CMC
specifies an alternate format as "mandatory to implement". The sense of the
group was that CMRF should be the mandatory request format for CMC.

(2) Carlisle Adams noted that secure initialization is not a feature of
CMC. After some discussion, there was a straw poll. The sense of the group
was that secure initialization should be feature of CMS and should be
mandatory to implement. This requirement can be supported using the CRMF
message format discussed above.

(3) The CMMF draft contains alternative formats for most messages. In brief
discussion of this fact, some attendees indicated a single format for
messages would be preferable. There was no discussion of how this could be
achieved.

(4) CMC includes a Diffie-Hellman based MAC. Paul Hoffman asked about the
patent status of this feature. The WG chair asked the authors to determine
the patent status and report to the group.

It was clarified that a new draft of CRMF will be produced taking into
account ASN.1 fixes and the fixes mentioned above.  This new draft will be
sent to the IESG to replace the draft they are currently considering.  The
target timescale for CMMF and CMC documents is to go to last call at the
Chicago IETF.

TIMESTAMP AND NOTARY DRAFTS

Rob Zucherrato presented an update on the timestamp and notary drafts. The
PKIX charter has not been modified, so both the timestamp draft and the
notary protocol draft have been moved to independent status. Jeff Schiller
informed the WG that he will not consider amending the charter until the
profile becomes an RFC.

Revised drafts for these protocols are now available under
"ietf-draft-adams-*". Most of the discussion centered on the difference
between the two protocols, which remains a source of confusion. The
timestamping protocol does not attempt to verify the identify of the
submitter; the notary protocol does. The notary protocol may also attempt
to validate a particular certification path at the time of submission. This
may be useful since secure archiving support is not widely deployed.

The title of the notary protocol may be one reason for the confusion. It
was suggested that the draft be renamed to reduce the ambiguity. Another
reason is the perceived overlap between the notary protocol and OCSP. The
goals of the protocols are very different; this should probably be
clarified in the notary draft.

Rob presented several outstanding issues for discussion. As a result of the
discussion, the group requested that the timestamp draft use CMS signed
data encapsulation, and omit the requester name in the response. (Since the
timestamp server does not verify the requester's identity, its appearance
in the response gives the wrong impression.)

In addition, Rob noted that both areas are the subject of numerous patents.
This may present a difficulty in progressing the drafts.

Brian LaMaachia presented implementation issues that he has encountered in
the area of path building. In particular, inconsistent use of key
identifiers and distinguished name fields makes it difficult to develop
paths. As a result of this discussion, the group proposed to require key
identifiers in all certificates and clarify the name matching rules. In
conjunction with the proposal to require issuer distinguished names in all
certificates, key identifiers will greatly simplify path building in PKIX1
compliant systems. The name matching rules will clarify ambiguities
introduced by BMPString and UTF8String encodings.

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

Approved-By:  Todd Glassey <[email-masked]>
Date:         Sat, 11 Apr 1998 13:10:03 -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: Todd Glassey <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: cc: warwick ford <[email-masked]>
To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0029_01BD654B.240E6E40
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: Warwick Ford <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, April 09, 1998 8:43 PM
Subject: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431

>I totally support the spirit behind the key clause in RFC 2028 regarding
>intellectual property and the IETF.  However, this clause may warrant some
>reconsideration ... taking into account the circumstances surrounding
>Nortel Patent 5699431 (PKIX and CRL distribution points).
>
>   To ensure a fair and open process, participants in the IETF and its
>   Working Groups must be able to disclose, and must disclose to the
>   Working Group chairs any relevant current or pending intellectual
>   property rights that are reasonably and personally known to the
>   participant if they participate in discussions about a specific
>   technology.
>
>This clause does not completely protect against the problems that occurred
>with 5699431.  The Nortel individuals (including myself) who developed the
>original CRL Distribution Point idea had no intention, at that time, to
>file a patent claim for the idea.  We submitted the idea to various
>standards groups, as a bona fide standards contribution, and promoted its
>adoption.  We were not violating RFC 2028 nor any other standards committee
>policies at that time.  It was almost 12 months later that someone
>concluded that Nortel could and should file a patent for that invention
>provided the filing occurred before the 12-month anniversary of the
>original publication of the idea.  (This seemed to me a reasonable
>IP-defensive action at the time -- I never imagined that Nortel or its
>heirs would later try to tax the industry on the basis of this patent.)
>
>After the patent was filed, I don't believe I ever participated
>significantly in discussions about CDPs in the IETF (I moved to VeriSign
>shortly after that time, so had given up all stake in the patent anyway).
>I think certain Entrust PKIX participants, however, still have something to
>answer re RFC 2028 adherence (the campaign waged by certain individuals
>against OCSP in favor of CRLs/CDPs in December 1997 springs to mind).

Warwick,
I understand and agree with you but from a process and legal perspective the
bottom line is the bottom line - When modulated by USPTMO Policy and US Law,
the wording of the current IETF and IESG charters and Standards Process
Models allows for Intellectual Properties to be patented after they have
been granted IETF and IESG blessings, and that's what's at question here.
You clearly just got caught in the public reaction to this loophole.

To address the underlying issue:
--------------------------------------------
Maybe it should be submitted as a question to the IETF Secrateriat and the
IESG as a whole...  isn't  this something that the IETF and IESG wanted to
avoid by their efforts?, the making any one technology financially more
valuable by the adding of "IETF/IESG Standard" and then having a patent
appear out of nowhere after the fact.

And by the way, wouldn't a simple fix for this  be to amend the standards
process so that NO standard under consideration may progress past the RFC
stage until...
    -    the one year anniversary is exceeded and no patent is applied for,
    -    or a patent is applied for and licensing rights compliant to some
"public usage" mode are instituted [This might be an interesting   project
for some of our mutual ABA friends to look at, the drafting of  the legal
language for the "public-usage" rights model.]
    -    or the patent is assigned into the public domain  [ Also another
project for our ABA friends to draft something for...].

Although an easier change would be to adjust the wording of the IP specific
text to read that no single technology or method suite may be standardized
if it is patented and its the only submitted form of the invention/method.
Exceptions to this would be like the Certicom model where only there method
is patented and ECC is public domain... This seems to me the easiest way to
administer what is and isn't standardizable.  Either way it seems that the
intent of these particular requirements are to create and support the
operation of  a more impartial, A-political IETF and that is a very good
idea!.

Todd

>
>That aside, even if everyone had followed RFC 2028 to the letter, the basic
>problem of 5699431 would remain.
>The way around this problem is not obvious.  We might consider, for
>example, requiring that when someone files a patent or learns of a patent
>filing that they be required to disclose such facts.  However, this is just
>not practical.  Most corporate employees and contractors are bound by
>contracts that prohibit them from disclosing intellectual property
>information, including information about filed but ungranted patents,
>without authorization.  In large corporations, such authorization can never
>be guaranteed to be under the control of the IETF participant.  The
>situation is worse in the case of a past employer -- when one leaves a
>corporation one is typically contractually bound to maintain silence on
>intellectual property matters and is also no longer in a position to
>influence the corporation to release the information.  (As many of you
>know, this is precisely the invidious situation I was in throughout most of
>1996 and 1997, when I knew of the existence of the filing of 5699431 but
>could not bring it to the attention of the IETF.)
>
>The other possibility is to oblige participants not to sign invention
>disclosures for technology that they have previously discussed in the IETF.
> This might work.
>
>I also understand the US Federal Government is working on revising the code
>to align with patent policies elsewhere, so maybe the problem will go away.
>
>This problem is more difficult for the IETF than other standards groups
>because of the absence of relationships between corporations (who generally
>own the IP) and the IETF.
>
>Perhaps others have valuable insight...
>
>Warwick
>
>(Disclaimer: These comments are my own and do not necessarily reflect
>positions of VeriSign, Inc.)
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., Tel (781)2456996 x225; Fax (781)2456006
>[email-masked];  301 Edgewater Pl, Suite 210, Wakefield, MA 01880
>---------------------------------------------------------------------
>

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

------=_NextPart_000_0029_01BD654B.240E6E40--

Approved-By:  Warwick Ford <[email-masked]>
Date:         Fri, 10 Apr 1998 23:39: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: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: John Day <[email-masked]>, [email-masked]
To: [email-masked]

John:

At 03:28 PM 4/10/98 -0400, John Day wrote:
>Actually, if Warwick submitted the stuff to ISO, they will claim copyright
>on all contributions (at least they have recently) and while copyright
>isn't a patent, they could make things messy.

To correct some details, it was not "Warwick" who submitted anything to
ISO.  Anyone who has taken the time to read the patent knows the standards
submission was a BNR corporate contribution to Standards Canada, originated
from Colin Ashford of BNR.  The Canadian National committee subsequently
endorsed this as a Canadian contribution to ISO/IEC.  ISO copyright is not
an issue here.

Warwick

---------------------------------------------------------------------
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:         Fri, 10 Apr 1998 09:38:36 -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: Scott Bradner <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

> As a non-organization IETF has no established
> legal relationships.

and as an organization the ISOC exists and the ISTF standards process
specifically refers to the ISOC

> It's most
> salient feature is that it probably helps minimize the liabilities
> of the participants in the process - especially the IESG.

the ISOC pays for insurance to cover the IESG (and the working
group chairs & the IAB)

> What
> if someone chooses to ignore the RFC?  If the answer is something
> other than nothing, it might be useful to articulate.

the same thing that happens when someone ignores the rules of
many other standards bodies - some wronged party, normally not the
standards body, throws lawyers at the situation

Scott

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 17:03:39 -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: Christian Huitema <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Scott Bradner <[email-masked]>, [email-masked], [email-masked]
To: [email-masked]

On Apr 10,  4:48pm, Scott Bradner wrote:
> Subject: Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
> --
> what about the expectation that there be at least two different examples of
> licenses prior to going to Draft Standard?
> --
>
> yes that is the case
>
> what was unclear from your note was teh idea that something might have
> to be done before any standards track work - a doc can go to
> proposed std without any of this
>
> also - there is no requirement for anyone to publish the details of
> the licence agreement just that there be more than one cases
> where the implementer felt that the license requirements were not
> too bad to be signed
>
> Scott
>-- End of excerpt from Scott Bradner

When I proposed the "let's see whether the licensing agreement work"
rule, I had really in mind a "rough consensus" approach.  If a significant
fraction of the working group believe that the license agreements are
inadequate, then there would be a case for either not progressing
the standard or at the very least authorizing work on an alternative
option.

If I understand correctly, CRL were only one of the options in PKIX,
and alternatives were debated.  If a significant fraction of the working
group believe that, in light of the patent announcement, the standard
should be revised, they should definitely be free to do so.

--
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 16:48:24 -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: Scott Bradner <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked], [email-masked]
To: [email-masked]

--
what about the expectation that there be at least two different examples of
licenses prior to going to Draft Standard?
--

yes that is the case

what was unclear from your note was teh idea that something might have
to be done before any standards track work - a doc can go to
proposed std without any of this

also - there is no requirement for anyone to publish the details of
the licence agreement just that there be more than one cases
where the implementer felt that the license requirements were not
too bad to be signed

Scott

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 16:42:45 -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: "Donald E. Eastlake 3rd" <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
To: [email-masked]

On Fri, 10 Apr 1998, Dave Crocker wrote:

> Date: Fri, 10 Apr 1998 12:57:15 -0700
> From: Dave Crocker <[email-masked]>
>
> ...
>
> Filing a claim after entering the knowledge into the standards process
> clearly goes against the IETF philosophy.  The fact that it is legal is
> really quite secondary.

Actually it is not clear that this is legal.  It is a somewhat murky area but
there is a concept of patent abuse which can lead to patent invalidation for
sufficiently egregious cases like this.

> ...
>
> d/
>
> __________________________________________________________________________
> Dave Crocker                 Brandenburg Consulting        +1 408 246 8253
> [email-masked]       675 Spruce Drive        (f) +1 408 249 6205
> www.brandenburg.com         Sunnyvale, CA 94086  USA

Donald
=====================================================================
Donald E. Eastlake 3rd     +1 978-287-4877(tel)     [email-masked]
   318 Acton Street        +1 978-371-7148(fax)     [email-masked]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.privacy.org/ipc

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 16:19:03 -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: Scott Bradner <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

--
If there are pre-existing claims, then they either
must be turned over to the IETF or the licensing arrangement must be
determined (and evaluated) prior to standardization.
--

actually that requirement was specifically removed in the revision of
1602 (now 2026) - the requirement for a preview of licensing arangements
turned out to be a real roadblock.  The rules are now that
the working group can decide to recommend going ahead even in
the face of a lack of specific details if it feels that the results
are important enough.

Scott

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 15:28:33 -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: John Day <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Dave Crocker <[email-masked]>
Comments: cc: Warwick Ford <[email-masked]>, [email-masked]
To: [email-masked]

At 14:23 -0400 4/10/98, Dave Crocker wrote:
>At 01:44 PM 4/10/98 -0400, John Day wrote:
>>According to a patent agent I know, you have 1 year from the time you
>>publish to file the patent or it can be considered public domain.  So if
>
>that's relative to publishing, but I believe that the ultimate
>determination for precedence of claim in the US is based on documentable
>demonstration of the practise, or somesuch.  In other words, it's when you
>did the work, not when you published or filed.
>
That may be the date for which you can claim to be first to invent and
therefore get the patent.  But if you have an idea, publish on it (and a
contribution to a standards meeting constitutes publishing), and then wait
more than a year to patent, the work is considered public domain (if
someone wants to complain).

Actually, if Warwick submitted the stuff to ISO, they will claim copyright
on all contributions (at least they have recently) and while copyright
isn't a patent, they could make things messy.

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 13:44:18 -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: John Day <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Dave Crocker <[email-masked]>
Comments: cc: Warwick Ford <[email-masked]>, [email-masked]
To: [email-masked]

At 11:22 -0400 4/10/98, Dave Crocker wrote:
>At 10:59 AM 4/10/98 -0400, John Day wrote:
>>since the idea was submitted to various standards organizations before the
>>patent was applied for one could argue that the invention is in the public
>>domain and the patent is invalid.  Of course, this requires lawyers, . . .
>
>My understanding is that US law attends to something along the lines of the
>time the practise is created, rather the than when the patent was filed.
>Filing date is taken as a prima facie indicator of precedents, but not the
>ultimate arbiter.

According to a patent agent I know, you have 1 year from the time you
publish to file the patent or it can be considered public domain.  So if
was more than a year from the time Warwick took the proposal to a standards
committee and the time Nortel filed the patent, the patent can be shown to
be invalid.  (at least in the US.)

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 10:18:08 -0400
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: cc: [email-masked]
To: [email-masked]

At 10:46 PM 4/9/98 -0700, Warwick Ford wrote:
>I totally support the spirit behind the key clause in RFC 2028 regarding
>intellectual property and the IETF.  However, this clause may warrant some
>reconsideration ... taking into account the circumstances surrounding
>Nortel Patent 5699431 (PKIX and CRL distribution points).
>
>   To ensure a fair and open process, participants in the IETF and its
>   Working Groups must be able to disclose, and must disclose to the
>   Working Group chairs any relevant current or pending intellectual
>   property rights that are reasonably and personally known to the
>   participant if they participate in discussions about a specific
>   technology.
>

Like Warwick, I like the spirit of this rule.

However, Article II of the United States Constitution specifically empowers
Congress to:

 "promote the progress of science and useful arts, by securing for limited
times to authors and inventors the exclusive right to their respective
writings and discoveries;"

Congress, therefore, gets to say what the rights of inventors are in the
patent laws.  My questions are:

1. Does the US patent law create a statutory right of inventors to maintain
the secrecy their invention, if they choose, while a patent application is
pending?  I thought perhaps it did.

2. If so, may the IETF properly impose obligations on inventors that run
counter to these rights, when they participate in IETF deliberations?

3. If not, is the IETF exposing itself or its participants to possible
damages from inventors whose rights have been abrogated by this rule?

4. Has this rule been vetted by IETF legal counsel?

Needless to say, I am not a lawyer, but I would want to know the answers to
these questions before I pushed this patent disclosure issue too far, or
attempted to punish those who may violate the patent clause in RFC 2028.
Regards,

Bill Burr

Approved-By: [email-masked]
Date:         Fri, 10 Apr 1998 09:58:53 -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: Tony Rutkowski <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Scott Bradner <[email-masked]>, [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

Scott,

>> legal relationships.
>
>and as an organization the ISOC exists and the ISTF standards process
>specifically refers to the ISOC

That's an affiliation.  This is an old story...eventually it
will probably happen.  The IETF should have legal personality
and it can only acquire that by incorporation.

The legal relationships that Warwick and I are talking
about are between a legal person (e.g., IETF, Inc) and
its participating members.  These plainly don't exist,
and can't exist under the present model.

>the ISOC pays for insurance to cover the IESG (and the working
>group chairs & the IAB)

I know how that was set up, and what it may or may not cover. :-)
Good luck.  In the U.S. legal system, you minimize your liability
with legal structures and process - not insurance.

--tony

Approved-By:  Warwick Ford <[email-masked]>
Date:         Fri, 10 Apr 1998 19:48:30 -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: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked], [email-masked]
To: [email-masked]

Perry:

I am not arguing the reasonableness of that action.  Having now seen how
unexpected subsequent actions can lead to a clearly unreasonable outcome
overall, I cannot disagree with you.  But in fairness to all, I think we
need to recognize that there is a misalignment in different people's
understandings and expectations.  Therefore, I am suggesting that we move
to better align and document understandings and expectations for the
future.  Like add some more precision to RFC 2028...

Also, in the interests of eliminating duplication, might I suggest that
this thread now be pursued only on the poised list where it most properly
belongs?

Warwick

At 11:59 AM 4/10/98 -0400, Perry E. Metzger wrote:
>I'm very angry about this sort of thing. I realize that you feel that
>it was reasonable for Nortel to file a patent on an idea already
>presented to the IETF, but I do not think this was reasonable
>behavior. The open standards process depends on people being fully
>informed of all the encumberances on technology they are
>considering.

(Disclaimer: These comments are my own and do not necessarily reflect
positions of VeriSign, Inc.)

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

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Fri, 10 Apr 1998 14:27: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: Paul Hoffman / IMC <[email-masked]>
Subject:      [IETF-PKIX] OCSP and HTTP proxy caching
To: [email-masked]

Greetings again. As I brought up last week at the LA IETF meeting, OCSP is
still in dangerous territory with respect to HTTP proxy caches. Basically,
we are betting that all HTTP proxy caches work according to spec, none of
the caches have clock skews from the HTTP servers that are emitting OCSP
responses, and all the caches work perfectly. If we're wrong, people will
get what appear to be authoritative responses that are out of date. No one
in their right mind should then rely on OCSP responses that didn't include
a nonce.

There are two ways to fix this problem: cache busting (making sure that no
request/response gets cached) or giving the user more knowledge about what
the result they get means. I think the latter is cleaner and more amenable
to scaling.

The current OCSP draft says about nextUpdate in section 2.4:

    The producer of the response MAY include a value for nextUpdate.  The
    exact interval between thisUpdate and nextUpdate for given response is
    a matter of local security and operational policy.  If the nextUpdate
    field is not present, the response is is known to be correct at the
    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
    check again with the responder.  If the value of nextUpdate is set, it
    is just a hint, not a guarantee, of when the responder expects to have
    new information about that certificate's status.

PKIX part 1, section 5.1.2.5, says:

   This field indicates the date by which the next CRL will be issued.
   The next CRL could be issued before the indicated date, but it will
   not be issued any later than the indicated date.
. . .
   This profile requires inclusion of nextUpdate in all CRLs issued by
   conforming CAs.

Notice the differences? :-)

If we adopt the requirements from PKIX part 1 (nextUpdate has a definitive
meaning, and it the field MUST be included), the recipient of an OCSP
response does not need to worry about broken caches and clock skew. Without
the kind of definitive wording used in PKIX, we *cannot* allow proxy
caching in OCSP because the end user would never know if they were getting
something that the OCSP server really believed in.

Thus, I propose that the wording from PKIX part 1 replace the current OCSP
wording.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  "Flanigan, Bill" <[email-masked]>
Date:         Fri, 10 Apr 1998 16:32:43 -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: "Flanigan, Bill" <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
To: [email-masked]

Don/Perry,

        Right on!  However, timing in life is EVERYTHING.  Maybe the
big-picture plan/hope was for either (1) Part I to become a Proposed
Standard BEFORE 97/12/16 or (2) the PTO wouldn't issue until AFTER 98/08/28.
Comments?

Bill Flanigan

> -----Original Message-----
> From: Dave Crocker [SMTP:[email-masked]]
> Sent: Friday, April 10, 1998 3:57 PM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
>
> At 11:59 AM 4/10/98 -0400, Perry E. Metzger wrote:
> >I'm very angry about this sort of thing. I realize that you feel that
> >it was reasonable for Nortel to file a patent on an idea already
> >presented to the IETF, but I do not think this was reasonable
> >behavior.
>
> The IETF has a pretty clear and straightforward position with respect to
> intellectual property:  If there are pre-existing claims, then they either
> must be turned over to the IETF or the licensing arrangement must be
> determined (and evaluated) prior to standardization.  "Inventions" that
> take place in the IETF context belong to the IETF.
>
> That's the philosophy.
>
> It creates a clear distinction between was an individual (or organization)
> can legally do and what they are ethically/morally bound to do.  An
> attitude which relies solely on the question of what is legal does not
> result in behavior that is generally felt to be socially acceptable.
> Quite
> the contrary.
>
> Filing a claim after entering the knowledge into the standards process
> clearly goes against the IETF philosophy.  The fact that it is legal is
> really quite secondary.
>
> Corporate constraints on their employees and consultants cannot be
> ignored,
> but neither can the choices available to the individuals.  The fact that a
> company asserts the requirement for confidentiality does not automatically
> bind the individual, nor does it prevent them from taking other actions.
>
> Perhaps we need to add language which states the intent even more clearly
> and which dictates the relevant behavioral rules more thoroughly.  However
> we also need to consider actions to be taken when the spirit or rules are
> violated.  Within the limited context of the IETF, there are nonetheless
> some choices we have in reacting to transgressions.
>
> Let's try to work through the possible timings and actions more thoroughly
> than we have in the past -- i.e., a case analysis -- treating this as a
> programming exercise, rather than a simple statement of a broad principle.
>
> d/
>
> __________________________________________________________________________
> Dave Crocker                 Brandenburg Consulting        +1 408 246 8253
> [email-masked]       675 Spruce Drive        (f) +1 408 249 6205
> www.brandenburg.com         Sunnyvale, CA 94086  USA

Approved-By:  Dave Crocker <[email-masked]>
Date:         Fri, 10 Apr 1998 13:27: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: Dave Crocker <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: Scott Bradner <[email-masked]>, [email-masked]
To: [email-masked]

At 04:19 PM 4/10/98 -0400, Scott Bradner wrote:
>turned out to be a real roadblock.  The rules are now that
>the working group can decide to recommend going ahead even in
>the face of a lack of specific details if it feels that the results
>are important enough.

what about the expectation that there be at least two different examples of
licenses prior to going to Draft Standard?

d/

__________________________________________________________________________
Dave Crocker                 Brandenburg Consulting        +1 408 246 8253
[email-masked]       675 Spruce Drive        (f) +1 408 249 6205
www.brandenburg.com         Sunnyvale, CA 94086  USA

Approved-By:  "Flanigan, Bill" <[email-masked]>
Date:         Fri, 10 Apr 1998 16:13:10 -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: "Flanigan, Bill" <[email-masked]>
Subject:      [IETF-PKIX] Some observations - technical and notTechnical
To: [email-masked]

technical:  instructions for joining the exploder at
<http://www.ietf.org/html.charters/pkix-charter.html> are hosed.  Needs
fixing!

notTechnical:  10 of the 14 I-Ds are presently authored or co-authored by
former/current employees of Entrust Technologies, Ltd.  Needs fixing?

Approved-By:  Dave Crocker <[email-masked]>
Date:         Fri, 10 Apr 1998 12:57:15 -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: Dave Crocker <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
To: [email-masked]

At 11:59 AM 4/10/98 -0400, Perry E. Metzger wrote:
>I'm very angry about this sort of thing. I realize that you feel that
>it was reasonable for Nortel to file a patent on an idea already
>presented to the IETF, but I do not think this was reasonable
>behavior.

The IETF has a pretty clear and straightforward position with respect to
intellectual property:  If there are pre-existing claims, then they either
must be turned over to the IETF or the licensing arrangement must be
determined (and evaluated) prior to standardization.  "Inventions" that
take place in the IETF context belong to the IETF.

That's the philosophy.

It creates a clear distinction between was an individual (or organization)
can legally do and what they are ethically/morally bound to do.  An
attitude which relies solely on the question of what is legal does not
result in behavior that is generally felt to be socially acceptable.  Quite
the contrary.

Filing a claim after entering the knowledge into the standards process
clearly goes against the IETF philosophy.  The fact that it is legal is
really quite secondary.

Corporate constraints on their employees and consultants cannot be ignored,
but neither can the choices available to the individuals.  The fact that a
company asserts the requirement for confidentiality does not automatically
bind the individual, nor does it prevent them from taking other actions.

Perhaps we need to add language which states the intent even more clearly
and which dictates the relevant behavioral rules more thoroughly.  However
we also need to consider actions to be taken when the spirit or rules are
violated.  Within the limited context of the IETF, there are nonetheless
some choices we have in reacting to transgressions.

Let's try to work through the possible timings and actions more thoroughly
than we have in the past -- i.e., a case analysis -- treating this as a
programming exercise, rather than a simple statement of a broad principle.

d/

__________________________________________________________________________
Dave Crocker                 Brandenburg Consulting        +1 408 246 8253
[email-masked]       675 Spruce Drive        (f) +1 408 249 6205
www.brandenburg.com         Sunnyvale, CA 94086  USA

Approved-By:  Dave Crocker <[email-masked]>
Date:         Fri, 10 Apr 1998 11:23: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: Dave Crocker <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: John Day <[email-masked]>
Comments: cc: John Day <[email-masked]>, Warwick Ford <[email-masked]>, [email-masked]
To: [email-masked]

At 01:44 PM 4/10/98 -0400, John Day wrote:
>According to a patent agent I know, you have 1 year from the time you
>publish to file the patent or it can be considered public domain.  So if

that's relative to publishing, but I believe that the ultimate
determination for precedence of claim in the US is based on documentable
demonstration of the practise, or somesuch.  In other words, it's when you
did the work, not when you published or filed.

d/
________________________________________________________________________
Dave Crocker                Brandenburg Consulting       +1 408 246 8253
[email-masked]      675 Spruce Drive       (f) +1 408 249 6205
www.brandenburg.com        Sunnyvale, CA 94086  USA

Approved-By:  "Perry E. Metzger" <[email-masked]>
Date:         Fri, 10 Apr 1998 11:59:57 -0400
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] RFC 2028 and Nortel Patent 5699431
To: [email-masked]

Warwick Ford writes:
> That aside, even if everyone had followed RFC 2028 to the letter, the basic
> problem of 5699431 would remain.
> The way around this problem is not obvious.  We might consider, for
> example, requiring that when someone files a patent or learns of a patent
> filing that they be required to disclose such facts.  However, this is just
> not practical.  Most corporate employees and contractors are bound by
> contracts that prohibit them from disclosing intellectual property
> information, including information about filed but ungranted patents,
> without authorization.

In that case, they should seek a waiver before going to the IETF
meetings.

I'm very angry about this sort of thing. I realize that you feel that
it was reasonable for Nortel to file a patent on an idea already
presented to the IETF, but I do not think this was reasonable
behavior. The open standards process depends on people being fully
informed of all the encumberances on technology they are
considering.

> In large corporations, such authorization can never
> be guaranteed to be under the control of the IETF participant.

Thats simply not true. Many large corporations are pefectly reasonable
about this. Those that cannot get their employers to be reasonable
about this should either not try to contribute technology at the IETF
or should change employers. I'm not joking. This sort of stuff simply
isn't acceptable, and the excuse that "Large companies are hard to
deal with" isn't sufficient.

I'm not trying to single you out, Warwick -- I'm sure you've done
everything here in good faith, but sometimes that isn't enough.

Perry

Approved-By:  Dave Crocker <[email-masked]>
Date:         Fri, 10 Apr 1998 08:22:39 -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: Dave Crocker <[email-masked]>
Subject:      Re: [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: John Day <[email-masked]>
Comments: cc: Warwick Ford <[email-masked]>, [email-masked]
To: [email-masked]

At 10:59 AM 4/10/98 -0400, John Day wrote:
>since the idea was submitted to various standards organizations before the
>patent was applied for one could argue that the invention is in the public
>domain and the patent is invalid.  Of course, this requires lawyers, . . .

My understanding is that US law attends to something along the lines of the
time the practise is created, rather the than when the patent was filed.
Filing date is taken as a prima facie indicator of precedents, but not the
ultimate arbiter.

d/
________________________________________________________________________
Dave Crocker                Brandenburg Consulting       +1 408 246 8253
[email-masked]      675 Spruce Drive       (f) +1 408 249 6205
www.brandenburg.com        Sunnyvale, CA 94086  USA

Approved-By:  Sean Turner <[email-masked]>
Date:         Fri, 10 Apr 1998 10:28:40 -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: Sean Turner <[email-masked]>
Organization: IECA, Inc.
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Tim,

I don't know if this is out of scope, but I don't think you should mandate AuthorityKeyIdentifier in self-signed certs.  The value of such a 'pointer' is dubious, unless this is how you check to see if the cert is self-signed.

Thoughts?

Tim Polk wrote:
>
> Along the lines of my last message:
>
> There was general discussion in the LA meeting about key identifiers.  If
> key identifiers are available, they greatly simplify path building and
> validation.  Unfortunately, there is no agreed method for generating the
> key identifiers.  Some vendors insert them, others try to "guess" them.
> Draft 07 of the profile recommends a method for generating key identifiers
> and recommends support for key identifiers, but there are no requirements.
>
> It was suggested that key identifiers be mandated for use in all
> certificates.  To facilitate chain building, I proposed we require
> authority key identifers in all certificates, and subject key identifiers
> in all CA certificates.  (Subject key identifiers in end-entity
> certificates do not affect chain-building.)
>
> There is no need to mandate a particular method for generating key
> identifiers if we include key identifiers in the certificate.  Assume a
> "CA-X" signs certificates with a private key "X-private" which has a
> corresponding public key "X-public".  The requirements are that the subject
> key identifier in CA certificates naming "CA-X" as the subject and
> containing "X-public" be the same as the authority key identifier ("AKI-X")
> in certificates issued by CA-X signed by the private key "X-private".
>
> Mandating a method is only needed if key identifiers are *implied*. I think
> it's too late for that - too many implementations have chosen different
> mechanisms all ready.
>
> Anyway, the general sense of the group (I don't think we took a straw poll)
> was that requiring key identifiers was a good idea.  This position still
> requires validation by the list.
>
> Note key identifiers would still be non-critical.  Certificate users would
> not be *required* to recognize them, much less use them.  Conforming CAs
> would simply be required to populate the extension.
>
> Tim Polk

--
Sean Turner - IECA, Inc.

Approved-By:  [email-masked]
Date:         Thu, 9 Apr 1998 20:22:53 -0700
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] Key Identifiers
Comments: To: [email-masked]
To: [email-masked]

>The issuer and serial number point to a single certificate.  The keyIdentifier
>field may be used to identify a set of certificates, all of which contain the
>same public key.
>
>In a network PKI, a CA may be the subject of n certificates from up to n
>issuers.  Many will contain the same public key. (Again, there may be more
>than one live key pair for rollover purposes.) In pathbuilding, any of those n
>certificates may be the one you need to construct a path.  The keyIdentifier
>allows you to quickly eliminate certificates for the "wrong" public key.

This is where I've never quite understood the purpose of the keyIdentifier:
Since it's tied to a CA's public key, for which there may be multiple
certificates, all it'll do is identify a (possibly unlimited) collection of
certs which may have issued the one I want to verify.  The authorityCert fields
bind unambiguously to an issuing cert, but the keyIdentifier only binds to an
arbitrary collection of certs which share the same key (while I'm on the topic,
it might be a good idea to explicitly point out that the authorityCertIssuer is
the issuerName of the issuing cert and not the issuerName of the subject cert -
this is obvious to people used to S/MIME's way of identifying certs, but may
confuse others).

The whole structure of that extension has always struck me as somewhat
peculiar.  What the text which goes with it (for PKIX, but not X.509) says is
that it should be treated like:

AuthorityKeyIdentifier ::= CHOICE {
    keyIdentifier   OCTET STRING,
    authorityCert   IssuerAndSerialNumber     -- From PKCS #7
    }

This is logically equivalent to 4.2.1.1/X.509 12.2.2.1, but without the need
for constraints and an accompanying explanatory text.

Given the parallel thread about bloat in certs and S/MIME, what would be useful
is the addition of a third possibility:

   authorityIdentifier [ 0 ] OCTET STRING

the OCTET STRING being the hash of the S/MIME-style IssuerAndSerialNumber.
This uniquely identifiers the issuer cert, and doesn't cause the unnecessary
bloat which use of the AuthorityCert will.

An alternative is a new extension authorityCertIdentifier:

AuthorityCertIdentifier ::= CHOICE {
    authorityIdentifier OCTET STRING,
    authorityCert       IssuerAndSerialNumber     -- From PKCS #7
    }

with recommended usage being the authorityIdentifier.  This uniquely identifies
an issuing cert (which seems to be what the intent of authorityKeyIdentifier
is), and doesn't cause unnecessary bloat.

Peter.

Approved-By:  Warwick Ford <[email-masked]>
Date:         Thu, 9 Apr 1998 22:46:01 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      [IETF-PKIX] RFC 2028 and Nortel Patent 5699431
Comments: To: [email-masked]
To: [email-masked]

I totally support the spirit behind the key clause in RFC 2028 regarding
intellectual property and the IETF.  However, this clause may warrant some
reconsideration ... taking into account the circumstances surrounding
Nortel Patent 5699431 (PKIX and CRL distribution points).

   To ensure a fair and open process, participants in the IETF and its
   Working Groups must be able to disclose, and must disclose to the
   Working Group chairs any relevant current or pending intellectual
   property rights that are reasonably and personally known to the
   participant if they participate in discussions about a specific
   technology.

This clause does not completely protect against the problems that occurred
with 5699431.  The Nortel individuals (including myself) who developed the
original CRL Distribution Point idea had no intention, at that time, to
file a patent claim for the idea.  We submitted the idea to various
standards groups, as a bona fide standards contribution, and promoted its
adoption.  We were not violating RFC 2028 nor any other standards committee
policies at that time.  It was almost 12 months later that someone
concluded that Nortel could and should file a patent for that invention
provided the filing occurred before the 12-month anniversary of the
original publication of the idea.  (This seemed to me a reasonable
IP-defensive action at the time -- I never imagined that Nortel or its
heirs would later try to tax the industry on the basis of this patent.)

After the patent was filed, I don't believe I ever participated
significantly in discussions about CDPs in the IETF (I moved to VeriSign
shortly after that time, so had given up all stake in the patent anyway).
I think certain Entrust PKIX participants, however, still have something to
answer re RFC 2028 adherence (the campaign waged by certain individuals
against OCSP in favor of CRLs/CDPs in December 1997 springs to mind).

That aside, even if everyone had followed RFC 2028 to the letter, the basic
problem of 5699431 would remain.
The way around this problem is not obvious.  We might consider, for
example, requiring that when someone files a patent or learns of a patent
filing that they be required to disclose such facts.  However, this is just
not practical.  Most corporate employees and contractors are bound by
contracts that prohibit them from disclosing intellectual property
information, including information about filed but ungranted patents,
without authorization.  In large corporations, such authorization can never
be guaranteed to be under the control of the IETF participant.  The
situation is worse in the case of a past employer -- when one leaves a
corporation one is typically contractually bound to maintain silence on
intellectual property matters and is also no longer in a position to
influence the corporation to release the information.  (As many of you
know, this is precisely the invidious situation I was in throughout most of
1996 and 1997, when I knew of the existence of the filing of 5699431 but
could not bring it to the attention of the IETF.)

The other possibility is to oblige participants not to sign invention
disclosures for technology that they have previously discussed in the IETF.
 This might work.

I also understand the US Federal Government is working on revising the code
to align with patent policies elsewhere, so maybe the problem will go away.

This problem is more difficult for the IETF than other standards groups
because of the absence of relationships between corporations (who generally
own the IP) and the IETF.

Perhaps others have valuable insight...

Warwick

(Disclaimer: These comments are my own and do not necessarily reflect
positions of VeriSign, Inc.)

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

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:46:01 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

I agree with this.

Dave S.

John Pawling wrote:

> Tim,
>
> I agree with your recommendations and have a few comments:
>
> 1) PKIX I should require each AuthorityKeyIdentifier to be popoulated with
> the keyIdentifier field rather than the pair (authorityCertIssuer,
> authorityCertSerialNumber).
>
> 2) I agree that PKIX I need not mandate that end-entity certs MUST include
> subjectKeyIdentifiers, but I believe that the spec should state that each
> end-entity cert SHOULD include a subjectKeyIdentifier.  This is useful for
> CAs to identify the key material that is included in a cert to assist with
> cert mgmt.  It also useful is some application environments.  For example,
> the US DoD ACP120 spec uses the subjectKeyIdentifier in the recipient's key
> management v3 X.509 certificate to match the recipient's copy of the
> encrypted session key with the recipient's key material.
>
> ================================
> John Pawling, [email-masked]
> J.G. Van Dyke & Associates, Inc.
> www.jgvandyke.com
> ================================
>
> At 12:39 PM 4/9/98 -0400, Tim Polk wrote:
> >Along the lines of my last message:
> >
> >There was general discussion in the LA meeting about key identifiers.  If
> >key identifiers are available, they greatly simplify path building and
> >validation.  Unfortunately, there is no agreed method for generating the
> >key identifiers.  Some vendors insert them, others try to "guess" them.
> >Draft 07 of the profile recommends a method for generating key identifiers
> >and recommends support for key identifiers, but there are no requirements.
> >
> >It was suggested that key identifiers be mandated for use in all
> >certificates.  To facilitate chain building, I proposed we require
> >authority key identifers in all certificates, and subject key identifiers
> >in all CA certificates.  (Subject key identifiers in end-entity
> >certificates do not affect chain-building.)
> >
> >There is no need to mandate a particular method for generating key
> >identifiers if we include key identifiers in the certificate.  Assume a
> >"CA-X" signs certificates with a private key "X-private" which has a
> >corresponding public key "X-public".  The requirements are that the subject
> >key identifier in CA certificates naming "CA-X" as the subject and
> >containing "X-public" be the same as the authority key identifier ("AKI-X")
> >in certificates issued by CA-X signed by the private key "X-private".
> >
> >Mandating a method is only needed if key identifiers are *implied*. I think
> >it's too late for that - too many implementations have chosen different
> >mechanisms all ready.
> >
> >Anyway, the general sense of the group (I don't think we took a straw poll)
> >was that requiring key identifiers was a good idea.  This position still
> >requires validation by the list.
> >
> >Note key identifiers would still be non-critical.  Certificate users would
> >not be *required* to recognize them, much less use them.  Conforming CAs
> >would simply be required to populate the extension.
> >
> >Tim Polk
> >

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:34:18 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Subject:      [IETF-PKIX] Key Usage Role in Cert Path Validation
To: [email-masked]

I would like to add another path processing action to the current list
(a-l) of Section 6, Certificate Path Validation:

"(m) If a key usage extension is marked critical, ensure the keyCertSign
bit is set."

The last sentence on p. 50 should then be modified to:

"Note that actions (h) through (m) are not applied to the end entity
certificate (certificate n)."

Dave S.

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:26:45 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

Paul,

I disagree.  If a certificate contains a critical "proprietary" extension of
any sort, whether it be CRL distribution points or some other private
extension, and PKIX-1 compliance is claimed, then the certificate may be
rejected.  If a certificate contains a non-critical "proprietary" extension of
any sort, then the extension may be ignored.  This is written in black and
white.  There is no reason to make an exception in this case.

With these actions you are harming more than just Nortel, you are affecting any
number of communities worldwide that were PKIX-1 compliant until now.  Again,
PKIX-1 stands independent of X.509.  Ignore the extension if you like, but
please leave well enough alone.

Dave S.

Paul Hoffman / IMC wrote:

> At 01:43 PM 4/9/98 -0700, Anil R. Gangolli wrote:
> >It is unreasonable for the profile to forbid (classify "non-conformant")
> >applications that are able to process such extensions under the
> >the profile's interpretation of critical/non-critical
> >(which still needs clarification -- but that's another thread).
>
> The problem with this approach is that two conformant implementations could
> come up with different results when processing the same cert path. I can
> already hear the end users saying "but my cert validates fine on this piece
> of software; yours must be broken". Trying to explain to them that the
> reason it didn't validate on one client is because someone didn't pay blood
> money for a submarine patent to Entrust won't do much good. I think that
> clear statements of what interoperable implementations do is the most
> important thing here.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:15:42 -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: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
Comments: To: [email-masked]
To: [email-masked]

I agree.

Dave S.

Anil R. Gangolli wrote:

> As much as I agree with the intent, this approach seems too severe
> and probably sets a bad precedent.
>
> It is reasonable to mandate that CAs conforming to the profile not include
> such proprietary extensions, and consequently that certificates including
> the extension do not conform to the profile.
>
> It is unreasonable for the profile to forbid (classify "non-conformant")
> applications that are able to process such extensions under the
> the profile's interpretation of critical/non-critical
> (which still needs clarification -- but that's another thread).
>
> --a.
>
> Paul Hoffman / IMC wrote:
> >
> > >Many, many months ago, we decided that PKIX Part 1 should say something about
> > >every extension in X.509.  Keeping with this philosophy, I propose the
> > >following words for the extensions that are being "removed:"
> > >CAs conforming to this profile must not issue certificates [or CRLs] that
> > >contain this extension.  If this extension is present and marked non-critical
> > >in a certificate [or CRL], conforming applications must ignore this
> > >non-critical extension.  If this extension is present and marked critical
> > in a
> > >certificate [or CRL], conforming applications must reject the certificate [or
> > >CRL] containing this critical extension.
> >
> > That sounds good to me. It covers the area completely without leaving "holes"
> > in the spec for implementors to guess about.
> >
> > I would feel differently if Entrust had different licensing for their patent.
> > If the patent were licensed along the lines of Netscape's SSL patent (no fees
> > or contract required, just an agreement to not hold any SSL-related patents
> > against Netscape), I would say we shouldn't rip out all the features. However,
> > since Entrust wants money from every commercial entity that uses these
> > features, this group have no choice but to excise the features. I think Russ'
> > wording is the best way to do this.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
>
> --
> Anil R. Gangolli
> Structured Arts Computing Corp.
> http://www.StructuredArts.com
> mailto:[email-masked]

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:15: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: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

The feature may be excised by deleting it from the profile.  I've had people tell
me in the past that we're not writing X.509 here.  If X.509 provides a feature
that you don't like, then ignore it.  There are enough differences between PKIX-1
and X.509 to make them independent standards.  There is no reason to forbid this
technology.

Dave S.

Paul Hoffman / IMC wrote:

> >Many, many months ago, we decided that PKIX Part 1 should say something about
> >every extension in X.509.  Keeping with this philosophy, I propose the
> >following words for the extensions that are being "removed:"
> >CAs conforming to this profile must not issue certificates [or CRLs] that
> >contain this extension.  If this extension is present and marked non-critical
> >in a certificate [or CRL], conforming applications must ignore this
> >non-critical extension.  If this extension is present and marked critical
> in a
> >certificate [or CRL], conforming applications must reject the certificate [or
> >CRL] containing this critical extension.
>
> That sounds good to me. It covers the area completely without leaving "holes"
> in the spec for implementors to guess about.
>
> I would feel differently if Entrust had different licensing for their patent.
> If the patent were licensed along the lines of Netscape's SSL patent (no fees
> or contract required, just an agreement to not hold any SSL-related patents
> against Netscape), I would say we shouldn't rip out all the features. However,
> since Entrust wants money from every commercial entity that uses these
> features, this group have no choice but to excise the features. I think Russ'
> wording is the best way to do this.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

Approved-By:  Simonetti David <[email-masked]>
Date:         Thu, 9 Apr 1998 19:05: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: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

I can live with deleting the text if we must, but I cannot agree to forbidding the
technology.  I greatly oppose such text.

Dave S.

Russ Housley wrote:

> At the PKIX meeting in LA, Tim Polk gave a presentation on the extensions that
> will be removed from PKIX Part 1 to remove any dependance on recently issued
> patents.  A straw poll confirmed overwhelming support for this approach,
> and we
> are making the changes to remove the extensions.
>
> Many, many months ago, we decided that PKIX Part 1 should say something about
> every extension in X.509.  Keeping with this philosophy, I propose the
> following words for the extensions that are being "removed:"
> CAs conforming to this profile must not issue certificates [or CRLs] that
> contain this extension.  If this extension is present and marked non-critical
> in a certificate [or CRL], conforming applications must ignore this
> non-critical extension.  If this extension is present and marked critical in a
> certificate [or CRL], conforming applications must reject the certificate [or
> CRL] containing this critical extension.
> Russ

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 9 Apr 1998 15:36:03 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

At 01:43 PM 4/9/98 -0700, Anil R. Gangolli wrote:
>It is unreasonable for the profile to forbid (classify "non-conformant")
>applications that are able to process such extensions under the
>the profile's interpretation of critical/non-critical
>(which still needs clarification -- but that's another thread).

The problem with this approach is that two conformant implementations could
come up with different results when processing the same cert path. I can
already hear the end users saying "but my cert validates fine on this piece
of software; yours must be broken". Trying to explain to them that the
reason it didn't validate on one client is because someone didn't pay blood
money for a submarine patent to Entrust won't do much good. I think that
clear statements of what interoperable implementations do is the most
important thing here.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  "Anil R. Gangolli" <[email-masked]>
Date:         Thu, 9 Apr 1998 13:43:41 -0700
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] Removing Extensions from PKIX Part 1
To: [email-masked]

As much as I agree with the intent, this approach seems too severe
and probably sets a bad precedent.

It is reasonable to mandate that CAs conforming to the profile not include
such proprietary extensions, and consequently that certificates including
the extension do not conform to the profile.

It is unreasonable for the profile to forbid (classify "non-conformant")
applications that are able to process such extensions under the
the profile's interpretation of critical/non-critical
(which still needs clarification -- but that's another thread).

--a.

Paul Hoffman / IMC wrote:
>
> >Many, many months ago, we decided that PKIX Part 1 should say something about
> >every extension in X.509.  Keeping with this philosophy, I propose the
> >following words for the extensions that are being "removed:"
> >CAs conforming to this profile must not issue certificates [or CRLs] that
> >contain this extension.  If this extension is present and marked non-critical
> >in a certificate [or CRL], conforming applications must ignore this
> >non-critical extension.  If this extension is present and marked critical
> in a
> >certificate [or CRL], conforming applications must reject the certificate [or
> >CRL] containing this critical extension.
>
> That sounds good to me. It covers the area completely without leaving "holes"
> in the spec for implementors to guess about.
>
> I would feel differently if Entrust had different licensing for their patent.
> If the patent were licensed along the lines of Netscape's SSL patent (no fees
> or contract required, just an agreement to not hold any SSL-related patents
> against Netscape), I would say we shouldn't rip out all the features. However,
> since Entrust wants money from every commercial entity that uses these
> features, this group have no choice but to excise the features. I think Russ'
> wording is the best way to do this.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium

--
Anil R. Gangolli
Structured Arts Computing Corp.
http://www.StructuredArts.com
mailto:[email-masked]

Approved-By:  Tim Polk <[email-masked]>
Date:         Thu, 9 Apr 1998 15:41:17 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Kevin,

The issuer and serial number point to a single certificate.  The
keyIdentifier field may be used to identify a set of certificates, all of
which contain the same public key.

If you envision a hierarchical PKI, the issuer and serial number are
sufficient, because the CA has only one certificate with that public key.
If the CA has mutiple key pairs, it will have one certificate issued by the
"parent CA" for each public key.

In a network PKI, a CA may be the subject of n certificates from up to n
issuers.  Many will contain the same public key. (Again, there may be more
than one live key pair for rollover purposes.) In pathbuilding, any of
those n certificates may be the one you need to construct a path.  The
keyIdentifier allows you to quickly eliminate certificates for the "wrong"
public key.

Tim Polk

At 12:00 PM 4/9/98 -0700, Kevin Kingdon wrote:
>Tim,
>
>How does the combination of authorityCertIssuer and
>authorityCertSerialNumber not "solve the problem?" Doesn't it uniquely
>identify the authority certificate? Isn't this enough for building a
>certificate chain? How is this any different from the S/MIME use of
>issuer-serialNumber to identify a certificate?
>
>Kevin Kingdon
>RSA Data Security, Inc.
>
>> -----Original Message-----
>> From: Tim Polk [SMTP:[email-masked]]
>> Sent: Thursday, April 09, 1998 11:19 AM
>> To:   [email-masked]
>> Subject:      Re: [IETF-PKIX] Key Identifiers
>>
>> [Kevin Kingdon]  snip...
>>  The authorityCertIssuer and authorityCertSerialNumber do not solve
>> the
>> problem; the keyIdentifier field in the AuthorityKeyIdentifier
>> extension
>> *does* solve it.  That is a *very* important point.
>> [Kevin Kingdon]  snip...
>
>

Approved-By:  Kevin Kingdon <[email-masked]>
Date:         Thu, 9 Apr 1998 12:00: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: Kevin Kingdon <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Tim,

How does the combination of authorityCertIssuer and
authorityCertSerialNumber not "solve the problem?" Doesn't it uniquely
identify the authority certificate? Isn't this enough for building a
certificate chain? How is this any different from the S/MIME use of
issuer-serialNumber to identify a certificate?

Kevin Kingdon
RSA Data Security, Inc.

> -----Original Message-----
> From: Tim Polk [SMTP:[email-masked]]
> Sent: Thursday, April 09, 1998 11:19 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Key Identifiers
>
> [Kevin Kingdon]  snip...
>  The authorityCertIssuer and authorityCertSerialNumber do not solve
> the
> problem; the keyIdentifier field in the AuthorityKeyIdentifier
> extension
> *does* solve it.  That is a *very* important point.
> [Kevin Kingdon]  snip...

Approved-By:  Tim Polk <[email-masked]>
Date:         Thu, 9 Apr 1998 14:19:03 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

John,

Thanks for the clarifying things!  I certainly agree with both points.

The authorityCertIssuer and authorityCertSerialNumber do not solve the
problem; the keyIdentifier field in the AuthorityKeyIdentifier extension
*does* solve it.  That is a *very* important point.

I also agree with the second point.  The document should recommend the use
of the subject key identifier, even for end-entities.

Tim

At 01:36 PM 4/9/98 -0400, John Pawling wrote:
>Tim,
>
>I agree with your recommendations and have a few comments:
>
>1) PKIX I should require each AuthorityKeyIdentifier to be popoulated with
>the keyIdentifier field rather than the pair (authorityCertIssuer,
>authorityCertSerialNumber).
>
>2) I agree that PKIX I need not mandate that end-entity certs MUST include
>subjectKeyIdentifiers, but I believe that the spec should state that each
>end-entity cert SHOULD include a subjectKeyIdentifier.  This is useful for
>CAs to identify the key material that is included in a cert to assist with
>cert mgmt.  It also useful is some application environments.  For example,
>the US DoD ACP120 spec uses the subjectKeyIdentifier in the recipient's key
>management v3 X.509 certificate to match the recipient's copy of the
>encrypted session key with the recipient's key material.
>
>================================
>John Pawling, [email-masked]
>J.G. Van Dyke & Associates, Inc.
>www.jgvandyke.com
>================================
>
>
>

Approved-By:  John Pawling <[email-masked]>
Date:         Thu, 9 Apr 1998 13:36:36 -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: John Pawling <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Identifiers
To: [email-masked]

Tim,

I agree with your recommendations and have a few comments:

1) PKIX I should require each AuthorityKeyIdentifier to be popoulated with
the keyIdentifier field rather than the pair (authorityCertIssuer,
authorityCertSerialNumber).

2) I agree that PKIX I need not mandate that end-entity certs MUST include
subjectKeyIdentifiers, but I believe that the spec should state that each
end-entity cert SHOULD include a subjectKeyIdentifier.  This is useful for
CAs to identify the key material that is included in a cert to assist with
cert mgmt.  It also useful is some application environments.  For example,
the US DoD ACP120 spec uses the subjectKeyIdentifier in the recipient's key
management v3 X.509 certificate to match the recipient's copy of the
encrypted session key with the recipient's key material.

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

At 12:39 PM 4/9/98 -0400, Tim Polk wrote:
>Along the lines of my last message:
>
>There was general discussion in the LA meeting about key identifiers.  If
>key identifiers are available, they greatly simplify path building and
>validation.  Unfortunately, there is no agreed method for generating the
>key identifiers.  Some vendors insert them, others try to "guess" them.
>Draft 07 of the profile recommends a method for generating key identifiers
>and recommends support for key identifiers, but there are no requirements.
>
>It was suggested that key identifiers be mandated for use in all
>certificates.  To facilitate chain building, I proposed we require
>authority key identifers in all certificates, and subject key identifiers
>in all CA certificates.  (Subject key identifiers in end-entity
>certificates do not affect chain-building.)
>
>There is no need to mandate a particular method for generating key
>identifiers if we include key identifiers in the certificate.  Assume a
>"CA-X" signs certificates with a private key "X-private" which has a
>corresponding public key "X-public".  The requirements are that the subject
>key identifier in CA certificates naming "CA-X" as the subject and
>containing "X-public" be the same as the authority key identifier ("AKI-X")
>in certificates issued by CA-X signed by the private key "X-private".
>
>Mandating a method is only needed if key identifiers are *implied*. I think
>it's too late for that - too many implementations have chosen different
>mechanisms all ready.
>
>Anyway, the general sense of the group (I don't think we took a straw poll)
>was that requiring key identifiers was a good idea.  This position still
>requires validation by the list.
>
>Note key identifiers would still be non-critical.  Certificate users would
>not be *required* to recognize them, much less use them.  Conforming CAs
>would simply be required to populate the extension.
>
>Tim Polk
>

Approved-By:  Tim Polk <[email-masked]>
Date:         Thu, 9 Apr 1998 12:39:41 -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: Tim Polk <[email-masked]>
Subject:      [IETF-PKIX] Key Identifiers
To: [email-masked]

Along the lines of my last message:

There was general discussion in the LA meeting about key identifiers.  If
key identifiers are available, they greatly simplify path building and
validation.  Unfortunately, there is no agreed method for generating the
key identifiers.  Some vendors insert them, others try to "guess" them.
Draft 07 of the profile recommends a method for generating key identifiers
and recommends support for key identifiers, but there are no requirements.

It was suggested that key identifiers be mandated for use in all
certificates.  To facilitate chain building, I proposed we require
authority key identifers in all certificates, and subject key identifiers
in all CA certificates.  (Subject key identifiers in end-entity
certificates do not affect chain-building.)

There is no need to mandate a particular method for generating key
identifiers if we include key identifiers in the certificate.  Assume a
"CA-X" signs certificates with a private key "X-private" which has a
corresponding public key "X-public".  The requirements are that the subject
key identifier in CA certificates naming "CA-X" as the subject and
containing "X-public" be the same as the authority key identifier ("AKI-X")
in certificates issued by CA-X signed by the private key "X-private".

Mandating a method is only needed if key identifiers are *implied*. I think
it's too late for that - too many implementations have chosen different
mechanisms all ready.

Anyway, the general sense of the group (I don't think we took a straw poll)
was that requiring key identifiers was a good idea.  This position still
requires validation by the list.

Note key identifiers would still be non-critical.  Certificate users would
not be *required* to recognize them, much less use them.  Conforming CAs
would simply be required to populate the extension.

Tim Polk

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 9 Apr 1998 09:34:39 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

>Many, many months ago, we decided that PKIX Part 1 should say something about
>every extension in X.509.  Keeping with this philosophy, I propose the
>following words for the extensions that are being "removed:"
>CAs conforming to this profile must not issue certificates [or CRLs] that
>contain this extension.  If this extension is present and marked non-critical
>in a certificate [or CRL], conforming applications must ignore this
>non-critical extension.  If this extension is present and marked critical
in a
>certificate [or CRL], conforming applications must reject the certificate [or
>CRL] containing this critical extension.

That sounds good to me. It covers the area completely without leaving "holes"
in the spec for implementors to guess about.

I would feel differently if Entrust had different licensing for their patent.
If the patent were licensed along the lines of Netscape's SSL patent (no fees
or contract required, just an agreement to not hold any SSL-related patents
against Netscape), I would say we shouldn't rip out all the features. However,
since Entrust wants money from every commercial entity that uses these
features, this group have no choice but to excise the features. I think Russ'
wording is the best way to do this.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Tim Polk <[email-masked]>
Date:         Thu, 9 Apr 1998 12:11:08 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

For those who weren't in the LA meeting, this proposal was requested by the
S/MIME working group.  An empty issuer name wreaks general havoc with their
protocols.  We expect S/MIME to be a major "customer" for PKIX, so that is
an important consideration.

In addition, implementors have identified name chaining as a specific
difficulty in PKIX implementations.  Prohibiting empty issuer names greatly
simplifies path building and validation.

When the issue was discussed in the meeting, no requirement for empty
issuer names was identified.  The original author of that section agreed
that empty subject names in end-entity certificates was sufficient for his
purposes.

Response at the meeting indicated general support (I don't recall any
objectsions) for requiring issuer names in all certificates.  Of course,
this decision requires validation by the list.

Assuming general consensus, John has done an excellent job of identifying
the changes that are required in the document.  I will make sure they are
all implemented.

Tim Polk

At 07:23 PM 4/8/98 -0400, John Pawling wrote:
>All,
>
>Based on the disussion at the recent PKIX meetings, propose that the
>following text should be added to the PKIX X.509 Certificate and CRL
>Profile, Issuer Name section (4.1.2.4) and Subject Name section (4.1.2.6):
>"All subject and issuer names MUST be populated (i.e. not an empty SEQUENCE)
>in PKIX-compliant X.509 certificates, except that the subject name in a
>user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in which case
>the subjectAltName extension will include the subject's identifier and MUST
>be marked as critical."
>
>This following text should be deleted from the Issuer Name section
>(4.1.2.4): "The issuer identity may be carried in the issuer name field
>and/or the issuerAltName extension.  If identity information is present only
>in the issuerAltName extension, then the issuer name may be an empty
>sequence and the issuerAltName extension must be critical."
>
>In the Issuer Name section (4.1.2.4), the phrase "Where it is non-null"
>should be deleted from "Where it is non-null, the issuer name field shall
>contain an X.500 distinguished name (DN)."
>
>In the Certificate Extensions section (4.2), the following text should be
>deleted: "If the CA issues certificates with an empty sequence for the
>issuer field, the CA must support the issuerAltName extension."
>
>In the Issuer Alternative Name section (4.2.1.8), the following text should
>be deleted: "If the only issuer identity included in the certificate is an
>alternative name form (e.g., an electronic mail address), then the issuer
>distinguished name shall be empty (an empty sequence), and the issuerAltName
>extension shall be present. If the subject field contains an empty sequence,
>the issuerAltName extension shall be marked critical."
>
>The CRL Issuer Name section (5.1.2.3) should be changed to read as follows:
>"The issuer name identifies the entity who has signed (and issued the CRL).
>The issuer name field shall contain an X.500 distinguished name (DN).  The
>issuer name field is defined as the X.501 type Name, and shall follow the
>encoding rules for the issuer name field in the certificate (see 4.1.2.4)."
>
>In section 5.1.2.6  Revoked Certificates, the phrase "or issuer altrnative
>name" should be delted from: "Certificates are uniquely identified by the
>combination of the issuer name or issuer alternative name along with the
>user certificate serial number."
>
>In section 5.2.2 Issuer Alternative Name, the following text should be
>deleted: "Further, if the only issuer identity included in the CRL is an
>alternative name form (e.g., an electronic mail address), then the issuer
>distinguished name should be empty (an empty sequence), the issuerAltName
>extension should be used, and the issuerAltName extension must be marked
>critical."
>
>In section 6, Certificate Path Validation, the following text should be
>deleted: "(If the certificate has an empty sequence in the name field, name
>chaining will use the critical subjectAltNames and issuerAltNames fields.)"
>
>================================
>John Pawling, [email-masked]
>J.G. Van Dyke & Associates, Inc.
>www.jgvandyke.com
>================================
>
>

Approved-By: [email-masked]
Date:         Wed, 9 Sep 1998 11:37:13 +0200
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mark Shuttleworth <[email-masked]>
Organization: Thawte Consulting
Subject:      [IETF-PKIX] Enforcing constraints
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms432C625C457E29CF13C6C705
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi folk

I think nameConstraints and basicConstraints, if implemented,
should be completely enforced.  People tend to ignore warnings
if there is an OK button there... especially if the warning
message is "The digital encryption certificate that has been
presented fails IETF PKIX X.509 constraints, path validation
or EKU processing rules. Abort, retry or ignore?"

--
Mark Shuttleworth
Thawte
--------------ms432C625C457E29CF13C6C705
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

--------------ms432C625C457E29CF13C6C705--

Approved-By: [email-masked]
Date:         Wed, 8 Apr 1998 17:25:00 -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: Tim Dierks <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

At 10:23 AM -0600 4/8/98, Bob Jueneman wrote:
>Tim, do I gather from the fact that the OID is just now being established
>for RSA with SHA-1 digital signatures, that few if any implementations are
>presently prepared to accept such an algorithm?

Also, the common SSL implementations (Consensus, Microsoft, Netscape,
others) support the RSA SHA-1 OID and encoding mechanism.

 - Tim

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Michael Myers <[email-masked]>
Date:         Thu, 9 Apr 1998 08:16:10 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

Sounds good to me.

At 09:31 AM 4/9/98 -0400, Russ Housley wrote:
>At the PKIX meeting in LA, Tim Polk gave a presentation on the extensions
that
>will be removed from PKIX Part 1 to remove any dependance on recently issued
>patents.  A straw poll confirmed overwhelming support for this approach,
>and we
>are making the changes to remove the extensions.
>
>Many, many months ago, we decided that PKIX Part 1 should say something about
>every extension in X.509.  Keeping with this philosophy, I propose the
>following words for the extensions that are being "removed:"
>CAs conforming to this profile must not issue certificates [or CRLs] that
>contain this extension.  If this extension is present and marked non-critical
>in a certificate [or CRL], conforming applications must ignore this
>non-critical extension.  If this extension is present and marked critical
in a
>certificate [or CRL], conforming applications must reject the certificate [or
>CRL] containing this critical extension.
>Russ
>
>

Approved-By:  Russ Housley <[email-masked]>
Date:         Thu, 9 Apr 1998 09:31:20 -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: Russ Housley <[email-masked]>
Subject:      [IETF-PKIX] Removing Extensions from PKIX Part 1
To: [email-masked]

At the PKIX meeting in LA, Tim Polk gave a presentation on the extensions that
will be removed from PKIX Part 1 to remove any dependance on recently issued
patents.  A straw poll confirmed overwhelming support for this approach,
and we
are making the changes to remove the extensions.

Many, many months ago, we decided that PKIX Part 1 should say something about
every extension in X.509.  Keeping with this philosophy, I propose the
following words for the extensions that are being "removed:"
CAs conforming to this profile must not issue certificates [or CRLs] that
contain this extension.  If this extension is present and marked non-critical
in a certificate [or CRL], conforming applications must ignore this
non-critical extension.  If this extension is present and marked critical in a
certificate [or CRL], conforming applications must reject the certificate [or
CRL] containing this critical extension.
Russ

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Thu, 9 Apr 1998 08:38:22 -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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] LDAP v2 schema - object classes for users and CAs
To: [email-masked]

Hi Sean,

The last paragraph of clause 3 includes the reasons for defining these
object classes. There are 2 basic reasons.

Firstly the mandatory attributes contained in the X.509 CA object class are
not mandatory for PKIX. PKIX CAs may choose to make CRLs available through
http or ftp for instance and not from a directory. However those same CAs
may choose to populate either the cACertificate or crossCertificatePair
attribute or both or neither. The only way to accommodate this is to make
all the attributes optional. When you suggest empty attributes do you mean
for instance that the CRL attribute type would have a single value which is
a signed construct corresponding to the right syntax or do you mean that
only an attribute type would be present and no value? The latter I don't
believe is possible (Tim/Pat can you comment?). The former (and probably
also the latter) creates a security problem in that a relying party
retrieving such an object could assume that no certificates had been
revoked.

The second reason for the new object classes is that the addition / deletion
of auxiliary object class values to the object class attribute is a facility
not widely supported by LDAPv2 servers. This support would be required if we
tried to use the X.509 object classes again because of the mandatory
attributes. You can't "preload" the object class values without also loading
the attributes. Also you can't delete the attributes from an entry without
removing the auxiliary object class values (user certificate is a mandatory
attribute). This would mean that every time you added/deleted the
certificate attribute from a user's entry or one of the mandatory attributes
from a CAs entry, you need to modify the object class attribute.

Hope this helps explain the rationale. (Incidentally I anticipate that
similar modifications will be proposed to X.509 as well).

Sharon

> ----------
> From:         Sean Turner[SMTP:[email-masked]]
> Sent:         April 9, 1998 7:19 AM
> To:   [email-masked]
> Subject:      [IETF-PKIX] LDAP v2 schema - object classes for users and
> CAs
>
> Sharon (and co-editors),
>
> I took a look at the first draft and have a couple of comments/questions:
>
> Why weren't the object classes strongAuthenticationUser and
> certificationAuthority (from X.521) used for storing user and CA certs in
> the directory?
>
> In the case of the pkiUser, the object class is the same as
> strongAuthenticationUser, except for the name and oid.  So, couldn't we
> just reuse the object class from X.521?
>
> In the case of pkiCA, it seems strange to me that you'd move the
> cACertificate, certificateRevocationList, and authorityRevocationList to
> 'MAY CONTAIN'.  I think you'd want these attributes to always be present
> in a CA's directory entry.  If there's no information for the CRL, ARL, or
> cross certificate pair they can be constructed to be 'empty'.  Even if
> there are reasons for making them optional attributes, I still can't see
> the reason for a new object class - why not just the one out of X.521?
>
> Thanks,
>
> --
> Sean Turner - IECA, Inc.
>

Approved-By:  Sean Turner <[email-masked]>
Date:         Thu, 9 Apr 1998 07:19:01 -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: Sean Turner <[email-masked]>
Organization: IECA, Inc.
Subject:      [IETF-PKIX] LDAP v2 schema - object classes for users and CAs
To: [email-masked]

Sharon (and co-editors),

I took a look at the first draft and have a couple of comments/questions:

Why weren't the object classes strongAuthenticationUser and certificationAuthority (from X.521) used for storing user and CA certs in the directory?

In the case of the pkiUser, the object class is the same as strongAuthenticationUser, except for the name and oid.  So, couldn't we just reuse the object class from X.521?

In the case of pkiCA, it seems strange to me that you'd move the cACertificate, certificateRevocationList, and authorityRevocationList to 'MAY CONTAIN'.  I think you'd want these attributes to always be present in a CA's directory entry.  If there's no information for the CRL, ARL, or cross certificate pair they can be constructed to be 'empty'.  Even if there are reasons for making them optional attributes, I still can't see the reason for a new object class - why not just the one out of X.521?

Thanks,

--
Sean Turner - IECA, Inc.

Approved-By:  John Pawling <[email-masked]>
Date:         Wed, 8 Apr 1998 19:23: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: John Pawling <[email-masked]>
Subject:      [IETF-PKIX] Subject/Issuer Name Population
To: [email-masked]

All,

Based on the disussion at the recent PKIX meetings, propose that the
following text should be added to the PKIX X.509 Certificate and CRL
Profile, Issuer Name section (4.1.2.4) and Subject Name section (4.1.2.6):
"All subject and issuer names MUST be populated (i.e. not an empty SEQUENCE)
in PKIX-compliant X.509 certificates, except that the subject name in a
user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in which case
the subjectAltName extension will include the subject's identifier and MUST
be marked as critical."

This following text should be deleted from the Issuer Name section
(4.1.2.4): "The issuer identity may be carried in the issuer name field
and/or the issuerAltName extension.  If identity information is present only
in the issuerAltName extension, then the issuer name may be an empty
sequence and the issuerAltName extension must be critical."

In the Issuer Name section (4.1.2.4), the phrase "Where it is non-null"
should be deleted from "Where it is non-null, the issuer name field shall
contain an X.500 distinguished name (DN)."

In the Certificate Extensions section (4.2), the following text should be
deleted: "If the CA issues certificates with an empty sequence for the
issuer field, the CA must support the issuerAltName extension."

In the Issuer Alternative Name section (4.2.1.8), the following text should
be deleted: "If the only issuer identity included in the certificate is an
alternative name form (e.g., an electronic mail address), then the issuer
distinguished name shall be empty (an empty sequence), and the issuerAltName
extension shall be present. If the subject field contains an empty sequence,
the issuerAltName extension shall be marked critical."

The CRL Issuer Name section (5.1.2.3) should be changed to read as follows:
"The issuer name identifies the entity who has signed (and issued the CRL).
The issuer name field shall contain an X.500 distinguished name (DN).  The
issuer name field is defined as the X.501 type Name, and shall follow the
encoding rules for the issuer name field in the certificate (see 4.1.2.4)."

In section 5.1.2.6  Revoked Certificates, the phrase "or issuer altrnative
name" should be delted from: "Certificates are uniquely identified by the
combination of the issuer name or issuer alternative name along with the
user certificate serial number."

In section 5.2.2 Issuer Alternative Name, the following text should be
deleted: "Further, if the only issuer identity included in the CRL is an
alternative name form (e.g., an electronic mail address), then the issuer
distinguished name should be empty (an empty sequence), the issuerAltName
extension should be used, and the issuerAltName extension must be marked
critical."

In section 6, Certificate Path Validation, the following text should be
deleted: "(If the certificate has an empty sequence in the name field, name
chaining will use the critical subjectAltNames and issuerAltNames fields.)"

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

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 8 Apr 1998 14:33:38 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
Comments: cc: Robert Jueneman <[email-masked]>
To: [email-masked]

Bob,

At 08:06 AM 4/8/98 -0600, you wrote:

[tony snip here]

>More to the point, if an implementation "enforces" such a constraint, what
do they
>do if the formal validation fails?  I would generally expect that a
reasonable
>implementation would simply buck the decision up to the human user "The
>xxx constraint is violated by certificate yyy. Do you want to accept the
>certificate anyway?"  What is the norm for most implementations?
>
>Bob

Like an "harmonic convergence", your paragraph above mirrors my question in
the "Criticality of extensions" thread.  By extension (no pun intended) what
if, for certain "common" extensions, the window pops-up with the additional
check-box labeled "Don't warn me again"?  (I.e., henceforth always accept
the cert if this particular constraint fails.)  I suppose this is perfectly
legal, but is contrary to what many "expect" by "enforces constraints."

____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 Hoffman / IMC <[email-masked]>
Date:         Wed, 8 Apr 1998 11:46: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

At 11:36 AM 4/8/98 -0400, David P. Kemp wrote:
>> >Validity Period Nesting
> . . .
>As before, this should not be a MUST, a SHOULD, or even a MAY in any
>PKIX or S/MIME document.  If someone is checking validity period
>nesting, they may possibly reject valid certification paths.   There is
>no security benefit to checking nesting; the only checking required is
>to ensure that each certificate is currently valid.

After reading David's earlier response to the nesting issue, I now agree
with him. It's just not important, since the EE is validating each step of
the path. To me, this is now a non-issue.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Wed, 8 Apr 1998 11:11:35 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Criticality of extensions
Comments: cc: "David P. Kemp" <[email-masked]>
To: [email-masked]

At 11:15 AM 4/8/98 -0400, you wrote:
>> From: Tony Bartoletti <[email-masked]>
>>
>> Regarding the last exchanges from Graham Bland and Paul Koning, I am
>> prompted to build this (possible) table:
>>
>>   Behaviors on Extensions:
>>
>>                           |  Critical           |  Non-Critical
>>                           |  Extensions         |  Extensions
>>   --------------------------------------------------------------------
>>   Extension Not           |   REJECT ?          |   IGNORE
>>   Recognised/Understood   |                     |
>>   --------------------------------------------------------------------
>>   Extension               |   CP/CPS ?          |   "RP Policy" ?
>>   Recognized/Understood   |                     |
>>   --------------------------------------------------------------------
>
>
>I like this table.

Thanks.  I intended it as a straw-man, and find I can think more clearly
when I have a picture to look at.

>
>Comments:
>
>1) Is there a reason for the question mark after REJECT?  If we can't
>   count on the application failing a critical extension it does not
>   support, then there isn't much reason to have the critical bit at all.

I agree.  I suppose I wanted to see if anyone would offer an argument
to the contrary.

>2) At least three words could be used in the row headings:
>   Recognised, Understood, Supported.  I believe that
>   Recognised/Understood does not have the right connotation; the idea
>   being that an application must not only "recognize" (know the syntax
>   of) an extension, it must also take some specified action before being
>   allowed to claim compliance with a standard or profile.  "Supported"
>   better captures that flavor, but other suggestions are welcome.

Right.  "Recognized" and "Supported" are really the two qualities that
I believe are confused in many minds here, and this gets to the heart
of my central question.  To expand:

Originally (I believe), the critical flag intended to tell the application
that "it must be *able* to [process, deal with] the extension in the course
of determining the validity.  This wording leaves some room for the RP to
exercise its discretion, perhaps through the setting of some preferences.

As an analogy, if I read in a Word-5 document in my Word-7 application,
make a change, and then attempt to save it, the application should pop-up
a window to warn me that "some formatting may be lost" if I attempt to
save it as a Word-5 document.  I can do so, but the application "did its
job".

In contrast, (I feel) that many intend to use the critical flag in some
manner to "enforce policy".  The scenario being, in a court of law, the
CA says, "The critical flag was set, and yet the plaintiff clearly chose
to ignore it, and validate the cert anyway."  The plaintiff says, "But my
application popped up a window, and gave me a choice of how to continue."

Well, the app certainly "recognised" the extension, and arguably it even
"processed" the extension.  But it did not "force compliance with the
(semantic) intent of the extension.

The point being, "recognizing", "able to process" and "forces processing
compliant with the semantic intent of the extension" are terms that must
be specified or explained when stating what it means for an application
to be "PKIX compliant".  The term "process" alone is overloaded.

>3) I've already ranted about conditioning the behavior of supported
>   extensions on the critical bit.  But to reiterate, I believe the
>   lower row should have the identical entries in both columns.  At
>   most, the "RP Policy" should be a binary choice, either treat a
>   non-critical extension identically to the same extension marked
>   critical, or ignore it.  (If the lower right box is IGNORE only, you
>   have Peter Gutmann's scenario of "this extension does nothing except
>   bulk up the certificate".  I'd prefer the box to be CP/CPS only, but
>   recognize that the RP always has the option of using downrev
>   software which doesn't support the extension.)

This seems to agree with my former use of "supports" above, but argues
back to my use of "REJECT?".  If I want to ignore a extension that I
would otherwise understand, I fall back to a downrev but I don't REJECT.

>
>Proposal:
>
>   Behaviors on Extensions:
>
>                           |  Critical           |  Non-Critical
>                           |  Extensions         |  Extensions
>   --------------------------------------------------------------------
>   Extension Not           |   REJECT            |   IGNORE
>   Supported               |                     |
>   --------------------------------------------------------------------
>   Extension               |   CP/CPS ?          |   RP configurable:
>   Supported               |                     |   CP/CPS or IGNORE
>   --------------------------------------------------------------------

Maybe we need a bigger table;)

___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:  Sharon Boeyen <[email-masked]>
Date:         Wed, 8 Apr 1998 13:58:27 -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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] LDAP v2 schema
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

> The structure is thus correct. However, adding more explanations to say
> that you may find there "new by new", "old by new" and "new by old"
> self-signed certificates would not hurt. Wouldn't it ?
>
I have no problem with additional explanatory text but for 509 it would need
to be submitted as ballot comment to the DTC. Will you be initiating that?

> An additional minor(?) question coming from what I heard at the meeting.
> Should the CRL distribution points and the reference to the patent from
> Entrust be deleted ?
>
I wasn't at the meeting but it is my understanding that CRL distribution
points and reference to the patent will be deleted.

> Finally, an editorial comment: Change section 5 into 4.2 and renumber
> the following.
Yup!

Thanks,
Sharon

Approved-By:  Brian Korver <[email-masked]>
Date:         Wed, 8 Apr 1998 10:51: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: Brian Korver <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

Tim Polk writes:
>
> Bob,
>
> The OID has been around for several years.  Version 1.5 of PKCS #1, which
> is the current version, was published in November of 1993.  Unfortunately,
> the OID was defined after that publication date.  Although RFC 2313 is more
> recent, it did not include any new information.
>
> There are a number of implementations that use this OID.  The S/MIME
> community uses it; I first heard about it when a vendor using the OIW oid
> for RSA and SHA-1 couldn't pass the interoperability tests.  The rationale
> for switching was that vendors had to support that oid for S/MIME, so why
> not use the same one?  The OIW oid is kind of an orphan now, anyway, so we
> did.
>
> Tim Polk

FYI, SET uses this OID as well.

brian
[email-masked]

Approved-By:  Robert Jueneman <[email-masked]>
Date:         Wed, 8 Apr 1998 08:06: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: Robert Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
Comments: To: [email-masked]
To: [email-masked]

On the issue of nested validity dates, I don't agree.

At time T, all that I need to know is whether the certificate chain is valid at
that instant. It makes no sense at all to reject a certificate at time T because
at time T+2 some CA's certificate will have expired, i.e., at time T+1.

This isn't even a nonrepudiation issue, at least for transactions that took place
at time T.

Since the CA's certificate might well be renewed prior to the time that it expires,
enforcing nesting of validity period prior to the earliest expiration makes no
sense at all.

I could care less whether some particular vendor's product misunderstands
the problem -- that's their problem to solve, and if they don't the marketplace
will solve it for them.  I am certainly NOT prepared to concede a de facto
veto power to Microsoft, Netscape, or anyone else.

Having said all that, I would certainly expect that CAs would typically issue
certificates with nested dates, but that shouldn't be an imposed constraint.

On the other hand, I do agree that some kind of an implementationCreatedBy
attribute would be useful, if only for debugging and information purposes.
If the IETF could QUICKLY agree upon the syntax and OID for such an attribute,
I could probably still get it into our forthcoming CA product release. Alternatively,
I could define an OID, and let everyone else adopt it. But there is no point in
our implementing such a concept if no one else does.

I would NOT suggest that everyone start trying to track a moving target of
everyone's favorite lame-brain implementation, especially within a standards
group. But as Peter has pointed out, the various implementations are
currently all over the map in certain areas, and if some vendors choose to be
more flexible in trying to interoperate with other vendor's products, that is
a valid way of trying to create their market niche.  After all, it takes a while
to turn around an oil tanker, and even after new releases become available
it will take a while before all of the old software versions disappear.

>Just out of interest, has anyone here seriously deployed X.509v3 software
>which actually uses and enforces basicConstraints, keyUsage/extendedKeyUsage,
>and the various policy constraints (as required by PKIX, including attention
>to critical flags) which interoperates correctly with mass-market software
>like MSIE, Exchange, Netscape Navigator, etc etc?

More to the point, if an implementation "enforces" such a constraint, what do they
do if the formal validation fails?  I would generally expect that a reasonable
implementation would simply buck the decision up to the human user "The
xxx constraint is violated by certificate yyy. Do you want to accept the
certificate anyway?"  What is the norm for most implementations?

Bob

>>>The validity period of a certificate must lie within the validity period of
>>>the certificate which signed it.
>>I'm not entirely happy with this suggestion. One can issue a new CA
>>certificate for a CA key whose original cert has expired, while keeping the
>>value of the key (and key version number extension) the same.
>
>The main reason for this is that currently the situation with enforcing
>nesting is ambiguous (as pointed out in the style guide), so that implementors
>can choose to enforce it either way.  The reason I recommended nesting is that
>given that it's a toss-up between enforcing and not enforcing it, and
>Microsoft (AFAIK) enforces it, you may as well do it too.  This has the added
>benefit that your certs will appear valid to MS software.
>
>The reason for being fascist about it ("do it this way or else") was that
>without clear guidelines we'll get the same situation that we already have
>with cert extensions, where 50% of people do it one way, 50% do it the other
>way, and the remaining 50% do it a third way which comes as a complete
>surprise to everyone else.
>
>>>This leads to a second type of extension, implementationWhichCreatedThis,
>>>which may be even more useful than the one described above.  As it is, it's
>>>already possible to identify certain implementations just by the bugs in the
>>>certificates they produce, but being able to make a positive ID would be
>>>really useful because by knowing how they (mis)interpret certain fields, your
>>>implementation could follow the same interpretation.
>
>>This way madness lies.
>>
>>It leads to a situation where each vendor has their own subtly different
>>protocol, and each implementation needs to be able to talk all of these
>>protocols.
>
>And this differs from the current situation in which way?  (See
>http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt for more details -
>there's a more recent version which has another round of CA and implementation
>bugs at the end which I haven't uploaded yet, so it's even worse than the
>already depressing picture painted in the guide.  It only covers cert formats,
>but the fact that there are implementations which will happily process the
>incorrect, illogical, and inconsistent nonsense which is appearing in some
>certs indicates that we're already in a situation where implementations are
>having to bend over backwards to handle the broken certificates others are
>issuing.  All that this proposal does is formalise the identification of cert
>types).
>
>It's nice to see that someone agrees with me that the current situation is
>crazy though :-).
>
>Just out of interest, has anyone here seriously deployed X.509v3 software
>which actually uses and enforces basicConstraints, keyUsage/extendedKeyUsage,
>and the various policy constraints (as required by PKIX, including attention
>to critical flags) which interoperates correctly with mass-market software
>like MSIE, Exchange, Netscape Navigator, etc etc?
>
>Peter.

Approved-By:  Tim Polk <[email-masked]>
Date:         Wed, 8 Apr 1998 13:17:06 -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: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]

Bob,

The OID has been around for several years.  Version 1.5 of PKCS #1, which
is the current version, was published in November of 1993.  Unfortunately,
the OID was defined after that publication date.  Although RFC 2313 is more
recent, it did not include any new information.

There are a number of implementations that use this OID.  The S/MIME
community uses it; I first heard about it when a vendor using the OIW oid
for RSA and SHA-1 couldn't pass the interoperability tests.  The rationale
for switching was that vendors had to support that oid for S/MIME, so why
not use the same one?  The OIW oid is kind of an orphan now, anyway, so we
did.

Tim Polk

At 10:23 AM 4/8/98 -0600, Bob Jueneman wrote:
>Tim, do I gather from the fact that the OID is just now being established
for RSA with SHA-1 digital signatures, that few if any implementations are
presently prepared to accept such an algorithm?  What is the recommend
algorithm OID for use in certificates in that case?  Bob  (Sorry, for some
reason my Enter key seems to be stuck or not working for text input. ???)
>>
>>>>> Tim Polk <[email-masked]> 04/08 7:16 AM >>>
>>The PKIX draft included the brief description of signatures using RSA since
>>there was no RFC to point to.  We used the OIW oid since there wasn't an
>>oid for RSA with SHA-1 in the pkcs-1 arc.
>>
>>Since we started, PKCS #1 Version 1.5 has become RFC 2313.  The next
>>(final!) draft will simply point to RFC 2313 for details on implementing
>>RSA signatures.
>>
>>The next draft will also use RSA with SHA-1 from the pkcs-1 arc.
>>Unfortunately, the RSA with SHA-1 oid is not in RFC 2313 (or any other
>>published version of PKCS #1.)  The following text was RSA-approved, so it
>>should be correct:
>>
>>**** RSA with SHA-1 text ****
>>
>>The signature algorithm with SHA-1 and the RSA encryption algorithm
>>is implemented using the padding and encoding conventions described in
>>PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1
>>hash algorithm.  The ASN.1 object identifier used to identify this
>>signature algorithm is:
>>
>>     sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
>>         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>>         pkcs-1(1) 5  }
>
>
>

Approved-By:  Robert Moskowitz <[email-masked]>
Date:         Wed, 8 Apr 1998 12:45:45 -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: Robert Moskowitz <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

At 10:44 AM 4/8/98 -0400, Paul Koning wrote:
>
>When certificates are used to authorize something that lasts for a
>while, it seems to me one would also want to determine the end of the
>validity period for a certificate.  For example, if a certificate is
>used to set up an IPSec (ISAKMP) SA, it would seem logical to limit
>the lifetime of that SA to be the validity period of the certificate
>used.
>
BTW, this behaviour is the recommended behaviour for IPsec (per wg
concensus) and will get captured in some IPsec document, most likely
Rodney's IPsec cert profile.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 8 Apr 1998 12:43:36 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

> From: Paul Koning <[email-masked]>
>
> When certificates are used to authorize something that lasts for a
> while, it seems to me one would also want to determine the end of the
> validity period for a certificate.  For example, if a certificate is
> used to set up an IPSec (ISAKMP) SA, it would seem logical to limit
> the lifetime of that SA to be the validity period of the certificate
> used.

I'm not sure I agree with the example.  My assumption would be that
the SA is authenticated at the time of creation and lasts for whatever
period is appropriate to the application.  If the cert happened to
expire 1/2 hour after the SA was established, and I otherwise intended
for the SA to last 8 hours, I wouldn't want to truncate the SA.
If I really needed 1/2 hour freshness granularity, I'd just negotiate
a new SA (with a new certification path check) every 1/2 hour.
If you took the "continuously valid" approach, you would need to check
not only validity period of the certs, but also their revocation status
throughout the SA lifetime.

But assuming that the example is valid, the "current time" would
become a "current time interval", which would need to be contained
in the validity period of every cert in the path.  That still doesn't
involve any nesting checks on the certs.

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 8 Apr 1998 10:23:28 -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: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
Comments: To: [email-masked]
To: [email-masked]

Tim, do I gather from the fact that the OID is just now being established for RSA with SHA-1 digital signatures, that few if any implementations are presently prepared to accept such an algorithm?  What is the recommend algorithm OID for use in certificates in that case?  Bob  (Sorry, for some reason my Enter key seems to be stuck or not working for text input. ???)
>
>>>> Tim Polk <[email-masked]> 04/08 7:16 AM >>>
>The PKIX draft included the brief description of signatures using RSA since
>there was no RFC to point to.  We used the OIW oid since there wasn't an
>oid for RSA with SHA-1 in the pkcs-1 arc.
>
>Since we started, PKCS #1 Version 1.5 has become RFC 2313.  The next
>(final!) draft will simply point to RFC 2313 for details on implementing
>RSA signatures.
>
>The next draft will also use RSA with SHA-1 from the pkcs-1 arc.
>Unfortunately, the RSA with SHA-1 oid is not in RFC 2313 (or any other
>published version of PKCS #1.)  The following text was RSA-approved, so it
>should be correct:
>
>**** RSA with SHA-1 text ****
>
>The signature algorithm with SHA-1 and the RSA encryption algorithm
>is implemented using the padding and encoding conventions described in
>PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1
>hash algorithm.  The ASN.1 object identifier used to identify this
>signature algorithm is:
>
>     sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
>         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
>         pkcs-1(1) 5  }

Approved-By: [email-masked]
Date:         Tue, 7 Apr 1998 17:49: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: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Comments on CMP-07
To: [email-masked]

The following are my comments on the CMP draft.  Please note that some of
the comments may be changed based on the outcome of issues dealing with the
CRMF draft which I have already asked about.

Not all of these comments are of equal weight, some are merely nits while
others are issues I feel strongly about.  I have not given weighting in this
message so that my personal opinions do not necessaryly come out as
opinions.

1.  Section 1.2.2 paragraph 4:  This paragraph defines the term "root CA"  I
wish to be sure that the fact this is the directly trusted root does not
imply that this is the CA which is going to issue my certificate.  I cannot
remember any text stating this but I wish to verify it.

2.  Section 1.3, page 6:  The graph is nice, however the letters marking the
paths are not refered to in the text.  It is dificult in some cases to be
sure what the letters refer to.  This is especially true of c and d.  Please
make a table of what the letters mean or refer to them from the text itself.

3.  Section 1.3 page 7: Formatting note:  please be consistant about how you
format the notes in the text.  I have found atleast two different ways of
this being done.  I suggest that you put in the word "NOTES:" and then a
numbered indented list.  This allows me to have an easy transistion both
into and out of the notes when reading the text.  The first pass on page 7 I
got lost about what I was reading since I was on a computer screen rather
than on a printed page.

4.  Section 2.1, paragraph #1:  The paragraph makes reference to obtaining
the information about the PKI functions supported, but gives no supporting
material on how this would be done.  Is this out-of-band in the same way
that acquiring the root CA public key is?

5.  Section 2.3, pargraph #1: Reference is made to the fact that a given
CA/RA may choose how to implement the POP enforcement, and the profile at
the end says it must be done, however I cannot find anyplace which says how
a client would find out which of the different methods are or are not
supported by the CA/RA.

6.  Section 2.3.2, pargraph 2:  You use the term "immediate", can you be
more explicit what you mean by this?  Is it legitiment that a e-mail based
protocol would use the direct method considering that the messages may take
several days to complete the round trip?

7.  Section 2.4, paragraph #1: I always dislike this type of hair splitting
but:  If I have a CA which has issued a certificate to an RA by the
definition in section 1.2.1 this might not apply to that CA.  In a more
general note, how does one go about updating the keys in a CA which has only
issued certificates to other CAs?  I would have thought that the same
procedure applied.

8.  Section 2.4, paragraph #2:  This paragraph contains the phrase "if
certificates are made available using an X.500 directory".  What are we
suppose to do if the certificates are NOT made available with an X.500
directory?  Never update the root CA keys?  This needs to be fleshed out.

9.  Section 2.4, paragraph #3:  If the CA changes some of the extensions on
the CA:  1) is this a kosher change to make and 2) how should these changes
be reflected in the new certificates?  According to new policy?

10.  Section 2.4, paragraph #3:  The time period of the cross-certificate
certs may also need to be modified according to how one thinks that the
certificates are in use over the wider internet.  Specifically how long
external entities will take to get the new certificate and establish a trust
point on it.

11.  Section 2.4.1:  It is ok to change the encoding of the name at this
point?  I specficically ask about this after some of the discussions at the
IETF about the new use of UTF8 and the fact that the perfered encoding rules
for distinguished names may end up changing over time.  It seems to me that
this would be a good place to handle this issue by doing a roll over of the
root certificates with new names, but maybe the same keys.

12.  Section 2.4.1, paragraph #8:  I disagree that the old CA private key
can be thrown away with impunitity at this time.  Specifically if you use
such an extension as CRL Distribution points, an internet client with an old
certificate may come looking for a new CRL and get one it cannot understand
as it is signed with the new key only.  Either one needs to determine a way
to return the new set of chainging certificates with this CRL or the CRL
with the old private key needs to be generated until such as time as the old
certificate expires.

13.  Section 2.4.2.2, paragraph #1:  Under what circumstances should the
client make this decision that the certificate must be the wrong one.  I can
see that this could be a problem in the internet where going and finding the
new CA key may be expensive.  One can no longer state that the signature was
bad on the certificate, one just weasel about how the certificate might be
good, if only one knew how to find the correct signing certificate.  Such a
lookup would be required anytime a certificate, including an apparently self
signed certificate, failed to verify.  After all the self-signed certificate
may really be a newWithOld or oldWithNew as the subject and issuer DNs would
match in these cases.

14.  Section 3.1, paragraph 5:  I dislike the term PKIProtection.  This
implies more to me that it really means.  What it really is would be
PKIAuthentication as all you are doing is authenticating the data not
protecting (or masking) the data.  Protection implies encryption to me.

15.  Section 3.1.1: Why is sender a GeneralName rather than a GeneralNames?
It seems to me that often times I would need to put a more compete set of
names here.  Two circumstances would be: a) during initialization when I
might not know which of several different names you might know me by and b)
if I don't have a Subject DN in my certificate but rather have a Subject
AltName extension which contains several different possible names.

16.  Section 3.1.1, page 22:  In the pargaraph on using sigantures for the
PKIProtection field, I have two questions:
        A)  Can I use a signature field at this location during the
initialization operation?  I can see the ability to do this if I am signing
with an already existing trusted certificate from a different infrastructure
that maps.  On the other hand I can see you "forbidding" this as being
incompatable with the published criteria of startup.
        B)  In the event that I posses multiple different signature pairs
which are all currently active (some of which may be historical but with
currently active certificates) how does the receiving party know which of
the potentially different certificates I used?  Does this require some type
of exhaustive testing?  Or are you assuming that one would only try the
currently published certificate(s) in the directory service?

17.  Section 3.2.3:  I see benifit of taking the PKIStatus and
PKIFailureInfo from both the CMMF and CMP documents and making them common
to the CRMF document.  This is espcially true as they currently have the
same name and are likely to diverge in terms of what additional errors may
be appended to the ends of the lists.

18.  Section 3.2.5:
        Bullet 1:  States that the certificate must be self-signed.  This
appears to go againist the statment that a root CA may be part of a
heirarchy as the certificate would not be self-signed in that case.
        Bullet 3:  PKIX part #1 is changing its stance on the lack of a
subject field in CA certificates.  You should choose working which is
agreement with the modifications to part #1.

19.  Section 3.2.8, page 27, first paragraph:  As I could not follow the
reasoning and was unable to easily find the referenced document, please
include a brief statement in the text about why this decryption of the
integer is not part of the security attack referenced in the security
section in the appendix.  Please note that it was not clear to me from
reading the document that I was suppose to compute the owf of the integer
and verify that it matched the witness value in order to state that the
challenge was to be returned.

20.  Section 3.2.9, page 27:  In the event that the POP challenge fails, is
there some specific error which should be returned? or can I just return
random errors.  Under what circumstances should the CA/RA retry the
challenge (i.e. what if the error returned isBadMessageCheck) or should all
challenge failures lead to imediate failures to enroll?

21.  Section 3.3.4, page 30, last paragraph:  The last line in this
statement is true only if the CA has not published the certificate until
after the confirmation of the POP has been received.  If the PKIConfirm has
not been received and the certificate has been published then the
certificate must be revoked by the CA.

22.  Section 3.3.11:  You should add a statement to this section which
states that a CA should never modify the requested subject name of a cross
certificate request.  If the CA desired to modify the subject name of a
cross certificate request, the CA should just deny the request.  If this is
done then the cross certificate cannot be used for the purpose required
(i.e. name chaining back to a trusted certificate).   I would like to say
that this refers to the actual bytes of the encoding of the name, but
recognized that doing a binary match of subject and issuer DNs is not the
"correct" way to do name chaining, even if it is what most people do.

23.  Section 3.3.18:  It is unclear to me from the content in the ASN
comment if these are real messages or are really just comments on the types
of things one must do.  If they are just types of things why do they have
real OIDs assigned to them.  On the other hand if they are real things to be
implemented, why do they have the word example at the top and consist of a
set of comments rather than real messages?

24.  Section 4.1, paragraph #2:  There was an explicit statement in the
front of the draft which stated that the root CA did not have to be at the
root of a heirarchy, but now there is a statement which says that all Root
CAs must have self-signed certificate.  These statements appear to be
contraditory, is there a reason why this section says that the CA must have
a "self-signed" certificate and not just a certificate?

25.  Section B.7, page 53:  the comment on subject says it may be NULL-DN
only if a subjectAltName extension is also proposed.  This should be
harmonized with the changes to go into part1 of PKIX and state that it may
be a NULL-DN only if the certificate is for a non PKI-Managment end-entity
and a subjectAltName extension is proposed.

26.  Appendix D:  Please remove the section on Encoding Considerations.  If
you want to state that the data is binary and appropriate care must be
taken, that is fine.  However you should not restrict the CTE to being
base64, let my MIME application take care of this as it might perfer to use
a binary encoding.

When I get back from vacation I will try and do a detailed analysis of the
docuement to look for deeper problems, however this should be a start for
conversations.

jim schaad

Approved-By: [email-masked]
Date:         Tue, 7 Apr 1998 17:51: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: "Jim Schaad (Exchange)" <[email-masked]>
Subject:      [IETF-PKIX] Comments on CMP-07
To: [email-masked]

The following are my comments on the CMP draft.  Please note that some of
the comments may be changed based on the outcome of issues dealing with the
CRMF draft which I have already asked about.

Not all of these comments are of equal weight, some are merely nits while
others are issues I feel strongly about.  I have not given weighting in this
message so that my personal opinions do not necessaryly come out as
opinions.

1.  Section 1.2.2 paragraph 4:  This paragraph defines the term "root CA"  I
wish to be sure that the fact this is the directly trusted root does not
imply that this is the CA which is going to issue my certificate.  I cannot
remember any text stating this but I wish to verify it.

2.  Section 1.3, page 6:  The graph is nice, however the letters marking the
paths are not refered to in the text.  It is dificult in some cases to be
sure what the letters refer to.  This is especially true of c and d.  Please
make a table of what the letters mean or refer to them from the text itself.

3.  Section 1.3 page 7: Formatting note:  please be consistant about how you
format the notes in the text.  I have found atleast two different ways of
this being done.  I suggest that you put in the word "NOTES:" and then a
numbered indented list.  This allows me to have an easy transistion both
into and out of the notes when reading the text.  The first pass on page 7 I
got lost about what I was reading since I was on a computer screen rather
than on a printed page.

4.  Section 2.1, paragraph #1:  The paragraph makes reference to obtaining
the information about the PKI functions supported, but gives no supporting
material on how this would be done.  Is this out-of-band in the same way
that acquiring the root CA public key is?

5.  Section 2.3, pargraph #1: Reference is made to the fact that a given
CA/RA may choose how to implement the POP enforcement, and the profile at
the end says it must be done, however I cannot find anyplace which says how
a client would find out which of the different methods are or are not
supported by the CA/RA.

6.  Section 2.3.2, pargraph 2:  You use the term "immediate", can you be
more explicit what you mean by this?  Is it legitiment that a e-mail based
protocol would use the direct method considering that the messages may take
several days to complete the round trip?

7.  Section 2.4, paragraph #1: I always dislike this type of hair splitting
but:  If I have a CA which has issued a certificate to an RA by the
definition in section 1.2.1 this might not apply to that CA.  In a more
general note, how does one go about updating the keys in a CA which has only
issued certificates to other CAs?  I would have thought that the same
procedure applied.

8.  Section 2.4, paragraph #2:  This paragraph contains the phrase "if
certificates are made available using an X.500 directory".  What are we
suppose to do if the certificates are NOT made available with an X.500
directory?  Never update the root CA keys?  This needs to be fleshed out.

9.  Section 2.4, paragraph #3:  If the CA changes some of the extensions on
the CA:  1) is this a kosher change to make and 2) how should these changes
be reflected in the new certificates?  According to new policy?

10.  Section 2.4, paragraph #3:  The time period of the cross-certificate
certs may also need to be modified according to how one thinks that the
certificates are in use over the wider internet.  Specifically how long
external entities will take to get the new certificate and establish a trust
point on it.

11.  Section 2.4.1:  It is ok to change the encoding of the name at this
point?  I specficically ask about this after some of the discussions at the
IETF about the new use of UTF8 and the fact that the perfered encoding rules
for distinguished names may end up changing over time.  It seems to me that
this would be a good place to handle this issue by doing a roll over of the
root certificates with new names, but maybe the same keys.

12.  Section 2.4.1, paragraph #8:  I disagree that the old CA private key
can be thrown away with impunitity at this time.  Specifically if you use
such an extension as CRL Distribution points, an internet client with an old
certificate may come looking for a new CRL and get one it cannot understand
as it is signed with the new key only.  Either one needs to determine a way
to return the new set of chainging certificates with this CRL or the CRL
with the old private key needs to be generated until such as time as the old
certificate expires.

13.  Section 2.4.2.2, paragraph #1:  Under what circumstances should the
client make this decision that the certificate must be the wrong one.  I can
see that this could be a problem in the internet where going and finding the
new CA key may be expensive.  One can no longer state that the signature was
bad on the certificate, one just weasel about how the certificate might be
good, if only one knew how to find the correct signing certificate.  Such a
lookup would be required anytime a certificate, including an apparently self
signed certificate, failed to verify.  After all the self-signed certificate
may really be a newWithOld or oldWithNew as the subject and issuer DNs would
match in these cases.

14.  Section 3.1, paragraph 5:  I dislike the term PKIProtection.  This
implies more to me that it really means.  What it really is would be
PKIAuthentication as all you are doing is authenticating the data not
protecting (or masking) the data.  Protection implies encryption to me.

15.

Approved-By: [email-masked]
Date:         Wed, 8 Apr 1998 10:29:59 -0400
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-ocsp-03.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           : X.509 Internet Public Key Infrastructure
                          Online Certificate Status Protocol - OCSP
        Author(s)       : C. Adams, M. Myers, A. Malpani, R. Ankney, S. Galperin
        Filename        : draft-ietf-pkix-ocsp-03.txt
        Pages           : 13
        Date            : 07-Apr-98

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
establishes 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 and appendix B
accumulates ASN.1 syntactic elements.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pkix-ocsp-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-03.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: ftp.ietf.org

        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:      [email-masked].  In the body type:
        "FILE /internet-drafts/draft-ietf-pkix-ocsp-03.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-ocsp-03.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ocsp-03.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--OtherAccess--

--NextPart--

Approved-By:  Paul Koning <[email-masked]>
Date:         Wed, 8 Apr 1998 11:43:33 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Criticality of extensions
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

 David> 3) I've already ranted about conditioning the behavior of
 David> supported extensions on the critical bit.  But to reiterate, I
 David> believe the lower row should have the identical entries in
 David> both columns.  At most, the "RP Policy" should be a binary
 David> choice, either treat a non-critical extension identically to
 David> the same extension marked critical, or ignore it.  (If the
 David> lower right box is IGNORE only, you have Peter Gutmann's
 David> scenario of "this extension does nothing except bulk up the
 David> certificate".  I'd prefer the box to be CP/CPS only, but
 David> recognize that the RP always has the option of using downrev
 David> software which doesn't support the extension.)

 David> Proposal:

 David> Behaviors on Extensions:

>                           |  Critical           |  Non-Critical
>                           |  Extensions         |  Extensions
>   --------------------------------------------------------------------
>   Extension Not           |   REJECT            |   IGNORE
>   Supported               |                     |
>   --------------------------------------------------------------------
>   Extension               |   CP/CPS ?          |   RP configurable:
>   Supported               |                     |   CP/CPS or IGNORE
>   --------------------------------------------------------------------

I find this still more confusing than necessary.

How about simply: if the extension is supported, act on it.  (In other
words, the bottom row has the same entries in both slots.)

The notion of a configuration parameter that controls whether you do
something with an extension is something I don't really understand.
In any case, if you want to do such a thing, simply model it as
configuration management control over whether the thing in question is
supported.  (In other words, a flag that switches you from the first
to the second row.)  That works for any extension (critical or not)
for whatever that's worth.  It also doesn't need to appear in the spec
at all since it's a local matter.

        paul

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 8 Apr 1998 11:36:20 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>
>
> >Validity Period Nesting
> >-----------------------
> >
> >The validity period of a certificate must lie within the validity period
> of the
> >certificate which signed it.
>
> I think this should be a SHOULD. If someone is checking the validity dates,
> they will notice the problem if it isn't followed. If they're not, they are
> pretty messed up anyways.

As before, this should not be a MUST, a SHOULD, or even a MAY in any
PKIX or S/MIME document.  If someone is checking validity period
nesting, they may possibly reject valid certification paths.   There is
no security benefit to checking nesting; the only checking required is
to ensure that each certificate is currently valid.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 8 Apr 1998 11:15:24 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Criticality of extensions
To: [email-masked]

> From: Tony Bartoletti <[email-masked]>
>
> Regarding the last exchanges from Graham Bland and Paul Koning, I am
> prompted to build this (possible) table:
>
>   Behaviors on Extensions:
>
>                           |  Critical           |  Non-Critical
>                           |  Extensions         |  Extensions
>   --------------------------------------------------------------------
>   Extension Not           |   REJECT ?          |   IGNORE
>   Recognised/Understood   |                     |
>   --------------------------------------------------------------------
>   Extension               |   CP/CPS ?          |   "RP Policy" ?
>   Recognized/Understood   |                     |
>   --------------------------------------------------------------------

I like this table.

Comments:

1) Is there a reason for the question mark after REJECT?  If we can't
   count on the application failing a critical extension it does not
   support, then there isn't much reason to have the critical bit at all.

2) At least three words could be used in the row headings:
   Recognised, Understood, Supported.  I believe that
   Recognised/Understood does not have the right connotation; the idea
   being that an application must not only "recognize" (know the syntax
   of) an extension, it must also take some specified action before being
   allowed to claim compliance with a standard or profile.  "Supported"
   better captures that flavor, but other suggestions are welcome.

3) I've already ranted about conditioning the behavior of supported
   extensions on the critical bit.  But to reiterate, I believe the
   lower row should have the identical entries in both columns.  At
   most, the "RP Policy" should be a binary choice, either treat a
   non-critical extension identically to the same extension marked
   critical, or ignore it.  (If the lower right box is IGNORE only, you
   have Peter Gutmann's scenario of "this extension does nothing except
   bulk up the certificate".  I'd prefer the box to be CP/CPS only, but
   recognize that the RP always has the option of using downrev
   software which doesn't support the extension.)

Proposal:

   Behaviors on Extensions:

                           |  Critical           |  Non-Critical
                           |  Extensions         |  Extensions
   --------------------------------------------------------------------
   Extension Not           |   REJECT            |   IGNORE
   Supported               |                     |
   --------------------------------------------------------------------
   Extension               |   CP/CPS ?          |   RP configurable:
   Supported               |                     |   CP/CPS or IGNORE
   --------------------------------------------------------------------

Approved-By:  Paul Koning <[email-masked]>
Date:         Wed, 8 Apr 1998 10:44:28 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

>>>>> "David" == David P Kemp <[email-masked]> writes:

 David> ...  Occam's razor dictates that the simplest possible
 David> interpretation of an ambiguous specification be used, and the
 David> simplest and most logical interpretation of "Validity" is that
 David> the validity period of the cert being checked includes the
 David> current date/time.  The current date check is always required;
 David> any nesting checks would be above and beyond what is
 David> necessary.

 David> I'm all in favor of amending X.509 to explicitly specify the
 David> current date/time check.

 David> There is no security-relevant rationale for enforcing validity
 David> nesting - the issuer is responsible for creating certs in
 David> accordance with it's policy, and that might reasonably include
 David> recertification of the issuer's key.  I would be opposed to
 David> PKIX or X.509 requiring or even recommending a nesting check.

When certificates are used to authorize something that lasts for a
while, it seems to me one would also want to determine the end of the
validity period for a certificate.  For example, if a certificate is
used to set up an IPSec (ISAKMP) SA, it would seem logical to limit
the lifetime of that SA to be the validity period of the certificate
used.

That's not directly related to the nesting question, but it does show
a scenario for going beyond "current date check" for some
applications.  Also, if it is done, and nesting is not required, then
what would the "end of the validity period" be?  The end date of the
last cert in the chain?  The earliest of the end dates in the chain?

        paul

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 8 Apr 1998 10:06:22 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

> From: Peter Gutmann <[email-masked]>
>
> >>The validity period of a certificate must lie within the validity period of
> >>the certificate which signed it.
> >I'm not entirely happy with this suggestion. One can issue a new CA
> >certificate for a CA key whose original cert has expired, while keeping the
> >value of the key (and key version number extension) the same.
>
> The main reason for this is that currently the situation with enforcing
> nesting is ambiguous (as pointed out in the style guide), so that implementors
> can choose to enforce it either way.

If X.509 is ambiguous, then X.509 should be fixed.

Section 12.4.3 says:

  The inputs to the certification path processing procedure are:
    a) a set of certificates comprising a certification path
      ...
    f) the current date/time

  The following checks are applied to a certificate:
    a) Check that the signature verifies, that dates are valid, that the
    certificate subject and certificate issuer names chain correctly, and
    that the certificate has not been revoked.

I suppose it is possible to interpret "that dates are valid" to mean
that validity of the certificate being checked must nest within the
validity of the issuer cert.  But that seems to me like a perverse and
highly extrapolated reading of the text.  Occam's razor dictates that
the simplest possible interpretation of an ambiguous specification be
used, and the simplest and most logical interpretation of "Validity" is
that the validity period of the cert being checked includes the current
date/time.  The current date check is always required; any nesting
checks would be above and beyond what is necessary.

I'm all in favor of amending X.509 to explicitly specify the current
date/time check.

There is no security-relevant rationale for enforcing validity
nesting - the issuer is responsible for creating certs in accordance
with it's policy, and that might reasonably include recertification of
the issuer's key.  I would be opposed to PKIX or X.509 requiring
or even recommending a nesting check.

The style guide, of course, may point out the interoperability
considerations and make whatever recommendations are appropriate
for its audience.

> >This way madness lies.
> >
> >It leads to a situation where each vendor has their own subtly different
> >protocol, and each implementation needs to be able to talk all of these
> >protocols.
>
> And this differs from the current situation in which way?
>
> It's nice to see that someone agrees with me that the current situation is
> crazy though :-).

We agree that the current situation is crazy.  We may disagree on
specific fixes.

Implementations which are clearly incorrect (non-conformant with any
possible reading of the standard) should be fixed.  One doesn't rewrite
the standard to accommodate the application behavior of the third 50%
("which comes as a complete surprise to everyone else") unless the
surprising behavior achieves consensus as a superior
thinking-out-of-the-box approach.

Where the standard is ambiguous, it should be clarified in the way
which makes sense, not necessarily the way which enables the maximum
number of current implementations to claim compliance.
Remember, the IETF doesn't vote.  We don't survey the current sorry
state-of-the-art and attempt to codify it.

Approved-By:  Tim Polk <[email-masked]>
Date:         Wed, 8 Apr 1998 09:16:09 -0400
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

The PKIX draft included the brief description of signatures using RSA since
there was no RFC to point to.  We used the OIW oid since there wasn't an
oid for RSA with SHA-1 in the pkcs-1 arc.

Since we started, PKCS #1 Version 1.5 has become RFC 2313.  The next
(final!) draft will simply point to RFC 2313 for details on implementing
RSA signatures.

The next draft will also use RSA with SHA-1 from the pkcs-1 arc.
Unfortunately, the RSA with SHA-1 oid is not in RFC 2313 (or any other
published version of PKCS #1.)  The following text was RSA-approved, so it
should be correct:

**** RSA with SHA-1 text ****

The signature algorithm with SHA-1 and the RSA encryption algorithm
is implemented using the padding and encoding conventions described in
PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1
hash algorithm.  The ASN.1 object identifier used to identify this
signature algorithm is:

     sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-1(1) 5  }

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Wed, 8 Apr 1998 15:06:08 -0700
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] LDAP v2 schema
Comments: To: Nada Kapidzic Cicovic <[email-masked]>
To: [email-masked]

Nada,

Since I answered to Sharon a few minutes ago, this mail may arrive
sooner that the previous. Nevertheless let us talk on this topic while
it is still hot.

>>Sharon Boeyen wrote:
>>>
>>> Hi Denis, I'm not sure I understand. Why can't these new by new and new by
>>> old be held in this attribute as currently defined? They are still
>>> self-signed certificates.
>>
>> They could. We could mix "oranges" and "apples" and then sort them out.
>> However self-signed certificates are not really  what we call
>> "cross-certificates" (alias CA-certificates).
>
> This is true, and that is why cross-certificates (as defined in PKIX part
> 3) are stored in crossCertificatePair attribute, whereas self-signed
> certificates (i.e. certificates which have the same subject and issuer
> field) are stored in cACertificate attribute.

I acknowledged this in my previous E-mail to Sharon.

> Denis, if I understand you right you would like to define three classes of
> certificates as compared to current two classes above:
>
> 1. Self-signed certificates of new-with-new type.
> 2. Self-signed certificates of old-with-new and new-with-old type.
> 3. Cross-certificates.

> Class 1 certificates are to be stored in cACertificate. Class 3
> certificates are to be stored in crossCertificatePair, and you would like
> to have a new attribute to store certificates of type 2.
>
> Did I understand you correctly?

This is not what I had in mind originally, but I like it better !

The problem would be whether this would also fit with the ISO defect
report question and answer.

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:         Wed, 8 Apr 1998 14:50:56 -0700
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] LDAP v2 schema
Comments: To: Sharon Boeyen <[email-masked]>
To: [email-masked]

Sharon,

Thank you for your fast response.

> > The defect report is DR 185. The text was agreed at the Jan '98 meeting
> > and is ready/submitted for ballot. I'm not sure if the ballot has issued
> > or if Hoyt has put the document on his server yet (he's away this week).
> > The text that will be balloted is exactly the text that currently appears
> > in the schema draft.
> >
> > I believe that the resolution of the defect does exactly what you want and
> > ensures the separation of the apples from the oranges. The apples bucket
> > (cACertificate attribute) holds certificates in which the issuer  and
> > subject are the same (regardless of the keys). The oranges bucket
> > (crossCertificatePair attribute) holds certificates for CA subjects in
> > which the issuer and subject are different (with the forward and reverse
> > elements used to differentiate the certs issued to the CA and by the CA of
> > interest).
> >
> > Isn't this the separation you need?

You are fully right. I misread the document (or read it too fast while
in the plane).
The structure is thus correct. However, adding more explanations to say
that you may find there "new by new", "old by new" and "new by old"
self-signed certificates would not hurt. Wouldn't it ?

An additional minor(?) question coming from what I heard at the meeting.
Should the CRL distribution points and the reference to the patent from
Entrust be deleted ?

Finally, an editorial comment: Change section 5 into 4.2 and renumber
the following.

Denis

>> Sharon Boeyen wrote:
>>>
>>> Hi Denis, I'm not sure I understand. Why can't these new by new and new
>> by
>>> old be held in this attribute as currently defined? They are still
>>> self-signed certificates.
>>
>> They could. We could mix "oranges" and "apples" and then sort them out.
>> However self-signed certificates are not really  what we call
>> "cross-certificates" (alias CA-certificates).
>>
>>> The text in the draft is lifted directly from the resolution of a defect
>> on
>>> that topic in 509, so if there is a problem we may need to address it
>> there
>>> as well.
>>
>> Could you give a pointer to this defect report and/or provide it ?
>>
>> Denis
>>
>>>> Sharon (and other co-editors),
>>>>
>>>> I reviewed the first draft and I have a comment on it:
>>>>
>>>> On top of page 4, the document says: "The cACertificate attribute
>> (...)
>>>> may be used to store self-signed certificates.
>>>>
>>>> My question is as follows: why not consider an independent attribute
>> to
>>>> store self-signed certificates ? It might then be easier to get them.
>>>>
>>>> By self-signed cerificates, I mean not only "new by new" self-signed
>>>> certificates, but also "new by old" self-signed certificates and "old
>> by
>>>> new" self-signed certificates.
>>>>
>>>>
>>>> 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:  Nada Kapidzic Cicovic <[email-masked]>
Date:         Wed, 8 Apr 1998 14:54:01 +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: Nada Kapidzic Cicovic <[email-masked]>
Subject:      Re: [IETF-PKIX] LDAP v2 schema
Comments: To: [email-masked]
To: [email-masked]

Sharon and Denis,

I hope you do not mind me jumping into the discussion.

At 10:55 4/8/98 -0700, Denis Pinkas wrote:
>Sharon Boeyen wrote:
>>
>> Hi Denis, I'm not sure I understand. Why can't these new by new and new by
>> old be held in this attribute as currently defined? They are still
>> self-signed certificates.
>
>They could. We could mix "oranges" and "apples" and then sort them out.
>However self-signed certificates are not really  what we call
>"cross-certificates" (alias CA-certificates).

This is true, and that is why cross-certificates (as defined in PKIX part
3) are stored in crossCertificatePair attribute, whereas self-signed
certificates (i.e. certificates which have the same subject and issuer
field) are stored in cACertificate attribute.

Denis, if I understand you right you would like to define three classes of
certificates as compared to current two classes above:

1. Self-signed certificates of new-with-new type.
2. Self-signed certificates of old-with-new and new-with-old type.
3. Cross-certificates.

Class 1 certificates are to be stored in cACertificate. Class 3
certificates are to be stored in crossCertificatePair, and you would like
to have a new attribute to store certificates of type 2.

Did I understand you correctly?

Regards,

Nada

>
>> The text in the draft is lifted directly from the resolution of a defect on
>> that topic in 509, so if there is a problem we may need to address it there
>> as well.
>
>Could you give a pointer to this defect report and/or provide it ?
>
>Denis
>
>> > Sharon (and other co-editors),
>> >
>> > I reviewed the first draft and I have a comment on it:
>> >
>> > On top of page 4, the document says: "The cACertificate attribute (...)
>> > may be used to store self-signed certificates.
>> >
>> > My question is as follows: why not consider an independent attribute to
>> > store self-signed certificates ? It might then be easier to get them.
>> >
>> > By self-signed cerificates, I mean not only "new by new" self-signed
>> > certificates, but also "new by old" self-signed certificates and "old by
>> > new" self-signed certificates.
>> >
>> >
>> > 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
>> >
>
>--
>      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:  Sharon Boeyen <[email-masked]>
Date:         Wed, 8 Apr 1998 08:30:58 -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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] LDAP v2 schema
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

> The defect report is DR 185. The text was agreed at the Jan '98 meeting
> and is ready/submitted for ballot. I'm not sure if the ballot has issued
> or if Hoyt has put the document on his server yet (he's away this week).
> The text that will be balloted is exactly the text that currently appears
> in the schema draft.
>
> I believe that the resolution of the defect does exactly what you want and
> ensures the separation of the apples from the oranges. The apples bucket
> (cACertificate attribute) holds certificates in which the issuer  and
> subject are the same (regardless of the keys). The oranges bucket
> (crossCertificatePair attribute) holds certificates for CA subjects in
> which the issuer and subject are different (with the forward and reverse
> elements used to differentiate the certs issued to the CA and by the CA of
> interest).
>
> Isn't this the separation you need?
>
>
> ----------
> From:         Denis Pinkas[SMTP:[email-masked]]
> Sent:         April 8, 1998 1:55 PM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] LDAP v2 schema
>
> Sharon Boeyen wrote:
> >
> > Hi Denis, I'm not sure I understand. Why can't these new by new and new
> by
> > old be held in this attribute as currently defined? They are still
> > self-signed certificates.
>
> They could. We could mix "oranges" and "apples" and then sort them out.
> However self-signed certificates are not really  what we call
> "cross-certificates" (alias CA-certificates).
>
> > The text in the draft is lifted directly from the resolution of a defect
> on
> > that topic in 509, so if there is a problem we may need to address it
> there
> > as well.
>
> Could you give a pointer to this defect report and/or provide it ?
>
> Denis
>
> > > Sharon (and other co-editors),
> > >
> > > I reviewed the first draft and I have a comment on it:
> > >
> > > On top of page 4, the document says: "The cACertificate attribute
> (...)
> > > may be used to store self-signed certificates.
> > >
> > > My question is as follows: why not consider an independent attribute
> to
> > > store self-signed certificates ? It might then be easier to get them.
> > >
> > > By self-signed cerificates, I mean not only "new by new" self-signed
> > > certificates, but also "new by old" self-signed certificates and "old
> by
> > > new" self-signed certificates.
> > >
> > >
> > > 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
> > >
>
> --
>       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:         Wed, 8 Apr 1998 10:55:42 -0700
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] LDAP v2 schema
To: [email-masked]

Sharon Boeyen wrote:
>
> Hi Denis, I'm not sure I understand. Why can't these new by new and new by
> old be held in this attribute as currently defined? They are still
> self-signed certificates.

They could. We could mix "oranges" and "apples" and then sort them out.
However self-signed certificates are not really  what we call
"cross-certificates" (alias CA-certificates).

> The text in the draft is lifted directly from the resolution of a defect on
> that topic in 509, so if there is a problem we may need to address it there
> as well.

Could you give a pointer to this defect report and/or provide it ?

Denis

> > Sharon (and other co-editors),
> >
> > I reviewed the first draft and I have a comment on it:
> >
> > On top of page 4, the document says: "The cACertificate attribute (...)
> > may be used to store self-signed certificates.
> >
> > My question is as follows: why not consider an independent attribute to
> > store self-signed certificates ? It might then be easier to get them.
> >
> > By self-signed cerificates, I mean not only "new by new" self-signed
> > certificates, but also "new by old" self-signed certificates and "old by
> > new" self-signed certificates.
> >
> >
> > 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
> >

--
      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 Ankney <[email-masked]>
Date:         Wed, 8 Apr 1998 06:12:30 -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: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

----------
> From: Marc Branchaud <[email-masked]>
> I've seen two previous messages about this same point but it has yet to
be
> addressed...
>
> In section 7.2.1 of Part 1, there's the following description of an RSA
> signature algorithm:
>
>    The data to be signed (e.g., the one-way hash function output value)
>    is first ASN.1 encoded as an OCTET STRING and the result is encrypted
>    (e.g., using RSA Encryption) to form the signed quantity.
>
> This is _not_ how PKCS1 works, and I think this should be changed so that
> they're more consistent:
>
>    The data to be signed (i.e., the DigestInfo SEQUENCE as described in
>    PKCS1) is first ASN.1 encoded as an OCTET STRING and the result is
>    encrypted (i.e., using RSA Encryption) to form the signed quantity.
>

But it's not encoded.  The PKCS #1 block is the PKCS padding (zero bytes,
block type, hex 'FF', zero byte delimiter) followed by the BER/DER encoding
of DigestInfo.

> FYI: DigestInfo is a SEQUENCE of the hash value and a hash algorithm ID.
>
> Actually, these last two paragraphs of section 7.2.1 deal with the BIT
STRING
> encoding of the signed value.  I don't see any practical deviation here
from
> what is described in section 10.1 of PKCS1, so I think it would be even
> clearer to just omit these paragraphs and leave the details entirely to
> PKCS1.
>

Agreed.

> I admit I'm not familiar with the OIW's RSA-with-SHA1 algorithm.  If it's
> significantly different than PKCS1 (e.g. it doesn't use DigestInfo) then
I
> suggest PKIX define a more PKCS1-like version of RSA-with-SHA1.
Otherwise,
> it's just too confusing.  Since RSA-with-SHA1 isn't common yet, now's a
good
> time to make sure it's not some mutant algorithm.  If there's a good
reason
> why RSA-with-SHA1 can't be PKCS1-like, I'd like to hear it and I'd like
the
> draft to be clear when it's talking about RSA-with-SHA1's non-PKCS1
behavior.
>

The OIW OID is for the ISO 9796 version of RSA, not PKCS #1.  On the off
chance someone is using it correctly, PKIX should use the RSADSI OID
for SHA1-with-RSAEncryption (per the OIDs in the SET spec).

> I'd dearly like to know why this inconsistency exists before the draft
> becomes an RFC.
>
>                 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/
>
+------------------------------------------------------------------------+

Regards,
Rich

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Tue, 7 Apr 1998 15:03:42 -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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
To: [email-masked]

>Canonical string encodings
>--------------------------
>
>Definition: Least inclusive encoding means encoding a string using the
minimal
>character set which is capable of encoding the string.  For DN's this means
>using PrintableString if possible, then T61String if possible, then
BMPString.

Two things here. This is *not* canonical string encodings, and shouldn't be
discussed as such. "Least inclusive encoding" is a much better term.
Canonical encoding for things like BMPString mean decomposition of combined
characters and so on.

Second, I do not think people should use T61String. However, since people
can populate the parts of a DN with any damn string type they want, the
spec should say something about trying real hard to accept every string
type, including UniversalString and UTF8String. (Yes, there will possibly
be purposes to use the upper two bytes in a UTC-4 encoding.)

>Validity Period Nesting
>-----------------------
>
>The validity period of a certificate must lie within the validity period
of the
>certificate which signed it.

I think this should be a SHOULD. If someone is checking the validity dates,
they will notice the problem if it isn't followed. If they're not, they are
pretty messed up anyways.

>Alternative Name Usage
>----------------------
>
>Name components which are explicitly provided for in the issuer and subject
>alternative name extensions (in particular email addresses and URL's) must be
>encoded using the alternative name extension and not stuffed into a DN using
>whatever OID is convenient.

A better way to say this (which I hope Tim is doing) is to simply list the
components which are allowed in a name.

>Extension Handling
>------------------

I like your chart very much.

>Compliance
>----------

This is out of scope for PKIX part 1, and is a politcal rathole. If you
really want it, I suggest you do it as a separate draft for an
authenticated attribute.

>Other Extensions
>----------------

Ditto.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 7 Apr 1998 14:08:52 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

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

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

Brian Korver <[email-masked]> scrawled:
>
> I believe that PKIX is now using RSA's PKCS1 RSA-with-SHA1 OID, which
> is identical to the MD* versions except for the digest algorithm.
>

Not according to draft-ietf-pkix-ipki-part1-07.txt.

After posting my original message, I became aware of the PKCS SHA1 OID.
Although I couldn't find any RSA-with-SHA OIDs on RSA's site, SET uses the
following:

   id-sha1-with-rsa-signature OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

If SET is correct, then I suggest that PKIX use this OID instead of the OIW
one, and that the last two paragraphs of part 1's section 7.2.1 be deleted
(since they're redundant to PKCS1).

                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: [email-masked]
Date:         Tue, 7 Apr 1998 14:44:06 -0400
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-ipki-part1-07.txt
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.

        Title           : Internet Public Key Infrastructure
                          X.509 Certificate and CRL Profile
        Author(s)       : D. Solo, R. Housley, W. Ford, T. Polk
        Filename        : draft-ietf-pkix-ipki-part1-07.txt
        Pages           : 116
        Date            : 06-Apr-98

   This is the seventh draft of the Internet Public Key Infrastructure
   X.509 Certificate and CRL Profile.  This draft is a complete
   specification.  This text includes minor modifications over the
   previous draft. This draft introduces UTF8 support, updates the path
   validation process to conform with the current X.509 specification,
   forbids wildcarding in subject alternative names, and clarifies
   conformance requirements. Please send comments on this document to
   the [email-masked] mail list.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pkix-ipki-part1-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-part1-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-ipki-part1-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-ipki-part1-07.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ipki-part1-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:  Tony Bartoletti <[email-masked]>
Date:         Tue, 7 Apr 1998 12:04: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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Criticality of extensions
To: [email-masked]

Regarding the last exchanges from Graham Bland and Paul Koning, I am
prompted to build this (possible) table:

  Behaviors on Extensions:

                          |  Critical           |  Non-Critical
                          |  Extensions         |  Extensions
  --------------------------------------------------------------------
  Extension Not           |   REJECT ?          |   IGNORE
  Recognised/Understood   |                     |
  --------------------------------------------------------------------
  Extension               |   CP/CPS ?          |   "RP Policy" ?
  Recognized/Understood   |                     |
  --------------------------------------------------------------------

As Graham points out, everyone can accept IGNORE (extension) in the
"Non-Critical/Not-Understood" category, or else extensibility equates
to "closed-loop proprietary".

Beyond this, I believe it is the nature of particular extensions that
must determine how "critical bit" is to be interpreted.  I know this is
unfortunately "chicken and egg", especially for the "Critical/Not-Grokked"
category.

Correct me if I am mistaken, but some extensions are employed by the
CA to contain their own liability caveats, key-usage conditions, etc.,
while others may contain elements opaque to the CA that convey similar
conditions as desired by the key-holder (perhaps above and beyond the
simple "non-verified subscriber info" data.)  If this is true, how can
one hope to formulate a consistent meaning for "critical" as regards
"compliant" software?

___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:         Mon, 7 Sep 1998 15:40:33 +0200
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mark Shuttleworth <[email-masked]>
Organization: Thawte Consulting
Subject:      Re: [IETF-PKIX] Questions about PKCS
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msA45153645DB487BCBAE7E080
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

If an application supports an extension, surely it should process
it whether or not that extension is marked critical?  Criticality
just means that processing automatically fails if the extension
is not supported.

For example, for the new chained CA service, we are putting in
a non-critical nameConstraints.  The current browsers will ignore
it, but the next generation should process it.  This gives us a
smooth roll-in to the newer browsers.  When enough support it,
we start making the extension critical.

--
Mark Shuttleworth
Thawte
--------------msA45153645DB487BCBAE7E080
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

--------------msA45153645DB487BCBAE7E080--

Approved-By:  Brian Korver <[email-masked]>
Date:         Tue, 7 Apr 1998 10:39:15 -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: Brian Korver <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

Marc Branchaud writes:
> I've seen two previous messages about this same point but it has yet to be
> addressed...
>
> In section 7.2.1 of Part 1, there's the following description of an RSA
> signature algorithm:
>
>    The data to be signed (e.g., the one-way hash function output value)
>    is first ASN.1 encoded as an OCTET STRING and the result is encrypted
>    (e.g., using RSA Encryption) to form the signed quantity.
>
> This is _not_ how PKCS1 works, and I think this should be changed so that
> they're more consistent:
>
>    The data to be signed (i.e., the DigestInfo SEQUENCE as described in
>    PKCS1) is first ASN.1 encoded as an OCTET STRING and the result is
>    encrypted (i.e., using RSA Encryption) to form the signed quantity.
>
> FYI: DigestInfo is a SEQUENCE of the hash value and a hash algorithm ID.
>
> Actually, these last two paragraphs of section 7.2.1 deal with the BIT STRING
> encoding of the signed value.  I don't see any practical deviation here from
> what is described in section 10.1 of PKCS1, so I think it would be even
> clearer to just omit these paragraphs and leave the details entirely to
> PKCS1.
>
> I admit I'm not familiar with the OIW's RSA-with-SHA1 algorithm.  If it's
> significantly different than PKCS1 (e.g. it doesn't use DigestInfo) then I
> suggest PKIX define a more PKCS1-like version of RSA-with-SHA1.  Otherwise,
> it's just too confusing.  Since RSA-with-SHA1 isn't common yet, now's a good
> time to make sure it's not some mutant algorithm.  If there's a good reason
> why RSA-with-SHA1 can't be PKCS1-like, I'd like to hear it and I'd like the
> draft to be clear when it's talking about RSA-with-SHA1's non-PKCS1 behavior.

I believe that PKIX is now using RSA's PKCS1 RSA-with-SHA1 OID, which
is identical to the MD* versions except for the digest algorithm.

>
> I'd dearly like to know why this inconsistency exists before the draft
> becomes an RFC.
>
>                 Marc

brian
[email-masked]

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 7 Apr 1998 10:35:35 -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: Marc Branchaud <[email-masked]>
Subject:      [IETF-PKIX] PKIX1 inconsistent with PKCS1
To: [email-masked]

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

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

I've seen two previous messages about this same point but it has yet to be
addressed...

In section 7.2.1 of Part 1, there's the following description of an RSA
signature algorithm:

   The data to be signed (e.g., the one-way hash function output value)
   is first ASN.1 encoded as an OCTET STRING and the result is encrypted
   (e.g., using RSA Encryption) to form the signed quantity.

This is _not_ how PKCS1 works, and I think this should be changed so that
they're more consistent:

   The data to be signed (i.e., the DigestInfo SEQUENCE as described in
   PKCS1) is first ASN.1 encoded as an OCTET STRING and the result is
   encrypted (i.e., using RSA Encryption) to form the signed quantity.

FYI: DigestInfo is a SEQUENCE of the hash value and a hash algorithm ID.

Actually, these last two paragraphs of section 7.2.1 deal with the BIT STRING
encoding of the signed value.  I don't see any practical deviation here from
what is described in section 10.1 of PKCS1, so I think it would be even
clearer to just omit these paragraphs and leave the details entirely to
PKCS1.

I admit I'm not familiar with the OIW's RSA-with-SHA1 algorithm.  If it's
significantly different than PKCS1 (e.g. it doesn't use DigestInfo) then I
suggest PKIX define a more PKCS1-like version of RSA-with-SHA1.  Otherwise,
it's just too confusing.  Since RSA-with-SHA1 isn't common yet, now's a good
time to make sure it's not some mutant algorithm.  If there's a good reason
why RSA-with-SHA1 can't be PKCS1-like, I'd like to hear it and I'd like the
draft to be clear when it's talking about RSA-with-SHA1's non-PKCS1 behavior.

I'd dearly like to know why this inconsistency exists before the draft
becomes an RFC.

                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: [email-masked]
Date:         Tue, 7 Apr 1998 15:12:41 +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: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      [IETF-PKIX] Definition of short OIDs in Distinguished Names
To: [email-masked]

Hello all,

I am looking for a reference of the commonly used short forms for the
attributes used in Distinguished Names. So for I have those:

C  (COUNTRY)
O  (ORGANIZATION)
OU (ORGANIZATIONAL UNIT)
CN (COMMON NAME)
S  (SURNAME)
L  (LOCALITY)
ST (STREET ADDRESS)
T  (TITLE)
SN (SERIAL NUMBER)
BC (BUSINESS CATEGORY)
D  (DESCRIPTION)
SP (STATE OR PROVINCE)
EMAIL (EMAIL ADDRESS)
DC (DOMAIN COMPONENT)

I know that any OID can appear in a Distinguished Name. I was just
wondering what to use so that most software can show them correctly.
Especially I am missing: ZIP code or equivalent, a date of birth (or any
date for that matter) and possibly a place of birth.

Andreas
--
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht

Approved-By:  Paul Koning <[email-masked]>
Date:         Tue, 7 Apr 1998 11:08:17 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Criticality of extensions
To: [email-masked]

>>>>> "Graham" == Graham Bland <[email-masked]> writes:

>...
 Graham> 2. If you understand the extension it then it is up to you
 Graham> what to do, if an implementation takes the trouble to
 Graham> understand the extension then it would seem sensible that it
 Graham> would act upon it.  It can ignore the contents completely if
 Graham> it wants as in 1.

I suppose "understand" is a somewhat vague concept, but I don't think
the definition you used is very useful.

For any particular component of a message or data structure, I can see
only two things you could do with it:

1. Know what it means and act on that.
2. Not know what it means (and ignore it or reject the cert according
to the "critical" flag.

The in-between notion of "I know what it means but I'm not going to
act on it" doesn't compute.

 Graham> There are three ways forward as I see it

 Graham> a) Set up a subset but don't call the certificates X509 v3,
 Graham> this allows extensions to be non critical but mandated.

I wouldn't call that a subset, and I think that having such a rule
shouldn't prevent you from calling the certificates in question
X.509.

 Graham> b) Make all mandated extensions critical.

I'd say that's a bad idea.  "Critical" means that it is necesary to
process the extension in question or bad things would happen (e.g.,
security holes).  If support of a certain extension is mandated by a
profile, then that's all there is to say; if the nature of the
extension is that it isn't critical then mandating it doesn't make it
critical.

 Graham> c) Add a single critical extension of PKIX compliance the
 Graham> presence of which would mandate implementations to act as in
 Graham> a).

I don't like that either for the same reason.

        paul

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Tue, 7 Apr 1998 08:59:32 -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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] LDAP v2 schema
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]

Hi Denis, I'm not sure I understand. Why can't these new by new and new by
old be held in this attribute as currently defined? They are still
self-signed certificates.

The text in the draft is lifted directly from the resolution of a defect on
that topic in 509, so if there is a problem we may need to address it there
as well.

> ----------
> From:         Denis Pinkas[SMTP:[email-masked]]
> Sent:         April 7, 1998 5:48 PM
> To:   [email-masked]
> Subject:      [IETF-PKIX] LDAP v2 schema
>
> Sharon (and other co-editors),
>
> I reviewed the first draft and I have a comment on it:
>
> On top of page 4, the document says: "The cACertificate attribute (...)
> may be used to store self-signed certificates.
>
> My question is as follows: why not consider an independent attribute to
> store self-signed certificates ? It might then be easier to get them.
>
> By self-signed cerificates, I mean not only "new by new" self-signed
> certificates, but also "new by old" self-signed certificates and "old by
> new" self-signed certificates.
>
>
> 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:         Tue, 7 Apr 1998 14:48:20 -0700
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] LDAP v2 schema
To: [email-masked]

Sharon (and other co-editors),

I reviewed the first draft and I have a comment on it:

On top of page 4, the document says: "The cACertificate attribute (...)
may be used to store self-signed certificates.

My question is as follows: why not consider an independent attribute to
store self-signed certificates ? It might then be easier to get them.

By self-signed cerificates, I mean not only "new by new" self-signed
certificates, but also "new by old" self-signed certificates and "old by
new" self-signed certificates.

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:         Tue, 7 Apr 1998 05:24:37 -0700
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] Duct-taping X.509
Comments: To: [email-masked]
To: [email-masked]

>>The validity period of a certificate must lie within the validity period of
>>the certificate which signed it.
>I'm not entirely happy with this suggestion. One can issue a new CA
>certificate for a CA key whose original cert has expired, while keeping the
>value of the key (and key version number extension) the same.

The main reason for this is that currently the situation with enforcing
nesting is ambiguous (as pointed out in the style guide), so that implementors
can choose to enforce it either way.  The reason I recommended nesting is that
given that it's a toss-up between enforcing and not enforcing it, and
Microsoft (AFAIK) enforces it, you may as well do it too.  This has the added
benefit that your certs will appear valid to MS software.

The reason for being fascist about it ("do it this way or else") was that
without clear guidelines we'll get the same situation that we already have
with cert extensions, where 50% of people do it one way, 50% do it the other
way, and the remaining 50% do it a third way which comes as a complete
surprise to everyone else.

>>This leads to a second type of extension, implementationWhichCreatedThis,
>>which may be even more useful than the one described above.  As it is, it's
>>already possible to identify certain implementations just by the bugs in the
>>certificates they produce, but being able to make a positive ID would be
>>really useful because by knowing how they (mis)interpret certain fields, your
>>implementation could follow the same interpretation.

>This way madness lies.
>
>It leads to a situation where each vendor has their own subtly different
>protocol, and each implementation needs to be able to talk all of these
>protocols.

And this differs from the current situation in which way?  (See
http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt for more details -
there's a more recent version which has another round of CA and implementation
bugs at the end which I haven't uploaded yet, so it's even worse than the
already depressing picture painted in the guide.  It only covers cert formats,
but the fact that there are implementations which will happily process the
incorrect, illogical, and inconsistent nonsense which is appearing in some
certs indicates that we're already in a situation where implementations are
having to bend over backwards to handle the broken certificates others are
issuing.  All that this proposal does is formalise the identification of cert
types).

It's nice to see that someone agrees with me that the current situation is
crazy though :-).

Just out of interest, has anyone here seriously deployed X.509v3 software
which actually uses and enforces basicConstraints, keyUsage/extendedKeyUsage,
and the various policy constraints (as required by PKIX, including attention
to critical flags) which interoperates correctly with mass-market software
like MSIE, Exchange, Netscape Navigator, etc etc?

Peter.

Approved-By:  Graham Bland <[email-masked]>
Date:         Tue, 7 Apr 1998 09:55: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: Graham Bland <[email-masked]>
Subject:      [IETF-PKIX] Criticality of extensions
To: [email-masked]

An implementation must ignore any non critical extensions which it does not
understand.  If this was not the case then no new extensions could ever be
added to a certificate until all existing implementations had been modified
to accept them.  Practically this freezes the addition of new extensions at
this point in time.

By my understanding X.509 v3 provides an extensible standard and to do this
allows a certificate issuer to add extensions in three ways:

One is a critical extension, if you don't understand AND act upon this
extension then the certificate is invalid.  Acting upon means taking note
of, an implementation can decide that the appropriate action is to ignore it
as in Certificate Policies.

The second two are for non critical extensions
1. If you don't understand the extension you can still use the certificate
and ignore the extension (as you don't know what it is)

2. If you understand the extension it then it is up to you what to do, if an
implementation takes the trouble to understand the extension then it would
seem sensible that it would act upon it.  It can ignore the contents
completely if it wants as in 1.

There are three ways forward as I see it

a) Set up a subset but don't call the certificates X509 v3, this allows
extensions to be non critical but mandated.

b) Make all mandated extensions critical.

c) Add a single critical extension of PKIX compliance the presence of which
would mandate implementations to act as in a).

Graham Bland

--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 6 Apr 1998 14:58:15 -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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Questions about PKCS #10 and cert extensions
To: [email-masked]

> From: Peter Gutmann <[email-masked]>
>
> >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.
>
>    [... and ...]
>
> 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.

I agree that X.509 and PKIX do not do a very good job of describing the
meaning of the critical flag, and that moreover, the definitions of some
specific extensions overload the meaning of the critical flag in ways
that were not origininally intended.

However, I don't think it is correct to assert that an implementation is
free to ignore any non-critical extension.

X.509 says:
  "When an implementation processing a certificate does not recognize
   an extension, if the criticality flag is FALSE, it may ignore that
   extension."

PKIX part 1 says:
  "Conforming CAs are required to support the basic Constraints extension,
   the key usage extension, ..."

and
  "At a minimum, applications conforming to this profile shall recognize
   extensions ...

   In addition, this profile recommends support for ..."

My reading of this text is that the intention of the authors is that
"recognize" and "support" have the identical meaning, regardless of what
a dictionary would say.  It would be helpful if someone did a global
search and replace on those documents to change every occurrence of
"recognize" to "support", but the intended meaning seems semi-unambiguous :-)
even without that change.

Therefore, an implementation might claim not to support, say, basic
constraints, in which case it's off the hook.  But it may *not* both
1) claim to support an extension and 2) ignore it if marked non-critical.

Similarly, an application which claims PKIX conformance must support a
fixed set of extensions and must not ignore any of those extensions,
regardless of the state of the criticality flag.

Approved-By: [email-masked]
Date:         Mon, 6 Apr 1998 11:50:52 +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: Michael Roe <[email-masked]>
Subject:      Re: [IETF-PKIX] Duct-taping X.509
Comments: To: [email-masked]
To: [email-masked]

In reply to Peter Gutmann's message:
> Validity Period Nesting
> -----------------------
>
> The validity period of a certificate must lie within the validity period of
> the
> certificate which signed it.
>
> Rationale: This ensures that the certificate will be regarded as valid by
> software which enforces validity period nesting.

I'm not entirely happy with this suggestion.
One can issue a new CA certificate for a CA key whose original cert has
expired, while keeping the value of the key (and key version number extension)
the same. This should allow a user certificate signed using the CA key to have
a lifetime overlapping that that of the CA cert:

          TIME ---->

       CA_Cert 1 valid     CA Cert 2 valid
    <-------------------><----------------->
            User cert valid
           <--------------------->

Where CA_Cert 1 and CA Cert 2 both certify key K_CA, and K_CA^{-1} signs
user cert.

Doing this can make certificate re-issuing easier by avoiding a flag day where
everyone's user certificate runs out at the same time. On the other hand,
it makes life more complex for UAs, because they have to somehow get hold
of CA Cert 2 when it's issued and attach it to their existing user cert.
So not everyone will want to do this., but it ought to be *permitted*.

However, I'll admit you can do gradual certificate re-issue with all
validity periods nested:

  TIME --->
   CA cert 1
  <------------------>
        |   Ca cert 2
        | <------------------>
        |         |
        V         V
       Ucert1  User cert 2
     <-------><------------->

> Other Extensions
> ----------------
>
> A while back someone made the comment that "It's good that <large vendor>
> always puts the name of the MUA in their mail headers, because it allows you
> to bypass <vendor>-specific bugs".  This leads to a second type of extension,
> implementationWhichCreatedThis, which may be even more useful than the one
> described above.  As it is, it's already possible to identify certain
> implementations just by the bugs in the certificates they produce, but being
> able to make a positive ID would be really useful because by knowing how they
> (mis)interpret certain fields, your implementation could follow the same
> interpretation.

This way madness lies.

It leads to a situation where each vendor has their own subtly different
protocol, and each implementation needs to be able to talk all of these
protocols. Standards exist to save us from this fate!

Mike

Approved-By:  Paul Koning <[email-masked]>
Date:         Mon, 6 Apr 1998 11:47:27 -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: Paul Koning <[email-masked]>
Subject:      Re: [IETF-PKIX] Critical flag processing (was: Re: RE: Signed Label )
To: [email-masked]

>>>>> "Bob" == Bob Jueneman <[email-masked]> writes:

 Bob> Russ, I just recently joined this list, and I am not at all up
 Bob> to speed with the context,.............
 Bob> Please pardon my cross-posting to both lists, but I think the
 Bob> issue is important to both groups, and I don't know how many
 Bob> people are members of both.

Another problem with the PKIX mailer is that it is somewhere between
very difficult and impossible (depending on your mail reader) to tell
that a message has been cross-posted and if so, to where.

        paul

Approved-By:  [email-masked]
Date:         Sat, 4 Apr 1998 03:15:39 -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] Duct-taping X.509
To: [email-masked]

Yesterday, someone sent me a random collection of 11 certs which Netscape had
accumulated for him while web-browsing.  After picking them apart, I've come to
the conclusion that we're all doomed.  There will be a general breakdown in
society culminating in an armageddon-type war, after which a new civilisation
will evolve from ants.

Three of the certs he sent were the dime-a-dozen Verisign SSL client certs.
Out of the remaining 8, 6 didn't have valid encodings, one had an extension
which identified it as a CA cert and another which identified it as a non-CA
cert, and the remaining one, dating from three weeks ago, used the MD2 hash
algorithm which has been deprecated for quite some time.  All this was without
even checking the validity, constraints, and whatever else you need to check to
validate a cert.

As a result, and based on various comments I've received in response to recent
postings, I've come up with the following proposal to try and sort out this
mess.  This is (yet another) X.509 profile (and PKIX and S/MIME) profile which
should fix all the problems I've been pointing out recently.  It's a very rough
sketch, if anyone has any further suggestions please let me know.

Peter.

-- Snip --

The following doesn't modify (in an incompatible manner) any existing standard
or profile.  All it does is provide a consistent interpretation of other
standards and profiles, and provide a means of communicating that this
interpretation has been followed.

Canonical string encodings
--------------------------

Definition: Least inclusive encoding means encoding a string using the minimal
character set which is capable of encoding the string.  For DN's this means
using PrintableString if possible, then T61String if possible, then BMPString.

Strings are encoded using the least inclusive encoding

If IA5String is used, it is limited to printable (non-control) characters only
(making it equivalent to VisibleString).

If T61String is used, it is limited to ISO 8859-1 only.  No shifting or escape
codes are allowed.  Anything which doesn't fit into 8859-1 is encoded as a
BMPString.

Rationale: These rules provide an unambiguous encoding for DN's (and character
strings in general), and ensure that the nameConstraints extension works as
intended.

Validity Period Nesting
-----------------------

The validity period of a certificate must lie within the validity period of the
certificate which signed it.

Rationale: This ensures that the certificate will be regarded as valid by
software which enforces validity period nesting.

Alternative Name Usage
----------------------

Name components which are explicitly provided for in the issuer and subject
alternative name extensions (in particular email addresses and URL's) must be
encoded using the alternative name extension and not stuffed into a DN using
whatever OID is convenient.

Rationale: These things were never intended to be put into DN's anyway, but
were a kludge which appeared because X.509v1 didn't provide any other way of
specifying them.

Extension Handling
------------------

Definition: Processing an extension means acting on the information contained
in all the fields of the extension (for example processing a keyUsage extension
means enforcing the key usage constraints specified in the extension).

If an extension is marked critical:

  If the implementation cannot process it, the certificate should be rejected.

  If the implementation can process it, the implementation must process the
  extension.

If an extension is not marked critical:

  If it is included in the compliance level for this implementation, the
  implementation must process the extension.

  If it is not included in the compliance level for this implementation, it may
  handle the extension as it sees fit (pick a standard, decide on an
  interpretation of it, and go with that).

Rationale: This clarifies the handling of critical extensions, resolves the
ambiguities over how extensions should be handled, and guarantees that certain
types of important extensions will be handled properly.

Compliance
----------

Compliance with these recommendations is handled through use of a "secret
handshake extension" (for want of a better term), by which compliant CA's,
implementations, and certificates identify themselves.  When submitting a
certification request, an implementation can specify which compliance level it
handles and the CA can accept or reject it based on this.  When selecting a CA,
a user can check the CA's certificate(s) to see whether they comply, and to
what level.  When verifying a certificate, a CA or end user can again check the
certificate to find the level of compliance.  For example any level of
compliance will guarantee that DN's are encoded in an unambiguous manner,
allowing precise DN comparisons for things like nameConstraints enforcement.

secretHandshake EXTENSION ::= {
    SYNTAX SecretHandshakeSyntax
    IDENTIFIED BY id-ce-secretHandshake
    }

SecretHandshakeSyntax ::= SEQUENCE {
    complianceLevel     INTEGER DEFAULT (0),
    ...
    }

The compliance levels are as follows:

Level   Supports
-----   --------

0       Canonical string encodings
        Alternative name usage
        Validity period nesting
        Correct handling of critical extension
        Correct handling of extensions basicConstraints, keyUsage,
          issuerAltName, and subjectAltName

1       All of level 0 plus:
        Correct handling of extensions certificatePolicies, policyConstraints,
          and extendedKeyUsage

2       All of level 1 plus:
        Correct handling of extensions policyMappings, and nameConstraints

n       Other possibilties like reliance limits

These are just suggestions, an alternative is to have a SET OF properly
supported extensions, however this has the disadvantage that implementors can
pick and mix whatever they happen to feel like supporting.

Another alternative is to have groups of extensions, eg:

1       All of level 0 plus:
        Policy extensions (certificatePolicies, policyConstraints,
            policyMappings)

2       All of level 0 plus:
        Constraints (extendedKeyUsage, others?)

This one will require a bit string instead of an integer value, but it's
getting back to the pick and mix problem again.

Other Extensions
----------------

A while back someone made the comment that "It's good that <large vendor>
always puts the name of the MUA in their mail headers, because it allows you
to bypass <vendor>-specific bugs".  This leads to a second type of extension,
implementationWhichCreatedThis, which may be even more useful than the one
described above.  As it is, it's already possible to identify certain
implementations just by the bugs in the certificates they produce, but being
able to make a positive ID would be really useful because by knowing how they
(mis)interpret certain fields, your implementation could follow the same
interpretation.

Approved-By:  [email-masked]
Date:         Fri, 3 Apr 1998 20:22:26 -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] Tagging problems
Comments: To: [email-masked]
To: [email-masked]

>You wrote "the TBSCertificate has an 'EXPLICIT' keyword in the definition
>which means that everything in it has explicit tagging)".  Doesn't the
>EXPLICIT refer only to the tagging of that item?  I thought the only
>specification of implicit/explicit tagging which extended beyond the immediate
>definition was in the DEFINITIONS statement.  Can you quote chapter & verse
>for your broader interpretation?

Actually seeing an EXPLICIT at that point in the definition came as a
considerable surprise to me, because I couldn't remember it being allowed in a
type definition unless it's immediately preceded by a tag.  Assuming there was
some obscure part of the ASN.1 spec which I'd missed, I used the interpretation
which was necessary to make the ASN.1 work, which was that everything beyond
this point was EXPLICIT TAGS (if you assume that only that item has explicit
tags then everything else will use the module-wide setting of implicit tags,
making it incompatible with X.509v3).

In any case, the current usage is invalid ASN.1.

Is there any reason why the module, and the one in Appendix A, use implicit
tags?  Although I haven't gone through it with a fine-toothed comb, it looks
like if the IMPLICIT TAGS was removed the whole thing would suddenly work.

Peter.

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 3 Apr 1998 15:38:28 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Babelfish and names
Comments: To: [email-masked]
To: [email-masked]

43?  42?

Ha, ha, ha, ha, ha!

I never heard those jokes before. They're hysterical!  Got any more?

A. 47.

Q. What's a prime number between 6x8 and 7x7?

>>> Tony Bartoletti <[email-masked]> 04/03 2:11 PM >>>
At 03:44 PM 4/3/98 -0500, you wrote:
>> 47
>>
>> Bob
>
>Isn't that 43 ??
>
>Regards,
>Rich

That's right.  6 times 7.

___tony___

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 3 Apr 1998 15:34:05 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Suspended Certificate in CRL
Comments: To: [email-masked]
To: [email-masked]

It depends a lot on how CRLs are distributed.

CAs may issue CRLs on a periodic basis, whether one a day, once week,
or once a month, but the vast majority will be for relatively benign reasons,
such as marriage/change of name, or quit the company. Unless someone
is a purchasing agent, those aren't earth-shaking events.

However, if someone suspects a compromised key, there is nothing that
prevents the CA from issuing a emergency CRL ahead of time.  For those relying
parties who are only selling disk rags, it may not be worth the bother of
getting a new CRL list all that often, so they can afford the risk. But if someone
trys to buy the Hope diamond, the relying party had better go get the very
latest CRL list, just in case. In that eventuality, the suspended certificate
would show up in the list, and would be of inestimable value.

Bob

>Regarding suspension of certificates I would like to know the opinion
>and ideas of others. IMO, suspended certificates and CRLs don't go
>together very well.
>
>The problem is the following: Let's say the CA issues CRLs every day.
>Now somebody requests suspension of his certificate because he cannot
>find his smartcard right now. If you don't allow multiple CRLs at the
>same validity time frame, the suspended certificate will show up on the
>next CRL, which will be issued the next day. So it will take up to 24
>hours until the certificate is suspended. During this time he has either
>found his smartcard and wants his certificate to be reactivated or he
>didn't find it and wants his certificate to be revoked.
>
>If you allow multiple CRLs for the same validity time frame, i.e. the
>CA issues a CRL whenever somebody requests suspension or revocation
>you will never know if it is the latest CRL you are using for
>verification.
>
>So, only in case of online-verification where you ask the CA directly
>about the status of a certain certificate, suspension of certificates
>is useful.
>
>Objections ?
>
>Best regards, Petra Glöckner

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:  Tony Bartoletti <[email-masked]>
Date:         Fri, 3 Apr 1998 13:11: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] Babelfish and names
To: [email-masked]

At 03:44 PM 4/3/98 -0500, you wrote:
>> 47
>>
>> Bob
>
>Isn't that 43 ??
>
>Regards,
>Rich

That's right.  6 times 7.

___tony___

Approved-By:  Darryl Stal <[email-masked]>
Date:         Fri, 3 Apr 1998 15:53: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: Darryl Stal <[email-masked]>
Subject:      Re: [IETF-PKIX] Babelfish and names
To: [email-masked]

Sorry guys, you're both wrong....it's 42. :)

> > 47
> >
> > Bob
>
> Isn't that 43 ??
>
> Regards,
> Rich
>

Approved-By: [email-masked]
Date:         Fri, 3 Apr 1998 09:20:37 +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: Petra Glöckner <[email-masked]>
Subject:      Re: [IETF-PKIX] Suspended Certificate in CRL
To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msA77FE3A8E98F2E45C208007B
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Regarding suspension of certificates I would like to know the opinion
and ideas of others. IMO, suspended certificates and CRLs don't go
together very well.

The problem is the following: Let's say the CA issues CRLs every day.
Now somebody requests suspension of his certificate because he cannot
find his smartcard right now. If you don't allow multiple CRLs at the
same validity time frame, the suspended certificate will show up on the
next CRL, which will be issued the next day. So it will take up to 24
hours until the certificate is suspended. During this time he has either
found his smartcard and wants his certificate to be reactivated or he
didn't find it and wants his certificate to be revoked.

If you allow multiple CRLs for the same validity time frame, i.e. the
CA issues a CRL whenever somebody requests suspension or revocation
you will never know if it is the latest CRL you are using for
verification.

So, only in case of online-verification where you ask the CA directly
about the status of a certain certificate, suspension of certificates
is useful.

Objections ?

Best regards, Petra Glöckner
--------------msA77FE3A8E98F2E45C208007B
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

--------------msA77FE3A8E98F2E45C208007B--

Approved-By:  Rich Ankney <[email-masked]>
Date:         Fri, 3 Apr 1998 15:44: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: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] Babelfish and names
To: [email-masked]

> 47
>
> Bob

Isn't that 43 ??

Regards,
Rich

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 3 Apr 1998 12:39:58 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Babelfish and names
Comments: To: [email-masked]
To: [email-masked]

Trevor,

You might actually be onto something with your suggestion #2.
Suggestion #1 would be fine for all of us non-PC, white anglo-saxon males,
but might get us stoned the next time we visit Quebec.

I could buy making the DN an organization OID, either independently and
nationally registered under the joint-iso-ccitt arc, or subordinate to the OID
of the CA, for those organizations which are not nationally registered.

Then ALL of the display names, in whatever languages are desired,
could be presented in the subjectAltName, thereby neatly avoiding the
emotional and ethnocentric issue of of which name is "preferred" or
in the dominant language.

Presumably, the CA would still be responsible for the due diligence in
verifying right to use of all of the names, but unlike the case of DNs,
we could more easily include a Nonverified Subscriber Information flag
to indicate which names might not be "official."

Certainly if Peter Gutman's assessment is correct, even a Babelfish
would have extreme difficulty in comparing DNs in different character sets.

(Do you suppose all of the people on this list have read the Hitchhikers Guide
to the Galaxy, and know what we are talking about?  Yeah, probably.)

47

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

>>> Trevor Freeman <[email-masked]> 04/02 11:47 PM >>>
The prospect of Babelfish technology being available to chain building
software so that it could understand the five ways Vogon's have of writing
the same name is a nonsense. And if it where available it probably would be
imminently patented. I therefore have two suggestion to make, one mildly
radical, the other heresy.
Suggestion one.
If we stop thinking of the subject name as one which a user may understand,
we could easily embody the concept of an internal system name using a single
namespace that the certificate chain building software universally
understands, and an external display name with n namespaces in a certificate
which the user understands. The internal name would be the one used in chain
building by the software, the display name would only be used when
displaying a representation of the certificate to the user.
How do we do that?
Simple.
Mandate that the subject and issuer name be present and in English. That the
subject and issuer alternate names be present and are the default display
name of choice by certificate interpreting UI software and can be in any
language. Now anyone who understands English, just happens to understand the
system namespace but that is coincidence. Vogons would fine the subject DN a
mystery, but would understand the display name(altSubjectName). As long as
the certificate UI software always understands English, you will always be
able to display something about the certificate. If I happen to have the
Vogon version  installed, then I would get the Vogon name. We can define how
we represent the internal and display names in the directory in the LDAP
schema.
Suggestion two
If I have made the split of internal names and display names - why have
English(or any language) in the internal names at all? Software would work
just as well using DN comprising on decimal integers or OID's. e.g. c=US,
o=12345, ou = 12345. Now the names I use for chain building would therefore
consist of a well understood set of characters which are intrinsically case
insensitive and language independent. Now my name searching can always
reliable be done on binary blob comparisons.

Approved-By:  "Charles W. Gardiner" <[email-masked]>
Date:         Fri, 3 Apr 1998 09:47: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: "Charles W. Gardiner" <[email-masked]>
Subject:      Re: [IETF-PKIX] Tagging problems
Comments: To: [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

    You wrote "the TBSCertificate has an 'EXPLICIT' keyword in the definition
which means that everything in it has explicit tagging)".  Doesn't the EXPLICIT
refer only to the tagging of that item?  I thought the only specification of
implicit/explicit tagging which extended beyond the immediate definition was in
the DEFINITIONS statement.  Can you quote chapter & verse for your broader
interpretation?

Charlie Gardiner

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Thu, 2 Apr 1998 22:47: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: Trevor Freeman <[email-masked]>
Subject:      [IETF-PKIX] Babelfish and names
To: [email-masked]

The prospect of Babelfish technology being available to chain building
software so that it could understand the five ways Vogon's have of writing
the same name is a nonsense. And if it where available it probably would be
imminently patented. I therefore have two suggestion to make, one mildly
radical, the other heresy.
Suggestion one.
If we stop thinking of the subject name as one which a user may understand,
we could easily embody the concept of an internal system name using a single
namespace that the certificate chain building software universally
understands, and an external display name with n namespaces in a certificate
which the user understands. The internal name would be the one used in chain
building by the software, the display name would only be used when
displaying a representation of the certificate to the user.
How do we do that?
Simple.
Mandate that the subject and issuer name be present and in English. That the
subject and issuer alternate names be present and are the default display
name of choice by certificate interpreting UI software and can be in any
language. Now anyone who understands English, just happens to understand the
system namespace but that is coincidence. Vogons would fine the subject DN a
mystery, but would understand the display name(altSubjectName). As long as
the certificate UI software always understands English, you will always be
able to display something about the certificate. If I happen to have the
Vogon version  installed, then I would get the Vogon name. We can define how
we represent the internal and display names in the directory in the LDAP
schema.
Suggestion two
If I have made the split of internal names and display names - why have
English(or any language) in the internal names at all? Software would work
just as well using DN comprising on decimal integers or OID's. e.g. c=US,
o=12345, ou = 12345. Now the names I use for chain building would therefore
consist of a well understood set of characters which are intrinsically case
insensitive and language independent. Now my name searching can always
reliable be done on binary blob comparisons.

Approved-By:  [email-masked]
Date:         Thu, 2 Apr 1998 15:33:30 -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] Tagging problems
To: [email-masked]

One of the responses I got to my posting yesterday about extensions was a
question about tagging.  The following text is what's currently in the guide
about this subject, I hope this is accurate (the more you look at the tagging
which is used, the more confusing it gets.  Is the Appendix A definition
actually digestible by an ASN.1 parser, and does it produce valid certificate
encodings?).  Anyway, if there are errors in this please let me know, it's
rather difficult to follow the tagging:

-- Snip --

The default tagging for certificates varies depending on which standard you're
using.  The original X.509v3 definition uses the ASN.1 default of explicit
tags.  The PKIX definition is quite confusing because the ASN.1 definitions in
the appendices use TAGS IMPLICIT but mix in X.509v3 definitions which use
explicit tags.  Appendix A has such a mixture of implied implicit and implied
explicit tags that it's not really possible to tell what tagging you're
supposed to use.  Appendix B (which first appeared in draft 7, March 1998) is
better in that it starts with TAGS IMPLICIT, but switches to TAGS EXPLICIT
after the first few definitions (this isn't very obvious, the TBSCertificate
has an 'EXPLICIT' keyword in the definition which means that everything in it
has explicit tagging).  The definitions given in the body of the document use
explicit tags, and the definitions of TBSCertificate and and TBSCertList have
both EXPLICIT and IMPLICIT tags present.  To resolve this, you can either rely
entirely on Appendix B with the 'IMPLICIT TAGS' at the start either removed or
changed to 'EXPLICIT TAGS' (this doesn't change the encoding because nothing in
the section covered by implicit tagging is actually tagged) or use the X.509v3
definitions.  The SET definitions consistently use implicit tags.

-- Snip --

Would it be possible to switch to a unified use of explicit tags as per
X.509v3?  This would make things a lot easier to handle.

Peter.

Approved-By: [email-masked]
Date:         Thu, 2 Apr 1998 20:29:15 +0200
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] Suspended Certificate in CRL
To: [email-masked]

--openmail-part-024b43e1-00000001
Content-Type: multipart/alternative; boundary=openmail-part-024b43e1-00000002

--openmail-part-024b43e1-00000002
Content-Type: text/plain; charset=ISO-8859-1; name="Suspended"
Content-Disposition: inline; filename="Suspended"
Content-Transfer-Encoding: quoted-printable

>From IPKI documents (draft-ietf-pkix-ipki3cmp-05.txt), I can't figure
out how suspension and subsequent reactivation of a certificate shall be=

managed in a CRL.

I understand that certificate extensions
(draft-ietf-pkix-ipki-part1-06.txt par. 5.3.2) can dictate how a
suspended certificate shall be handled  by a relying party.  =20

Furthermore, draft-ietf-pkix-ipki-part4-02.txt par.4.4.4 mentions
certificate suspension among operational requirements to be addressed by=

a policy or CPS:
 ...
 * Circumstances under which a certificate may be suspended;
 * Who can request the suspension of a certificate;
 * Procedures to request certificate suspension;
 * How long the suspension may last;
  ...

My questions are:
a) shall a certificate be removed from a CRL when its suspension period
expires or after its reactivation?
b) why hasn't made provision for a reactivation message?

Thanks,
G.
=2D---------------------------------------------
Giorgio Gatto
Finsiel S.p.A.
Via Matteucci 34b
56126 Pisa (Italy)
+39 50 968675 phone
+39 50  968626 fax
mailto:[email-masked]
http:www.finsiel.it

--openmail-part-024b43e1-00000002
Content-Type: application/rtf; name="Suspended"
Content-Disposition: attachment; filename="Suspended"
Content-Transfer-Encoding: base64

--openmail-part-024b43e1-00000002--

--openmail-part-024b43e1-00000001

--openmail-part-024b43e1-00000001--

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 2 Apr 1998 08:19: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:      [IETF-PKIX] Critical flag processing (was: Re: RE: Signed Label )
Comments: To: [email-masked], [email-masked], [email-masked]
Comments: cc: [email-masked]
To: [email-masked]

Russ,

I just recently joined this list, and I am not at all up to speed with the context, but
I believe that throwing out all Critical attributes, either in certificates or
elsewhere, would be like throwing the baby out with the bath water.

My view of the Critical flag is that it important to protect the interests of the CA
or the signer of a message, or both, against unwarranted assumptions of
validity made on the basis of software which does not implement some
particular attribute. (Since NONE of the ietf standards in this area have done
a very good job of defining minimally, average, and fully compliant suites of
functions, implementors who cannot swallow everything whole all at once
are forced to pick and choose features without much guidance. And
unfortunately, the one or two ubiquitous browsers end up setting de facto
standards.  Hopefully now that Netscape has released their source code
into the public domain, some of these incompatibility issues can be
resolved more quickly.)

In particular, the various constraints, together with the CPS and user notice fields,
serve a very important purpose -- they are the equivalent of a legal notice or
caveat -- sort of a Miranda warning to the relying party.

In addition to the 'standard' attributes (which are confusing and sometimes
fluid enough), there is also the issue of propritetary attributes which may be
defined by some organization, and may or may not ever be well accepted
by the general vendor population. Without the Critical flag, a user who
believes that some attribute was particuarly important has no legal defense
against a relying party whose software ignores that attribute.

Take a Reliance Limit, of example.  I don't intend to get into a debate as to
whether that is a good concept or not, but its use in enshrined in several
state's statutes, and in the forthcoming release of Novell's PKIS (Public Key
Infrastructure Services) product we intend to define and support such an attribute
under our own OID, unless or until such time as the ietf cares to standardize such
a use.

The subscriber can either include the attributre or not, and if included, mark it
Critical or not, recognizing the potential interoperability problems that may cause.

But if the Reliance Limit is deemed to be quite important for that user's piece of
mind, interoperability problems IS PRECISELY WHAT IS DESIRED.

If someone's browser doesn't recognize the extension, it should reject the
certificate. The relying party can then decide whether to proceed with the
transaction, but the burden of proof and the burden of liability presumably
will have shifted to the relying party in that case, even if the orignator had been
unforgivably careless with his keys, for example.

It seems to me that the same would apply to a security label or other construct
in S/MIME. The originator is essentially telling the recipient, and perhaps
more importantly the user's agent, "If you can't understand and agree to my terms,
don't read, or at least don't believe my message."

I don't see how you can reasonably do without such a construct.

A random poll of ietf attendees is not sufficient justification for removing a critical
(no pun intended) feature. It IS sufficient justification to demand that we fix
the sloppy syntax and semantics that has been created between the X.509 v3,
PKIX, and S/MIME doucments.

Please pardon my cross-posting to both lists, but I think the issue is important
to both groups, and I don't know how many people are members of both.

Bob

>
>>>> Russ Housley <[email-masked]> 04/01 7:03 PM >>>
>Tim:
>
>Your note has a huge impact.  You point out that the message originator
>cannot ensure that the recipient will honor any attributbes in SignerInfo,
>even if they are marked critical.  For example, the recipient can ignore
>the critical attribute containing the security label.
>
>Here at the IETF meeting, I have asked several people about the usefulness
>of critical attributes.  Of the people that I polled, no one supports them.
> At this point, I am planning to remove critical attributes from the next
>draft of the CMS document.
>
>Russ
>
>At 10:28 AM 3/31/98 +0100, Tim Dean wrote:
>>Russ,
>>>>What happens if a recipient receives a forwarded message that include a
>>>>security policy in the eSSSecurityLabel  that he/she in does not
>understand,
>>>>is that still an error?
>>
>>>Absolutely.  The security label must be marked critical, so the inability
>>>to process the critical attribute must cause an error to be reported to the
>>>user.
>>
>>>>I think the proposed text will mislead implementations to always discarding
>>>>the message if a security policy is unknown.  I do not think that is right.
>>
>>>We disagree.  Rule-based access control cannot be enforced if the recipient
>>>is allowed to ignore the security label.
>>
>>Two thoughts:
>>
>>1.  Insisting that the UA software parse and understand the label before
>showing the message to the user
>>raises serious denial-of-service issues.  There are many circumstances
>when operational necessity
>>demands label-based access control is over-ridden - certainly on reception
>in a distributed system.
>>There are likely to be many, many label formats floating around out there,
>and systems should not stop
>>working just because they don't recognise all of them.
>>
>>2. I am somewhat doubtful that access control in the recipient's user
>agent is going to add a jot of Real
>>Security in practice.  It would surely be extremely unwise to place any
>kind of reliance on it.  Any
>>Computer Scientist worth his salt is quickly going to figure how to
>by-pass this check and read
>>everything which arrives in his computer.  (And he is probably the kind of
>person you didn't want to
>>unintentionally send a message to anyway!)
>>
>>Therefore I think I must agree with John R's suggestion on this: or at
>least make the it a configurable
>>option dependent on security policy.  Also, ESS should probably contain a
>health warning about relying
>>on recipient side access control processing.  By all means check message
>labels on transmission and at
>>points along the path: for example just before the message is about to
>exit your organisation.  Hopefully
>>the label semantics are understood at least that far.  After that I
>suspect it may be too late.
>>
>>Tim
>>
>>-----------------------------------------------
>>Tim Dean
>>Defence Evaluation & Research Agency
>>Malvern
>>United Kingdom
>>telephone:      +44-1684-894239
>>facsimile:      +44-1684-896113
>>e-mail:         [email-masked]
>>----------------------------------------------------
>>
>>
>>
>>
>>John Ross wrote:
>>>What happens if a recipient receives a forwarded message that include a
>>>security policy in the eSSSecurityLabel  that he/she in does not understand,
>>>is that still an error?
>>
>>Absolutely.  The security label must be marked critical, so the inability
>>to process the critical attribute must cause an error to be reported to the
>>user.
>>
>>>I think the proposed text will mislead implementations to always discarding
>>>the message if a security policy is unknown.  I do not think that is right.
>>
>>We disagree.  Rule-based access control cannot be enforced if the recipient
>>is allowed to ignore the security label.
>>
>
>>>All I think needs to be done is to leave such decisions to local policy;
>>>Thus reword your text as..
>>>
>>>"Receiving agents SHOULD have a local policy which specifies
>>>what action is taken when an eSSSecurityLabel is received which
>>>includes a security-policy-identifier that the processing software
>>>does not recognize."
>>>
>>>
>>>If think there is a need to specify default handling, then It should be to
>>>ignore security labels when the policy is not understood.
>>
>>Completely disagree!
>>
>>>Also, I still think that the security policy should not be optional.
>>
>>Wow.  We agree on this one.  The syntax that we are using comes from X.411.
>> In X.411, this field is optional, and we are trying to maintain
>>compatibility.  I suggest that we use english text to state that the
>>security policy must be present.
>>
>>-- Russ
>>

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:         Thu, 2 Apr 1998 09:32: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
Comments: To: [email-masked]
To: [email-masked]

Peter Gutmann wrote:
>
> Moshe Litvin <[email-masked]> writes:
>
> >Unless explicitly specified an application must process any extension it
> >understands regardless of the criticality flag.
>
> This isn't expressed very clearly in the current PKIX text.

Indeed.

>  What it says
> (section 4.2) is that "CA's are required to support <various constraint
> extensions>",

It is not all that it says.When section 4.2 defines the critical flag al
l it says two things about it:

1. A certificate using system (an application
   validating a certificate) must reject the certificate if it
   encounters a critical extension it does not recognize.
2 A non-critical extension may be ignored if it is not recognized.

(the numbering is not from the draft).

Both sentences apply to application that do not recognize an extension,
I havn't seen in PKIX permision for an application to disregard a known
extension just because it is marked not-critical.

> The X.509v3 draft says (in various places) that the
> extensions are advisory only.  In either case it implies that you can recognise
> whatever you like, but there's no requirement to act on it.

I would like to see the paragraphs that led you to this conclusion. More
specifically I would like to see where it is written that in the general
case an application that recognise an extension can decide weather to
honor it or not depending on the critical flag.

By the general case I meen a text that is not related to a specific
extension

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:         Wed, 1 Apr 1998 22:18:00 -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
To: [email-masked]

After getting a number of responses to my comments on cert extension handling,
and finding that for n respondents there are about n+3 interpretations of how
extensions should be handled, I've updated the style guide to include the
following on cert extensions.  As usual, I'd welcome comments on this.

Peter.

Extensions
----------

Extensions ::= SEQUENCE OF Extension

Extension ::= SEQUENCE {
    extnid                  OBJECT IDENTIFIER,
    critical                BOOLEAN DEFAULT FALSE,
    extnValue               OCTETSTRING
    }

X.509 certificate extensions are like a LISP property list: an
ISO-standardised place to store crufties.  Extensions can consist of key and
policy information, certificate subject and issuer attributes, certificate
path constraints, CRL distribution points, and private extensions.

X.509 Amendment 1 of 30 June 1996 and the X.509v3 draft of June 1997 contains
the ASN.1 formats for the standard V3 Certificate, V2 CRL and V2 CRLEntry
extensions.  In theory you should be able to handle all of these, but there
are large numbers of them and some may not be in active use, or may be
meaningless in some contexts.

                    'It's called a shovel,' said the Senior Wrangler.  'I've
                    seen the gardeners use them.  You stick the sharp end in
                    the ground.  Then it gets a bit technical'
                        -- Terry Pratchett, "Reaper Man"

Extensions are encoded with IMPLICIT tags, it's traditional to specify this in
some other part of the standard which is at least 20 pages away from the
section where the extension is actually defined.

There are a whole series of superseded and deprecated OIDs for extensions,
often going back through several generations.  Older software and certificates
will still use obsolete OIDs, any new software should try and emit attributes
tagged with the OID du jour rather than using deprecated OIDs.

We can break extensions into two types, constraint extensions and
informational extensions.  Constraint extensions limit the way in which the
key in a certificate, or the certificate itself, can be used.  For example
they may limit the key usage to digital signatures only, or limit the DN's for
which a CA may issue certificates.  The most common constraint extensions are
basic constraints, key usage and extended key usage, certificate policies
(modified by policy mappings and policy constraints), and name constraints. In
contrast, informational extensions contain information which may or may not be
useful for certificate users, but which doesn't limit the certificate use in
any way.  For example an informational extension may contain additional
information which identifies the CA which issued it.  The most common
informational extensions are key identifiers and alternative names.

The processing of these extensions is mostly specified in three different
standards, which means that there are three more or less mutually incompatible
ways to handle them.  In theory, constraint extensions should be enforced
religiously, however the three standards which cover certificates differ both
in how they specify the interpretation of the critical flag, and how they
require constraint extensions to be enforced.

                    We could not get it out of our minds that some subtle but
                    profoundly alien element had been added to the aesthetic
                    feeling behind the technique.
                        - H.P.Lovecraft, "At the Mountains of Madness".

The original X.509v3 specification requires that a certificate be regarded as
invalid if an unrecognised critical extension is encountered.  As for the
extension itself, you can use whatever interpretation you choose (that is, the
extension is specified as being of an advisory nature only).  This means that
if you encounter constraints which require that a key be used only for digital
signatures, you're free to use it for encryption anyway.  If you encounter a
key which is marked as being a non-CA key, you can use it as a CA key anyway.
The X.509v3 interpretation of extensions is a bit like the recommended 130kmh
speed limit on autobahns, the theoretical limit is 130, you're sitting there
doing 180, and you're getting overtaken by Porsches doing about 250.  Using
this interpretation, it's mostly pointless including any extensions because
everyone is free to ignore them.

The second interpretation of extensions comes from the IETF-PKIX X.509
profile. Like X.509v3, this also requires that a certificate be regarded as
invalid if an unrecognised critical extension is encountered.  However it
seems to imply that a critical extension must be processed, and probably
considers non-critical extensions to be advisory only.  Unfortunately the
wording is ambiguous enough that a number of interpretations exist.  Section
4.2 says that "CA's are required to support <constraint extensions>", but the
degree of support is left open, and what non-CA's are supposed to do isn't
specified. The paragraph which follows this says that implementations "shall
recognise extensions", which implies that you can recognise whatever you like,
but there's no requirement to actually act on it.

The third interpretation comes from S/MIME, which requires that
implementations correctly handle a subset of the constraint and informational
extensions.  However, as with IETF-PKIX, "correctly handle" isn't specified,
so it's possible to "correctly handle" an extension as per X.509v3, as per
IETF-PKIX (choose the interpretation you prefer), or as per S/MIME, which
leaves the issue open (it specifies that implementations may include various
bits and pieces in their extensions, but not how they should be enforced).
S/MIME seems to place a slightly different interpretation on the critical
flag, limiting its use to the small subset of extensions which are mentioned
in the S/MIME spec, so it's not possible to add other critical extensions to
an S/MIME certificate.

Finally, the waters are further muddied by CA policies, which can add their
own spin to the above interpretations.  For example the Verisign CPS, section
2.4.3, says that "all persons shall process the extension [...] or else ignore
the extension", which would seem to cover all the bases.

The whole issue is complicated by the fact that some of the most common
implementations will reject a certificate which contains critical constraint
extensions, so that even if you interpret the critical flag to mean "this
extension must be enforced" (rather than just "reject this certificate if you
don't recognise the extension"), you can't use it because it will render the
certificate unusable.  These implementations provide yet another
interpretation of the critical flag, "reject this certificate if you encounter
a critical extension".

                    Zaphod stared at him as if expecting a cuckoo to leap out
                    of his forehead on a small spring.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

Because of this confusion, it's probably impossible to include a set of
constraint extensions in a certificate which will be handled properly by
different implementations.

The best interpretation of constraint extensions is that if a certificate is
marked as an X.509v3 certificate, constraints should always be enforced.  This
includes enforcing implied settings if the extension is missing, so that a
certificate being used in a CA role which has no basicConstraints extension
present should be regarded as being invalid.  However even if one of the
standards is reworded to precisely define extension handling, there are still
plenty of other standards and interpretations which can be used.  The only
solution to this is to include a critical policy extension which requires that
all constraint extensions up and down the cert chain be enforced.  Going back
to the autobahn analogy, this mirrors the situation at the Austrian border,
where everyone slows down to the strictly enforced speed limit as soon as they
cross the border.

Currently the only way to include a constraint enforcement extension is to
make it a critical policy extension.  This is somewhat unfortunate since
including some other random policy may make the extension unrecognisable,
causing it, and the entire certificate, to be rejected (as usual, what
constitutes an unrecognisable extension is open to debate: if you can process
all the fields in an extension but don't recognise the contents of one of the
fields, it's up to you whether you count this as being unrecognisable or not).

A better alternative would be to define a new extension, enforceConstraints:

enforceConstraints EXTENSION ::= {
    SYNTAX EnforceConstraintsSyntax
    IDENTIFIED BY id-ce-enforceConstraints
    }

EnforceConstraintsSyntax ::= BOOLEAN DEFAULT FALSE

This makes the default setting compatible with the current "do whatever you
feel like" enforcement of extensions.  Enforcing constraints is defined as
enforcing all constraints contained in constraint extensions, incuding implied
settings if the extension is missing, as part of the certificate chain
validation process (which means that they should be enforced up and down the
cert chain).  Recognising/supporting/handling/<whatever other wording is used
in standards> an extension is defined as processing and acting on all
components of all fields of an extension.

                    'Where was I?' said Zaphod Beeblebrox the Fourth.
                    'Pontificating' said Zaphod Beeblebrox.
                    'Oh yes'.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

Just to mention a further complication with critical extensions, there are
instances in which it's possible to create certificates which are always
regarded as being invalid due to conflicts with extensions.  For example a
generation n-1 critical extension might be replaced by a generation n critical
extension, resulting in a mixture of certs with generation n-1 extensions,
generation n-1 and generation n extensions (for compatibility) and
(eventually) generation n extensions only.  However until every piece of
software is upgraded, generation n-1 software will be forced to reject all
certs with generation n extensions, even the (supposedly)
backwards-compatibile certs with both generations of extension in them.

                    'Mr.Beeblebrox, sir', said the insect in awed wonder,
                    'you're so weird you should be in movies'.
                        -- Douglas Adams, "The Restaurant at the End of the
                           Universe.

Approved-By: [email-masked]
Date:         Wed, 1 Apr 1998 10:12:01 -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
To: [email-masked]

Moshe Litvin <[email-masked]> writes:

>Unless explicitly specified an application must process any extension it
>understands regardless of the criticality flag.

This isn't expressed very clearly in the current PKIX text.  What it says
(section 4.2) is that "CA's are required to support <various constraint
extensions>", but the degree of support is left open, and this only covers what
CA's can do.  The following paragraph says that implementations "shall
recognise extensions", and the X.509v3 draft says (in various places) that the
extensions are advisory only.  In either case it implies that you can recognise
whatever you like, but there's no requirement to act on it.  It would help if
the degree of "support" for an extension were made explicit in the text, ie
explicitly state that conformant implementations must enforce any constraint
extensions which are present, and perhaps point out that this differs markedly
from X.509v3 in which the requirement to enforce the constraint is absent.

I can see that this is going to take a long writeup in the style guide to cover
the intricacies of extension handling and straight X.509v3 vs PKIX.

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

Presumably a ca=TRUE basicConstraint will be accompanied by a
keyUsage=keyCertSign | crlSign constraint (I would hope that a CA's cert
signing key isn't goint to be used for, say, key exchange purposes).  If you
follow the X.509v3 text, you're free to ignore this and use it for key
exchange/data encipherment/whatever anyway.  If the constraint is a NOP (as in
your example) then it doesn't matter, but where it really is a constraint
present, you want to be sure it's going to be enforced by implementations
which encounter it.

Bob Jueneman <[email-masked]> added:

>Constraint extensions are optional unless indicated by the Critical flag.

That's certainly what X.509v3 says, and PKIX seems to imply as well (depending
on how you interpret "shall recognise" - see the comments above).

I'll do a longer writeup which summarises the different points of view later
today after I've had some sleep, and try to think up a unified solution which
is compatible with current implementations (if that's possible).

Peter.

Approved-By:  Moshe Litvin <[email-masked]>
Date:         Wed, 1 Apr 1998 19:37:47 +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: Bob Jueneman <[email-masked]>
To: [email-masked]

Just to be on the same page PKIX part 1 specify in section 4.2:

   Each extension in a certificate may be designated as crit-
   ical or non-critical.  A certificate using system (an application
   validating a certificate) must reject the certificate if it
   encounters a critical extension it does not recognize.

That is the draft gives permission to ignore the extension only if you
don't understand it.

Bob Jueneman wrote:
>
> I disagree.
> >
> >>>> Moshe Litvin <[email-masked]> 04/01 12:14 AM >>>
>
> >> 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.
>
> I STRONGLY disagree. From my perspective, one of the most important
> reasons for defining the Critical flag was to force applications to reject
> a certificate if they didn't understand some attribute which the subscriber
> or CA thought was particularly important.. In particular, a user notice field,
> a reliance limit field, or some other constraint which either
> the CA or the subscriber feels is absolutely crucial for her protection.

There is a connection between important and critical, but it is not the
same. An extremely important extension can be marked as not critical
without any compromise to the security.

Let me return to my example of a basicConstraint extension with ca=TRUE
and no pathLenConstraint.

This is a very important certificate because it gives it holder
"absolute" power. If an application consider every certificate without
basic constraint as a non CA certificate (a reasonable approach) that
extension gives him invaluable information.

But there is no loss of security if an application ignores the
extension.

That is important does not mean critical, while the opposite is probably
true, there is no need in making an extension critical if it is of no
importance.

> >> 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.
>
> No, it isn't.  Constraint extensions are optional unless indicated by the
> Critical flag.

Where does it says that?

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:  Bob Jueneman <[email-masked]>
Date:         Wed, 1 Apr 1998 06:52: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]

I disagree.
>
>>>> Moshe Litvin <[email-masked]> 04/01 12:14 AM >>>

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

I STRONGLY disagree. From my perspective, one of the most important
reasons for defining the Critical flag was to force applications to reject
a certificate if they didn't understand some attribute which the subscriber
or CA thought was particularly important.. In particular, a user notice field,
a reliance limit field, or some other constraint which either
the CA or the subscriber feels is absolutely crucial for her protection.

The various constraints, of course, potentially fall into that category, but
there are interoperability  issues with existing software that have to be
taken into account.
>
>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.

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

This brings up a whole 'nother issue. what does it mean to be PKIX compliant?
My interpretation of the PKIX spec is that it is a very long laundry list of nice to have
features, but I claim that I could be PKIX compliant and only implement a relatively
small subset of those features.  Basically, the only thing I _really_ have to do
is recognize and honor the Critical flag.

I'm not necessarily espousing that philosophy, only pointing out that that is
how I read the spec. Certainly if everything in the spec is supposed to be
mandatory, I'm going to have to get up on my high horse and start objecting t
o some things a lot more loudly, starting with the use of both Teletex and
Universal strings, the entire section of X.400 attributes (which are completely
useless from the standpoint of international applications), and the complete
lack, so far, of any agreed upon set of RDN component attributes and their
appropriate schemas, etc, etc.

If the standard is going to address what it means to be PKIX-compliant in
terms of what portions other than the very basic elements plus the Critical
flag, I believe we are going to have to define some Category A, B, and C
elements. We probably need to do that anyway -- the current spec is rich
with function, and other than a few instances nice things to have, but it
is unlikely that anyone is going to implement either a CA toolkit or a relying party
validation module that would include all of those functions in the first release.

The spec needs to be broken down into modular chunks, for the sake of
interoperability.

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

No, it isn't.  Constraint extensions are optional unless indicated by the
Critical flag.  If you want to change the spec so that all such constraints
are marked with the Critical flag, that's worth discussing. But that's not
what it says now.

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