Subject: RE: OCSPv2: 02: certHash is not unique

From: Ambarish Malpani <[email-masked]>
Date: Mon, 26 Mar 2001 08:21:48 -0800

Hi James,
    I agree with you completely.

The other reason why using the certHash is not  a good idea, is
because the only entity that can respond to the request is the CA. Also, to
be able to respond, a responder needs access to data in a
format that isn't really available to anybody today - unclear why
we would want to standardize on such a format.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Manger, James H [mailto:[email-masked]]
Sent: Sunday, March 25, 2001 10:15 PM
To: [email-masked]'
Subject: OCSPv2: 02: certHash is not unique

Comment on draft-ietf-pkix-ocspv2-02.txt

In section 3.1.2 Certificate Identification, the ReqCert type includes a
certHash field as one option for a client to identify a certificate.  The
syntax for the certHash field is an OCTET STRING.
There is no text describing the certHash field.  I guess it holds a hash of
the certificate.  I guess the hash is calculated over the DER-encoding of
the complete certificate.  There seems to be no indication of the hash
algorithm - perhaps it is always SHA-1.
I guess a certHash value is supposed to match the certificate "fingerprint"
or "thumbprint" that the browsers display.  A browsers relies on a
thumbprint unambiguously identifying a single certificate.  OCSPv2, on the
other hand, relies on a certificate having a unique certHash value.  These
properties - unambiguity and uniqueness - are quite different.  It is
reasonable to assume a certificate thumbprint is unambiguous, but it is
dangerous to assume it is unique for the certificate.
There are a number of ways to alter the encoding of the unsigned portion of
a certificate (signatureAlgorithm field, signatureValue field and outer most
tags).  Such modification don't alter the signed portion so the signature
remains valid, but they do change the thumbprint.  An attacker can modify
the bytes (hence thumbprint) without modifying the semantics of a
certificate.
For instance, consider omitting the NULL signature parameters associated
with sha1WithRSAEncryption in the signatureAlgorithm field.  It is not
unreasonable for a system to still accept such a certificate (particularly
with the "be strict with what you send but lenient with what you receive"
philosophy).  Yet the bytes do change so the thumbprint also changes.
An OCSPv2 responder may have one thumbprint of a certificate in its table of
revoked certificates, but would return "good" if a different thumbprint for
the same certificate appeared in the certHash field.
A better thumbprint (that is unique for a certificate) is a hash over only
the signed portion of the certificate (i.e. the same hash that goes into the
signature).
SOLUTION:  Delete the certHash field from the ReqCert type.

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 27 Mar 2001 11:15:07 +1000

That's fine.

This is probably the best approach.  It offers potentially useful
flexibility without introducing extra security issues for certificate
parsers.  Explicitly stating that certHash is only likely to be appropriate
in selected environments may diffuse some criticism.

----------
From: Michael Myers [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Tuesday, 27 March 2001 10:51

..I'd prefer to maintain certHash a option but composed in the manner you
describe..

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 29 Mar 2001 05:58:39 (NZST)

Manger, James H <[email-masked]> writes:

>the certificate.  I guess the hash is calculated over the DER-encoding of the
>complete certificate.  There seems to be no indication of the hash algorithm -
>perhaps it is always SHA-1.

The implication was that it's calculated the same way as the "fingerprint"
displayed by a web browser, although I guess it'd help to have this stated
explicitly in case there's anything out there which doesn't already do this.

>There are a number of ways to alter the encoding of the unsigned portion of a
>certificate (signatureAlgorithm field, signatureValue field and outer most
>remains valid, but they do change the thumbprint.  An attacker can modify the
>bytes (hence thumbprint) without modifying the semantics of a certificate.

But the same can happen for a "fingerprint" without it ever having been raised
as an issue in the past.  "Fingerprints" have been used for years without any
problems, they're widely recognised, and they're present in web browsers and a
lot of related software (I added them to my code ages ago in response to user
requests, some CA or cert policies apparently require matching of cert
fingerprints by users during the cert issuance confirmation process).  It's a
widely-used and -recognised way of identifying a cert which has been around for
years, unless there's a demonstrated, real problem (rather than a hypothetical
one) I don't see why it should be disallowed in OCSP.

Peter.

---

From: "Carlin Covey" <[email-masked]>
Date: Wed, 28 Mar 2001 12:27:58 -0700

Peter and Jim,

I am quite content with the suggestion that Jim made concerning
computing the certHash over only the signed portions of the
certificate.  However, I concur with Peter that the attack Jim
postulated is not much of a threat.  (A long-winded rationale follows.)

------

I'm no cryptographer (I don't even play one on the web),  but it
seems to me that the issue concerns what I believe is a form of
"birthday attack."  In a birthday attack, the attacker attempts
to find two different bit strings that yield the same value under
a given transformation (such as a hash or digital signature), with
the intent of fooling someone else into accepting the wrong bit
string.  In the certHash case, the attacker faces an even harder
problem, because he is not trying to find just any two bit strings that
produce the same hash, he is trying to find a second bit string that
produces the same hash as another bit string that he cannot change
(the bit string that the OCSP responder used when computing the hash).
In fact, the attacker has an even harder problem than this.  He can
change only certain bits of the "substitute" bit string (the bits that
he doesn't need to work his evil deeds). He can, however, choose various
"good" certificates to use as the substitute string.  (After all, he's
looking for any "good" certificate whose certHash matches the certHash of
his carefully-modified "bad" certificate.)

certHash uses SHA-1, which (and here we could use some help from
a cryptographer) I believe was specifically designed to make
birthday attacks time consuming by making it difficult to predict
what bits to change in the input bit string to yield a particular
value for the SHA-1 hash (hence the "S", standing for "security",
in "SHA-1").  So the certHash attacker must do an exhaustive search
of the possible combinations of the "don't care" bits in his bad
certificate for a SHA-1 hash that matches the SHA-1 hash of a
certificate that the OCSP responder will report as good.  Not only
would such an attack be time-consuming, but, within the constraints
imposed by the need to create a reasonable-looking bad certificate,
it is quite likely that the exhaustive search will be in vain.

Cryptographers, please correct any errors I have made.

Regards,

Carlin

____________________________

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 29, 2001 5:59 AM
To: [email-masked]
Subject: Re: OCSPv2: 02: certHash is not unique

>the certificate.  I guess the hash is calculated over the DER-encoding of
the

>There are a number of ways to alter the encoding of the unsigned portion of
a
>remains valid, but they do change the thumbprint.  An attacker can modify
the
>bytes (hence thumbprint) without modifying the semantics of a certificate.

But the same can happen for a "fingerprint" without it ever having been
raised
as an issue in the past.  "Fingerprints" have been used for years without
any
problems, they're widely recognised, and they're present in web browsers and
a
lot of related software (I added them to my code ages ago in response to
user
requests, some CA or cert policies apparently require matching of cert
fingerprints by users during the cert issuance confirmation process).  It's
a
widely-used and -recognised way of identifying a cert which has been around
for
years, unless there's a demonstrated, real problem (rather than a
hypothetical
one) I don't see why it should be disallowed in OCSP.

Peter.

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 29 Mar 2001 18:05:16 +1000

Peter & Calin,

>> An attacker can modify the bytes (hence thumbprint)
>> without modifying the semantics of a certificate. 

> But the same can happen for a "fingerprint" without it ever having been
raised as an issue in the past 

This is NOT an issue for the way browsers currently use "fingerprints", but
it IS an issue for OCSP.  These two uses rely on DIFFERENT properties of the
certificate id.

In the current browser use, such an attack (modifying the "fingerprint", but
not the certificate) would mean the user fails to recognise that the
certificate is one they trust.  Hence, the user will treat the trusted
certificate as untrusted.  This is not a security violation.  It is a mild
(and irrelevant) form of Denial of Service.

In the OCSP use, such an attack would mean a relying party and OCSP server
would calculate different "fingerprints" for the same revoked certificate.
An OCSP server with a list of "fingerprints" of revoked certificates, would
fail to match the "fingerprint" in the OCSP request and would not return
"revoked".  This is a security violation.

Note: If the OCSP server kept a list of "fingerprints" of un-revoked
certificates (and assumed all other were revoked) the attack would not
succeed.  However, this is not how revocation is usually implemented.

[In some vague sort of pseudo UML]
Browser use assumes:  (1)    id  *------1  certificate
OCSP use assumes:     (2)   id    1-----*  certificate

A hash of the DER-encoded complete certificate - "fingerprint" - satisfies
(1) but not (2).

Calin, 

This issues has nothing to do with birthday attacks and nothing to do with
the security of SHA-1.

---

From: "Carlin Covey" <[email-masked]>
Date: Thu, 29 Mar 2001 13:26:46 -0700

Jim,

I just realized that I did not CC the PKIX list.  I guess my confusion about
the
issue stemmed from my interpretation of a couple of sentences in your first
message in the thread:

"... These properties - unambiguity and uniqueness - are quite different.
   It is reasonable to assume a certificate thumbprint is unambiguous,
   but it is dangerous to assume it is unique for the certificate."

I came up with two interpretations for "... unique for the certificate."

(1) for every certificate there is just one hash
(2) there are no two certificates with the same hash

Interpretation (1) matched my working definition of "unambiguous," so I
attached interpretation (2) to "unique."  And it is quite true that one
should
not assume that there are no two certificates with the same hash (the
size of the hash value space being much smaller than the size of the
input space).  So I tried to guess why you said that it is dangerous,
and I came up with the "birthday attack" scenario.  That proved to be
an incorrect guess.

- Carlin

  -----Original Message-----
  From: Carlin Covey [mailto:[email-masked]]
  Sent: Thursday, March 29, 2001 10:33 AM
  To: Manger, James H
  Subject: RE: OCSPv2: 02: certHash is not unique

  Jim,

  Ahh!  I see.  I thought the attack was an attempt to alter the certificate
  so that the hash value would match a good certificate, thereby causing
  the responder to return a "good" response.  In the case that you cite
  the responder should return a response of "unknown" (since it is highly
  unlikely that the hash would match any real certificate due to the
  "anti-birthday attack"  feature of SHA-1).  This would only a security
  issue if the Relying Party uses the certificate anyway.

  But I see your point.  This would be a security issue if the responder
  calculated and stored certHash  for all the certificates that it knows
  to be revoked, and returned a response of "not revoked" if the target
  certHash was not found on its stored list.  This would happen whether
  the bits of the target certificate were altered intentionally or by error.
  The "security considerations" section of the internet-draft should point
  out that this is not an acceptable implementation. The response
  should always "fail-safe" to "unknown".

  Regards,

  Carlin

  -  Carlin Covey
     Cylink Corporation

    -----Original Message-----
    From: Manger, James H [mailto:[email-masked]]
    Sent: Thursday, March 29, 2001 1:05 AM
    To: [email-masked]'
    Subject: RE: OCSPv2: 02: certHash is not unique

    Peter & Calin,

      > But the same can happen for a "fingerprint" without it ever having
been raised as an issue in the past

    This is NOT an issue for the way browsers currently use "fingerprints",
but it IS an issue for OCSP.  These two uses rely on DIFFERENT properties of
the certificate id.

    In the current browser use, such an attack (modifying the "fingerprint",
but not the certificate) would mean the user fails to recognise that the
certificate is one they trust.  Hence, the user will treat the trusted
certificate as untrusted.  This is not a security violation.  It is a mild
(and irrelevant) form of Denial of Service.

    In the OCSP use, such an attack would mean a relying party and OCSP
server would calculate different "fingerprints" for the same revoked
certificate.  An OCSP server with a list of "fingerprints" of revoked
certificates, would fail to match the "fingerprint" in the OCSP request and
would not return "revoked".  This is a security violation.

    A hash of the DER-encoded complete certificate - "fingerprint" -
satisfies (1) but not (2).

    Calin,

    This issues has nothing to do with birthday attacks and nothing to do
with the security of SHA-1.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 30 Mar 2001 10:45:23 (NZST)

"Manger, James H" <[email-masked]> writes:

>would calculate different "fingerprints" for the same revoked certificate. An
>OCSP server with a list of "fingerprints" of revoked certificates, would fail
>to match the "fingerprint" in the OCSP request and would not return "revoked".
>This is a security violation.

OK, so you can turn "revoked" into "unknown".  Exactly the same effect can be
obtained by flipping a single bit in the ID in the OCSP query (which isn't
integrity-protected) as the TCP packet floats past.  I can certainly see your
point, but it's just another way of doing what you can already do (in fact by
taking advantage of the fact that the average peecee's clock can be out by
hours or even days you can go all the way and turn a "revoked" into an "OK" by
replaying old queries, so there are far more serious attacks than that).  The
vulnerability you've pointed out doesn't seem any worse than existing ones.

(Another thing about re-coding certs into non-DER forms, if you take a cert and
 BER-encode it by using an indefinite-length encoding, Windows won't even
 recognise the resulting object as a certificate any more, let alone be able to
 perform an OCSP query with it).

Peter.

---

From: [email-masked]
Date: Fri, 30 Mar 2001 11:05:29 +0100

>>In the OCSP use, such an attack would mean a relying party and OCSP
server

>integrity-protected) as the TCP packet floats past.

Erm, no you can't.  This latter attack would be spotted by the client, who
should match the certificate identifiers in the response to those in the
original request.

This is not true of the problem James M highlights.  A client could very
easily fall in this trap accidentally, even without anyone acting
maliciously, if the server has the default-OK behaviour Carlin describes.

>This would be a security issue if  the responder
>calculated and stored certHash  for all the  certificatesthat it knows
>certHash was not found on itsstored  list.  This would happen whether
>out  that this is not an acceptableimplementation. The  response

Agreed.

>The vulnerability you've pointed out doesn't seem any worse than existing
ones.

Even if this were true, it's hardly a logical reason not to address it!

Regards,

Jonathan
------------
Dr Jonathan Tuliani
www.symbian.com

**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [email-masked] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************

---

From: Ryan Hurst <[email-masked]>
Date: Sat, 31 Mar 2001 19:04:07 -0800

I agree, in our interoperability testing we have found that even with a
protocol with as few MAYs as OCSPv1 that there are a still a number of very
interesting non-standard ways that others have implemented their OCSP
clients/servers. For this reason I am one for keeping the MAYs to a minimum,
particularly for something as core as identification of the certificate in
question.

Ryan M. Hurst
Manager Solutions Engineering

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Thursday, March 29, 2001 2:09 AM
To: [email-masked]
Subject: RE: OCSPv2: 02: certHash is not unique

Mike,
    As I have said a few times before, I strongly oppose the
idea of using certHash as a method of identifying the certificate
whose status you want to check. It forces the responder to have
access to information that is not normally available to most
responders - even those run by most CAs (AFAIK).

I don't know that we are saving all that many bytes by using
certHash as opposed to certID.

It just doesn't make sense to me that we provide 5-6 different
ways of identifying a certificate in OCSP - I think it will
lead to a lot more interop problems, without buying us any
additional functionality.

Regards,
Ambarish

> From: Michael Myers [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2001 5:59 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Peter,
> After some correspondence, I've come to the same conclusion 
> despite my prior
> proposal to Jim.  The high-level intent of the presence of an 
> option to
> hash/fingerprint the cert was to enable alignment to known 
> practices, not
> produce yet another variant.
> 
> Mike
> 
> > Sent: Thursday, March 29, 2001 9:47 AM
> > To: [email-masked]; [email-masked]
> > "Carlin Covey" <[email-masked]> writes:
> >
> > computing the
> > >certHash over only the signed portions of the certificate.
> >
> > I'm not.  I already have to create, track, store, and process a
> > whole pile of
> > certificate identifiers, and adding yet another wierdo 
> identifier which is
> > compatible with nothing else in existence to that pile when
> > there's no need for
> > it to be incompatible is something which I can really do without.
> >  The SHA-1
> > hash of the whole cert as "fingerprint" is pretty much
> > universally used and
> > accepted, unless there's a very strong reason not to use it I
> > don't see why we
> > need to invent yet another new identifier.
> >
> > Peter.
> >
> >
> 

Content-return: allowed
Date: Sat, 31 Mar 2001 19:04:07 -0800
From: Ryan Hurst <[email-masked]>
Subject: RE: OCSPv2: 02: certHash is not unique
To: Ambarish Malpani <[email-masked]>, [email-masked]

I agree, in our interoperability testing we have found that even with a
protocol with as few MAYs as OCSPv1 that there are a still a number of very
interesting non-standard ways that others have implemented their OCSP
clients/servers. For this reason I am one for keeping the MAYs to a minimum,
particularly for something as core as identification of the certificate in
question.

Ryan M. Hurst
Manager Solutions Engineering

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Thursday, March 29, 2001 2:09 AM
To: [email-masked]
Subject: RE: OCSPv2: 02: certHash is not unique

Mike,
    As I have said a few times before, I strongly oppose the
idea of using certHash as a method of identifying the certificate
whose status you want to check. It forces the responder to have
access to information that is not normally available to most
responders - even those run by most CAs (AFAIK).

I don't know that we are saving all that many bytes by using
certHash as opposed to certID.

It just doesn't make sense to me that we provide 5-6 different
ways of identifying a certificate in OCSP - I think it will
lead to a lot more interop problems, without buying us any
additional functionality.

Regards,
Ambarish

> From: Michael Myers [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2001 5:59 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Peter,
> After some correspondence, I've come to the same conclusion 
> despite my prior
> proposal to Jim.  The high-level intent of the presence of an 
> option to
> hash/fingerprint the cert was to enable alignment to known 
> practices, not
> produce yet another variant.
> 
> Mike
> 
> > Sent: Thursday, March 29, 2001 9:47 AM
> > To: [email-masked]; [email-masked]
> > "Carlin Covey" <[email-masked]> writes:
> >
> > computing the
> > >certHash over only the signed portions of the certificate.
> >
> > I'm not.  I already have to create, track, store, and process a
> > whole pile of
> > certificate identifiers, and adding yet another wierdo 
> identifier which is
> > compatible with nothing else in existence to that pile when
> > there's no need for
> > it to be incompatible is something which I can really do without.
> >  The SHA-1
> > hash of the whole cert as "fingerprint" is pretty much
> > universally used and
> > accepted, unless there's a very strong reason not to use it I
> > don't see why we
> > need to invent yet another new identifier.
> >
> > Peter.
> >
> >
> 

Date: Fri, 30 Mar 2001 18:41:29 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Subject: Gee, was it something I said?

I just received the following message, with the subject 
"ScanMail Message: To Sender, sensitive content found and action taken." 

>>> System Attendant <[email-masked]> 03/30/01 06:10PM >>>
>Trend SMEX Content Filter has detected sensitive content. 

>Place = [email-masked] ; ; 
>Sender = Bob Jueneman 
>Subject = RE: Logotypes in certificates 
>Delivery Time = March 30, 2001 (Friday) 17:10:55 
>Policy = Verisign 
>Action on this mail = Archive message 

>Warning message from administrator: 
>Content filter has detected a sensitive e-mail. 

I can only wonder what would have happened if I had 
referred to the fact that a number of couples attended 
SuperBowl XXX, or that I saw a  Robin Red Breast yesterday, 
or commented on the Nazi use of cryptography 
during WWII, or to the fact that some programs bomb 
out all too often, or that some photocopiers have difficulty 
discriminating between various shades of blacks,
or that a photographer took several shots of the President, 
or that the best laid plans of mice and men gang aft aglay?

Guess I'll find out, unless my VeriSign certificate isn't accepted.

Gimme a break!  :-)

Bob

Date: Fri, 30 Mar 2001 17:53:33 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Subject: RE: Logotypes in certificates

I've been behind on my e-mail or I would have jumped 
into this discussion much earlier, for I think that Stefan 
is dead on, and it isn't just about branding.

I proposed including logos in certificates about three or 
four years ago or longer, due to one overwhelming problem
when it comes to human acceptance of certificates,
and that is the issue of multiple language support and
non-ASCII characters.

I don't know about anyone else, but my Russian is extremely
rusty, and I can barely read the alphabet. I don't speak or
read Greek, but I can at least read the alphabet.

Now, if someone sends me a certificate with a name in 
Japanese, Chinese, Hebrew, Arabic, Sanscrit, Thai,
or Klingon -- arbitrary Unicode characters, if you
will --  what I am supposed to do with it? I can't even read 
the characters well enough to do a visual comparison
for equality.

And it gets worse when you consider the issue of "right to
use" names, particularly in some of the Asian countries where 
the CAs are closely tied to the government -- they will 
insist on the native language of that country being
used.

Yes, you could put either an English translation or
transliteration in an alternate subject name, but those 
names probably aren't in any sense official, and 
there are therefore significant right to use issues.
When you translate from the Cyrillic, should the name
be "Krasny Izvestia" , or "Red Star"?  Likewise
there are the "Peking" vs. "Beijing" issues, etc.
To us these issues seem be relatively unimportant, but
wars have been fought  over such linguistic matters.

My options would therefore seem to be:

1. Accept everything that comes from VeriSign, etc.,
whether I can read the entity's name or not.

2. Reject everything that comes from VeriSign, etc.,
whether I can read the entity's name or not, and
especially if I can't -- make everyone speak English! :-)

3. Participate only in closed user groups where
the decisions as to whether I should accept a
certificate are taken out of my hands and are
enforced by my MIS organization or higher-ups.

None of these are acceptable, in my opinion.

But if I put a logo in the certificate, in all likelihood
that logo is a trademark that is vigorously defended
and may be recognized worldwide.

Yes, the CAs will have to worry about trademark right 
to use issues, but in fact those issues are well understood
from a legal perspective, and certainly under better 
control than the slippery issue of right-to-use for DNS names.

I don't have an opinion yet as to issues of precisely how
such information should be encoded, and/or whether
name subordination ought to apply, but I think there is
a strong justification for the ability to include a logo
in a certificate.

Off the top of my head, I believe it ought to be possible to
associate a logo with both Subject and Issuer, and
I absolutely agree with Russ -- a policy OID or constraint
would be an absolutely terrible place to put it, except perhaps
as a seal of approval or qualification mark for a closed 
user group or association.

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software

Date: Fri, 30 Mar 2001 14:30:03 -0500
To: "Tolga Acar" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: WG Last Call: Algorithms draft
Cc: <[email-masked]>, <[email-masked]>

Tolga:

>* For reference to the RFC corresponding to PKCS#1, RFC2437 obsoletes 
>RFC2313. Replace all references to 2313 with 2437.

We only use PKCS#1 v1.5, so the older reference is still okay.

>  * For DSA, there is a FIPS 186-2. It may be wise to replace all 
> references to FIPS 186 by FIPS 186-2.

You are right.  Since FIPS 186-2 includes three signature algorithms, we 
thought that the reference to a document with a single signature algorithm 
was more helpful.

>* In Section 2.3.3, the Diffie-Hellman's Domain Parameters definition, it 
>says"g specifies the generator of the multiplicative subgroup of order g". 
>The order is not g, it must be q. Yes, the same error is also in RFC2459, 
>and I posted about this more than a year ago, but no one seems to care.
>It is also prudent to modify the definition of q as "the large prime 
>factor of p-1, and the order of g".

We will fix it in this document.  Once an RFC is posted, it cannot be changed.

We did not mean to ignore your comments.  Sorry.  Please review the 
soon-to-be-posted update and make sure we get it right.

>* A refererence to the IEEE's P1363 Standard Specifications for Public Key 
>Cryptography seems appropriate for all algorithms, in addition to 
>references to various X9s.

It is my understanding that X9 and IEEE P1363 groups cooperate.  However, 
the X9 groups assign the OIDs, so we were trying to point to the most 
helpful document.  We can certainly add IEEE P1363 to the list of 
references.  Can you provide the reference?  It would save a few minutes 
tracking it down.

>  * In section 2.3.5, definition of id-ecPublicKey has a reference to 
> id-publicKeyType, that is undefined. I suspect it is a typo.

Thanks.  We will fix it.  Again, please review the soon-to-be-posted update 
and make sure we get it right.

Russ

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Secure Extranet Authentication the way it will done
Date: Fri, 30 Mar 2001 17:24:06 +0200

The answer to the question on how individuals should securely authenticate to business parties
have so far been: Use client-certificates and SSL-authentication.  Drawbacks:

- There is no global issuing of  "employment certificates"

- To become a CA or RA under somebody else's umbrella is not core business and does neither
  scale-up (large organizations want to do this themselves), nor scale-down (too complex and expensive)

- If every organization instead becomes a stand-alone CA the whole concept of trust disappears
  and business parties will have to constantly install new root certificates

- X509 certificates do not contain the information needed for many relations which leads
  to out-of-band maintenance of  user attributes which make certificates pretty useless

- IETF attribute certificates have currently almost no infrastructure support

- Bridge CAs address problems that are entirely imposed by poor use of PKI

On  http://buyer.x-obi.com  you can get a glimpse of the future of PKI for B2B.  
Enjoy a free PKI-secured B2B-ride!

Tech/marketing whitepaper:  http://www.x-obi.com/purple

A future standard based on the same basic concept is created in the OASIS security-service TC.

regards
Anders Rundgren
CEO X-OBI AB
+46 70 - 627 74 37

From: [email-masked]
Subject: RE: OCSPv2: 02: certHash is not unique
To: [email-masked]
Date: Fri, 30 Mar 2001 11:05:29 +0100

server

Agreed.

ones.

Regards,

Jonathan
------------
Dr Jonathan Tuliani
www.symbian.com

From: "Martin Szotkowski" <[email-masked]>
To: <[email-masked]>
Subject: search for PKCS10 extension
Date: Fri, 30 Mar 2001 09:17:11 +0200
Organization: PVT, a.s.

I will add into PKCS10 request information about source of private key, but
I don't know if some extension exist or if I must create own.

I search for cases:
1. This information will be CSP Name who generate request
2. This information will be SHA1 over the Secret data on hardware token

thanks Martin

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: OCSPv2: 02: certHash is not unique
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 30 Mar 2001 10:45:23 (NZST)

Peter.

From: "Carlin Covey" <[email-masked]>
To: <[email-masked]>
Subject: FW: OCSPv2: 02: certHash is not unique
Date: Thu, 29 Mar 2001 13:26:46 -0700
Importance: Normal

This is a multi-part message in MIME format.

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

Jim,

- Carlin

  -----Original Message-----
  From: Carlin Covey [mailto:[email-masked]]
  Sent: Thursday, March 29, 2001 10:33 AM
  To: Manger, James H
  Subject: RE: OCSPv2: 02: certHash is not unique

  Jim,

  Regards,

  Carlin

  -  Carlin Covey
     Cylink Corporation

    -----Original Message-----
    From: Manger, James H [mailto:[email-masked]]
    Sent: Thursday, March 29, 2001 1:05 AM
    To: [email-masked]'
    Subject: RE: OCSPv2: 02: certHash is not unique

    Peter & Calin,

    Calin,

------=_NextPart_000_0002_01C0B853.E7391C90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001>Jim,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>I just=20
realized that I did not CC the PKIX list.&nbsp; I guess my confusion =
about=20
the</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>issue=20
stemmed from my interpretation of a couple of sentences in your first=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001>message </SPAN></FONT><FONT color=3D#0000ff =
face=3DArial=20
size=3D2><SPAN class=3D003220920-29032001>in the =
thread:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>"...=20
These properties - unambiguity and uniqueness - are quite =
different.&nbsp;=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001>&nbsp;&nbsp; It is reasonable to assume a =
certificate=20
thumbprint is unambiguous, </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001>&nbsp;&nbsp; but it is dangerous to assume it =
is unique=20
for the certificate."</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>I came=20
up with two interpretations for "... unique for the=20
certificate."</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>(1)=20
for every certificate there is just one hash</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>(2)=20
there are no two certificates with the same hash</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001>Interpretation (1) matched my working =
definition of=20
"unambiguous," so I</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001>attached interpretation (2) to =
"unique."&nbsp; And it=20
is quite true that one should</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>not=20
assume that there are no two certificates with the same hash=20
(the</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>size=20
of the hash value space being much smaller than the size of the=20
</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>input=20
space).&nbsp; So I tried to guess why you said that it is=20
dangerous,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>and I=20
came up with the "birthday attack" scenario.&nbsp; That proved to=20
be</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>an=20
incorrect guess.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D003220920-29032001>-=20
Carlin</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D003220920-29032001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Carlin Covey=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, March 29, 2001 =
10:33=20
  AM<BR><B>To:</B> Manger, James H<BR><B>Subject:</B> RE: OCSPv2: 02: =
certHash=20
  is not unique<BR><BR></DIV></FONT>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>Jim,</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>Ahh!&nbsp; I see.&nbsp; I thought the =
attack was an=20
  attempt to alter the certificate </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>so=20
  that the hash value would match</SPAN></FONT><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2><SPAN class=3D229111417-29032001> a good certificate, thereby =
causing=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>the=20
  responder to return a "good" response.&nbsp; In the case that you=20
  cite</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>the=20
  responder should return a response of "unknown" (since it is highly=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>unlikely that the hash would match=20
  any</SPAN></FONT><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001> real certificate due to the =
</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>"anti-birthday attack"&nbsp; feature of =
SHA-1).&nbsp;=20
  This&nbsp;would only a security </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>issue if the Relying </SPAN></FONT><FONT=20
  color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>Party uses the=20
  certificate anyway.&nbsp; </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>But=20
  I see</SPAN></FONT><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001> your point.&nbsp; This would be a security =
issue if=20
  the responder </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>calculated and stored certHash&nbsp; for =
all the=20
  certificates</SPAN></FONT><FONT color=3D#0000ff face=3DArial =
size=3D2><SPAN=20
  class=3D229111417-29032001> that it knows </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>to=20
  be revoked, and returned a response of "not revoked" if the target=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>certHash was not found on =
its</SPAN></FONT><FONT=20
  color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001> stored=20
  list.&nbsp; This would happen whether </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>the=20
  bits of the target certificate were altered intentionally or by =
error.&nbsp;=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>The=20
  "security considerations" section of the internet-draft should point=20
  </SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>out=20
  that this is not an acceptable</SPAN></FONT><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2><SPAN class=3D229111417-29032001> implementation. The=20
  response</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001>should always "fail-safe" to=20
  "unknown".</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D229111417-29032001>
  <P><FONT=20
  =
size=3D2>Regards,<BR><BR>Carlin<BR><BR>____________________________<BR><B=
R>-&nbsp;=20
  Carlin Covey<BR>&nbsp;&nbsp; Cylink Corporation=20
</FONT></P></SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D229111417-29032001></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Manger, James H=20
    [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, =
March 29,=20
    2001 1:05 AM<BR><B>To:</B> [email-masked]'<BR><B>Subject:</B> =
RE:=20
    OCSPv2: 02: certHash is not unique<BR><BR></DIV></FONT><SPAN=20
    class=3D336071605-26032001>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D031501206-29032001>Peter &amp;&nbsp;Calin,</SPAN></FONT></P>
    <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
      <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
        <P><FONT face=3DArial><FONT color=3D#800000><FONT =
color=3D#800000>&gt;<FONT=20
        color=3D#800000>&gt;</FONT></FONT><SPAN =
class=3D031501206-29032001><FONT=20
        color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN>An attacker can =
modify the<SPAN=20
        class=3D336071605-26032001> </SPAN>bytes (hence =
thumbprint)<BR><SPAN=20
        class=3D336071605-26032001>&gt;<FONT color=3D#800000>&gt;</FONT> =

        </SPAN>without modifying the semantics of a =
certificate.</FONT><FONT=20
        size=3D2><FONT color=3D#0000ff><SPAN=20
        =
class=3D031501206-29032001>&nbsp;</SPAN></FONT></FONT></FONT></P></BLOCKQ=
UOTE>
      <P><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
      class=3D031501206-29032001>&gt;&nbsp;</SPAN></FONT>But the same =
can happen=20
      for a "fingerprint" without it ever having been raised<SPAN=20
      class=3D336071605-26032001> </SPAN>as an issue in the past<SPAN=20
      class=3D031501206-29032001><FONT=20
      =
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></P></BLOCKQUOTE>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D031501206-29032001>This=20
    is NOT an issue for the way browsers currently use "fingerprints", =
but it IS=20
    an issue for OCSP.&nbsp; These two uses rely on DIFFERENT properties =
of the=20
    certificate id.</SPAN></FONT></P>
    <P><FONT face=3DArial><FONT color=3D#0000ff size=3D2><SPAN=20
    class=3D031501206-29032001><FONT color=3D#0000ff size=3D2><SPAN=20
    class=3D031501206-29032001>In the current browser use</SPAN></FONT>, =
such an=20
    attack (modifying the "fingerprint", but not the certificate) would =
mean the=20
    user fails to recognise that the certificate is one they =
trust.&nbsp; Hence,=20
    the user will treat the trusted certificate as untrusted.&nbsp; This =
is not=20
    a security violation.&nbsp; It is a mild (and irrelevant) form of =
Denial of=20
    Service.</SPAN></FONT></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D031501206-29032001>In=20
    the OCSP use, such an attack would mean a relying party and OCSP =
server=20
    would calculate different "fingerprints" for the same revoked=20
    certificate.&nbsp; An OCSP server with a list of "fingerprints" of =
revoked=20
    certificates, would fail to match the "fingerprint" in the OCSP =
request and=20
    would not return "revoked".&nbsp; This is a security=20
    violation.</SPAN></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D031501206-29032001>Note: If the OCSP server kept a list of=20
    "fingerprints" of&nbsp;un-revoked certificates&nbsp;(and assumed all =
other=20
    were revoked) the attack would not succeed.&nbsp; However, this is =
not how=20
    revocation is usually implemented.</SPAN></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D031501206-29032001>[In=20
    some vague sort of pseudo UML]<BR>Browser use assumes:&nbsp;=20
    (1)&nbsp;&nbsp;&nbsp; id&nbsp; *------1&nbsp; certificate<BR>OCSP =
use=20
    assumes:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(2)&nbsp;&nbsp; =
id&nbsp;&nbsp;&nbsp;=20
    1-----*&nbsp;&nbsp;certificate</SPAN></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D031501206-29032001>A=20
    hash of the DER-encoded&nbsp;complete certificate - "fingerprint" -=20
    satisfies (1) but not (2).</SPAN></FONT><FONT color=3D#0000ff =
size=3D2><SPAN=20
    class=3D031501206-29032001></SPAN></FONT></P>
    <P><FONT color=3D#0000ff size=3D2><SPAN=20
    class=3D031501206-29032001></SPAN></FONT>&nbsp;</P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D031501206-29032001>Calin, </SPAN></FONT></P>
    <P><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D031501206-29032001>This=20
    issues has nothing to do with birthday attacks and nothing to do =
with the=20
    security of=20
SHA-1.</SPAN></FONT></P></BLOCKQUOTE></BLOCKQUOTE></SPAN></BODY></HTML>

------=_NextPart_000_0002_01C0B853.E7391C90--

Date: Thu, 29 Mar 2001 10:37:35 -0800
From: Jeff Jacoby <[email-masked]>
Organization: RSA Security, Inc.
To: [email-masked]
Subject: Re: ASN.1 DER parser/compiler

Jonathan Jenkyn wrote:
> 
> Bob,
> 
>         As far as parsing goes the best known free tool is P.Gutmann's
> dumpasn1.
> This can be found at his website (http://www.cs.aukuni.ac.nz/~pgut001/)

I've also found that the GUI parser on IMC's SecureConnect 2 web page to
be quite nice (Windows only, though).  Two features I've found very
useful are recursive decoding of BIT STRINGs and OCTET STRINGs, and the 
ability to save a sub-component to its own file.

The page is at:  http://www.imc.org/imc-secureconnect/

Scroll down to the very bottom of the page.  

Jeff

Date: Thu, 29 Mar 2001 19:17:38 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked], Stephen Kent <[email-masked]>
Subject: Re: some thoughts re DPD and DPV

Steve,

Since Steve Kent is not present this week, I have refrained to answer too
quickly so that we can continue this thread with him when he comes back. 

> Denis,
> 
> > " Steve introduced a nice notion, i.e. to limit the number of paths that the
> > client is prepared to accept. It could then be one only or five. If you get
> > four what asking for five, this means that you got the best the sever could
> > do."
 
> What's the server supposed to do when the client says "5"? Is it supposed
> to find all possible paths and return just 5? If so, the protocol doesn't
> have a way for the client to recover if the client doesn't like all 5
> returned.
 
> Or, is the server supposed to do whatever it likes (say finding
> one) and send that back? 

You have provided yourself the right answer to your question just below:

> In that case, the client who doesn't like the
> result has to at some point increase the number in the request. 

> But hang on, that server already has one path that satisfies the request,
> so it'll just send that back and never go looking for more paths. (Unless
> the server is stateful per-client of course:-)

The server will return the previous answer(s) and more paths whenever
possible until the number of paths that has been requested has been reached.
So no "stateful per-client" functionality is needed. :-)

> Basically, you're not sending the right signals but developing a protocol
> which can lead to a kind of livelock (maybe that's not the right term
> though? http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?livelock defines it).
> 
> retryReference or an equivalent mechanism is needed and I haven't seen
> any other worked out proposal for an equivalent mechanism. I'm sure one
> could be proposed, it hasn't so far (or send the URL if I missed it).
>
> > You are ignoring the fact that if the client does not specify trust points,
> > the server will. If the client is not pleased with these trust points, then
> > it
> > should specify itself the trust points. AFAIR, you did not disagreed with
> > Steve during the meeting about the number of paths that, in practice, would
> > be returned, taking into account the existence of cross-certificates.
 
> But the server hasn't told the client which trust paths it picked, so if
> the client asks again then the client has no way to say that it didn't like
> the previous answer.

When the client does not specify trust points, the server will. If
the client does not like the trust point chosen by the server, he may then
specify or *change the validation conditions*, e.g. the trust point(s), the
root key(s), the associated name and/or policy constraints or the validation
policy.

If these changes in the selection of the validation policy are done, then
the client will get different results. We should no forget that DPD clients
are PKI aware, since they perform the validation themselves, so they will
certainly be able to adjust the request parameters to their needs. 
 
> > > 3) unnecessary and inefficient bloat: given that 90% (or whatever) of the time
> > > any path is a fine answer - we shouldn't bloat 100% of responses for the sake
> > > of a small number of cases
> >
> > If the criteria is finely tuned, then you are right and only one path will
> > be returned. If the criteria is "broad", e.g. three root keys with no other
> > constraints, then you may get more and any path is a fine answer to the
> > question raised, but not any more when applying additional local conditions.
> 
> This is the "that's a bad path construction policy" argument I mentioned
> in my first mail.
> 
> > I agree with you that "statefull server" might be an overstatement. Let us
> > speak of cache management. I would think that it may be appropriate for
> > efficiency reasons to keep track of already found paths. This does not mean
> > that the leaf certificate must be kept, but that all the CA certificates
> > above that path might be kept. Now this cached information should not be
> > associated with a retryReference number, so that *any* subsequent client can
> > get advantage of a speed improvement as soon as the CA from the leaf
> > certificate is the same.
> 
> There's nothing to prevent implementations doing such but that level of
> cache management does not need to be visible in the protocol. The path
> level does however due to the inherent "incompleteness" of path construction
> policy.
> 
> > However, all these details are implementation
> > details, not visible at a protocol level. Hence we do not need to support a
> > retryReference number.
> 
> We clearly disagree.
> 
> I think one of the things that Steve K. is keen we do more of is think about
> state machines. 
>
> IMO, the retryReference is a useful trick that matches well with
> the state machine folks would implement (and which probably does need more work
> in the ocspv2 draft). It seems that the putative alternative (client says: "I'll
> take up to 5") leads to a state machine which (admittedly in rare cases) causes
> the protocol to fail to do its job.
> 
> In any case, the ocspv2 proposal contains the retryReference for now and I think
> we've aired the arguments enough for today at least. Probably better to look at
> it again in the next draft of ocspv2 and see what we all think then.

It not because it was there in version -02, that it should be maintained in
the next version, version -03. The ocspv2 draft is no more than a draft for
discussions. :-)

Using your terminology, my conclusion, at this time, would be:

A "stateful per-client" server can be avoided:

1) by specify the maximum number of paths that should be returned, and
2) by refining the parameters of the validation policy, in case the first
   request has too broad parameters.

The advantage of being able to get more that one path at a time may also
save the number of exchanges.

However, don't forget that is more a case study, since currently, in
practice, they are not so many paths from a given leaf certificate 
to one root key. :-)

Regards,

Denis

> Stephen.
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:[email-masked]
> Ireland                             http://www.baltimore.com

Date: Thu, 29 Mar 2001 18:21:19 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: pkix <[email-masked]>
Subject: Re: some thoughts re DPD and DPV

Peter,

> Denis Pinkas <[email-masked]> writes:
 
> >There are other objections, since the model you are referring is also making
> >additional major changes from the PKIX model, in particular about the way to
> >check the validity of a certificate chain and the nomination of the OCSP
> >servers responsible for a given CA. Once again, we are in the PKIX WG with a
> >well defined model based on X.509. There are certainly alternatives to this
> >model. Alernatives may have their own merits. However, they should not be
> >progressed in the PKIX WG.
> 
> Uhh, I think you're reading way too much into my suggestion.  All I was doing
> was making the observation that currently when you query an OCSP responder it
> replies with "I could tell you all sorts of things about this cert, but instead
> I'm going to return a partial response and leave you to guess the rest".  By
> adding a small amount of additional information (which the client is free to
> ignore if they want) the responder may provide a more complete response than
> they currently can.  

If using a new extension in the request, a client wants to ask more
information about a certificate, e.g. "is that certificate present in 
the private Directory of the CA ? ", then this can be done by asking the
question explicitly. Clients worried by the response to this question should
ask the question using an extension. If they are not worried, then they
should not ask. 

In any case, as Ambarish indicated, we should change the three meanings of
an OCSP v1 response, i.e. "not revoked", "revoked", "unkown", and thus we
should not add any other status at that level. 

> If the client wants to stick religiously to the current
> OCSP/PKIX/whatever model they're free to ignore the extra information - all
> this is is supplementary data, if you don't like it you can ignore it, if you
> think it's useful and it saves you some work, you can use it.

We should no overload responses with responses to questions that have not
been requested.
 
> >Everyone can make its own private extensions and in that case, and we are not
> >going to stop this.
> 
> The problem is that since there appears to be at least some demand for this,
> everyone *will* add their own private extension, all of which will have
> slightly incompatible semantics, all of which will be completely different, and
> most of which will be undocumented.  

I agree with you that an *extension in the request* could be defined to ask
for this additional information, i.e. either using the
singleRequestExtensions sub-field of the Request structure or using the
requestExtensions sub-field of the tbsRequest. 

Note: In the case of ISIS, I believe that the former choice has been
selected.

In any case, I would recommend to define extensions in separate RFCs, so
that it is easier to be able to claim conformance when this fuctionality is
supported. A further advantage would be to support such extensions both with 
OCSPv1 or OCSPv2 (whenever it exists).

> Even worse, some groups may decide to
> override the semantics of OCSP itself (eg ISIS).  Rather than allow things to
> degenerate to the point where you need to handle a dozen different ways of
> doing the same thing, the RFC should include a single standard way of doing it
> with well-defined semantics which everyone can follow (or ignore if they feel so
> inclined).

Denis

> Peter.

Date: Thu, 29 Mar 2001 18:12:02 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Ambarish Malpani <[email-masked]>
CC: [email-masked]
Subject: Re: OCSPv2: 02: certHash is not unique

Ambarish,

I second your position.

Denis

> Mike,
>     As I have said a few times before, I strongly oppose the
> idea of using certHash as a method of identifying the certificate
> whose status you want to check. It forces the responder to have
> access to information that is not normally available to most
> responders - even those run by most CAs (AFAIK).
> 
> I don't know that we are saving all that many bytes by using
> certHash as opposed to certID.
> 
> It just doesn't make sense to me that we provide 5-6 different
> ways of identifying a certificate in OCSP - I think it will
> lead to a lot more interop problems, without buying us any
> additional functionality.
> 
> Regards,
> Ambarish
> 
> > From: Michael Myers [mailto:[email-masked]]
> > Sent: Wednesday, March 28, 2001 5:59 PM
> > To: [email-masked]; [email-masked]; [email-masked]
> > Peter,
> > After some correspondence, I've come to the same conclusion
> > despite my prior
> > proposal to Jim.  The high-level intent of the presence of an
> > option to
> > hash/fingerprint the cert was to enable alignment to known
> > practices, not
> > produce yet another variant.
> >
> > Mike
> >
> > > Sent: Thursday, March 29, 2001 9:47 AM
> > > To: [email-masked]; [email-masked]
> > > "Carlin Covey" <[email-masked]> writes:
> > >
> > > computing the
> > > >certHash over only the signed portions of the certificate.
> > >
> > > I'm not.  I already have to create, track, store, and process a
> > > whole pile of
> > > certificate identifiers, and adding yet another wierdo
> > identifier which is
> > > compatible with nothing else in existence to that pile when
> > > there's no need for
> > > it to be incompatible is something which I can really do without.
> > >  The SHA-1
> > > hash of the whole cert as "fingerprint" is pretty much
> > > universally used and
> > > accepted, unless there's a very strong reason not to use it I
> > > don't see why we
> > > need to invent yet another new identifier.
> > >
> > > Peter.
> > >
> > >
> >

Content-return: allowed
Date: Thu, 29 Mar 2001 07:13:16 -0800
From: Frank Balluffi <[email-masked]>
Subject: RE: Logotypes [not] in certificates
To: "'Bodo Moeller'" <[email-masked]>
Cc: [email-masked]

Bodo Moeller said:

> So it is likely that logos will be trusted *instead of* looking at the
> certificate details, rather than in addition to that.  I.e., most
> users won't even notice to which country the logo applies.  This opens
> a new can of worms.  Just one example: Until a couple of years ago,
> the owner of the Bayer name and the Bayer cross logo for the US and
> Canada was a company that had little to do with Bayer AG.  (In 1994,
> Bayer AG bought the division of Sterling Winthrop that had previously
> used these trademarks in North America; then, in 1995, Bayer's US and
> Canadian subsidiaries changed their names from "Miles Inc." and "Miles
> Canada Inc." into "Bayer Corporation" and "Bayer Inc.", respectively.)
> It is because of issues like this that distinguished names are
> hierarchical.

The level of trust will depend upon the application. A bad application is a
bad application. As RFC 3039 says about biometric information, logos should
be used to "enhance identification of the subject."

Frank

Date: Thu, 29 Mar 2001 16:43:32 +0200
To: Dean Povey <[email-masked]>, Aram Perez <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Logotypes in certificates 
Cc: [email-masked]

Dean,

At 20:30 2001-03-23 +1000, Dean Povey wrote:
>We also need to think beyond just logos.  What about photographs of employees
>in Certificates?  This is such a useful thing to be able to do.  I am
>cognisant of the reticence of people to stuff too much in certs, and I think
>in general this is a good principle.  But providing it is done sensibly I 
>think
>there is a fair bit to suggest that a scheme like this would significantly
>contribute to the security of PKI systems.

Photographs in certificates are already covered in RFC 3039 (see 
biometricInfo extension).

My original proposal for logos actually used the same technique to include 
logos as is used in RFC 3039 to include photos and other displayable images 
of biometric-characteristics.

/Stefan

Date: Thu, 29 Mar 2001 14:48:19 +0200
From: Bodo Moeller <[email-masked]>
To: Dean Povey <[email-masked]>
Cc: [email-masked]
Subject: Re: Logotypes [not] in certificates

On Tue, Mar 27, 2001 at 10:13:11AM +1000, Dean Povey wrote:

> [...]         The idea is to make user's more involved in the process, not 
> more removed from it.  The point about the logo is it is in your face.

So it is likely that logos will be trusted *instead of* looking at the
certificate details, rather than in addition to that.  I.e., most
users won't even notice to which country the logo applies.  This opens
a new can of worms.  Just one example: Until a couple of years ago,
the owner of the Bayer name and the Bayer cross logo for the US and
Canada was a company that had little to do with Bayer AG.  (In 1994,
Bayer AG bought the division of Sterling Winthrop that had previously
used these trademarks in North America; then, in 1995, Bayer's US and
Canadian subsidiaries changed their names from "Miles Inc." and "Miles
Canada Inc." into "Bayer Corporation" and "Bayer Inc.", respectively.)
It is because of issues like this that distinguished names are
hierarchical.

> Browser designers tend to hide away Certificate details.

If this is considered a problem, it should be changed.  Displaying
some text (as found in most certificates these days) is not
essentially harder than displaying a logo; quite in contrary.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Content-return: allowed
Date: Thu, 29 Mar 2001 02:08:54 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: OCSPv2: 02: certHash is not unique
To: [email-masked]

Mike,
    As I have said a few times before, I strongly oppose the
idea of using certHash as a method of identifying the certificate
whose status you want to check. It forces the responder to have
access to information that is not normally available to most
responders - even those run by most CAs (AFAIK).

I don't know that we are saving all that many bytes by using
certHash as opposed to certID.

It just doesn't make sense to me that we provide 5-6 different
ways of identifying a certificate in OCSP - I think it will
lead to a lot more interop problems, without buying us any
additional functionality.

Regards,
Ambarish

> From: Michael Myers [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2001 5:59 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Peter,
> After some correspondence, I've come to the same conclusion 
> despite my prior
> proposal to Jim.  The high-level intent of the presence of an 
> option to
> hash/fingerprint the cert was to enable alignment to known 
> practices, not
> produce yet another variant.
> 
> Mike
> 
> > Sent: Thursday, March 29, 2001 9:47 AM
> > To: [email-masked]; [email-masked]
> > "Carlin Covey" <[email-masked]> writes:
> >
> > computing the
> > >certHash over only the signed portions of the certificate.
> >
> > I'm not.  I already have to create, track, store, and process a
> > whole pile of
> > certificate identifiers, and adding yet another wierdo 
> identifier which is
> > compatible with nothing else in existence to that pile when
> > there's no need for
> > it to be incompatible is something which I can really do without.
> >  The SHA-1
> > hash of the whole cert as "fingerprint" is pretty much
> > universally used and
> > accepted, unless there's a very strong reason not to use it I
> > don't see why we
> > need to invent yet another new identifier.
> >
> > Peter.
> >
> >
> 

Content-return: allowed
Date: Thu, 29 Mar 2001 02:02:37 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: some thoughts re DPD and DPV
To: "[email-masked]'" <[email-masked]>, [email-masked]

Peter, you want to be careful about what you indicate the server
is saying in its response.

The question of whether a server is making any statement about
the expiry status or issuance status of a certificate in an OCSP
response or not did come up in the OCSP discussion earlier. The
concensus at that time was, that the question being asked was
about the revocation status of the certificate. If the client
wanted to know about the expiry status of the certificate, it
could check the certificate for itself. Similarly, if it wanted
to know whether the certificate was ever issued or not, it could
verify the signature on the certificate. So implying anything
about the expiry/issuance status of certificates was not
included in the protocol.

I know of ISIS's desire to have an OCSP response indicate not
only the status of the certificate, but also its existance in a
directory. While I still don't see the benefit of the additional
guarantee, if enough people want it, I don't see a problem with
adding it in a standard way to OCSP, but I would strongly urge
the group to do so via additional extensions.

Changing the meaning of good/revoked/unknown to also include
something about issued/expired, etc. is very, very unclean.

Hope this makes sense,
Regards,
Ambarish

> Sent: Thursday, March 29, 2001 7:30 AM
> To: [email-masked]
> Subject: Re: some thoughts re DPD and DPV
> 
> 
> Denis Pinkas <[email-masked]> writes:
> 
> >There are other objections, since the model you are 
> referring is also making
> >additional major changes from the PKIX model, in particular 
> about the way to
> >check the validity of a certificate chain and the nomination 
> of the OCSP
> >servers responsible for a given CA. Once again, we are in 
> the PKIX WG with a
> >well defined model based on X.509. There are certainly 
> alternatives to this
> >model. Alernatives may have their own merits. However, they 
> should not be
> >progressed in the PKIX WG. 
> 
> Uhh, I think you're reading way too much into my suggestion.  
> All I was doing
> was making the observation that currently when you query an 
> OCSP responder it
> replies with "I could tell you all sorts of things about this 
> cert, but instead
> I'm going to return a partial response and leave you to guess 
> the rest".  By
> adding a small amount of additional information (which the 
> client is free to
> ignore if they want) the responder may provide a more 
> complete response than
> they currently can.  If the client wants to stick religiously 
> to the current
> OCSP/PKIX/whatever model they're free to ignore the extra 
> information - all
> this is is supplementary data, if you don't like it you can 
> ignore it, if you
> think it's useful and it saves you some work, you can use it.
> 
> >Everyone can make its own private extensions and in that 
> case, and we are not
> >going to stop this. 
> 
> The problem is that since there appears to be at least some 
> demand for this,
> everyone *will* add their own private extension, all of which 
> will have
> slightly incompatible semantics, all of which will be 
> completely different, and
> most of which will be undocumented.  Even worse, some groups 
> may decide to
> override the semantics of OCSP itself (eg ISIS).  Rather than 
> allow things to
> degenerate to the point where you need to handle a dozen 
> different ways of
> doing the same thing, the RFC should include a single 
> standard way of doing it
> with well-defined semantics which everyone can follow (or 
> ignore if they feel so
> inclined).
> 
> Peter.
> 

From: "Manger, James H" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: OCSPv2: 02: certHash is not unique
Date: Thu, 29 Mar 2001 18:05:16 +1000

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B826.FD3174DE
Content-Type: text/plain;
	charset="iso-8859-1"

Peter & Calin,

Calin, 

------_=_NextPart_001_01C0B826.FD3174DE
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 5.00.3105.105" name=GENERATOR></HEAD>
<BODY><SPAN class=336071605-26032001>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>Peter 
&amp;&nbsp;Calin,</SPAN></FONT></P>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <P><FONT face=Arial><FONT color=#800000><FONT color=#800000>&gt;<FONT 
    color=#800000>&gt;</FONT></FONT><SPAN class=031501206-29032001><FONT 
    color=#0000ff size=2>&nbsp;</FONT></SPAN>An attacker can modify the<SPAN 
    class=336071605-26032001> </SPAN>bytes (hence thumbprint)<BR><SPAN 
    class=336071605-26032001>&gt;<FONT color=#800000>&gt;</FONT> </SPAN>without 
    modifying the semantics of a certificate.</FONT><FONT size=2><FONT 
    color=#0000ff><SPAN 
    class=031501206-29032001>&nbsp;</SPAN></FONT></FONT></FONT></P></BLOCKQUOTE>
  <P><FONT face=Arial><FONT size=2><FONT color=#0000ff><SPAN 
  class=031501206-29032001>&gt;&nbsp;</SPAN></FONT>But the same can happen for a 
  "fingerprint" without it ever having been raised<SPAN 
  class=336071605-26032001> </SPAN>as an issue in the past<SPAN 
  class=031501206-29032001><FONT 
  color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></P></BLOCKQUOTE>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>This is 
NOT an issue for the way browsers currently use "fingerprints", but it IS an 
issue for OCSP.&nbsp; These two uses rely on DIFFERENT properties of the 
certificate id.</SPAN></FONT></P>
<P><FONT face=Arial><FONT color=#0000ff size=2><SPAN 
class=031501206-29032001><FONT color=#0000ff size=2><SPAN 
class=031501206-29032001>In the current browser use</SPAN></FONT>, such an 
attack (modifying the "fingerprint", but not the certificate) would mean the 
user fails to recognise that the certificate is one they trust.&nbsp; Hence, the 
user will treat the trusted certificate as untrusted.&nbsp; This is not a 
security violation.&nbsp; It is a mild (and irrelevant) form of Denial of 
Service.</SPAN></FONT></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>In the 
OCSP use, such an attack would mean a relying party and OCSP server would 
calculate different "fingerprints" for the same revoked certificate.&nbsp; An 
OCSP server with a list of "fingerprints" of revoked certificates, would fail to 
match the "fingerprint" in the OCSP request and would not return 
"revoked".&nbsp; This is a security violation.</SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>Note: If 
the OCSP server kept a list of "fingerprints" of&nbsp;un-revoked 
certificates&nbsp;(and assumed all other were revoked) the attack would not 
succeed.&nbsp; However, this is not how revocation is usually 
implemented.</SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>[In some 
vague sort of pseudo UML]<BR>Browser use assumes:&nbsp; (1)&nbsp;&nbsp;&nbsp; 
id&nbsp;  *------1&nbsp; certificate<BR>OCSP use 
assumes:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(2)&nbsp;&nbsp;  id&nbsp;&nbsp;&nbsp; 
1-----*&nbsp;&nbsp;certificate</SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>A hash 
of the DER-encoded&nbsp;complete certificate - "fingerprint" - satisfies (1) but 
not (2).</SPAN></FONT><FONT color=#0000ff size=2><SPAN 
class=031501206-29032001></SPAN></FONT></P>
<P><FONT color=#0000ff size=2><SPAN 
class=031501206-29032001></SPAN></FONT>&nbsp;</P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>Calin, 
</SPAN></FONT></P>
<P><FONT color=#0000ff face=Arial size=2><SPAN class=031501206-29032001>This 
issues has nothing to do with birthday attacks and nothing to do with the 
security of SHA-1.</SPAN></FONT></P></SPAN></BODY></HTML>

------_=_NextPart_001_01C0B826.FD3174DE--

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: some thoughts re DPD and DPV 
Date: Wed, 28 Mar 2001 20:18:21 -0800
Importance: Normal

Peter,

Given that the current debate largely centers around various OPTIONAL
elements to enable clients to assert in-band controls/filters/etc. if they
choose, what are your thoughts on the minimal interpretation of OCSP-based
DPV?  That is,

"A DPV response SHALL contain a value of id-pkix-ocsp-valid-rsp in the
ResponseType field of the ResponseBytes syntax.

id-pkix-ocsp-valid-rsp    OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

DPVCertStatus ::= CHOICE {
    valid       [0]     IMPLICIT NULL,
    invalid     [1]     IMPLICIT NULL,
    unknown     [2]     IMPLICIT NULL  }"

where:

"The "valid" state SHALL be interpreted as indicating that the certificate
at a
minimum satisfies the path validation rules defined in [RFC2459]."

Mike

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: some thoughts re DPD and DPV 
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 29 Mar 2001 15:29:46 (NZST)

Denis Pinkas <[email-masked]> writes:

>There are other objections, since the model you are referring is also making
>additional major changes from the PKIX model, in particular about the way to
>check the validity of a certificate chain and the nomination of the OCSP
>servers responsible for a given CA. Once again, we are in the PKIX WG with a
>well defined model based on X.509. There are certainly alternatives to this
>model. Alernatives may have their own merits. However, they should not be
>progressed in the PKIX WG. 

Uhh, I think you're reading way too much into my suggestion.  All I was doing
was making the observation that currently when you query an OCSP responder it
replies with "I could tell you all sorts of things about this cert, but instead
I'm going to return a partial response and leave you to guess the rest".  By
adding a small amount of additional information (which the client is free to
ignore if they want) the responder may provide a more complete response than
they currently can.  If the client wants to stick religiously to the current
OCSP/PKIX/whatever model they're free to ignore the extra information - all
this is is supplementary data, if you don't like it you can ignore it, if you
think it's useful and it saves you some work, you can use it.

>Everyone can make its own private extensions and in that case, and we are not
>going to stop this. 

The problem is that since there appears to be at least some demand for this,
everyone *will* add their own private extension, all of which will have
slightly incompatible semantics, all of which will be completely different, and
most of which will be undocumented.  Even worse, some groups may decide to
override the semantics of OCSP itself (eg ISIS).  Rather than allow things to
degenerate to the point where you need to handle a dozen different ways of
doing the same thing, the RFC should include a single standard way of doing it
with well-defined semantics which everyone can follow (or ignore if they feel so
inclined).

Peter.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: OCSPv2: 02: certHash is not unique
Date: Wed, 28 Mar 2001 17:58:30 -0800
Importance: Normal

Peter,

After some correspondence, I've come to the same conclusion despite my prior
proposal to Jim.  The high-level intent of the presence of an option to
hash/fingerprint the cert was to enable alignment to known practices, not
produce yet another variant.

Mike

> Sent: Thursday, March 29, 2001 9:47 AM
> To: [email-masked]; [email-masked]
> "Carlin Covey" <[email-masked]> writes:
>
> computing the
> >certHash over only the signed portions of the certificate.
>
> I'm not.  I already have to create, track, store, and process a
> whole pile of
> certificate identifiers, and adding yet another wierdo identifier which is
> compatible with nothing else in existence to that pile when
> there's no need for
> it to be incompatible is something which I can really do without.
>  The SHA-1
> hash of the whole cert as "fingerprint" is pretty much
> universally used and
> accepted, unless there's a very strong reason not to use it I
> don't see why we
> need to invent yet another new identifier.
>
> Peter.
>
>

From: "Carlin Covey" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: OCSPv2: 02: certHash is not unique
Date: Wed, 28 Mar 2001 14:58:42 -0700
Importance: Normal

Peter and Tim,

I'm content with the "fingerprint" too.  I place my faith in the
SHA-1 hash, not whether or not some of the bits fed into the hash
can be manipulated.  Tim, is my faith in SHA-1 misplaced?

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 29, 2001 9:47 AM
To: [email-masked]; [email-masked]
Subject: Re: OCSPv2: 02: certHash is not unique

"Carlin Covey" <[email-masked]> writes:

>I am quite content with the suggestion that Jim made concerning computing
the
>certHash over only the signed portions of the certificate.

I'm not.  I already have to create, track, store, and process a whole pile
of
certificate identifiers, and adding yet another wierdo identifier which is
compatible with nothing else in existence to that pile when there's no need
for
it to be incompatible is something which I can really do without.  The SHA-1
hash of the whole cert as "fingerprint" is pretty much universally used and
accepted, unless there's a very strong reason not to use it I don't see why
we
need to invent yet another new identifier.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: OCSPv2: 02: certHash is not unique
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 29 Mar 2001 09:47:29 (NZST)

"Carlin Covey" <[email-masked]> writes:

>I am quite content with the suggestion that Jim made concerning computing the
>certHash over only the signed portions of the certificate.  

I'm not.  I already have to create, track, store, and process a whole pile of
certificate identifiers, and adding yet another wierdo identifier which is
compatible with nothing else in existence to that pile when there's no need for
it to be incompatible is something which I can really do without.  The SHA-1
hash of the whole cert as "fingerprint" is pretty much universally used and
accepted, unless there's a very strong reason not to use it I don't see why we
need to invent yet another new identifier.

Peter.

From: "Carlin Covey" <[email-masked]>
To: <[email-masked]>
Subject: RE: confidential
Date: Wed, 28 Mar 2001 14:43:36 -0700
Importance: Normal

"...  propelled by smart, determined professionals  ..."

Anybody want to be a propeller?  I hear there are some nifty beanies ....
;-}

Date: Wed, 28 Mar 2001 13:18:36 -0800 (PST)
From: [email-masked]
To: [email-masked]
Subject: confidential

Senior Manager - Midwest and East Coast
eWorkforce  Consulting Practice  

My name is Brian McCloskey and I am a headhunter. I am currently conducting a search for a focused, fast growing, global consulting firm.  

My client is an organization with tremendous momentum, propelled by smart, determined professionals who are driven by a singular ambition - to provide clients with successful, cutting-edge e-Business solutions.  They pride themselves on the teams of skilled and experienced professionals assembled to meet e-Business challenges.

The Ideal candidate will be able to communicate the business function and solution to all levels of client and internal staff.  Keys to success with this practice include client focus, industry savvy and the ability to work independently and as part of a collaborative team. 

·	Fluid executive level presence
·	Transition from C level meetings to hands on work in delivery with client and staff
·	Project Management and meeting facilitation skills, including business metrics definition, systems functionality requirements, project status reviews, etc.
·	Thought leadership and analytical thinking skills in leading best practice teams; able to convincingly guide client and internal teams toward appropriate solutions as supported by best practices experience
·	Executive presentation skills, both in planned conference or proposal settings and ad hoc "quick on the feet" responsiveness
·	Extensive network and/or demonstrated experience in selling work to new or existing clients, and business case / value proposition orientation
·	Experience in leading large scale multi-site/multi-national reporting projects including familiarity with data warehousing techniques, OLAP tools, and other front-end reporting capabilities.
·	Performance management skills, across direct staff managed, virtual teams, and client resources.		

If this is of interest to you, or at the very least, you would like to stay aware of the opportunities in the industry, please contact me. 

Best regards,

Brian
_____________________________________________________________________
Brian McCloskey
AM Search Consulting   http://www.amsearch.com
1801 Research Boulevard,  Suite 602
Rockville, MD  20850
Phone:	301-315-9030 ext. 18
Fax: 	301-315-9036
Email:  [email-masked]

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: RE: ASN.1 DER parser/compiler
Date: Wed, 28 Mar 2001 14:45:27 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C0B7BF.A360CAC0
Content-Type: text/plain;
	charset="iso-8859-1"

Jonathan wrote: 
"	* snacc - freeware ASN.1 to C/C++ compiler
http://www.idiom.com/free-compilers/TOOL/ASN1-1.html - I believe this only
deals with BER rather than DER compilation".

We have enhanced the SNACC freeware to support DER.  Please see the attached
message for more information.

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

------_=_NextPart_000_01C0B7BF.A360CAC0
Content-Type: message/rfc822
Content-Description: v1.3 R5 Enhanced SNACC ASN.1 Freeware 

Message-ID: <[email-masked]>
From: "Pawling, John" <[email-masked]>
To: "Pawling, John" <[email-masked]>
Subject: v1.3 R5 Enhanced SNACC ASN.1 Freeware 
Date: Fri, 16 Feb 2001 16:27:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"

All,

Getronics Government Solutions has delivered the v1.3 R5 Enhanced SNACC
Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library
source code compilable for Linux, Sun Solaris 2.7 and Microsoft Windows
NT/95/98/2000.  The source code and the Enhanced SNACC Software Public
License are freely available to everyone from:
<http://www.getronicsgov.com/hot/snacc_home.htm>

In past releases, Getronics enhanced the SNACC library to implement the
Distinguished Encoding Rules (DER).  In the v1.3 R5 SNACC release, Getronics
included the following enhancements:

1) Resolved compiler warnings.

2) Enhanced C++ library encode/decode performance.

3) Converted all source code to use CVS configuration management system.

4) Update SNACC readme file. 

5) Tested with v1.9 S/MIME Freeware Library (SFL)
<http://www.getronicsgov.com/hot/sfl_home.htm>
 that uses SNACC to implement the IETF S/MIME v3 set of specifications.  

6) Tested with freeware v1.9 Certificate Management Library (CML)
<http://www.getronicsgov.com/hot/cml_home.htm> that
uses SNACC to implement the 2000 X.509 Recommendation and RFC 2459.  

7) Tested with freeware v1.5 Access Control Library (ACL)
<http://www.getronicsgov.com/hot/acl_home.htm> that uses SNACC to provide
automated access control.  

SNACC implements the majority of ASN.1 encoding/decoding rules.  SNACC does
not support all of
the latest ASN.1 features, but there are work-arounds that allow SNACC to be
used to produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note that
many of the PKIX specs, such as RFC 2459, include 1988-compliant ASN.1
syntax modules which can be compiled using SNACC.

The SNACC ASN.1 library is totally unencumbered as stated in the Enhanced
SNACC Software Public License.  All source code for the Enhanced SNACC
software is being provided at no cost and with no financial limitations
regarding its use and distribution.  Organizations can use the Enhanced
SNACC software without paying any royalties or licensing fees.  

The Internet Mail Consortium (IMC) has established a SNACC web page
<http://www.imc.org/imc-snacc/>.  The IMC has also established a SNACC mail
list which is used to: distribute information regarding SNACC releases;
discuss SNACC-related issues; and provide a means for SNACC users to provide
feedback, comments, bug reports, etc.  Subscription information for the
imc-snacc mail list is at the IMC web site listed above.

We welcome all feedback regarding the Enhanced SNACC software.  If bugs are
reported, then we will investigate each reported bug and, if required, will
produce a patch or an updated release of the software to repair the bug. 

This SNACC release announcement was sent to several mail lists, but please
send all messages regarding the Enhanced SNACC software to the imc-snacc
mail list ONLY.  Please do not send messages regarding the Enhanced SNACC
software to any of the IETF mail lists.  We will respond to all messages
sent to the imc-snacc mail list.

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

------_=_NextPart_000_01C0B7BF.A360CAC0--

From: "Jonathan Jenkyn" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: ASN.1 DER parser/compiler
Date: Wed, 28 Mar 2001 20:38:25 +0100
Importance: Normal

Bob,

	As far as parsing goes the best known free tool is P.Gutmann's dumpasn1.
This can be found at his website (http://www.cs.aukuni.ac.nz/~pgut001/)

	Compilation can be done through several different tools:
	* snacc - freeware ASN.1 to C/C++ compiler
http://www.idiom.com/free-compilers/TOOL/ASN1-1.html - I believe this only
deals with BER rather than DER compilation
	* cryptlib - shareware crypto library for C++ written by P.Gutmann
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ - specifically adheres to
X.692 (DER encoding)

	Other ASN.1 compilers exist, but most of them you have to buy. If you are
still interested, ONE (http://www.one.com/products/a_1_t.html) make a good
one, as do OSS (http://www.oss.com/products/asn1cpp/tools_cpp.html)

	The location of many other ASN tools can be found here
:http://www-sop.inria.fr/rodeo/personnel/hoschka/asn1.html

	Hope this is of some help

	Regards

	Jonathan Jenkyn

Jonathan Jenkyn
Head of Cryptographic Systems
De La Rue InterClear
UK
+44(0)7957568126
[email-masked]
www.interclear.com

-----Original Message-----
From: Robert T. Bell [mailto:[email-masked]]
Sent: 28 March 2001 19:14
To: PKIX-MailList (E-mail)
Subject: ASN.1 DER parser/compiler

Is there a good ASN.1 DER parser tool and also a good compiler available
somewhere? Could someone provide me with a pointer to them?

Thanks ---- Bob Bell

Bob Bell
Cisco Systems, Inc.
576 S. Brentwood Ln.
Bountiful, Utah 84010
801-294-3034 (v)
801-204-3023 (f)
801-971-4200 (cell)
[email-masked] <mailto:[email-masked]>  (email)

From: "Carlin Covey" <[email-masked]>
To: <[email-masked]>
Subject: Re: OCSPv2: 02: certHash is not unique
Date: Wed, 28 Mar 2001 12:27:58 -0700
Importance: Normal

Peter and Jim,

------

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 29, 2001 5:59 AM
To: [email-masked]
Subject: Re: OCSPv2: 02: certHash is not unique

the

a
the

Peter.

Reply-To: <[email-masked]>
From: "Robert T. Bell" <[email-masked]>
To: "PKIX-MailList \(E-mail\)" <[email-masked]>
Subject: ASN.1 DER parser/compiler
Date: Wed, 28 Mar 2001 11:13:39 -0700
Importance: Normal

Is there a good ASN.1 DER parser tool and also a good compiler available
somewhere? Could someone provide me with a pointer to them?

Thanks ---- Bob Bell

Bob Bell
Cisco Systems, Inc.
576 S. Brentwood Ln.
Bountiful, Utah 84010
801-294-3034 (v)
801-204-3023 (f)
801-971-4200 (cell)
[email-masked] <mailto:[email-masked]>  (email)

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: OCSPv2: 02: certHash is not unique 
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 29 Mar 2001 05:58:39 (NZST)

Peter.

Date: Tue, 27 Mar 2001 11:23:45 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Need an OID from the PKIX arc?

With the help of Paul Hoffman, we have set up a special mail address to 
obtain OIDs from the PKIX arc.  Please send future requests for OIDs in the 
PKIX arc to <[email-masked]>.  I have set up a filter in my mail 
client to flag messages that are sent to this address.  This should help me 
to handle OID requests efficiently and effectively.

As usual, the PKIX OIDs are posted at imc.org.

Russ

Date: Tue, 27 Mar 2001 11:25:00 -0500
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Need an OID from the S/MIME arc?

With the help of Paul Hoffman, we have set up a special mail address to 
obtain OIDs from the S/MIME arc.  Please send future requests for OIDs in 
the S/MIME arc to <[email-masked]>.  I have set up a filter in 
my mail client to flag messages that are sent to this address.  This should 
help me to handle OID requests efficiently and effectively.

As usual, the S/MIME OIDs are posted at imc.org.

Russ 

Date: Tue, 27 Mar 2001 05:32:04 -0800 (PST)
From: Hahaha <[email-masked]>
Subject: Enanito si, pero con que pedazo!

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

Faltaba apenas un dia para su aniversario de de 18 años. Blanca de Nieve fuera
siempre muy bien cuidada por los enanitos. Ellos le prometieron una *grande*
sorpresa para su fiesta de compleaños. Al entardecer, llegaron. Tenian un brillo
incomun en los ojos...

----VEBS5YBGDI78HANK5MNW5EFGPAJ
Content-Type: application/octet-stream; name="blanca de nieve.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="blanca de nieve.scr"

AAAAAAAAAAAAAAAA

----VEBS5YBGDI78HANK5MNW5EFGPAJ--

From: Peter Sylvester <[email-masked]>
Date: Tue, 27 Mar 2001 13:48:35 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: some thoughts re DPD and DPV
Cc: [email-masked], [email-masked]

> 
> Denis,
> 
> > I noticed that your were the single one at the IETF meeting advocating the
> > need for the retryReference. There migh be other individuals present at the
> > meeting or people on the mailing list supporting this idea as well, but up
> > to now they have remain silent. :-)
> 
> That never seems to bother you, so I'm ok with it in this case:-)
> 

There was a discussion on that point some months ago. If I rememeber
it right, in ended in violant agreement among me and Stephen Farrell.

Date: Tue, 27 Mar 2001 12:20:35 +0200
From: Avi Zelovich <[email-masked]>
To: [email-masked]
Subject: (no subject)

unsubscribe

Date: Tue, 27 Mar 2001 12:10:00 +0200
From: Avi Zelovich <[email-masked]>
To: [email-masked]
Subject: (no subject)

UNSUBSCRIBE

Sender: [email-masked]
Date: Tue, 27 Mar 2001 12:11:25 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: Dean Povey <[email-masked]>
Cc: [email-masked]
Subject: Re: Logotypes in certificates

Dean Povey wrote:
> 
> I think you would concede however that
> while they might not do exhaustive checking, the trademark process provides
> some level of assurance as companies are quite vigilant about protecting
> their trademarks.

No. Although I agree that companies are very vigilant about
protecting their trademarks there are too many trade mark and logo
cases going to courts. IMHO this whole trademark stuff is even more
ambigous than natural names (like X.500 naming CN,L,OU,O,C) of
residential persons.

Ciao, Michael.

Date: Tue, 27 Mar 2001 16:45:38 +0800
From: "Raymond Chiu" <[email-masked]>
Organization: Motorola Semiconductor Products Sector
To: [email-masked]
Subject: (no subject)

unsubscribe

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: CRLs 
Date: Tue, 27 Mar 2001 09:25:02 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B697.6B436630
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Dean,
	I was thinking about CRLDistributionPoint. But the question is how
to verify such CRL, and what about CRL extensions and entry extension. From
the begining.
1. What exactly should include field cRLIssuer in CRLDistributionPoint
extension?
2. I should received verification path for the cert, which signed CRL. And I
think that the root certificate should the one, which sign certificate.
Otherwise it's possible to create false CRL (maybe I'm wrong, I don't know
the answer to question #1).
3. What about CRL extension: Issuing Distribution Point - to indicate that
CRL is indirect, and CRL entry extension: Certificate Issuer - to identify
certificate issuer.

In general, how such CRL should be validated? I think that standard is not
consistent, and should be changed.

Regards,

Pawel Krupinski

-----Original Message-----
From: Dean Povey [mailto:[email-masked]]
Sent: Tuesday, March 27, 2001 1:25 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: CRLs 

>Hi,
>	I'm trying to split CA functionality. I want to have one private key
>to sign certificates (CA key), and the second one to sign CRLs.
>	First is it possible to do it? Because in the standard I've found:
>"The CRL is signed using the CA's private key." (is it the same CA, which
>sign this certificate? In other words, CA can only revoke certificates it
>signed, Am I right?)

Hi Pawel,

You can use the cRLDistributionPoint extension to indicate a CRL issuer 
other than the CA that issued the Certificate.  See section 4.2.1.14 of
RFC2459, or of the updated Cert and CRL profile at:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-05.txt

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for
embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

------_=_NextPart_001_01C0B697.6B436630
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: CRLs </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Dean,</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>I was =
thinking about CRLDistributionPoint. But the question is how to verify =
such CRL, and what about CRL extensions and entry extension. From the =
begining.</FONT></P>

<P><FONT SIZE=3D2>1. What exactly should include field cRLIssuer in =
CRLDistributionPoint extension?</FONT>
<BR><FONT SIZE=3D2>2. I should received verification path for the cert, =
which signed CRL. And I think that the root certificate should the one, =
which sign certificate. Otherwise it's possible to create false CRL =
(maybe I'm wrong, I don't know the answer to question #1).</FONT></P>

<P><FONT SIZE=3D2>3. What about CRL extension: Issuing Distribution =
Point - to indicate that CRL is indirect, and CRL entry extension: =
Certificate Issuer - to identify certificate issuer.</FONT></P>

<P><FONT SIZE=3D2>In general, how such CRL should be validated? I think =
that standard is not consistent, and should be changed.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Pawel Krupinski</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Dean Povey [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 27, 2001 1:25 AM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: CRLs </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt;Hi,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I'm trying =
to split CA functionality. I want to have one private key</FONT>
<BR><FONT SIZE=3D2>&gt;to sign certificates (CA key), and the second =
one to sign CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First is it =
possible to do it? Because in the standard I've found:</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;The CRL is signed using the CA's private =
key.&quot; (is it the same CA, which</FONT>
<BR><FONT SIZE=3D2>&gt;sign this certificate? In other words, CA can =
only revoke certificates it</FONT>
<BR><FONT SIZE=3D2>&gt;signed, Am I right?)</FONT>
</P>

<P><FONT SIZE=3D2>Hi Pawel,</FONT>
</P>

<P><FONT SIZE=3D2>You can use the cRLDistributionPoint extension to =
indicate a CRL issuer </FONT>
<BR><FONT SIZE=3D2>other than the CA that issued the Certificate.&nbsp; =
See section 4.2.1.14 of</FONT>
<BR><FONT SIZE=3D2>RFC2459, or of the updated Cert and CRL profile =
at:</FONT>
</P>

<P><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-05=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-pkix-ne=
w-part1-05.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Dean =
Povey,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | e-m: =
[email-masked] | JCSI:&nbsp; Java Crypto Toolkit </FONT>
<BR><FONT SIZE=3D2>Research Scientist&nbsp; | ph:&nbsp; +61 7 3864 =
5120&nbsp;&nbsp; | uPKI:&nbsp; C PKI toolkit for embedded</FONT>
<BR><FONT SIZE=3D2>Security Unit, DSTC | fax: +61 7 3864 =
1282&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
systems</FONT>
<BR><FONT SIZE=3D2>Brisbane, Australia | www: security.dstc.com | =
Oscar: C++ PKI toolkit </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B697.6B436630--

From: =?Windows-1252?Q?Juan_Antonio_P=E9rez_de_la_Fuente?= <[email-masked]>
To: <[email-masked]>
Date: Tue, 27 Mar 2001 10:13:57 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01C0B6A6.A2724CC0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

subscribe

------=_NextPart_000_002A_01C0B6A6.A2724CC0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>subscribe</DIV></BODY></HTML>

------=_NextPart_000_002A_01C0B6A6.A2724CC0--

From: "Manger, James H" <[email-masked]>
To: [email-masked]
Subject: RE: OCSPv2: 02: certHash is not unique
Date: Tue, 27 Mar 2001 11:15:07 +1000

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B65B.616CBAEE
Content-Type: text/plain;
	charset="iso-8859-1"

That's fine.

----------

------_=_NextPart_001_01C0B65B.616CBAEE
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 5.00.3105.105" name=GENERATOR></HEAD>
<BODY>
<P><FONT color=#0000ff face=Arial size=2>That's fine.</FONT></P>
<P><FONT color=#0000ff face=Arial size=2>This is probably the best 
approach.&nbsp; It offers potentially useful flexibility without introducing 
extra security issues for certificate parsers.&nbsp;&nbsp;Explicitly stating 
that certHash is only likely to be appropriate in selected environments may 
diffuse some criticism.</FONT></P>
<P><FONT size=2>----------<BR>From: Michael Myers [<A 
href="mailto:[email-masked]">mailto:[email-masked]</A>]<BR>Sent: 
Tuesday, 27 March 2001 10:51</FONT></P>
<P><FONT size=2>..I'd prefer to maintain certHash a option but composed in the 
manner you describe..<BR></P></FONT></BODY></HTML>

------_=_NextPart_001_01C0B65B.616CBAEE--

From: "Michael Myers" <[email-masked]>
To: "Manger, James H" <[email-masked]>, <[email-masked]>
Subject: RE: OCSPv2: 02: certHash is not unique
Date: Mon, 26 Mar 2001 16:51:23 -0800
Importance: Normal

James,

A good catch.  Thanks for taking the time to read the OCSPv2-02.

I was convinced to include certHash among the ReqCert CHOICEs based on a
projection that some PKI-using environments may find this form of
certificate identification more useful to their needs than others,
particularly those that are bandwidth-constrained.

You propose that a hash over the signed portion of the certificate (i.e. the
same hash that goes into the signature) would eliminate the risk you've
identified.  I'll take any opportunity I can to simplify the protocol;
deleting certHash as a ReqCert option certainly addresses that design
objective.  At this point though I'd prefer to maintain certHash a option
but composed in the manner you describe.

This would at a minimum separate out the security of this mechanism from the
question of whether or not this mechanism, even though secure in its
specification, provides sufficient value to warrant the additional
complexity in the protocol.

Mike

To: [email-masked]
cc: [email-masked]
Subject: Re: CRLs 
Date: Tue, 27 Mar 2001 10:24:47 +1000
From: Dean Povey <[email-masked]>

>Hi,
>	I'm trying to split CA functionality. I want to have one private key
>to sign certificates (CA key), and the second one to sign CRLs.
>	First is it possible to do it? Because in the standard I've found:
>"The CRL is signed using the CA's private key." (is it the same CA, which
>sign this certificate? In other words, CA can only revoke certificates it
>signed, Am I right?)

Hi Pawel,

You can use the cRLDistributionPoint extension to indicate a CRL issuer 
other than the CA that issued the Certificate.  See section 4.2.1.14 of
RFC2459, or of the updated Cert and CRL profile at:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-05.txt

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

To: [email-masked]
cc: [email-masked]
Subject: Re: Logotypes in certificates 
Date: Tue, 27 Mar 2001 10:16:09 +1000
From: Dean Povey <[email-masked]>

>> One way, is that the CA can ensure that the logo is a registered
>> trademark owned by the subject it is being issued to.  The USPTO and other
>> organisations like it already have processes to ensure that trademarks are
>> not confusingly similar.
>
>I disagree. The organizations registering trade marks/logos (e.g.
>Deutsches Patentamt in Germany) do not guarantee that the trade
>marks/logos are not similar to others. They're just doing the
>registration, no exhaustive checking for conflicts => a CA cannot
>rely on such a service.

My apologies, I made such a broad generalisation based on my knowledge of
what I had recently read about the USPTO and what I remembered about the
Trademark process in Australia.  I think you would concede however that
while they might not do exhaustive checking, the trademark process provides
some level of assurance as companies are quite vigilant about protecting
their trademarks.  Users merely have to treat the information appropriately
in view of this, as they have to do with all information that they find in
a Certificate.

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

To: Bodo Moeller <[email-masked]>
cc: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Logotypes [not] in certificates 
Date: Tue, 27 Mar 2001 10:13:11 +1000
From: Dean Povey <[email-masked]>

<snip>
>> target.  For a concrete examples see the recent slashdot story:
>> 
>> http://slashdot.org/articles/01/03/22/1947233.shtml
>> 
>> And MicroSoft's Bulletin:
>> http://www.microsoft.com/technet/security/bulletin/MS01-017.asp
>> 
>> Logos are much easier for humans to recognise.  By having a CA bind the
>> public key to a logo and having the UI use it appropriately you enable
>> users to make much better decisions about how they use their certificates.
>
>I am not sure I get your point.  Are you saying that including logos
>into certificates could have prevented this from happening?
>According to the Microsoft Security Bulletin,
>
>     VeriSign, Inc., recently advised Microsoft that on January 29 and 30,
>     2001, it issued two VeriSign Class 3 code-signing digital certificates
>     to an individual who fraudulently claimed to be a Microsoft employee.
>
>I fail to see what difference it would have made to include logos into
>the process.

Hmm, I just reread the information.  I had misunderstood, I thought it was 
just the case that they had mistakenly issued a Microsoft Corp CN, but 
that the DN was some division in Microsoft.  Providing the CA had rules 
about only issuing logos to corporate identities, rather than specific 
divisions this would mitigate the risk somewhat. But even given my 
misunderstanding I agree it is a weak example. Mea Culpa.

However, in at least one other post I have given a much better example 
where ambiguity in names leads to poor security.

>In the message that started this thread it was claimed that "logotypes
>are carriers of trust," whatever this means.  The argument was made
>that certificates "must be user friendly" and not only be accessible
>to "technically oriented users".  Let me assume the role of advocatus
>diaboli: The basic idea appears to be that users who don't have a clue
>of what is going on should not notice that they don't.  The technical
>process of certification is enriched with colourful logotypes to give
>certificate recipients warm fuzzies and convey a feeling of "trust."
>Users who don't understand the concept of chain validation and the
>risks of mis-certification will gladly accept certificates as genuine
>because they carry the proper logo.  In other words, we are discussing
>how to enable the digital world for one of the traditional tricks for
>faking physical ID, which is to use logos to evoke trust.

Au contrair.  The idea is to make user's more involved in the process, not 
more removed from it.  The point about the logo is it is in your face.
Browser designers tend to hide away Certificate details.  Of course it is 
not perfect, but it is a lot better than what tends to happen at the 
moment (i.e. users just ignore it all together).

I think the risk of certification being subverted by logos is being 
overstated somewhat.  Providing the CA follows good rules for 
certification (e.g. ensure the logo is a registered trademark), they must 
surely be as good as standard text names which are also ambiguous.

The logo is just there as an extra datapoint, it cannot be relied on for 
path processing (partially because the current proposal is an external 
reference and the image may simply not be available at the time of 
processing).

>You say that logos bound to public keys "enable users to make much
>better decisions about how they use their certificates."  Will logos
>really help to make *better* decisions?  Won't they rather make it
>easier to make mistakes?

Well, I think it is a good start if users are actually making decisions. 
Yes logos can cause a false sense of security if:

- The CA gets it wrong
- The CA lies
- The user mistakenly recognises the logo as belonging to someone else.

However, at least for the first two points, the whole PKI system falls down
in a screaming heap if this happens anyway (well at least it will for the 
first as long until CRLs become truly ubiquitous).  The third point is also
true for names.  What, are you saying that people will be more confident in
their mistake if they choose a logo over a name?  I think that the cases 
where this will happen are going to be rare in practice.  After all a logo 
is only useful if the user recognises it as belonging to an established 
brand, so they will most likely discount their trust in the site 
accordingly.

No one seems to be objecting to the fact that names are ambiguous, and that 
all of the same issues being pointed out for logos are true for names.   
Yet everyone seems comfortable with names in Certificates.  We are not 
proposing replacing names, merely adding additional information to the 
certificate to aid the user.

Cheers.
Dean.

Date: Mon, 26 Mar 2001 11:18:29 -0700
From: "Tolga Acar" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: WG Last Call: Algorithms draft

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_93C81BED.DABBB8F3
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Tim,

Here are my comments:

* For reference to the RFC corresponding to PKCS#1, RFC2437 obsoletes =
RFC2313. Replace all references to 2313 with 2437.

* For DSA, there is a FIPS 186-2. It may be wise to replace all references =
to FIPS 186 by FIPS 186-2.

* In Section 2.3.3, the Diffie-Hellman's Domain Parameters definition, it =
says"g specifies the generator of the multiplicative subgroup of order g". =
The order is not g, it must be q. Yes, the same error is also in RFC2459, =
and I posted about this more than a year ago, but no one seems to care.
It is also prudent to modify the definition of q as "the large prime =
factor of p-1, and the order of g".

* A refererence to the IEEE's P1363 Standard Specifications for Public Key =
Cryptography seems appropriate for all algorithms, in addition to =
references to various X9s.

* In section 2.3.5, definition of id-ecPublicKey has a reference to =
id-publicKeyType, that is undefined. I suspect it is a typo.

Best,
- Tolga

>>> Tim Polk <[email-masked]> 3/21/01 15:06:45 >>>
Folks,

This message announces Working Group Last Call for the updates to the =
PKIX=20
Public Key Algorithms draft. The specification is currently available =
at=20
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-02.txt. =
The=20
chairs plan to request Proposed Standard status for this document, and =
it=20
will advance with the Certs and CRL Profile.

Last Call will remain open through at least April 4, 2001.

Thanks,

Tim Polk

--=_93C81BED.DABBB8F3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN-TOP: 2px; FONT: 10pt Arial; MARGIN-LEFT: 2px">
<DIV>Tim,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Here are my comments:</DIV>
<DIV>&nbsp;</DIV>
<DIV>* For reference to the RFC corresponding to PKCS#1, RFC2437 =
obsoletes=20
RFC2313. Replace all references to 2313 with 2437.</DIV>
<DIV>&nbsp;</DIV>
<DIV>* For DSA, there is a FIPS 186-2. It may be wise to replace all =
references=20
to FIPS 186 by FIPS 186-2.</DIV>
<DIV>&nbsp;</DIV>
<DIV>* In Section 2.3.3, the Diffie-Hellman's Domain Parameters definition,=
 it=20
says"g specifies the generator of the multiplicative subgroup of order g". =
The=20
order is not g, it must be q. Yes, the same error is also in RFC2459, and =
I=20
posted about this more than a year ago, but no one seems to care.</DIV>
<DIV>It is also prudent to modify the definition of q as "the large prime =
factor=20
of p-1, and the order of g".</DIV>
<DIV>&nbsp;</DIV>
<DIV>*&nbsp;A refererence to the IEEE's P1363 Standard Specifications for =
Public=20
Key Cryptography seems appropriate for all algorithms, in addition to =
references=20
to various X9s.</DIV>
<DIV>&nbsp;</DIV>
<DIV>* In section 2.3.5, definition of id-ecPublicKey has a reference =
to=20
id-publicKeyType, that is undefined. I suspect it is a typo.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Best,</DIV>
<DIV>- Tolga<BR><BR>&gt;&gt;&gt; Tim Polk &lt;[email-masked]&gt; =
3/21/01=20
15:06:45 &gt;&gt;&gt;<BR>Folks,<BR><BR>This message announces Working =
Group Last=20
Call for the updates to the PKIX <BR>Public Key Algorithms draft. The=20
specification is currently available at <BR><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-02.=
txt.">http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-02.tx=
t.</A>=20
The <BR>chairs plan to request Proposed Standard status for this document, =
and=20
it <BR>will advance with the Certs and CRL Profile.<BR><BR>Last Call will =
remain=20
open through at least April 4, 2001.<BR><BR>Thanks,<BR><BR>Tim=20
Polk<BR><BR></DIV></BODY></HTML>

--=_93C81BED.DABBB8F3--

Date: Mon, 26 Mar 2001 11:08:47 -0800
From: [email-masked] (Terry Hayes)
To: "Manger James H" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: OCSPv2: 02: certHash is not unique

--------------040200010205080701090504
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

James correctly points out some issues with the current definition of 
the proposed certHash method of identifying a certificate in an OCSP 
request.  I'd like to address several points in the message.

First, the draft does not indicate what digest algorithm should be used 
to calculate the hash.  This appears to be correct.  The current 
definition needs to be changed to include an AlgorithmInfo value that 
includes this information.

Second, he claims that the security of this method is suspect.  He has 
correctly pointed out a potential flaw in the security, however normal 
processing of certificates and signatures on certificates will prevent 
this from occurring.   James asserts that we should be "be strict with  
what you send but lenient with what you receive", but this general rule 
does not apply in situations where the security would be compromised.  
In this particular case two checks should be applied that will prevent 
this situation.  The primary check is that the signature algorithm in 
the "outer" portion of the certificate should match exactly the value in 
the "inner" (to-be-signed) portion.  A secondary solution is to ensure 
that the signatureAlgorithm field is exactly as defined for the 
algorithm used (DER-encoding rules are followed).

While the security is maintained given the correct procedures, it is 
easy to see how an implementation would get it wrong.  The need for 
these checks should certainly be mentioned in a security note in the draft.

Third, the certHash field is difficult to use in some deployments.  
Amberish points out that a certHash is not useful to a responder that is 
acting as a proxy for OCSP (or DPV).  In addition, even service that is 
responding for a single CA may not have certHash data available if it 
relies on CRLs for its revocation information.

Overall, I don't think the utility of this particular method of 
identification overcomes the potential problems and limitations.  I 
would be in favor of deleting it from the draft.

Terry Hayes

Manger, James H wrote:

> In section 3.1.2 Certificate Identification, the ReqCert type includes 
> a certHash field as one option for a client to identify a 
> certificate.  The syntax for the certHash field is an OCTET STRING.
> 
> There is no text describing the certHash field.  I guess it holds a 
> hash of the certificate.  I guess the hash is calculated over the 
> DER-encoding of the complete certificate.  There seems to be no 
> indication of the hash algorithm - perhaps it is always SHA-1.
> 
> I guess a certHash value is supposed to match the certificate 
> "fingerprint" or "thumbprint" that the browsers display.  A browsers 
> relies on a thumbprint unambiguously identifying a single 
> certificate.  OCSPv2, on the other hand, relies on a 
> certificate having a unique certHash value.  These properties - 
> unambiguity and uniqueness - are quite different.  It is reasonable to 
> assume a certificate thumbprint is unambiguous, but it is dangerous to 
> assume it is unique for the certificate.
> 
> There are a number of ways to alter the encoding of the unsigned 
> portion of a certificate (signatureAlgorithm field, signatureValue 
> field and outer most tags).  Such modification don't alter the signed 
> portion so the signature remains valid, but they do change the 
> thumbprint.  An attacker can modify the bytes (hence thumbprint) 
> For instance, consider omitting the NULL signature parameters 
> associated with sha1WithRSAEncryption in the signatureAlgorithm 
> field.  It is not unreasonable for a system to still accept such a 
> certificate (particularly with the "be strict with what you send but 
> lenient with what you receive" philosophy).  Yet the bytes do change 
> so the thumbprint also changes.
> 
> An OCSPv2 responder may have one thumbprint of a certificate in its 
> table of revoked certificates, but would return "good" if a different 
> thumbprint for the same certificate appeared in the certHash field.
> 
> A better thumbprint (that is unique for a certificate) is a hash over 
> only the signed portion of the certificate (i.e. the same hash that 
> goes into the signature).
> 

--------------040200010205080701090504
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html><head></head><body>James correctly points out some issues with the
current definition of the proposed certHash method of identifying a certificate
in an OCSP request.&nbsp; I'd like to address several points in the message.<br>
<br>
First, the draft does not indicate what digest algorithm should be used to
calculate the hash.&nbsp; This appears to be correct.&nbsp; The current definition
needs to be changed to include an AlgorithmInfo value that includes this
information.<br>
<br>
Second, he claims that the security of this method is suspect.&nbsp; He has correctly
pointed out a potential flaw in the security, however normal processing of
certificates and signatures on certificates will prevent this from occurring.
&nbsp; James asserts that we should be "be strict with&nbsp; what you send but lenient
with what you receive", but this general rule does not apply in situations
where the security would be compromised.&nbsp; In this particular case two checks
should be applied that will prevent this situation.&nbsp; The primary check is
that the signature algorithm in the "outer" portion of the certificate should
match exactly the value in the "inner" (to-be-signed) portion.&nbsp; A secondary
solution is to ensure that the signatureAlgorithm field is exactly as defined
for the algorithm used (DER-encoding rules are followed).<br>
<br>
While the security is maintained given the correct procedures, it is easy
to see how an implementation would get it wrong.&nbsp; The need for these checks
should certainly be mentioned in a security note in the draft.<br>
<br>
Third, the certHash field is difficult to use in some deployments.&nbsp; Amberish
points out that a certHash is not useful to a responder that is acting as
a proxy for OCSP (or DPV).&nbsp; In addition, even service that is responding
for a single CA may not have certHash data available if it relies on CRLs
for its revocation information.<br>
<br>
Overall, I don't think the utility of this particular method of identification
overcomes the potential problems and limitations.&nbsp; I would be in favor of
deleting it from the draft.<br>
<br>
Terry Hayes<br>
<br>
<br>
Manger, James H wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">
  <p><font face="Arial"><font size="2">Comment on <font size="2">draft-ietf-pkix-ocspv2-02.txt<br><br></font></font><font size="2">In 
section 3.1.2 <em>Certificate Identification</em><span class="336071605-26032001"><em>, </em></span>the <strong>ReqCert</strong> type 
includes a <strong>certHash</strong> field as one option for a client to 
identify&nbsp;a certificate.<span class="336071605-26032001">&nbsp; The syntax for 
the <strong>certHash</strong> field is an <strong>OCTET 
STRING</strong>.</span></font></font></p>
  <p><font face="Arial"><font size="2"><span class="336071605-26032001">There is no text 
describing the <strong>certHash</strong> field.&nbsp;&nbsp;I guess it holds a 
hash of the certificate.&nbsp; I guess the hash is calculated over the 
DER-encoding of the complete certificate.&nbsp; There seems to be no indication 
of the hash algorithm -&nbsp;perhaps it is always 
SHA-1.</span></font></font></p>
  <p><font face="Arial"><font size="2"><span class="336071605-26032001">I guess a 
<strong>certHash</strong> value is supposed to match the certificate 
"fingerprint" or "thumbprint" that the browsers display.&nbsp; A browsers relies 
on&nbsp;a thumbprint unambiguously identifying a single certificate.&nbsp; 
OCSPv2, on the other hand, relies on&nbsp;a certificate&nbsp;having a unique 
<strong>certHash</strong> value.&nbsp; These properties - unambiguity and 
uniqueness - are quite different.&nbsp; It is reasonable to assume a certificate 
thumbprint is unambiguous, but it is dangerous to assume it is unique for the 
certificate.</span></font></font></p>
  <p><font face="Arial" size="2"><span class="336071605-26032001">There are a number of 
ways to alter the encoding of the unsigned portion of a certificate 
(<strong>signatureAlgorithm</strong> field, <strong>signatureValue</strong> 
field and outer most tags).&nbsp; Such modification don't alter the signed 
portion so the signature remains valid, but they do change the thumbprint.&nbsp; 
An attacker can modify the bytes (hence thumbprint) without modifying the 
semantics of a certificate.</span></font></p>
  <p><font face="Arial" size="2"><span class="336071605-26032001">For instance, consider 
omitting the <strong>NULL</strong> signature parameters associated with 
<strong>sha1WithRSAEncryption</strong> in the 
<strong>signatureAlgorithm</strong> field.&nbsp; It is not unreasonable for a 
system to still accept such a certificate (particularly with the "be strict with 
what you send but lenient with what you receive" philosophy).&nbsp; Yet the 
bytes do change so the thumbprint also changes.</span></font></p>
  <p><font face="Arial" size="2"><span class="336071605-26032001">An OCSPv2 responder may 
have&nbsp;one thumbprint of a certificate in its table of revoked certificates, 
but would return "<font face="Courier New">good</font>" if a different 
thumbprint for the same certificate appeared in the <strong>certHash</strong> 
field.</span></font></p>
  <p><font face="Arial" size="2"><span class="336071605-26032001">A better thumbprint 
(that is unique for a certificate) is a hash over only the signed portion of the 
certificate (i.e. the same hash that goes into the signature).</span></font></p>
  <p><font face="Arial" size="2"><span class="336071605-26032001">SOLUTION:&nbsp; Delete 
the <strong>certHash</strong> field from the <strong>ReqCert</strong> 
type.</span></font></p>
  </blockquote>
  <br>
</body></html>
--------------040200010205080701090504--

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: some thoughts re DPD and DPV
Date: Mon, 26 Mar 2001 10:36:18 -0800
Importance: Normal

Peter,

It's not clear to me that a separate, perhaps private, extension to OCSP
is needed to enable a CA to indicate a certificate's validity beyond that
currently defined by the DPV I-D (now folded into the OCSPv2 I-D along
with the DPD I-D).

Note that there exists DPV as a concept and DPV as specified over OCSP.
The later defines a value of id-pkix-ocsp-valid-rsp for use in
ResponseBytes.ResponseType field vs. the value of id-pkix-ocsp-basic
defined by RFC 2560.  The effect is that that values of CertStatus
become context sensitive against the value of ResponseBytes.ResponseType
but in a fashion that enables full backwards interoperability with
RFC 2560.  For example,

   IF   {certStatus == 0 AND responseType == id-pkix-ocsp-basic }
   THEN the certificate is NOT REVOKED as defined by RFC 2560bis

while

   IF   {certStatus == 0 AND responseType == id-pkix-ocsp-valid-rsp }
   THEN the certificate is VALID as defined by OCSPv2.

The latter means at a minimum that the responder confirms that
subject certificate passes the path validation algorithm defined
by RFC 2459.

Does this work for your needs?

Mike

Content-return: allowed
Date: Mon, 26 Mar 2001 08:29:59 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: some thoughts re DPD and DPV
To: "'Carlin Covey'" <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: Paul Hoffman / IMC <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked]

One of the things that we have had in SCVP for some time was the
following:

a. A configuration identifier
b. A usage area

The configuration identifier was a shortcut for a client to 
provide configuration parameters.

The usage, where the client says what purpose it wants to use
the certificate for.

The thing we need to add to the usage, is an extra parameter,
which contains data that applies to that usage - the server
URL where you are an SSL client, the sender e-mail where you
are an e-mail recipient, etc.

Regards,
Ambarish

> Sent: Monday, March 26, 2001 7:40 AM
> To: Denis Pinkas
> Cc: Paul Hoffman / IMC; Stephen Kent; [email-masked]
> Subject: RE: some thoughts re DPD and DPV
> 
> 
> Denis,
> 
> When I said "client-type" in my previous email, I meant email-client,
> browser, VPN-client etc.  I should have said "application."  
> I think we
> are in agreement on this point.  Sorry for the confusion.
> 
> Regards,
> 
> Carlin
> 
> -  Carlin Covey
>    Cylink Corporation
> 
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Monday, March 26, 2001 2:18 AM
> To: Carlin Covey
> Cc: Paul Hoffman / IMC; Stephen Kent; [email-masked]
> Subject: Re: some thoughts re DPD and DPV
> 
> <snip>
> 
> > I also agree with Paul that a typical client will
> > make a choice among very few policies.  In fact, most clients
> > will never make a choice.  The clients and servers will be
> > pre-configured with one policy per client-type per enterprise.
> 
> I do not believe so. The policy is application dependent. One 
> application
> will usually be linked with one policy. Since a client will 
> normally support
> multiple applications, he will use more than one policy.
> 
> <snip>
> 
> 

From: "Carlin Covey" <[email-masked]>
To: <[email-masked]>, "Denis Pinkas" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: RE: some thoughts re DPD and DPV
Date: Mon, 26 Mar 2001 09:23:11 -0700
Importance: Normal

Denis and Stephen,

Sorry to add on to this thread but ....

[Denis]: Steve introduced a nice notion, i.e. to limit 
         the number of paths that the client is prepared 
         to accept. It could then be one only or five. 
         If you get four what asking for five, this means 
         that you got the best the sever could do. 

         For that reason I do not see why we should support 
         a statefull server, which is what retryRefrence 
         implies. :-(

[Carlin]: Denis, suppose a client used Steve Kent's nice notion,
         and requested two paths, but wasn't happy with either 
         of them.  Does the client now ask for four paths (knowing 
         that the first two of them will be the two that it has
         already seen), or should the server be "stateful" and
         and return the next two paths that it hasn't already sent?
         The first option wastes bandwidth, the second option 
         requires that the server maintain state.  The client 
         could ask for four paths initially, but the client may 
         be happy with the first of the four paths, in which case 
         sending three additional paths is a waste of bandwidth.  

[Denis]: I noticed that you [Stephen Farrell] were the single one 
         at the IETF meeting advocating the need for the retryReference. 
         There might be other individuals present at the meeting or 
         people on the mailing list supporting this idea as well, but 
         up to now they have remain silent. :-)

[Carlin]: This is Carlin making some noise.    ;-)   
         retryReference helps to maintain synchronization between
         request and the server's state in the case of lost or delayed 
         requests or responses.  Even if Steve's nice notion were 
         implemented, I think you would still want a mechanism like 
         retryReference (un;ess you were willing to put up with 
         resending previously sent paths). 

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation 

Content-return: allowed
Date: Mon, 26 Mar 2001 08:21:48 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: OCSPv2: 02: certHash is not unique
To: "'Manger, James H'" <[email-masked]>, "[email-masked]'" <[email-masked]>

Hi James,

Regards,
Ambarish

-----Original Message-----
From: Manger, James H [mailto:[email-masked]]
Sent: Sunday, March 25, 2001 10:15 PM
To: [email-masked]'
Subject: OCSPv2: 02: certHash is not unique

From: "Carlin Covey" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "Paul Hoffman / IMC" <[email-masked]>, "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: RE: some thoughts re DPD and DPV
Date: Mon, 26 Mar 2001 08:40:13 -0700
Importance: Normal

Denis,

When I said "client-type" in my previous email, I meant email-client,
browser, VPN-client etc.  I should have said "application."  I think we
are in agreement on this point.  Sorry for the confusion.

Regards,

Carlin

-  Carlin Covey
   Cylink Corporation

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Monday, March 26, 2001 2:18 AM
To: Carlin Covey
Cc: Paul Hoffman / IMC; Stephen Kent; [email-masked]
Subject: Re: some thoughts re DPD and DPV

<snip>

> I also agree with Paul that a typical client will
> make a choice among very few policies.  In fact, most clients
> will never make a choice.  The clients and servers will be
> pre-configured with one policy per client-type per enterprise.

I do not believe so. The policy is application dependent. One application
will usually be linked with one policy. Since a client will normally support
multiple applications, he will use more than one policy.

<snip>

From: "Peter H. Gien" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Wed, 26 Mar 1997 09:52:38 -0500
Importance: Normal

unsubscribe

Date: Mon, 26 Mar 2001 15:13:22 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Denis Pinkas <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: some thoughts re DPD and DPV

Denis,

> " Steve introduced a nice notion, i.e. to limit the number of paths that the
> client is prepared to accept. It could then be one only or five. If you get
> four what asking for five, this means that you got the best the sever could
> do."

What's the server supposed to do when the client says "5"? Is it supposed
to find all possible paths and return just 5? If so, the protocol doesn't
have a way for the client to recover if the client doesn't like all 5
returned. 

Or, is the server supposed to do whatever it likes (say finding
one) and send that back? In that case, the client who doesn't like the
result has to at some point increase the number in the request. But
hang on, that server already has one path that satisfies the request,
so it'll just send that back and never go looking for more paths. (Unless
the server is stateful per-client of course:-)

Basically, you're not sending the right signals but developing a protocol
which can lead to a kind of livelock (maybe that's not the right term 
though? http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?livelock defines it).

retryReference or an equivalent mechanism is needed and I haven't seen
any other worked out proposal for an equivalent mechanism. I'm sure one 
could be proposed, it hasn't so far (or send the URL if I missed it).

> You are ignoring the fact that if the client does not specify trust points,
> the server will. If the client is not pleased with these trust points, then
> it
> should specify itself the trust points. AFAIR, you did not disagreed with
> Steve during the meeting about the number of paths that, in practice, would
> be returned, taking into account the existence of cross-certificates.

But the server hasn't told the client which trust paths it picked, so if 
the client asks again then the client has no way to say that it didn't like 
the previous answer.

> > 3) unnecessary and inefficient bloat: given that 90% (or whatever) of the time
> > any path is a fine answer - we shouldn't bloat 100% of responses for the sake
> > of a small number of cases
> 
> If the criteria is finely tuned, then you are right and only one path will
> be returned. If the criteria is "broad", e.g. three root keys with no other
> constraints, then you may get more and any path is a fine answer to the
> question raised, but not any more when applying additional local conditions.

This is the "that's a bad path construction policy" argument I mentioned
in my first mail.

> I agree with you that "statefull server" might be an overstatement. Let us
> speak of cache management. I would think that it may be appropriate for
> efficiency reasons to keep track of already found paths. This does not mean
> that the leaf certificate must be kept, but that all the CA certificates
> above that path might be kept. Now this cached information should not be
> associated with a retryReference number, so that *any* subsequent client can
> get advantage of a speed improvement as soon as the CA from the leaf
> certificate is the same. 

There's nothing to prevent implementations doing such but that level of
cache management does not need to be visible in the protocol. The path
level does however due to the inherent "incompleteness" of path construction 
policy.

> However, all these details are implementation
> details, not visible at a protocol level. Hence we do not need to support a
> retryReference number.

We clearly disagree.

I think one of the things that Steve K. is keen we do more of is think about
state machines. IMO, the retryReference is a useful trick that matches well with
the state machine folks would implement (and which probably does need more work
in the ocspv2 draft). It seems that the putative alternative (client says: "I'll 
take up to 5") leads to a state machine which (admittedly in rare cases) causes 
the protocol to fail to do its job.

In any case, the ocspv2 proposal contains the retryReference for now and I think 
we've aired the arguments enough for today at least. Probably better to look at
it again in the next draft of ocspv2 and see what we all think then.

Stephen.
-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: Dave Farrell <[email-masked]>
To: [email-masked]
Subject: 
Date: Mon, 26 Mar 2001 08:58:51 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B5FE.96B9142A
Content-Type: text/plain; charset="iso-8859-1"

unsubscribe ietf-pkix <mailto:[email-masked]> @imc.org

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

------_=_NextPart_001_01C0B5FE.96B9142A
Content-Type: text/html; charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT size=2><FONT face="Bookman Old Style" size=3>
<P>unsubscribe <A href="mailto:[email-masked]">ietf-pkix<SPAN 
class=161180714-26032001>@</SPAN>imc.org</A></P></FONT></FONT></DIV><CODE><FONT SIZE=3><BR>
<BR>
-----------------------------------------------------------------------------------------------------------------<BR>
The information contained in this message is confidential and is intended <BR>
for the addressee(s) only.  If you have received this message in error or <BR>
there are any problems please notify the originator immediately.  The <BR>
unauthorized use, disclosure, copying or alteration of this message is <BR>
strictly forbidden. Baltimore Technologies plc will not be liable for direct, <BR>
special, indirect or consequential damages arising from alteration of the <BR>
contents of this message by a third party or as a result of any virus being <BR>
passed on.<BR>
<BR>
In addition, certain Marketing collateral may be added from time to time to <BR>
promote Baltimore Technologies products, services, Global e-Security or <BR>
appearance at trade shows and conferences.<BR>
 <BR>
This footnote confirms that this email message has been swept by <BR>
Baltimore MIMEsweeper for Content Security threats, including<BR>
computer viruses.<BR>
</FONT></CODE></BODY></HTML>

------_=_NextPart_001_01C0B5FE.96B9142A--

Date: Mon, 26 Mar 2001 15:01:24 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: some thoughts re DPD and DPV

Steve,

(deleted stuff)

> > So the basic question that I ask you is the following: why not retrurn once
> > all these four certification paths ?
 
> 1) the server probably won't have all of 'em to start with (is every server
> implementation going to do an exhaustive search for every new request? what
> about when 1 of 6 LDAP servers doesn't respond to the DPD server?)

You have deleted one paragraph from my previous e-mail that provides you
with an answer. I copy here again for you:

" Steve introduced a nice notion, i.e. to limit the number of paths that the
client is prepared to accept. It could then be one only or five. If you get
four what asking for five, this means that you got the best the sever could
do." 

If you ask for one path, then you will not get more than one (you may get
none !). If you ask for three paths, but 1 of 6 LDAP servers doesn't
respond, 
then you will only get two paths. At some point of time in the future you 
might get more. So I do not see that there is a problem here.

> 2) I disagree about the "4" - you're ignoring different validity periods and
> also caCertificates which, if they exist, can lead anywhere if the client
> doesn't specify trust points

You are ignoring the fact that if the client does not specify trust points,
the server will. If the client is not pleased with these trust points, then
it
should specify itself the trust points. AFAIR, you did not disagreed with
Steve during the meeting about the number of paths that, in practice, would
be returned, taking into account the existence of cross-certificates. 

> 3) unnecessary and inefficient bloat: given that 90% (or whatever) of the time
> any path is a fine answer - we shouldn't bloat 100% of responses for the sake
> of a small number of cases

If the criteria is finely tuned, then you are right and only one path will
be returned. If the criteria is "broad", e.g. three root keys with no other
constraints, then you may get more and any path is a fine answer to the
question raised, but not any more when applying additional local conditions.

> > For that reason I do not see why we should support a statefull server, which
> > is what retryRefrence implies. :-(
 
> "Statefull server" is an overstatement:-) I'd bet that any sensible DPD server
> code would want to remember paths it had sent in response to requests
> anyway (for speed and anti-DoS reasons). retryReference just leverages that.

I agree with you that "statefull server" might be an overstatement. Let us
speak of cache management. I would think that it may be appropriate for
efficiency reasons to keep track of already found paths. This does not mean
that the leaf certificate must be kept, but that all the CA certificates
above that path might be kept. Now this cached information should not be
associated with a retryReference number, so that *any* subsequent client can
get advantage of a speed improvement as soon as the CA from the leaf
certificate is the same. However, all these details are implementation
details, not visible at a protocol level. Hence we do not need to support a
retryReference number.

Regards,

Denis

> Stephen.

Date: Mon, 26 Mar 2001 14:18:57 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: pkix <[email-masked]>, S-MIME / IETF <[email-masked]>
Subject: ETSI ESI call on Policy requirements for TSAs

Policy requirements for Time-Stamping Authorities

The ETSI ESI working group (European Telecommunications Standards Institute,
Electronic Signature and Infrastructure working group) is working on a
standard addressing functional and quality requirements for Time-Stamping
Authorities to form the basis of a generic time-stamping policy.  This work
item is being carried out within the overall framework of the European
Electronic Signature Standardization Initiative (EESSI).

The initial focus of this standard is in support of qualified electronic
signatures (i.e. in line with article 5.1 of the European Directive on a
community framework for electronic signatures) but may be applied to any
application requiring trusted time-stamps of equivalent quality.

The aim of this document is to provide policy requirements equivalent to
those for CA issuing qualified certificates as defined in TS 101 456 
(see below for web site), but targeted at Time-Stamping Authorities.

International, European and national communities, authorities, associations,
standardization bodies, vendors, service providers, users are requested to
provide any information that is relevant to this activity to the editor
for this area of standardization (see below).  

In particular, ETSI ESI requests input on:

· Views on minimum essential requirements, for time-stamping services to
  provide a level of quality such as is necessary in support of legally
  recognised electronic signatures,

· Relevant documents and specifications (draft or approved) - 
  preferably in English

Even if your organization has no specific input to make, indications of
interest in this activity would be welcomed.  We can then keep you 
informed of the availability of drafts for comment.

Response is requested by end April 2001. However, if meeting schedules 
do not make this possible, input at the earliest convenience date 
would be welcomed.

It is planned to produce a first working draft for general review by 
3rd quarter of this year.

Further details, documents, and e-mail list registration on this and 
other activities of ETSI on electronic signature standardization 
(including TS 101 456) may be found on: 
http://www.etsi.org/sec/el-sign.htm

Please send responses to the editor of this document: 
Nick Pope. mailto:[email-masked]

Regards,

Denis

Date: Mon, 26 Mar 2001 12:26:10 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Denis Pinkas <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: some thoughts re DPD and DPV

Denis,

> I noticed that your were the single one at the IETF meeting advocating the
> need for the retryReference. There migh be other individuals present at the
> meeting or people on the mailing list supporting this idea as well, but up
> to now they have remain silent. :-)

That never seems to bother you, so I'm ok with it in this case:-)

> So the basic question that I ask you is the following: why not retrurn once
> all these four certification paths ?

1) the server probably won't have all of 'em to start with (is every server
implementation going to do an exhaustive search for every new request? what
about when 1 of 6 LDAP servers doesn't respond to the DPD server?)

2) I disagree about the "4" - you're ignoring different validity periods and
also caCertificates which, if they exist, can lead anywhere if the client
doesn't specify trust points

3) unnecessary and inefficient bloat: given that 90% (or whatever) of the time 
any path is a fine answer - we shouldn't bloat 100% of responses for the sake 
of a small number of cases

> For that reason I do not see why we should support a statefull server, which
> is what retryRefrence implies. :-(

"Statefull server" is an overstatement:-) I'd bet that any sensible DPD server
code would want to remember paths it had sent in response to requests 
anyway (for speed and anti-DoS reasons). retryReference just leverages that.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Date: Mon, 26 Mar 2001 12:30:57 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: some thoughts re DPD and DPV

Steve (Farrell),

Steve will not reply soon to your e-mail because he advertised that he will
be off on vacation this week. So do not assume that silence from him means
acceptance. :-)

> Steve (Kent),
> 
> Just picking up on this one...
> 
> > 3- we still have some significant disagreement about the nature of the path validation controls to
> > be used for both services, but especially for DPD. Related to this disagreement is the issue of
> > whether an DPD should support incremental queries relative to the same target certificate. I don't
> > think we have seen a concise, comprehensive description of the application model where such an
> > incremental approach is warranted, so I solicit the proponents of this approach to provide such a
> > description, so that we can resolve this issue.
> 
> I'm glad to see that we're tending towards the "abbreviated" DPD/DPV protocol,
> rather than exhaustively specifying options on the wire. The retryReference field
> in DPD is, I believe, necessary regardless of whether we take this sensible
> approach or the more verbose approach.

I noticed that your were the single one at the IETF meeting advocating the
need for the retryReference. There migh be other individuals present at the
meeting or people on the mailing list supporting this idea as well, but up
to now they have remain silent. :-)

> Basically, the issue is that path constuction policies can never be "complete",
> in the sense that there is always the possibility that two paths exist which
> satisfy the policy, but where the application prefers one path over the other.
> (BTW: I simply assert this, I'm not saying I've a proof.)

Since the client may wish to apply additional conditions on the
certification path that he gets back, e.g. looking for the presence of
private extensions, then, in theory, what you say is certainly possible.
However, as Steve (Kent) noticed during the meeting, in practice, no more
than four certification path would ever be returned. 

So the basic question that I ask you is the following: why not retrurn once
all these four certification paths ? 

Steve introduced a nice notion, i.e. to limit the number of paths that the
client is prepared to accept. It could then be one only or five. If you get
four what asking for five, this means that you got the best the sever could
do. 

For that reason I do not see why we should support a statefull server, which
is what retryRefrence implies. :-(

Hoping that your next message can close this thread ...

Regards,

Denis
 
> The inclusion/exclusion of a non-critical application-specific extension
> in one certificate in the path can cause this, as can overlaps in the
> validity fields of certificates (which some application may choose to care
> about).
> 
> What you're left with is the fact that its not actually possible (never
> mind wise:-), to include in a protocol every possible thing that an application
> may care about related to path construction policy.
> 
> Without the retryReference field, the server is basically leaving any such
> application stranded. If the application retries the "meat" of the request,
> then it'll get the same response. The application's only choice is to start
> "guessing" variations on the request which might produce a different response.
> Not a good idea.
> 
> Some folks might counter that this just means that the path construction policy
> being used is "bad", and say that we should just introduce a new path construction
> policy. Well, as you can see from the above I don't think that works in general,
> and even if it did work in lots of cases a) we might end up generating *lots*
> of path construction polices, a recipie for confusion, and b) the resulting
> DPD protocol would still suffer from the problem described in the previous
> paragraph, which sounds like a bad characteristic of a "query" style
> protocol.
> 
> So, we're left with a problem of finding "another", or equally, "the next"
> path that satisfies the relevant path construction policy, and of managing
> the restricted state information necessary for this purpose. (As I said at
> the meeting, the state in question need *not* be DPD-client specific, but is
> rather returned-path-specific, a different thing entirely. A hash over the
> path is probably a good implementation choice for the retryReference value.)
> 
> That's what the retryReference allows - the client, for whatever reason,
> says: "didn't like that path"; the server, if it supports the function (which
> I think it should, at least to handle overlapping validity periods), tries
> to find another path and if it does returns that (with a new retryReference).
> 
> You said concise, so I'll stop now. I can only hope this is comprehensive too:-)
> 
> Hoping this doesn't turn into another of those endless threads...
> Stephen.
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:[email-masked]
> Ireland                             http://www.baltimore.com

Date: Mon, 26 Mar 2001 11:05:34 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: some thoughts re DPD and DPV

Steve,

Just picking up on this one...

> 3- we still have some significant disagreement about the nature of the path validation controls to
> be used for both services, but especially for DPD. Related to this disagreement is the issue of
> whether an DPD should support incremental queries relative to the same target certificate. I don't
> think we have seen a concise, comprehensive description of the application model where such an
> incremental approach is warranted, so I solicit the proponents of this approach to provide such a
> description, so that we can resolve this issue.

I'm glad to see that we're tending towards the "abbreviated" DPD/DPV protocol,
rather than exhaustively specifying options on the wire. The retryReference field 
in DPD is, I believe, necessary regardless of whether we take this sensible 
approach or the more verbose approach. 

Basically, the issue is that path constuction policies can never be "complete", 
in the sense that there is always the possibility that two paths exist which 
satisfy the policy, but where the application prefers one path over the other.
(BTW: I simply assert this, I'm not saying I've a proof.)

The inclusion/exclusion of a non-critical application-specific extension
in one certificate in the path can cause this, as can overlaps in the
validity fields of certificates (which some application may choose to care
about).

What you're left with is the fact that its not actually possible (never
mind wise:-), to include in a protocol every possible thing that an application 
may care about related to path construction policy.

Without the retryReference field, the server is basically leaving any such
application stranded. If the application retries the "meat" of the request, 
then it'll get the same response. The application's only choice is to start
"guessing" variations on the request which might produce a different response.
Not a good idea.

Some folks might counter that this just means that the path construction policy
being used is "bad", and say that we should just introduce a new path construction
policy. Well, as you can see from the above I don't think that works in general,
and even if it did work in lots of cases a) we might end up generating *lots*
of path construction polices, a recipie for confusion, and b) the resulting 
DPD protocol would still suffer from the problem described in the previous 
paragraph, which sounds like a bad characteristic of a "query" style 
protocol.

So, we're left with a problem of finding "another", or equally, "the next"
path that satisfies the relevant path construction policy, and of managing
the restricted state information necessary for this purpose. (As I said at
the meeting, the state in question need *not* be DPD-client specific, but is
rather returned-path-specific, a different thing entirely. A hash over the 
path is probably a good implementation choice for the retryReference value.)

That's what the retryReference allows - the client, for whatever reason,
says: "didn't like that path"; the server, if it supports the function (which
I think it should, at least to handle overlapping validity periods), tries
to find another path and if it does returns that (with a new retryReference).

You said concise, so I'll stop now. I can only hope this is comprehensive too:-)

Hoping this doesn't turn into another of those endless threads...
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Date: Mon, 26 Mar 2001 11:18:17 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Carlin Covey <[email-masked]>
CC: Paul Hoffman / IMC <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: some thoughts re DPD and DPV

Carlin,

> Paul and Steve,
 
> I agree that the DPD and DPV protocols should be simplified by
> including just a reference to a server-resident path-validation
> policy.  

Fine.

> I also agree with Paul that a typical client will
> make a choice among very few policies.  In fact, most clients
> will never make a choice.  The clients and servers will be
> pre-configured with one policy per client-type per enterprise.

I do not believe so. The policy is application dependent. One application
will usually be linked with one policy. Since a client will normally support
multiple applications, he will use more than one policy.

> Simply including one policy OID in the request (possibly echoed
> in the response) will satisfy the great majority of use cases.

As I proposed during the last IETF meeting, if the client does not indicate
anything about the policy to be used in his request, then the server should
indicate what has been used.

> Paul points out the near-zero success-rate of policy protocols.
> DPD/DPV should not be made into a quasi-policy-protocol by
> including explicit policy information in the requests.  

See my proposal above. The client MAY include a reference or the client
SHOULD include a reference. 

> An OID
> will do.  If there remains a need for client-configuration of
> server-resident policies, put that in a separate protocol as
> Steve has suggested.

Fine.
 
> Let's proceed with a simplified, low-bandwidth DPD/DPV that is as
> free as possible of the burden of policy configuration.

Agreed.

Regards,

Denis

> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Friday, March 23, 2001 6:42 PM
> To: Stephen Kent; [email-masked]
> Subject: Re: some thoughts re DPD and DPV
> 
> At 7:09 PM -0500 3/23/01, Stephen Kent wrote:
> >We could make ALL requests refer to a policy configured at the
> >server, rather than allowing for explicit transmission of these
> >parameters. To make this as flexible as the current proposals, we
> >would have to add a new protocol, to allow a client to register a
> >policy with a server, so that the client could later refer to that
> >policy. We probably want a facility to inquire about a registered
> >policy as well.
> 
> This sounds horrendously complex. To date, the IETF has had near-zero
> success with defining policy protocols, with policy working groups
> pretty much being unable to get closure. The method promoted in SCVP
> (can give individual policy info in requests or can use aggregated
> OIDs) seems much more sensible than forcing all clients to know (or,
> worse, discover and push) the policies on the server.
> 
> The number of policies a typical client wants will probably be few
> (most likely, just roots). Why make this so much more complicated
> than needed?
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

From: [email-masked]
Subject: Extended certificate status fields (WAS: some thoughts re DPD and DPV)
To: [email-masked]
Cc: [email-masked]
Date: Mon, 26 Mar 2001 10:15:06 +0100

Peter, All,

I agree that the current OCSP certificate status values have room for
improvement.  I like the idea of an extension to achieve this purpose, but
don't see why we should restrict ourselves simply to a boolean.  Why not a
new 'detailedStatus' enum, that covers some of the other different states
explicitly: not yet valid, expired, suspended, for example, as well as
those states already discussed.  Alternatively, since not all of these
states a mutually exclusive, some kind of bitfield may be preferred.

Regards,

Jonathan
------------
Dr Jonathan Tuliani
www.symbian.com

                    [email-masked]                                                                                   
                    land.ac.nz             To:     [email-masked], [email-masked]                             
                    (Peter Gutmann)        cc:     [email-masked]                                                       
                    Sent by:               Subject:     RE: some thoughts re DPD and DPV                              
                    [email-masked]                                                                                   
                    land.ac.nz                                                                                        

                    24/03/01 14:02                                                                                    
                    Please respond                                                                                    
                    to pgut001                                                                                        

Speaking of OCSP, I have a suggestion for v2: Currently the status values
which
are returned are not-revoked, revoked, and unknown (note that I've used
"not-
revoked" rather than "OK" because what's called "OK" doesn't actually mean
the
cert is OK).  I've had a request from a user in Germany for an addition to
this
which provides a true-OK response (that is, a response of "This certificate
was
definitely issued and is valid as of the time the response was sent") as
well
as a true-invalid response ("This certificate wasn't issued/has been
revoked/has expired").  My suggestion for providing this was to create a
(private) extension which contains this information, but given that things
like
ISIS are doing something similar by overloading RFC 2560 it might be useful
to
make this a bit more standardised by adding it to the RFC rather than
having
everyone invent their own incompatible, ad-hoc solutions.

Note that this isn't any infringement on DPD/DPV's territory, all this is
doing
is providing more useful status information than the current return values
do.
For the extension I'd proposed the following:

  ExtendedStatus ::= BOOLEAN

  If set to true, the responder is indicating that the certificate has been
  issued and is curently valid.

  If set to false, the responder is indicating that the certificate has not
  been issued, has not become valid yet or has expired, or has been revoked
  (more information is contained in the certStatus field) or otherwise
  withdrawn from use.

This doesn't do any path validation or anything else provided for in
DPD/DPV,
all it is is an assertion from the CA/responder that as far as they're
concerned it's valid or it's not valid.  This is a very simple fix to OCSP
which is fully backwards-compatible and helps avoid the problems caused by
the
limited ability of the certStatus value to report certain certificate
conditions.

Peter.

Date: Mon, 26 Mar 2001 11:07:47 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: some thoughts re DPD and DPV

Peter,

> Speaking of OCSP, I have a suggestion for v2: Currently the status values which
> are returned are not-revoked, revoked, and unknown (note that I've used "not-
> revoked" rather than "OK" because what's called "OK" doesn't actually mean the
> cert is OK).  

I fully support this. I have been making the same request to Mike for months
(years ?) and I do hope that we will finally get that change done. :-)

> I've had a request from a user in Germany for an addition to this
> which provides a true-OK response (that is, a response of "This certificate was
> definitely issued and is valid as of the time the response was sent") as well
> as a true-invalid response ("This certificate wasn't issued/has been
> revoked/has expired").  My suggestion for providing this was to create a
> (private) extension which contains this information, but given that things like
> ISIS are doing something similar by overloading RFC 2560 it might be useful to
> make this a bit more standardised by adding it to the RFC rather than having
> everyone invent their own incompatible, ad-hoc solutions.

Everyone can make its own private extensions and in that case, and we are
not going to stop this. It would be the right thing to do. Supporting a
standardised way to advertise these status goes well behind the simple
addition of two status and is thus much more than " a very simple fix to
OCSP". These additions would not be compatible with our basic model
described in RFC 2459 or son-of-RFC2459. 

The main objection is the following:

If you rely on "this certificate was definitely issued [by the CA] and is
valid as of the time the response was sent", then there is no more need for
the client to check for the signature of the certificate since this check
will/can be done by the server. Furthermore, there is no need for a
signature itself on the certificate since the server will/can make a bit to
bit comparison with the certificate stored in its database or against a hash
of the full content of the certificate stored in its database. So going into
that direction would negate the need to sign certificates ! We could
certainly design a new architecture where certificates are no more
certificates since they do not need to be signed anymore, but I would
recommend to study these alternatives in a forum different from the IETF
PKIX WG.

There are other objections, since the model you are referring is also making
additional major changes from the PKIX model, in particular about the way to
check the validity of a certificate chain and the nomination of the OCSP
servers responsible for a given CA. Once again, we are in the PKIX WG with a
well defined model based on X.509. There are certainly alternatives to this
model. Alernatives may have their own merits. However, they should not be
progressed in the PKIX WG. Note that this topic has already been brought up
to the PKIX list and discarded.

Regards,

Denis

> Note that this isn't any infringement on DPD/DPV's territory, all this is doing
> is providing more useful status information than the current return values do.
> For the extension I'd proposed the following:
> 
>   ExtendedStatus ::= BOOLEAN
> 
>   If set to true, the responder is indicating that the certificate has been
>   issued and is curently valid.
> 
>   If set to false, the responder is indicating that the certificate has not
>   been issued, has not become valid yet or has expired, or has been revoked
>   (more information is contained in the certStatus field) or otherwise
>   withdrawn from use.
> 
> This doesn't do any path validation or anything else provided for in DPD/DPV,
> all it is is an assertion from the CA/responder that as far as they're
> concerned it's valid or it's not valid.  This is a very simple fix to OCSP
> which is fully backwards-compatible and helps avoid the problems caused by the
> limited ability of the certStatus value to report certain certificate
> conditions.
> 
> Peter.

From: [email-masked]
To: [email-masked]
Subject: CRLs
Date: Mon, 26 Mar 2001 09:41:49 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B5D0.9951E500
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
	I'm trying to split CA functionality. I want to have one private key
to sign certificates (CA key), and the second one to sign CRLs.
	First is it possible to do it? Because in the standard I've found:
"The CRL is signed using the CA's private key." (is it the same CA, which
sign this certificate? In other words, CA can only revoke certificates it
signed, Am I right?)
	
	I've read draft "Internet X.509 Public Key Infrastructure:
Certificate and CRL Profile" and I didn't find response. Could someone
explain me what for is CRL entry extension Certificate Issuer, I guess
should indicate certificate signer, but it should be the same authority
which signed CRL. In my opinion it's not clear enough.

Reagrds,

Pawel Krupinski

------_=_NextPart_001_01C0B5D0.9951E500
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>CRLs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>I'm =
trying to split CA functionality. I want to have one private key to =
sign certificates (CA key), and the second one to sign CRLs.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>First is =
it possible to do it? Because in the standard I've found: &quot;The CRL =
is signed using the CA's private key.&quot; (is it the same CA, which =
sign this certificate? In other words, CA can only revoke certificates =
it signed, Am I right?)</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>I've read =
draft &quot;Internet X.509 Public Key Infrastructure: Certificate and =
CRL Profile&quot; and I didn't find response. Could someone explain me =
what for is CRL entry extension Certificate Issuer, I guess should =
indicate certificate signer, but it should be the same authority which =
signed CRL. In my opinion it's not clear enough.</FONT></P>

<P><FONT SIZE=3D2>Reagrds,</FONT>
</P>

<P><FONT SIZE=3D2>Pawel Krupinski</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B5D0.9951E500--

Date: Mon, 26 Mar 2001 10:48:29 +0200
From: Bodo Moeller <[email-masked]>
To: Dean Povey <[email-masked]>
Cc: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Logotypes [not] in certificates

On Fri, Mar 23, 2001 at 07:59:17AM +1000, Dean Povey wrote:

> [...]  However, names are frequently ambiguous and in some cases are 
> difficult to recognise.  This leads to problems where an attacker obtains 
> a Certificate for a name similar to an organisation they are trying to 
> target.  For a concrete examples see the recent slashdot story:
> 
> http://slashdot.org/articles/01/03/22/1947233.shtml
> 
> And MicroSoft's Bulletin:
> http://www.microsoft.com/technet/security/bulletin/MS01-017.asp
> 
> Logos are much easier for humans to recognise.  By having a CA bind the
> public key to a logo and having the UI use it appropriately you enable
> users to make much better decisions about how they use their certificates.

I am not sure I get your point.  Are you saying that including logos
into certificates could have prevented this from happening?
According to the Microsoft Security Bulletin,

     VeriSign, Inc., recently advised Microsoft that on January 29 and 30,
     2001, it issued two VeriSign Class 3 code-signing digital certificates
     to an individual who fraudulently claimed to be a Microsoft employee.

I fail to see what difference it would have made to include logos into
the process.

In the message that started this thread it was claimed that "logotypes
are carriers of trust," whatever this means.  The argument was made
that certificates "must be user friendly" and not only be accessible
to "technically oriented users".  Let me assume the role of advocatus
diaboli: The basic idea appears to be that users who don't have a clue
of what is going on should not notice that they don't.  The technical
process of certification is enriched with colourful logotypes to give
certificate recipients warm fuzzies and convey a feeling of "trust."
Users who don't understand the concept of chain validation and the
risks of mis-certification will gladly accept certificates as genuine
because they carry the proper logo.  In other words, we are discussing
how to enable the digital world for one of the traditional tricks for
faking physical ID, which is to use logos to evoke trust.

(Exit advocatus diaboli.  Enter Bodo.)

You say that logos bound to public keys "enable users to make much
better decisions about how they use their certificates."  Will logos
really help to make *better* decisions?  Won't they rather make it
easier to make mistakes?

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

From: "Manger, James H" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: OCSPv2: 02: certHash is not unique
Date: Mon, 26 Mar 2001 16:14:50 +1000

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B5C0.3C2BFB3C
Content-Type: text/plain;
	charset="iso-8859-1"

------_=_NextPart_001_01C0B5C0.3C2BFB3C
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE></TITLE>

<META content="MSHTML 5.00.3105.105" name=GENERATOR></HEAD>
<BODY>
<P><FONT face=Arial><FONT size=2>Comment on <FONT 
face="Courier New"></FONT><FONT 
size=2>draft-ietf-pkix-ocspv2-02.txt<BR><BR></FONT></FONT><FONT size=2>In 
section 3.1.2 <EM>Certificate Identification</EM><SPAN 
class=336071605-26032001><EM>, </EM></SPAN>the <STRONG>ReqCert</STRONG> type 
includes a <STRONG>certHash</STRONG> field as one option for a client to 
identify&nbsp;a certificate.<SPAN class=336071605-26032001>&nbsp; The syntax for 
the <STRONG>certHash</STRONG> field is an <STRONG>OCTET 
STRING</STRONG>.</SPAN></FONT></FONT></P>
<P><FONT face=Arial><FONT size=2><SPAN class=336071605-26032001>There is no text 
describing the <STRONG>certHash</STRONG> field.&nbsp;&nbsp;I guess it holds a 
hash of the certificate.&nbsp; I guess the hash is calculated over the 
DER-encoding of the complete certificate.&nbsp; There seems to be no indication 
of the hash algorithm -&nbsp;perhaps it is always 
SHA-1.</SPAN></FONT></FONT></P>
<P><FONT face=Arial><FONT size=2><SPAN class=336071605-26032001>I guess a 
<STRONG>certHash</STRONG> value is supposed to match the certificate 
"fingerprint" or "thumbprint" that the browsers display.&nbsp; A browsers relies 
on&nbsp;a thumbprint unambiguously identifying a single certificate.&nbsp; 
OCSPv2, on the other hand, relies on&nbsp;a certificate&nbsp;having a unique 
<STRONG>certHash</STRONG> value.&nbsp; These properties - unambiguity and 
uniqueness - are quite different.&nbsp; It is reasonable to assume a certificate 
thumbprint is unambiguous, but it is dangerous to assume it is unique for the 
certificate.</SPAN></FONT></FONT></P>
<P><FONT face=Arial size=2><SPAN class=336071605-26032001>There are a number of 
ways to alter the encoding of the unsigned portion of a certificate 
(<STRONG>signatureAlgorithm</STRONG> field, <STRONG>signatureValue</STRONG> 
field and outer most tags).&nbsp; Such modification don't alter the signed 
portion so the signature remains valid, but they do change the thumbprint.&nbsp; 
An attacker can modify the bytes (hence thumbprint) without modifying the 
semantics of a certificate.</SPAN></FONT></P>
<P><FONT face=Arial size=2><SPAN class=336071605-26032001>For instance, consider 
omitting the <STRONG>NULL</STRONG> signature parameters associated with 
<STRONG>sha1WithRSAEncryption</STRONG> in the 
<STRONG>signatureAlgorithm</STRONG> field.&nbsp; It is not unreasonable for a 
system to still accept such a certificate (particularly with the "be strict with 
what you send but lenient with what you receive" philosophy).&nbsp; Yet the 
bytes do change so the thumbprint also changes.</SPAN></FONT></P>
<P><FONT face=Arial size=2><SPAN class=336071605-26032001></SPAN></FONT><FONT 
face=Arial size=2><SPAN class=336071605-26032001>An OCSPv2 responder may 
have&nbsp;one thumbprint of a certificate in its table of revoked certificates, 
but would return "<FONT face="Courier New">good</FONT>" if a different 
thumbprint for the same certificate appeared in the <STRONG>certHash</STRONG> 
field.</SPAN></FONT></P>
<P><FONT face=Arial size=2><SPAN class=336071605-26032001>A better thumbprint 
(that is unique for a certificate) is a hash over only the signed portion of the 
certificate (i.e. the same hash that goes into the signature).</SPAN></FONT></P>
<P><FONT face=Arial size=2><SPAN class=336071605-26032001>SOLUTION:&nbsp; Delete 
the <STRONG>certHash</STRONG> field from the <STRONG>ReqCert</STRONG> 
type.</SPAN></FONT></P></BODY></HTML>

------_=_NextPart_001_01C0B5C0.3C2BFB3C--

Reply-To: <[email-masked]>
From: "James T. Chao" <[email-masked]>
To: <[email-masked]>
Subject: FW: Would you like to recieve information on how to register your pet online for free?
Date: Sun, 25 Mar 2001 14:58:15 -0600
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01C0B53C.050A4C00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

WE SHOULD NOT TOLERATE THIS KIND OF JUNK EMAILS!

Please investigate on this!

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, March 25, 2001 2:04 AM
To: [email-masked]
Subject: Would you like to recieve information on how to register your pet
online for free?

Hello!
Would you like to know how to register your pet online for free?
If you would like to be removed from ever receiving another email please
type REMOVE only in the return subject header. We respect your right to
privacy.
If you would like to receive more information on how to register your pet
for free just reply to this email message with PLEASE SEND INFO only in the
subject header.
Thank You

------=_NextPart_000_0004_01C0B53C.050A4C00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<title>Untitled Document</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:16792199 0 0 0 65791 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	color:black;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	color:black;}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	color:black;}
span.EmailStyle16
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1"/>
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>WE=
 SHOULD
NOT TOLERATE THIS KIND OF JUNK =
EMAILS!<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><!=
[if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Pl=
ease
investigate on this!<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><!=
[if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>++=
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++++++++<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><!=
[if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> [email-masked]
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Sunday, March 25, =
2001 2:04
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Would you like =
to recieve
information on how to register your pet online for =
free?</span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Hello!<o:p></o:p></span></font></p>

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Would
you like to know how to register your pet online for =
free?<o:p></o:p></span></font></p>

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>If
you would like to be removed from ever receiving another email please =
type
REMOVE only in the return subject header. We respect your right to =
privacy.<o:p></o:p></span></font></p>

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>If
you would like to receive more information on how to register your pet =
for free
just reply to this email message with PLEASE SEND INFO only in the =
subject
header.<o:p></o:p></span></font></p>

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Thank
You<o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0004_01C0B53C.050A4C00--

Reply-To: "Liaquat Khan" <[email-masked]>
From: "Liaquat Khan" <[email-masked]>
To: "Carlin Covey" <[email-masked]>, <[email-masked]>
Subject: Re: some thoughts re DPD and DPV
Date: Sun, 25 Mar 2001 15:16:26 +0100

This is a multi-part message in MIME format.

------=_NextPart_000_0026_01C0B53E.8F59CA00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

some thoughts re DPD and DPVThe options you propose also make sense to =
me.  One question though, how does the RP know which policies have been =
pre-configured on the server? =20

Maybe, the RP application could also be pre-configured with the OIDs of =
the (validation) policies which are acceptable to it.  It could then =
uses these in its request messages.

Regards,
Liaquat

  ----- Original Message -----=20
  From: Carlin Covey=20
  To: Liaquat Khan ; [email-masked] ; Stephen Kent=20
  Sent: Saturday, March 24, 2001 10:46 PM
  Subject: RE: some thoughts re DPD and DPV

  Liaquat,

  I agree with you that it may be more appropriate for authorities other =
than the client
  to configure the path-validation policies.  The client would then be =
free to choose one
  of these already-configured policies via the appropriate OID in the =
request (or, if the
  client didn't like any of the policies, to either cause another one to =
be configured at
  the server in some out-of-band fashion, or to do the path validation =
itself).  The CA
  who issued the target certificate might be an appropriate authority to =
configure some
  policies, but the RP's own CA might be more appropriate in other =
situations.  In the
  case of a DPV/DPD server that supports a particular enterprise, a =
likely candidate
  is the human authority who manages the DPV/DPD server for the =
enterprise.
  -  Carlin Covey
     Cylink Corporation=20

    -----Original Message-----
    From: Liaquat Khan [mailto:[email-masked]]
    Sent: Saturday, March 24, 2001 4:13 AM
    To: [email-masked]; Stephen Kent
    Subject: Re: some thoughts re DPD and DPV

    I'm not against the idea of having a (validation) policy registered =
on the server, which the client refers to in its request message.  =
However, IMO would it not be more practical for the CA which issued the =
certificate to be responsible for defining this policy and registering =
it directly with its validation server?  This may remove some of the =
complexity of each client having its own policy and a protocol for =
registering this at the server.    The client would only need to refer =
to the appropriate policy, which will be based on the target certificate =
being checked.   Just some initial thoughts...

    Regards,
    Liaquat

      ----- Original Message -----=20
      From: Stephen Kent=20
      To: [email-masked]=20
      Sent: Saturday, March 24, 2001 12:09 AM
      Subject: some thoughts re DPD and DPV

      Based on presentations by and discussions with various folks =
during the IETF meeting this week, I have some suggestions for DPD/DPV =
requirements that I would like to put forth for discussion.

      1- a motivation for both DPD and PDV has been to reduce the =
bandwidth consumed by the path validation process. However, moving all =
of the parameters required for path validation between a server and a =
client is expensive in terms of bandwidth. Thus I think we should =
consider a suggestion Denis Pinkas made on the list a while ago. We =
could make ALL requests refer to a policy configured at the server, =
rather than allowing for explicit transmission of these parameters. To =
make this as flexible as the current proposals, we would have to add a =
new protocol, to allow a client to register a policy with a server, so =
that the client could later refer to that policy. We probably want a =
facility to inquire about a registered policy as well. We could proceed =
with the development of DPD/DPV protocols prior to having the policy =
registration and inquiry protocols defined, if we feel the need to, but =
I would prefer parallel development of such protocols. The bottom line =
would be much simpler syntax for the requests and responses for both DPD =
and DPV, and smaller message sizes.

      2- Along the same line of reasoning, Denis rightly noted that the =
primary purpose of DPV is to provide the yes/no/maybe response to a =
query re a target certificate. Thus, we ought to have a compact message =
format to provide this response, and a separate message for retrieval of =
the supporting data for the response, e.g., for NR purposes.  He =
proposed this split, with a hash of the "evidence" in the short =
response, to tie the two together. I like this suggestion and propose =
that we adopt this model as part of out requirements. Of course, we need =
the protocol for retrieving the evidence as well, to make the system =
complete.

      3- we still have some significant disagreement about the nature of =
the path validation controls to be used for both services, but =
especially for DPD. Related to this disagreement is the issue of whether =
an DPD should support incremental queries relative to the same target =
certificate. I don't think we have seen a concise, comprehensive =
description of the application model where such an incremental approach =
is warranted, so I solicit the proponents of this approach to provide =
such a description, so that we can resolve this issue.

      I'm off on vacation next week, see you later,

      Steve

------=_NextPart_000_0026_01C0B53E.8F59CA00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>some thoughts re DPD and DPV</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
DL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
OL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
LI {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>

<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>The options you propose also make sense =
to=20
me.&nbsp; One question though, how does the RP know which policies have =
been=20
pre-configured on the server?&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Maybe, the RP application could also be =

pre-configured with the OIDs of the (validation) policies which are =
acceptable=20
to it.&nbsp; It could&nbsp;then uses these in its request =
messages.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Liaquat</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked] href=3D"mailto:[email-masked]">Carlin =
Covey</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Liaquat Khan</A> ; <A=20
  title=[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</A>=20
  ; <A title=[email-masked] href=3D"mailto:[email-masked]">Stephen =
Kent</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, March 24, 2001 =
10:46=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: some thoughts re =
DPD and=20
  DPV</DIV>
  <DIV><BR></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT =
face=3DArial>Liaquat<SPAN=20
  class=3D536413321-24032001>,</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>I agree with you that it may be more =
appropriate for=20
  authorities other than the client</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>to configure the path-validation =
policies.&nbsp; The=20
  client would then be free to choose =
one</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>of these already-configured policies via =
the=20
  appropriate OID in the request (or, if =
the</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>client didn't like any of the policies, to =
either=20
  cause another one to be configured =
at</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>the server in =
</SPAN></FONT></FONT></FONT><FONT=20
  size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>some out-of-band fashion, or to do the path =

  validation itself).&nbsp; The CA</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>who issued the target certificate might be =
an=20
  appropriate authority to configure =
some</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>policies, but the RP's own CA might be more =

  appropriate in other situations.&nbsp; In=20
the</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>case of a DPV/DPD server that supports a =
particular=20
  enterprise, a likely candidate</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>is </SPAN></FONT></FONT></FONT><FONT =
size=3D2><FONT=20
  color=3D#0000ff><FONT face=3DArial><SPAN =
class=3D536413321-24032001>the human=20
  authority </SPAN></FONT></FONT></FONT><FONT size=3D2><FONT =
color=3D#0000ff><FONT=20
  face=3DArial><SPAN class=3D536413321-24032001>who manages the DPV/DPD =
server for=20
  the enterprise.</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001>
  <P><FONT size=3D2>-&nbsp; Carlin Covey<BR>&nbsp;&nbsp; Cylink =
Corporation=20
  </FONT></P></SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
  class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Liaquat Khan=20
    [mailto:[email-masked]]<BR><B>Sent:</B> Saturday, March =
24, 2001=20
    4:13 AM<BR><B>To:</B> [email-masked]; Stephen =
Kent<BR><B>Subject:</B> Re:=20
    some thoughts re DPD and DPV<BR><BR></DIV></FONT>
    <DIV><FONT face=3DArial size=3D2>I'm not against the idea of having =
a=20
    (validation) policy registered on the server, which the client =
refers to in=20
    its request message.&nbsp; However, IMO would it not be more =
practical for=20
    the CA which issued the certificate to be responsible for defining =
this=20
    policy and registering it directly with its validation server?&nbsp; =
This=20
    may remove some of the complexity of each client having&nbsp;its=20
    own&nbsp;policy and a protocol for registering this at the =
server.&nbsp;=20
    &nbsp;&nbsp;The client would only need to refer to&nbsp;the =
appropriate=20
    policy, which will be&nbsp;based on the target certificate being=20
    checked.&nbsp;&nbsp; Just some initial thoughts...</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2>Liaquat</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
      <DIV style=3D"FONT: 10pt arial">----- Original Message ----- =
</DIV>
      <DIV=20
      style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
      <A title=[email-masked] href=3D"mailto:[email-masked]">Stephen =
Kent</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
      href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, March 24, =
2001 12:09=20
      AM</DIV>
      <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> some thoughts re =
DPD and=20
      DPV</DIV>
      <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>
      <DIV><FONT color=3D#000000>Based on presentations by and =
discussions with=20
      various folks during the IETF meeting this week, I have some =
suggestions=20
      for DPD/DPV requirements that I would like to put forth for=20
      discussion.<BR><BR>1- a motivation for both DPD and PDV has been =
to reduce=20
      the bandwidth consumed by the path validation process. However, =
moving all=20
      of the parameters required for path validation between a server =
and a=20
      client is expensive in terms of bandwidth. Thus I think we should =
consider=20
      a suggestion Denis Pinkas made on the list a while ago. We could =
make ALL=20
      requests refer to a policy configured at the server, rather than =
allowing=20
      for explicit transmission of these parameters. To make this as =
flexible as=20
      the current proposals, we would have to add a new protocol, to =
allow a=20
      client to register a policy with a server, so that the client =
could later=20
      refer to that policy. We probably want a facility to inquire about =
a=20
      registered policy as well. We could proceed with the development =
of=20
      DPD/DPV protocols prior to having the policy registration and =
inquiry=20
      protocols defined, if we feel the need to, but I would prefer =
parallel=20
      development of such protocols. The bottom line would be much =
simpler=20
      syntax for the requests and responses for both DPD and DPV, and =
smaller=20
      message sizes.<BR><BR>2- Along the same line of reasoning, Denis =
rightly=20
      noted that the primary purpose of DPV is to provide the =
yes/no/maybe=20
      response to a query re a target certificate. Thus, we ought to =
have a=20
      compact message format to provide this response, and a separate =
message=20
      for retrieval of the supporting data for the response, e.g., for =
NR=20
      purposes.&nbsp; He proposed this split, with a hash of the =
"evidence" in=20
      the short response, to tie the two together. I like this =
suggestion and=20
      propose that we adopt this model as part of out requirements. Of =
course,=20
      we need the protocol for retrieving the evidence as well, to make =
the=20
      system complete.</FONT><BR><FONT color=3D#000000></FONT></DIV>
      <DIV><FONT color=3D#000000>3- we still have some significant =
disagreement=20
      about the nature of the path validation controls to be used for =
both=20
      services, but especially for DPD. Related to this disagreement is =
the=20
      issue of whether an DPD should support incremental queries =
relative to the=20
      same target certificate. I don't think we have seen a concise,=20
      comprehensive description of the application model where such an=20
      incremental approach is warranted, so I solicit the proponents of =
this=20
      approach to provide such a description, so that we can resolve =
this=20
      issue.</FONT></DIV>
      <DIV><BR></DIV>
      <DIV>I'm off on vacation next week, see you later,</DIV>
      <DIV><BR></DIV>
      =
<DIV>Steve</DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0026_01C0B53E.8F59CA00--

From: "[email-masked]" <[email-masked]>
To: [email-masked]
Date: Sun, 25 Mar 2001 02:03:30 -0600
Subject: Would you like to recieve information on how to register your pet online for free?

This is a Multipart MIME message.

------=_NextPart_000_001__18765896_7410.38
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

------=_NextPart_000_001__18765896_7410.38
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

------=_NextPart_000_001__18765896_7410.38--

From: Michael Zolotarev <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, [email-masked]
Subject: RE: some thoughts re DPD and DPV
Date: Sun, 25 Mar 2001 16:53:15 +1000

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B4F8.44547A50
Content-Type: text/plain; charset="iso-8859-1"

Stephen,
 
Returning a hash of the supporting data will inevitably complicate server
design, requiring running a potentially huge evidential database. Shall we
mandate a server to support it? Or otherwise, what's going to happen if the
client asks for the hash? An error returned? Or a complete evidence (which
the client presumably won't digest)? 
 
Who would be to decide for how long the evidence should be kept by the
server? TTLs tend to be messy.
 
What happens if a client sends a certificate which happens to be
preconfigured as a trusted root by the server policy (so that the answer is
'valid')? Hash of *what* should be returned?
 
All these questions will have a number of possible answers, all reasonable
in some extent. But in the whole, I'm seriously afraid that the requirement
will dramatically complicate implementation of the server, and the overall
design of the protocol. 
 
We may consider the fact that should the evidence data be returned by a DPV,
it don't have to be signed by the DVP. Therefore, we can solve the problem
by implementing a simple client proxy located between the client and DPV
server. The proxy can remove the evidence data off the response and store
it, passing just a hash of it to the client.
 
Regards
Michael

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Saturday, March 24, 2001 11:10 AM
To: [email-masked]
Subject: some thoughts re DPD and DPV

Based on presentations by and discussions with various folks during the IETF
meeting this week, I have some suggestions for DPD/DPV requirements that I
would like to put forth for discussion.

1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client is
expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. We could make ALL
requests refer to a policy configured at the server, rather than allowing
for explicit transmission of these parameters. To make this as flexible as
the current proposals, we would have to add a new protocol, to allow a
client to register a policy with a server, so that the client could later
refer to that policy. We probably want a facility to inquire about a
registered policy as well. We could proceed with the development of DPD/DPV
protocols prior to having the policy registration and inquiry protocols
defined, if we feel the need to, but I would prefer parallel development of
such protocols. The bottom line would be much simpler syntax for the
requests and responses for both DPD and DPV, and smaller message sizes.

2- Along the same line of reasoning, Denis rightly noted that the primary
purpose of DPV is to provide the yes/no/maybe response to a query re a
target certificate. Thus, we ought to have a compact message format to
provide this response, and a separate message for retrieval of the
supporting data for the response, e.g., for NR purposes.  He proposed this
split, with a hash of the "evidence" in the short response, to tie the two
together. I like this suggestion and propose that we adopt this model as
part of out requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.

3- we still have some significant disagreement about the nature of the path
validation controls to be used for both services, but especially for DPD.
Related to this disagreement is the issue of whether an DPD should support
incremental queries relative to the same target certificate. I don't think
we have seen a concise, comprehensive description of the application model
where such an incremental approach is warranted, so I solicit the proponents
of this approach to provide such a description, so that we can resolve this
issue.

I'm off on vacation next week, see you later,

Steve

This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

------_=_NextPart_001_01C0B4F8.44547A50
Content-Type: text/html; charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>some thoughts re DPD and DPV</TITLE>

<STYLE type=text/css>BLOCKQUOTE {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
DL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
UL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
OL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
LI {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
</STYLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001>Stephen,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001>Returning a hash of the supporting data will inevitably 
complicate server design,&nbsp;requiring running a potentially huge evidential 
database.&nbsp;Shall we mandate a server to support it? Or otherwise, what's 
going to happen if the client asks for the hash? An error returned? Or a 
complete evidence (which the client presumably won't digest)? 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=014454205-21032001>Who 
would be to decide for how long the evidence should be kept by the 
server?&nbsp;TTLs tend to be messy.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=014454205-21032001>What 
happens if a client sends a certificate which happens to be preconfigured as a 
trusted root by the server policy (so that the answer is 'valid')? Hash of 
*what* should be returned?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=014454205-21032001>All 
these questions will have a number of possible answers, all reasonable in some 
extent. But in the whole, I'm seriously afraid that the requirement will 
dramatically complicate implementation of the server, and the overall design of 
the protocol. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=014454205-21032001>We may 
consider the fact that should the evidence data be returned by a DPV, it don't 
have to be signed by the DVP.&nbsp;Therefore, we can solve the problem by 
implementing a simple&nbsp;client proxy&nbsp;located between the client and DPV 
server. The proxy can remove the evidence data off the response and store it, 
passing just a hash of it to the client.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001>Regards</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=014454205-21032001>Michael</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Stephen Kent 
  [mailto:[email-masked]]<BR><B>Sent:</B> Saturday, March 24, 2001 11:10 
  AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> some thoughts re DPD and 
  DPV<BR><BR></DIV></FONT>
  <DIV><FONT color=#000000>Based on presentations by and discussions with 
  various folks during the IETF meeting this week, I have some suggestions for 
  DPD/DPV requirements that I would like to put forth for discussion.<BR><BR>1- 
  a motivation for both DPD and PDV has been to reduce the bandwidth consumed by 
  the path validation process. However, moving all of the parameters required 
  for path validation between a server and a client is expensive in terms of 
  bandwidth. Thus I think we should consider a suggestion Denis Pinkas made on 
  the list a while ago. We could make ALL requests refer to a policy configured 
  at the server, rather than allowing for explicit transmission of these 
  parameters. To make this as flexible as the current proposals, we would have 
  to add a new protocol, to allow a client to register a policy with a server, 
  so that the client could later refer to that policy. We probably want a 
  facility to inquire about a registered policy as well. We could proceed with 
  the development of DPD/DPV protocols prior to having the policy registration 
  and inquiry protocols defined, if we feel the need to, but I would prefer 
  parallel development of such protocols. The bottom line would be much simpler 
  syntax for the requests and responses for both DPD and DPV, and smaller 
  message sizes.<BR><BR>2- Along the same line of reasoning, Denis rightly noted 
  that the primary purpose of DPV is to provide the yes/no/maybe response to a 
  query re a target certificate. Thus, we ought to have a compact message format 
  to provide this response, and a separate message for retrieval of the 
  supporting data for the response, e.g., for NR purposes.&nbsp; He proposed 
  this split, with a hash of the "evidence" in the short response, to tie the 
  two together. I like this suggestion and propose that we adopt this model as 
  part of out requirements. Of course, we need the protocol for retrieving the 
  evidence as well, to make the system complete.</FONT><BR><FONT 
  color=#000000></FONT></DIV>
  <DIV><FONT color=#000000>3- we still have some significant disagreement about 
  the nature of the path validation controls to be used for both services, but 
  especially for DPD. Related to this disagreement is the issue of whether an 
  DPD should support incremental queries relative to the same target 
  certificate. I don't think we have seen a concise, comprehensive description 
  of the application model where such an incremental approach is warranted, so I 
  solicit the proponents of this approach to provide such a description, so that 
  we can resolve this issue.</FONT></DIV>
  <DIV><BR></DIV>
  <DIV>I'm off on vacation next week, see you later,</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV><CODE><FONT size=3><BR><BR>This footnote confirms that this 
  email message has been swept by<BR>MIMEsweeper for the presence of computer 
  viruses.<BR></BLOCKQUOTE></FONT></CODE><CODE><FONT SIZE=3><BR>
<BR>
-----------------------------------------------------------------------------------------------------------------<BR>
The information contained in this message is confidential and is intended <BR>
for the addressee(s) only.  If you have received this message in error or <BR>
there are any problems please notify the originator immediately.  The <BR>
unauthorized use, disclosure, copying or alteration of this message is <BR>
strictly forbidden. Baltimore Technologies plc will not be liable for direct, <BR>
special, indirect or consequential damages arising from alteration of the <BR>
contents of this message by a third party or as a result of any virus being <BR>
passed on.<BR>
<BR>
In addition, certain Marketing collateral may be added from time to time to <BR>
promote Baltimore Technologies products, services, Global e-Security or <BR>
appearance at trade shows and conferences.<BR>
 <BR>
This footnote confirms that this email message has been swept by <BR>
Baltimore MIMEsweeper for Content Security threats, including<BR>
computer viruses.<BR>
</FONT></CODE></BODY></HTML>

------_=_NextPart_001_01C0B4F8.44547A50--

From: Michael Zolotarev <[email-masked]>
To: "'Carlin Covey'" <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked]
Subject: RE: some thoughts re DPD and DPV
Date: Sun, 25 Mar 2001 15:31:30 +1000

All,
Been fully agree with Paul in what he is saying about greivances of
client-server policy management, I suggest we do not limit ourselves to a
particular use mode. Instead, I would solicit leaving both the policy OID
and the explicit parameters options available (and optional) for the
clients.
Having a place for both an OID and for the parameters in the message
provides clients with flexibility to fine-tune a predefined policy, saying
"use this policy, but append/modify THAT parameter of it". Which may be a
real requirement down the track.

At that stage, our judgment is based on a very little practical experience
regarding what DPD/DPV client may become, and the environments they may be
operating in. Defining a protocol as a framework, and later on profiling it
for particular uses, may be a better choice.

Michael

-----Original Message-----
From: Carlin Covey [mailto:[email-masked]]
Sent: Sunday, March 25, 2001 7:26 AM
To: Paul Hoffman / IMC; Stephen Kent; [email-masked]
Subject: RE: some thoughts re DPD and DPV

Paul and Steve,

I agree that the DPD and DPV protocols should be simplified by
including just a reference to a server-resident path-validation
policy.  I also agree with Paul that a typical client will
make a choice among very few policies.  In fact, most clients 
will never make a choice.  The clients and servers will be 
pre-configured with one policy per client-type per enterprise.  
Simply including one policy OID in the request (possibly echoed 
in the response) will satisfy the great majority of use cases.  

Paul points out the near-zero success-rate of policy protocols.
DPD/DPV should not be made into a quasi-policy-protocol by 
including explicit policy information in the requests.  An OID
will do.  If there remains a need for client-configuration of 
server-resident policies, put that in a separate protocol as 
Steve has suggested.  

Let's proceed with a simplified, low-bandwidth DPD/DPV that is as 
free as possible of the burden of policy configuration.

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Friday, March 23, 2001 6:42 PM
To: Stephen Kent; [email-masked]
Subject: Re: some thoughts re DPD and DPV

At 7:09 PM -0500 3/23/01, Stephen Kent wrote:
>We could make ALL requests refer to a policy configured at the 
>server, rather than allowing for explicit transmission of these 
>parameters. To make this as flexible as the current proposals, we 
>would have to add a new protocol, to allow a client to register a 
>policy with a server, so that the client could later refer to that 
>policy. We probably want a facility to inquire about a registered 
>policy as well.

This sounds horrendously complex. To date, the IETF has had near-zero 
success with defining policy protocols, with policy working groups 
pretty much being unable to get closure. The method promoted in SCVP 
(can give individual policy info in requests or can use aggregated 
OIDs) seems much more sensible than forcing all clients to know (or, 
worse, discover and push) the policies on the server.

The number of policies a typical client wants will probably be few 
(most likely, just roots). Why make this so much more complicated 
than needed?

--Paul Hoffman, Director
--Internet Mail Consortium

This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

Sender: [email-masked]
Date: Sun, 25 Mar 2001 01:39:11 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: [email-masked]
Subject: Re: Logotypes in certificates

Dean Povey wrote:
> 
> One way, is that the CA can ensure that the logo is a registered
> trademark owned by the subject it is being issued to.  The USPTO and other
> organisations like it already have processes to ensure that trademarks are
> not confusingly similar.

I disagree. The organizations registering trade marks/logos (e.g.
Deutsches Patentamt in Germany) do not guarantee that the trade
marks/logos are not similar to others. They're just doing the
registration, no exhaustive checking for conflicts => a CA cannot
rely on such a service.

> Also, one other potential use of an image reference in an EE certificate
> is a digital photo of an employee which obviously has a pretty good
> mechanism for verification (i.e. look at photo, look at person).

I agree here. A photo of a person could be of some use.

Ciao, Michael.

To: [email-masked]
Subject: Re: Logotypes in certificates 
Date: Sun, 25 Mar 2001 10:04:23 +1000
From: Dean Povey <[email-masked]>

>"David P. Kemp" wrote:
> 
> If no one can propose a method by which a CA should decide not to
> certify a logo "similar to" the Chevrolet bowtie or the AT&T deathstar
> for someone other than Chevrolet or AT&T respectively, then it is
> obvious that changing PKIX to support logos has *NO* value to the
> user.
>

One way, is that the CA can ensure that the logo is a registered
trademark owned by the subject it is being issued to.  The USPTO and other
organisations like it already have processes to ensure that trademarks are 
not confusingly similar.

Again, similar problems exist for CAs working out what name to give to a 
subject, yet they manage to do a reasonable job of working it out. No one
seems to disagree that this is a problem, and everyone seems to be 
more or less comfortable with living with it.

Also, one other potential use of an image reference in an EE certificate
is a digital photo of an employee which obviously has a pretty good 
mechanism for verification (i.e. look at photo, look at person).

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

content-class: urn:content-classes:message
Subject: RE: specific policies used in conjunction with anyPolicy
Date: Sat, 24 Mar 2001 15:48:00 -0800
From: "Trevor Freeman" <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: <[email-masked]>

David,
Any CA will have to be fully aware of its actions relating to supporting
its client base. Just because it maybe aware of an extensions existence,
does not mean its clients are ware of it. That has nothing to do with
the issue here. Is there any benefit from an explicitly defined policy
over the use of the all policy OID. A parent CA may restrict the range
of policies it is prepared to except from a subordinate using the
all-policy OID, but is there any benefit in wanting that policy explicit
marked. Without some more concrete justification, then the case seems
week, and does not justify the increased complexity we are inheriting.
It is think kind of "feature creep" that will the undoing of this group.
Trevor

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Thursday, March 22, 2001 2:12 PM
To: Trevor Freeman; [email-masked]
Subject: RE: specific policies used in conjunction with anyPolicy

Trevor,

I do not see why you think I have made a "big leap". Are you referring
to my suggestion that one can assert both anyPolicy and some specific
policies or that applications may choose different values for
initial-any-policy-inhibit?

First, we have to acknowledge the existence of the inhibitAnyPolicy
extension. If a CA includes this extension in a certificate that it
issues, then the anyPolicy OID will be ignored in any certificates that
follow that certificate in a certification path. If the issuers of those
certificates do not specify policies other than anyPolicy in their
certificates, then the certification path will either be rejected or
will be accepted under no polices. So, if policies are important, and
there is the possibility that a CA (or the relying party) will inhibit
the processing of anyPolicy, then it will not be sufficient for CAs to
assert just the anyPolicy OID. If you want it to be the case that "if
you assert the all polices OID in a CA certificate, it is an operational
simplification, and the administrator does not need to add any more",
then you'll to get rid of inhibitAnyPolicy.

Second, while you may not be able to conceive of an instance where an
application would care about the value of initial-any-policy-inhibit, it
appears that Carlin Covey can. He stated that he wanted "to support
applications that insist on finding a specific policy OID, and also
support more liberal applications that will tolerate the anyPolicy OID."
The way for an application to specify that it insists on finding a
specify policy OID is to set initial-any-policy-inhibit.

At 11:58 AM 3/22/01 -0800, Trevor Freeman wrote:
>Dave,
>You have made a big leap here which I had not interpreted from the 
>text. This revolved around who is driving the inputs into the path 
>validation process. I can conceive instances where an application would

>want to pass in a-d. I do not think for one moment that an application 
>would care about the rest, nor should they. This stuff is already way 
>to complex, and interdependencies like this are a nightmare. We are on 
>an uphill battle to get applications to use PK wisely in the first 
>place because they think it is hard. Now you are asserting that we need

>to make PK administrators knowledgeable about what applications they 
>are supporting and expect that they are intimacy aware of all their 
>needs.

As I stated above, I was merely describing how Carlin Covey could
accomplished what he wanted to do. If you think there is something wrong
with what he wants to do, that is a different matter. I was merely
pointing out that it is supported by the standard.

>That is not doing to happen. We need clean simple rules if this is to 
>be successful. So lets start be saying if you assert the all polices 
>OID in a CA certificate, it is an operational simplification, and the 
>administrator does not need to add any more.

Unless the inhibitAnyPolicy extension is eliminated, this is simply not
the case.

>Trevor
>From: David A. Cooper [mailto:[email-masked]]
>Sent: Wednesday, March 21, 2001 12:32 PM
>To: [email-masked]
>Subject: Re: specific policies used in conjunction with anyPolicy
>
>Yes, you may assert both anyPolicy and specific certificate policies in

>the same certificate. This may not be specifically stated, but path 
>processing algorithm (section 6.1.3) does take this possibility into 
>account.
>
>The reason that this is allowed is exactly the one you stated. 
>Originally there was a rule that if anyPolicy were included in the 
>certificatePolicies extension, then no other policy could be included. 
>This rule was removed when the inhibitAnyPolicy extension was 
>developed. In the case you mention, the "strict" applications would set

>initial-any-policy-inhibit in order to ensure that the path would only 
>be considered valid under policies that had been explicitly listed in 
>each certificate. The more liberal applications would not set 
>initial-any-policy-inhibit and would then (possibly) consider the path 
>to be valid under more policies.
>
>At 01:11 PM 3/21/01 -0600, Carlin Covey wrote:
> >The certificate policies extension allows a sequence of policy OIDs. 
> >One such policy OID is anyPolicy.  I assume that it is permissible in

> >a CA cert to include specific policy OIDs in addition to the 
> >anyPolicy OID. The reason I would want to do this is to support 
> >applications that insist on finding a specific policy OID, and also 
> >support more liberal applications that will tolerate the anyPolicy 
> >OID.
> >
> >draft-ietf-pkix-new-part1-05 does not appear to prohibit using 
> >specific policy OIDs and the anyPolicy OID in the same CA cert.  Is 
> >this true?

From: "Carlin Covey" <[email-masked]>
To: "Liaquat Khan" <[email-masked]>, <[email-masked]>, "Stephen Kent" <[email-masked]>
Subject: RE: some thoughts re DPD and DPV
Date: Sat, 24 Mar 2001 14:46:30 -0700
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_0006_01C0B471.36B09460
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

some thoughts re DPD and DPVLiaquat,

I agree with you that it may be more appropriate for authorities other than
the client
to configure the path-validation policies.  The client would then be free to
choose one
of these already-configured policies via the appropriate OID in the request
(or, if the
client didn't like any of the policies, to either cause another one to be
configured at
the server in some out-of-band fashion, or to do the path validation
itself).  The CA
who issued the target certificate might be an appropriate authority to
configure some
policies, but the RP's own CA might be more appropriate in other situations.
In the
case of a DPV/DPD server that supports a particular enterprise, a likely
candidate
is the human authority who manages the DPV/DPD server for the enterprise.
-  Carlin Covey
   Cylink Corporation

  -----Original Message-----
  From: Liaquat Khan [mailto:[email-masked]]
  Sent: Saturday, March 24, 2001 4:13 AM
  To: [email-masked]; Stephen Kent
  Subject: Re: some thoughts re DPD and DPV

  I'm not against the idea of having a (validation) policy registered on the
server, which the client refers to in its request message.  However, IMO
would it not be more practical for the CA which issued the certificate to be
responsible for defining this policy and registering it directly with its
validation server?  This may remove some of the complexity of each client
having its own policy and a protocol for registering this at the server.
The client would only need to refer to the appropriate policy, which will be
based on the target certificate being checked.   Just some initial
thoughts...

  Regards,
  Liaquat

    ----- Original Message -----
    From: Stephen Kent
    To: [email-masked]
    Sent: Saturday, March 24, 2001 12:09 AM
    Subject: some thoughts re DPD and DPV

    Based on presentations by and discussions with various folks during the
IETF meeting this week, I have some suggestions for DPD/DPV requirements
that I would like to put forth for discussion.

    1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client is
expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. We could make ALL
requests refer to a policy configured at the server, rather than allowing
for explicit transmission of these parameters. To make this as flexible as
the current proposals, we would have to add a new protocol, to allow a
client to register a policy with a server, so that the client could later
refer to that policy. We probably want a facility to inquire about a
registered policy as well. We could proceed with the development of DPD/DPV
protocols prior to having the policy registration and inquiry protocols
defined, if we feel the need to, but I would prefer parallel development of
such protocols. The bottom line would be much simpler syntax for the
requests and responses for both DPD and DPV, and smaller message sizes.

    2- Along the same line of reasoning, Denis rightly noted that the
primary purpose of DPV is to provide the yes/no/maybe response to a query re
a target certificate. Thus, we ought to have a compact message format to
provide this response, and a separate message for retrieval of the
supporting data for the response, e.g., for NR purposes.  He proposed this
split, with a hash of the "evidence" in the short response, to tie the two
together. I like this suggestion and propose that we adopt this model as
part of out requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.

    3- we still have some significant disagreement about the nature of the
path validation controls to be used for both services, but especially for
DPD. Related to this disagreement is the issue of whether an DPD should
support incremental queries relative to the same target certificate. I don't
think we have seen a concise, comprehensive description of the application
model where such an incremental approach is warranted, so I solicit the
proponents of this approach to provide such a description, so that we can
resolve this issue.

    I'm off on vacation next week, see you later,

    Steve

------=_NextPart_000_0006_01C0B471.36B09460
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>some thoughts re DPD and DPV</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<STYLE type=3Dtext/css>BLOCKQUOTE {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
DL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
UL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
OL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
LI {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
</STYLE>

<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT =
face=3DArial>Liaquat<SPAN=20
class=3D536413321-24032001>,</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>I agree with you that it may be more =
appropriate for=20
authorities other than the client</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>to configure the path-validation =
policies.&nbsp; The=20
client would then be free to choose =
one</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>of these already-configured policies via the=20
appropriate OID in the request (or, if =
the</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>client didn't like any of the policies, to =
either cause=20
another one to be configured at</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>the server in =
</SPAN></FONT></FONT></FONT><FONT=20
size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN =
class=3D536413321-24032001>some=20
out-of-band fashion, or to do the path validation itself).&nbsp; The=20
CA</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>who issued the target certificate might be an =

appropriate authority to configure =
some</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>policies, but the RP's own CA might be more =
appropriate=20
in other situations.&nbsp; In the</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>case of a DPV/DPD server that supports a =
particular=20
enterprise, a likely candidate</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>is </SPAN></FONT></FONT></FONT><FONT =
size=3D2><FONT=20
color=3D#0000ff><FONT face=3DArial><SPAN class=3D536413321-24032001>the =
human=20
authority </SPAN></FONT></FONT></FONT><FONT size=3D2><FONT =
color=3D#0000ff><FONT=20
face=3DArial><SPAN class=3D536413321-24032001>who manages the DPV/DPD =
server for the=20
enterprise.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001>
<P><FONT size=3D2>-&nbsp; Carlin Covey<BR>&nbsp;&nbsp; Cylink =
Corporation=20
</FONT></P></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT color=3D#0000ff><FONT face=3DArial><SPAN=20
class=3D536413321-24032001></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Liaquat Khan=20
  [mailto:[email-masked]]<BR><B>Sent:</B> Saturday, March 24, =
2001=20
  4:13 AM<BR><B>To:</B> [email-masked]; Stephen =
Kent<BR><B>Subject:</B> Re:=20
  some thoughts re DPD and DPV<BR><BR></DIV></FONT>
  <DIV><FONT face=3DArial size=3D2>I'm not against the idea of having a =
(validation)=20
  policy registered on the server, which the client refers to in its =
request=20
  message.&nbsp; However, IMO would it not be more practical for the CA =
which=20
  issued the certificate to be responsible for defining this policy and=20
  registering it directly with its validation server?&nbsp; This may =
remove some=20
  of the complexity of each client having&nbsp;its own&nbsp;policy and a =

  protocol for registering this at the server.&nbsp; &nbsp;&nbsp;The =
client=20
  would only need to refer to&nbsp;the appropriate policy, which will=20
  be&nbsp;based on the target certificate being checked.&nbsp;&nbsp; =
Just some=20
  initial thoughts...</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Liaquat</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A href=3D"mailto:[email-masked]" title=[email-masked]>Stephen =
Kent</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:[email-masked]"=20
    title=[email-masked]>[email-masked]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, March 24, =
2001 12:09=20
    AM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> some thoughts re DPD =
and=20
    DPV</DIV>
    <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>
    <DIV><FONT color=3D#000000>Based on presentations by and discussions =
with=20
    various folks during the IETF meeting this week, I have some =
suggestions for=20
    DPD/DPV requirements that I would like to put forth for=20
    discussion.<BR><BR>1- a motivation for both DPD and PDV has been to =
reduce=20
    the bandwidth consumed by the path validation process. However, =
moving all=20
    of the parameters required for path validation between a server and =
a client=20
    is expensive in terms of bandwidth. Thus I think we should consider =
a=20
    suggestion Denis Pinkas made on the list a while ago. We could make =
ALL=20
    requests refer to a policy configured at the server, rather than =
allowing=20
    for explicit transmission of these parameters. To make this as =
flexible as=20
    the current proposals, we would have to add a new protocol, to allow =
a=20
    client to register a policy with a server, so that the client could =
later=20
    refer to that policy. We probably want a facility to inquire about a =

    registered policy as well. We could proceed with the development of =
DPD/DPV=20
    protocols prior to having the policy registration and inquiry =
protocols=20
    defined, if we feel the need to, but I would prefer parallel =
development of=20
    such protocols. The bottom line would be much simpler syntax for the =

    requests and responses for both DPD and DPV, and smaller message=20
    sizes.<BR><BR>2- Along the same line of reasoning, Denis rightly =
noted that=20
    the primary purpose of DPV is to provide the yes/no/maybe response =
to a=20
    query re a target certificate. Thus, we ought to have a compact =
message=20
    format to provide this response, and a separate message for =
retrieval of the=20
    supporting data for the response, e.g., for NR purposes.&nbsp; He =
proposed=20
    this split, with a hash of the "evidence" in the short response, to =
tie the=20
    two together. I like this suggestion and propose that we adopt this =
model as=20
    part of out requirements. Of course, we need the protocol for =
retrieving the=20
    evidence as well, to make the system complete.</FONT><BR><FONT=20
    color=3D#000000></FONT></DIV>
    <DIV><FONT color=3D#000000>3- we still have some significant =
disagreement=20
    about the nature of the path validation controls to be used for both =

    services, but especially for DPD. Related to this disagreement is =
the issue=20
    of whether an DPD should support incremental queries relative to the =
same=20
    target certificate. I don't think we have seen a concise, =
comprehensive=20
    description of the application model where such an incremental =
approach is=20
    warranted, so I solicit the proponents of this approach to provide =
such a=20
    description, so that we can resolve this issue.</FONT></DIV>
    <DIV><BR></DIV>
    <DIV>I'm off on vacation next week, see you later,</DIV>
    <DIV><BR></DIV>
    <DIV>Steve</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0006_01C0B471.36B09460--

From: "Carlin Covey" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: RE: some thoughts re DPD and DPV
Date: Sat, 24 Mar 2001 14:26:20 -0700
Importance: Normal

Paul and Steve,

I agree that the DPD and DPV protocols should be simplified by
including just a reference to a server-resident path-validation
policy.  I also agree with Paul that a typical client will
make a choice among very few policies.  In fact, most clients 
will never make a choice.  The clients and servers will be 
pre-configured with one policy per client-type per enterprise.  
Simply including one policy OID in the request (possibly echoed 
in the response) will satisfy the great majority of use cases.  

Paul points out the near-zero success-rate of policy protocols.
DPD/DPV should not be made into a quasi-policy-protocol by 
including explicit policy information in the requests.  An OID
will do.  If there remains a need for client-configuration of 
server-resident policies, put that in a separate protocol as 
Steve has suggested.  

Let's proceed with a simplified, low-bandwidth DPD/DPV that is as 
free as possible of the burden of policy configuration.

-  Carlin Covey
   Cylink Corporation 

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]]
Sent: Friday, March 23, 2001 6:42 PM
To: Stephen Kent; [email-masked]
Subject: Re: some thoughts re DPD and DPV

At 7:09 PM -0500 3/23/01, Stephen Kent wrote:
>We could make ALL requests refer to a policy configured at the 
>server, rather than allowing for explicit transmission of these 
>parameters. To make this as flexible as the current proposals, we 
>would have to add a new protocol, to allow a client to register a 
>policy with a server, so that the client could later refer to that 
>policy. We probably want a facility to inquire about a registered 
>policy as well.

This sounds horrendously complex. To date, the IETF has had near-zero 
success with defining policy protocols, with policy working groups 
pretty much being unable to get closure. The method promoted in SCVP 
(can give individual policy info in requests or can use aggregated 
OIDs) seems much more sensible than forcing all clients to know (or, 
worse, discover and push) the policies on the server.

The number of policies a typical client wants will probably be few 
(most likely, just roots). Why make this so much more complicated 
than needed?

--Paul Hoffman, Director
--Internet Mail Consortium

From: Santosh Chokhani <[email-masked]>
To: Liaquat Khan <[email-masked]>, [email-masked], Stephen Kent <[email-masked]>
Subject: RE: some thoughts re DPD and DPV
Date: Sat, 24 Mar 2001 07:11:19 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B45B.88A740E0
Content-Type: text/plain;
	charset="iso-8859-1"

With all due respect to PKI and X.509, a more versatile and simpler approach
to revise the path validation algorithm where the validator says for which
policies in the relying party domain the path is good for, if any.
 
The application then will have a simple check to make (locally) if any one
of these policies is acceptable to it.
 
This however, may not reduce the need for setting other policy related state
variables, the most important of them being, inhibit policy mapping related
initial skipCerts value.
 
-----Original Message-----
From: Liaquat Khan [mailto:[email-masked]]
Sent: Saturday, March 24, 2001 6:13 AM
To: [email-masked]; Stephen Kent
Subject: Re: some thoughts re DPD and DPV

I'm not against the idea of having a (validation) policy registered on the
server, which the client refers to in its request message.  However, IMO
would it not be more practical for the CA which issued the certificate to be
responsible for defining this policy and registering it directly with its
validation server?  This may remove some of the complexity of each client
having its own policy and a protocol for registering this at the server.
The client would only need to refer to the appropriate policy, which will be
based on the target certificate being checked.   Just some initial
thoughts...
 
Regards,
Liaquat

----- Original Message ----- 
From: Stephen Kent <mailto:[email-masked]>  
To: [email-masked] <mailto:[email-masked]>  
Sent: Saturday, March 24, 2001 12:09 AM
Subject: some thoughts re DPD and DPV

Based on presentations by and discussions with various folks during the IETF
meeting this week, I have some suggestions for DPD/DPV requirements that I
would like to put forth for discussion.

1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client is
expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. We could make ALL
requests refer to a policy configured at the server, rather than allowing
for explicit transmission of these parameters. To make this as flexible as
the current proposals, we would have to add a new protocol, to allow a
client to register a policy with a server, so that the client could later
refer to that policy. We probably want a facility to inquire about a
registered policy as well. We could proceed with the development of DPD/DPV
protocols prior to having the policy registration and inquiry protocols
defined, if we feel the need to, but I would prefer parallel development of
such protocols. The bottom line would be much simpler syntax for the
requests and responses for both DPD and DPV, and smaller message sizes.

2- Along the same line of reasoning, Denis rightly noted that the primary
purpose of DPV is to provide the yes/no/maybe response to a query re a
target certificate. Thus, we ought to have a compact message format to
provide this response, and a separate message for retrieval of the
supporting data for the response, e.g., for NR purposes.  He proposed this
split, with a hash of the "evidence" in the short response, to tie the two
together. I like this suggestion and propose that we adopt this model as
part of out requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.

3- we still have some significant disagreement about the nature of the path
validation controls to be used for both services, but especially for DPD.
Related to this disagreement is the issue of whether an DPD should support
incremental queries relative to the same target certificate. I don't think
we have seen a concise, comprehensive description of the application model
where such an incremental approach is warranted, so I solicit the proponents
of this approach to provide such a description, so that we can resolve this
issue.

I'm off on vacation next week, see you later,

Steve

------_=_NextPart_001_01C0B45B.88A740E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>some thoughts re DPD and DPV</TITLE>

<STYLE type=text/css>BLOCKQUOTE {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
DL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
UL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
OL {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
LI {
	MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
</STYLE>

<META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=511121712-24032001>With 
all due respect to PKI and X.509, a more versatile and simpler approach to 
revise the path validation algorithm where the validator says for which policies 
in the relying party domain the path is good for, if any.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=511121712-24032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=511121712-24032001>The 
application then will have a simple check to make (locally) if any one of these 
policies is acceptable to it.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=511121712-24032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=511121712-24032001>This 
however, may not reduce the need for setting other policy related state 
variables, the most important of them being, inhibit policy mapping related 
initial skipCerts value.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
size=2>-----Original Message-----<BR><B>From:</B> Liaquat Khan 
[mailto:[email-masked]]<BR><B>Sent:</B> Saturday, March 24, 2001 6:13 
AM<BR><B>To:</B> [email-masked]; Stephen Kent<BR><B>Subject:</B> Re: some 
thoughts re DPD and DPV<BR><BR></FONT></DIV>
<DIV><FONT face=Arial size=2>I'm not against the idea of having a (validation) 
policy registered on the server, which the client refers to in its request 
message.&nbsp; However, IMO would it not be more practical for the CA which 
issued the certificate to be responsible for defining this policy and 
registering it directly with its validation server?&nbsp; This may remove some 
of the complexity of each client having&nbsp;its own&nbsp;policy and a protocol 
for registering this at the server.&nbsp; &nbsp;&nbsp;The client would only need 
to refer to&nbsp;the appropriate policy, which will be&nbsp;based on the target 
certificate being checked.&nbsp;&nbsp; Just some initial 
thoughts...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Regards,</FONT></DIV>
<DIV><FONT face=Arial size=2>Liaquat</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A href="mailto:[email-masked]" title=[email-masked]>Stephen Kent</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A href="mailto:[email-masked]" 
  title=[email-masked]>[email-masked]</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Saturday, March 24, 2001 12:09 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> some thoughts re DPD and 
  DPV</DIV>
  <DIV><FONT face=Arial size=2></FONT><BR></DIV>
  <DIV><FONT color=#000000>Based on presentations by and discussions with 
  various folks during the IETF meeting this week, I have some suggestions for 
  DPD/DPV requirements that I would like to put forth for discussion.<BR><BR>1- 
  a motivation for both DPD and PDV has been to reduce the bandwidth consumed by 
  the path validation process. However, moving all of the parameters required 
  for path validation between a server and a client is expensive in terms of 
  bandwidth. Thus I think we should consider a suggestion Denis Pinkas made on 
  the list a while ago. We could make ALL requests refer to a policy configured 
  at the server, rather than allowing for explicit transmission of these 
  parameters. To make this as flexible as the current proposals, we would have 
  to add a new protocol, to allow a client to register a policy with a server, 
  so that the client could later refer to that policy. We probably want a 
  facility to inquire about a registered policy as well. We could proceed with 
  the development of DPD/DPV protocols prior to having the policy registration 
  and inquiry protocols defined, if we feel the need to, but I would prefer 
  parallel development of such protocols. The bottom line would be much simpler 
  syntax for the requests and responses for both DPD and DPV, and smaller 
  message sizes.<BR><BR>2- Along the same line of reasoning, Denis rightly noted 
  that the primary purpose of DPV is to provide the yes/no/maybe response to a 
  query re a target certificate. Thus, we ought to have a compact message format 
  to provide this response, and a separate message for retrieval of the 
  supporting data for the response, e.g., for NR purposes.&nbsp; He proposed 
  this split, with a hash of the "evidence" in the short response, to tie the 
  two together. I like this suggestion and propose that we adopt this model as 
  part of out requirements. Of course, we need the protocol for retrieving the 
  evidence as well, to make the system complete.</FONT><BR><FONT 
  color=#000000></FONT></DIV>
  <DIV><FONT color=#000000>3- we still have some significant disagreement about 
  the nature of the path validation controls to be used for both services, but 
  especially for DPD. Related to this disagreement is the issue of whether an 
  DPD should support incremental queries relative to the same target 
  certificate. I don't think we have seen a concise, comprehensive description 
  of the application model where such an incremental approach is warranted, so I 
  solicit the proponents of this approach to provide such a description, so that 
  we can resolve this issue.</FONT></DIV>
  <DIV><BR></DIV>
  <DIV>I'm off on vacation next week, see you later,</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0B45B.88A740E0--

From: "Liaquat Khan" <[email-masked]>
To: <[email-masked]>, "Stephen Kent" <[email-masked]>
Subject: Re: some thoughts re DPD and DPV
Date: Sat, 24 Mar 2001 11:12:57 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01C0B453.613F5680
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

some thoughts re DPD and DPVI'm not against the idea of having a =
(validation) policy registered on the server, which the client refers to =
in its request message.  However, IMO would it not be more practical for =
the CA which issued the certificate to be responsible for defining this =
policy and registering it directly with its validation server?  This may =
remove some of the complexity of each client having its own policy and a =
protocol for registering this at the server.    The client would only =
need to refer to the appropriate policy, which will be based on the =
target certificate being checked.   Just some initial thoughts...

Regards,
Liaquat

  ----- Original Message -----=20
  From: Stephen Kent=20
  To: [email-masked]=20
  Sent: Saturday, March 24, 2001 12:09 AM
  Subject: some thoughts re DPD and DPV

  Based on presentations by and discussions with various folks during =
the IETF meeting this week, I have some suggestions for DPD/DPV =
requirements that I would like to put forth for discussion.

  1- a motivation for both DPD and PDV has been to reduce the bandwidth =
consumed by the path validation process. However, moving all of the =
parameters required for path validation between a server and a client is =
expensive in terms of bandwidth. Thus I think we should consider a =
suggestion Denis Pinkas made on the list a while ago. We could make ALL =
requests refer to a policy configured at the server, rather than =
allowing for explicit transmission of these parameters. To make this as =
flexible as the current proposals, we would have to add a new protocol, =
to allow a client to register a policy with a server, so that the client =
could later refer to that policy. We probably want a facility to inquire =
about a registered policy as well. We could proceed with the development =
of DPD/DPV protocols prior to having the policy registration and inquiry =
protocols defined, if we feel the need to, but I would prefer parallel =
development of such protocols. The bottom line would be much simpler =
syntax for the requests and responses for both DPD and DPV, and smaller =
message sizes.

  2- Along the same line of reasoning, Denis rightly noted that the =
primary purpose of DPV is to provide the yes/no/maybe response to a =
query re a target certificate. Thus, we ought to have a compact message =
format to provide this response, and a separate message for retrieval of =
the supporting data for the response, e.g., for NR purposes.  He =
proposed this split, with a hash of the "evidence" in the short =
response, to tie the two together. I like this suggestion and propose =
that we adopt this model as part of out requirements. Of course, we need =
the protocol for retrieving the evidence as well, to make the system =
complete.

  3- we still have some significant disagreement about the nature of the =
path validation controls to be used for both services, but especially =
for DPD. Related to this disagreement is the issue of whether an DPD =
should support incremental queries relative to the same target =
certificate. I don't think we have seen a concise, comprehensive =
description of the application model where such an incremental approach =
is warranted, so I solicit the proponents of this approach to provide =
such a description, so that we can resolve this issue.

  I'm off on vacation next week, see you later,

  Steve

------=_NextPart_000_000D_01C0B453.613F5680
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>some thoughts re DPD and DPV</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<STYLE type=3Dtext/css>BLOCKQUOTE {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
DL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
OL {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
LI {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>

<META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I'm not against the idea of having a =
(validation)=20
policy registered on the server, which the client refers to in its =
request=20
message.&nbsp; However, IMO would it not be more practical for the CA =
which=20
issued the certificate to be responsible for defining this policy and=20
registering it directly with its validation server?&nbsp; This may =
remove some=20
of the complexity of each client having&nbsp;its own&nbsp;policy and a =
protocol=20
for registering this at the server.&nbsp; &nbsp;&nbsp;The client would =
only need=20
to refer to&nbsp;the appropriate policy, which will be&nbsp;based on the =
target=20
certificate being checked.&nbsp;&nbsp; Just some initial=20
thoughts...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Liaquat</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked] href=3D"mailto:[email-masked]">Stephen Kent</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, March 24, 2001 =
12:09=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> some thoughts re DPD =
and=20
  DPV</DIV>
  <DIV><FONT face=3DArial size=3D2></FONT><BR></DIV>
  <DIV><FONT color=3D#000000>Based on presentations by and discussions =
with=20
  various folks during the IETF meeting this week, I have some =
suggestions for=20
  DPD/DPV requirements that I would like to put forth for =
discussion.<BR><BR>1-=20
  a motivation for both DPD and PDV has been to reduce the bandwidth =
consumed by=20
  the path validation process. However, moving all of the parameters =
required=20
  for path validation between a server and a client is expensive in =
terms of=20
  bandwidth. Thus I think we should consider a suggestion Denis Pinkas =
made on=20
  the list a while ago. We could make ALL requests refer to a policy =
configured=20
  at the server, rather than allowing for explicit transmission of these =

  parameters. To make this as flexible as the current proposals, we =
would have=20
  to add a new protocol, to allow a client to register a policy with a =
server,=20
  so that the client could later refer to that policy. We probably want =
a=20
  facility to inquire about a registered policy as well. We could =
proceed with=20
  the development of DPD/DPV protocols prior to having the policy =
registration=20
  and inquiry protocols defined, if we feel the need to, but I would =
prefer=20
  parallel development of such protocols. The bottom line would be much =
simpler=20
  syntax for the requests and responses for both DPD and DPV, and =
smaller=20
  message sizes.<BR><BR>2- Along the same line of reasoning, Denis =
rightly noted=20
  that the primary purpose of DPV is to provide the yes/no/maybe =
response to a=20
  query re a target certificate. Thus, we ought to have a compact =
message format=20
  to provide this response, and a separate message for retrieval of the=20
  supporting data for the response, e.g., for NR purposes.&nbsp; He =
proposed=20
  this split, with a hash of the "evidence" in the short response, to =
tie the=20
  two together. I like this suggestion and propose that we adopt this =
model as=20
  part of out requirements. Of course, we need the protocol for =
retrieving the=20
  evidence as well, to make the system complete.</FONT><BR><FONT=20
  color=3D#000000></FONT></DIV>
  <DIV><FONT color=3D#000000>3- we still have some significant =
disagreement about=20
  the nature of the path validation controls to be used for both =
services, but=20
  especially for DPD. Related to this disagreement is the issue of =
whether an=20
  DPD should support incremental queries relative to the same target=20
  certificate. I don't think we have seen a concise, comprehensive =
description=20
  of the application model where such an incremental approach is =
warranted, so I=20
  solicit the proponents of this approach to provide such a description, =
so that=20
  we can resolve this issue.</FONT></DIV>
  <DIV><BR></DIV>
  <DIV>I'm off on vacation next week, see you later,</DIV>
  <DIV><BR></DIV>
  <DIV>Steve</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000D_01C0B453.613F5680--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: some thoughts re DPD and DPV
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sat, 24 Mar 2001 14:02:28 (NZST)

Speaking of OCSP, I have a suggestion for v2: Currently the status values which
are returned are not-revoked, revoked, and unknown (note that I've used "not-
revoked" rather than "OK" because what's called "OK" doesn't actually mean the
cert is OK).  I've had a request from a user in Germany for an addition to this
which provides a true-OK response (that is, a response of "This certificate was
definitely issued and is valid as of the time the response was sent") as well
as a true-invalid response ("This certificate wasn't issued/has been
revoked/has expired").  My suggestion for providing this was to create a
(private) extension which contains this information, but given that things like
ISIS are doing something similar by overloading RFC 2560 it might be useful to
make this a bit more standardised by adding it to the RFC rather than having
everyone invent their own incompatible, ad-hoc solutions.

Note that this isn't any infringement on DPD/DPV's territory, all this is doing
is providing more useful status information than the current return values do.
For the extension I'd proposed the following:

  ExtendedStatus ::= BOOLEAN

  If set to true, the responder is indicating that the certificate has been
  issued and is curently valid.

  If set to false, the responder is indicating that the certificate has not
  been issued, has not become valid yet or has expired, or has been revoked
  (more information is contained in the certStatus field) or otherwise
  withdrawn from use.

This doesn't do any path validation or anything else provided for in DPD/DPV,
all it is is an assertion from the CA/responder that as far as they're
concerned it's valid or it's not valid.  This is a very simple fix to OCSP
which is fully backwards-compatible and helps avoid the problems caused by the
limited ability of the certStatus value to report certain certificate
conditions.

Peter.

Date: Fri, 23 Mar 2001 17:42:04 -0800
To: Stephen Kent <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: some thoughts re DPD and DPV

At 7:09 PM -0500 3/23/01, Stephen Kent wrote:
>We could make ALL requests refer to a policy configured at the 
>server, rather than allowing for explicit transmission of these 
>parameters. To make this as flexible as the current proposals, we 
>would have to add a new protocol, to allow a client to register a 
>policy with a server, so that the client could later refer to that 
>policy. We probably want a facility to inquire about a registered 
>policy as well.

This sounds horrendously complex. To date, the IETF has had near-zero 
success with defining policy protocols, with policy working groups 
pretty much being unable to get closure. The method promoted in SCVP 
(can give individual policy info in requests or can use aggregated 
OIDs) seems much more sensible than forcing all clients to know (or, 
worse, discover and push) the policies on the server.

The number of policies a typical client wants will probably be few 
(most likely, just roots). Why make this so much more complicated 
than needed?

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Michael Myers" <[email-masked]>
To: "Ietf-Pkix@Imc. Org" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>
Subject: RE: some thoughts re DPD and DPV
Date: Fri, 23 Mar 2001 17:20:33 -0800
Importance: Normal

Steve,

Speaking from the OCSP perspective, our formulations of OCSPv1 and OCSPv2
implicitly assumed and continues to assume that policy management between
relying parties and validating parties is out of scope.  We of the OCSP team
agree that the parallel development of such protocols is strongly preferred
vice deltas to OCSPv2.

I have no problem with an optional evidentiary hash in a DPV response if
it's client-precipitated.  As Denis and I had discussed earlier this week,
some environments may prefer this to the constant reiteration by a server of
a full chain or other policy indicators (e.g. the full text of a policy
document).  We will take this as a requirement and study how best to fold
this requirement into the current OCSPv2 technical framework.

When you refer to "incremental queries relative to the same target
certificate" are you speaking to the currently proposed retryReference
mechanism?

Mike

From: Stephen Kent [[email-masked]]
Sent: Friday, March 23, 2001 4:10 PM
To: [email-masked]
Subject: some thoughts re DPD and DPV

Based on presentations by and discussions with various folks during the IETF
meeting this week, I have some suggestions for DPD/DPV requirements that I
would like to put forth for discussion.

1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client is
expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. We could make ALL
requests refer to a policy configured at the server, rather than allowing
for explicit transmission of these parameters. To make this as flexible as
the current proposals, we would have to add a new protocol, to allow a
client to register a policy with a server, so that the client could later
refer to that policy. We probably want a facility to inquire about a
registered policy as well. We could proceed with the development of DPD/DPV
protocols prior to having the policy registration and inquiry protocols
defined, if we feel the need to, but I would prefer parallel development of
such protocols. The bottom line would be much simpler syntax for the
requests and responses for both DPD and DPV, and smaller message sizes.

2- Along the same line of reasoning, Denis rightly noted that the primary
purpose of DPV is to provide the yes/no/maybe response to a query re a
target certificate. Thus, we ought to have a compact message format to
provide this response, and a separate message for retrieval of the
supporting data for the response, e.g., for NR purposes.  He proposed this
split, with a hash of the "evidence" in the short response, to tie the two
together. I like this suggestion and propose that we adopt this model as
part of out requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.

3- we still have some significant disagreement about the nature of the path
validation controls to be used for both services, but especially for DPD.
Related to this disagreement is the issue of whether an DPD should support
incremental queries relative to the same target certificate. I don't think
we have seen a concise, comprehensive description of the application model
where such an incremental approach is warranted, so I solicit the proponents
of this approach to provide such a description, so that we can resolve this
issue.

I'm off on vacation next week, see you later,

Steve

Date: Fri, 23 Mar 2001 19:09:46 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: some thoughts re DPD and DPV

--============_-1226729903==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Based on presentations by and discussions with various folks during 
the IETF meeting this week, I have some suggestions for DPD/DPV 
requirements that I would like to put forth for discussion.

1- a motivation for both DPD and PDV has been to reduce the bandwidth 
consumed by the path validation process. However, moving all of the 
parameters required for path validation between a server and a client 
is expensive in terms of bandwidth. Thus I think we should consider a 
suggestion Denis Pinkas made on the list a while ago. We could make 
ALL requests refer to a policy configured at the server, rather than 
allowing for explicit transmission of these parameters. To make this 
as flexible as the current proposals, we would have to add a new 
protocol, to allow a client to register a policy with a server, so 
that the client could later refer to that policy. We probably want a 
facility to inquire about a registered policy as well. We could 
proceed with the development of DPD/DPV protocols prior to having the 
policy registration and inquiry protocols defined, if we feel the 
need to, but I would prefer parallel development of such protocols. 
The bottom line would be much simpler syntax for the requests and 
responses for both DPD and DPV, and smaller message sizes.

2- Along the same line of reasoning, Denis rightly noted that the 
primary purpose of DPV is to provide the yes/no/maybe response to a 
query re a target certificate. Thus, we ought to have a compact 
message format to provide this response, and a separate message for 
retrieval of the supporting data for the response, e.g., for NR 
purposes.  He proposed this split, with a hash of the "evidence" in 
the short response, to tie the two together. I like this suggestion 
and propose that we adopt this model as part of out requirements. Of 
course, we need the protocol for retrieving the evidence as well, to 
make the system complete.

3- we still have some significant disagreement about the nature of 
the path validation controls to be used for both services, but 
especially for DPD. Related to this disagreement is the issue of 
whether an DPD should support incremental queries relative to the 
same target certificate. I don't think we have seen a concise, 
comprehensive description of the application model where such an 
incremental approach is warranted, so I solicit the proponents of 
this approach to provide such a description, so that we can resolve 
this issue.

I'm off on vacation next week, see you later,

Steve
--============_-1226729903==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>some thoughts re DPD and DPV</title></head><body>
<div><font color="#000000">Based on presentations by and discussions
with various folks during the IETF meeting this week, I have some
suggestions for DPD/DPV requirements that I would like to put forth
for discussion.<br>
<br>
1- a motivation for both DPD and PDV has been to reduce the bandwidth
consumed by the path validation process. However, moving all of the
parameters required for path validation between a server and a client
is expensive in terms of bandwidth. Thus I think we should consider a
suggestion Denis Pinkas made on the list a while ago. We could make
ALL requests refer to a policy configured at the server, rather than
allowing for explicit transmission of these parameters. To make this
as flexible as the current proposals, we would have to add a new
protocol, to allow a client to register a policy with a server, so
that the client could later refer to that policy. We probably want a
facility to inquire about a registered policy as well. We could
proceed with the development of DPD/DPV protocols prior to having the
policy registration and inquiry protocols defined, if we feel the need
to, but I would prefer parallel development of such protocols. The
bottom line would be much simpler syntax for the requests and
responses for both DPD and DPV, and smaller message sizes.<br>
<br>
2- Along the same line of reasoning, Denis rightly noted that the
primary purpose of DPV is to provide the yes/no/maybe response to a
query re a target certificate. Thus, we ought to have a compact
message format to provide this response, and a separate message for
retrieval of the supporting data for the response, e.g., for NR
purposes.&nbsp; He proposed this split, with a hash of the
"evidence" in the short response, to tie the two together. I like
this suggestion and propose that we adopt this model as part of out
requirements. Of course, we need the protocol for retrieving the
evidence as well, to make the system complete.</font><br>
<font color="#000000"></font></div>
<div><font color="#000000">3- we still have some significant
disagreement about the nature of the path validation controls to be
used for both services, but especially for DPD. Related to this
disagreement is the issue of whether an DPD should support incremental
queries relative to the same target certificate. I don't think we
have seen a concise, comprehensive description of the application
model where such an incremental approach is warranted, so I solicit
the proponents of this approach to provide such a description, so that
we can resolve this issue.</font></div>
<div><br></div>
<div>I'm off on vacation next week, see you later,</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1226729903==_ma============--

Reply-To: <[email-masked]>
From: =?iso-8859-1?Q?Juan_Carlos_P=E9rez_Aguayo?= <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: draft meeting minutes, please comment 
Date: Fri, 23 Mar 2001 16:47:37 -0400
Importance: Normal

I'am working with the RFC2527 and I'am very interested in changes too.

Thanks

Juan Carlos

-----Original Message-----
From: Michael Helm [mailto:[email-masked]]
Sent: Viernes, 23 de Marzo de 2001 15:58
To: [email-masked]
Subject: Re: draft meeting minutes, please comment 

Stephen Kent writes:
> PKIX WG Meeting 3/20-01
  ...
> Evolving Specifications
        ...
> 	CP/CPS Framework

Tim Polk said a few brief words about this, but I don't 
have any more in my notes than are in the minutes.
I couldn't find a draft in the ietf site or in my
non-deleting mirror.   Is there anything out there?
We're working with the earlier framework & interested
in changes.  Thanks, ==mwh
Michael Helm
ESnet/LBNL

To: [email-masked]
Reply-to: [email-masked]
Subject: Re: draft meeting minutes, please comment 
Date: Fri, 23 Mar 2001 11:58:20 -0800
From: Michael Helm <[email-masked]>

Stephen Kent writes:
> PKIX WG Meeting 3/20-01
  ...
> Evolving Specifications
        ...
> 	CP/CPS Framework

Tim Polk said a few brief words about this, but I don't 
have any more in my notes than are in the minutes.
I couldn't find a draft in the ietf site or in my
non-deleting mirror.   Is there anything out there?
We're working with the earlier framework & interested
in changes.  Thanks, ==mwh
Michael Helm
ESnet/LBNL

Sender: [email-masked]
Date: Fri, 23 Mar 2001 18:52:59 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: [email-masked]
Subject: Re: Logotypes in certificates

"David P. Kemp" wrote:
> 
> If no one can propose a method by which a CA should decide not to
> certify a logo "similar to" the Chevrolet bowtie or the AT&T deathstar
> for someone other than Chevrolet or AT&T respectively, then it is
> obvious that changing PKIX to support logos has *NO* value to the
> user.

And being a CA I would be so afraid of trademark issues that I would
refuse to decide about "similar" logos at all.

> I submit that it has negative value; a misleading logo
> in a certificate is worse than none at all.

I agree on that.

Ciao, Michael.

Sender: [email-masked]
Date: Fri, 23 Mar 2001 12:46:49 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: Logotypes in certificates

"Manger, James H" wrote:
> 
> An entity does not have to have a unique logo.  To be useful,
> it is sufficient that the logo unambiguously identifies
> an entity (within the context of use).
> 
   ... and
> 
> Images (e.g. logos) are a widely used form of identification (and for good
> reason, as they are very human-friendly (ease to use)).  I suggest PKIX
> should change to support logos, rather than trying to changes our five
> senses.

A correlary of the first statement is: If the logo does not
unambiguously identify an entity within the context of use, then
it is not useful.  I predict that Stefan will find it impossible
to propose a criterion against which it can be determined that
a CA is operating correctly, i.e. that the CA will certify a logo
that identifies the entity, and that it will not certify a logo
that mis-identifies the entity.

If no one can propose a method by which a CA should decide not to
certify a logo "similar to" the Chevrolet bowtie or the AT&T deathstar
for someone other than Chevrolet or AT&T respectively, then it is
obvious that changing PKIX to support logos has *NO* value to the
user.

I submit that it has negative value; a misleading logo
in a certificate is worse than none at all.

(I concede that a logo capability has marketing value to CAs and
entertainment value to us geeks.  But PKIX shouldn't be about
satisfying those urges at the expense of the user.)

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Matching CertIDs between OCSP requests and responses
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sat, 24 Mar 2001 04:19:44 (NZST)

Jeff Jacoby <[email-masked]> writes:

>Pardon my naivte, but couldn't the responder apply a different BER/DER
>encoding to CertID in its response, yet keeping the actual encoded values
>within a CertID identical?

Well, you couldn't use a different DER encoding (there's only one correct one),
and you wouldn't BER-encode signed data, so I doubt there's any real problem.

Peter.

Date: Fri, 23 Mar 2001 10:11:25 -0500
To: Stefan Santesson <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Logotypes in certificates
Cc: [email-masked]

Stefan,

>Steve,
>
>There was a suggestion during a dinner yesterday that logotypes 
>actually could be provided as a policy qualifier. That would 
>actually solve your problem since you could directly tie acceptance 
>of logotypes in certificates to a particular policy.
>
>This enables you to control the path validation problem with the use 
>of policy constraints.
>

I'd be comfortable with that approach, except that we have 
discouraged use of policy qualifiers, as Russ noted.

Let me suggest again that you send another message that includes a 
comprehensive rationale for inclusion of logotypes, indicating what 
types of certs would be allowed to contain them, what reference form 
you envision, and what controls you think should be employed to 
prevent the sorts of misuse I warned about.  With a concrete 
proposal, and well articulated rationale on the table, I think we 
have a better chance of making progress.

Steve

From: "Anders Rundgren" <[email-masked]>
To: "Dean Povey" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Logotypes in certificates 
Date: Fri, 23 Mar 2001 11:43:33 +0100

Dean,

>We also need to think beyond just logos.  What about photographs of employees
>in Certificates?  This is such a useful thing to be able to do.

That is indeed a working solution for folks working with digital ID-cards
although QC suggests another (much harder to implement and deploy)
solution.

>But I feel that perhaps the weight of opinion is against me :-(.

In IETF-PKIX yes, outside no.

Anders

To: Aram Perez <[email-masked]>
cc: [email-masked]
Subject: Re: Logotypes in certificates 
Date: Fri, 23 Mar 2001 20:30:34 +1000
From: Dean Povey <[email-masked]>

>> This message is in MIME format. Since your mail reader does not understand
>this format, some or all of this message may not be legible.
>
>--MS_Mac_OE_3068143512_561796_MIME_Part
>Content-type: text/plain; charset="US-ASCII"
>Content-transfer-encoding: 7bit
>
>So which is the the real logo?
>

Similar logos deleted.  

This is of course a valid point, but one can find similar examples in names.

One of the major banks in Australia is "The Commonwealth Bank of
Australia " (commonly shortened to CBA) so which of the following is
the correct domain name for it? (All of these are valid domains with live
websites attached).

1. www.cba.com.au
2. www.cba.com
3. www.commbank.com.au
4. www.commonwealthbank.com

The answer is actually 3, although 1 redirects to this.  Actually I can't
be 100 percent sure that it is 3 since connecting to 
https://www.commbank.com.au redirects me to the non-ssl website so the
connection is not secured :-). 

We are not proposing that logos are less ambiguous than names, simply that they are another datapoint which the user can use to make their decision. Part of
the problem can be addressed by CAs only certifying registered trademarks
which they can easily check and which have to by nature be unlike other
trademarks.  Policy and procedures can deal with many of the objections that
people raise. 

We also need to think beyond just logos.  What about photographs of employees
in Certificates?  This is such a useful thing to be able to do.  I am 
cognisant of the reticence of people to stuff too much in certs, and I think
in general this is a good principle.  But providing it is done sensibly I think
there is a fair bit to suggest that a scheme like this would significantly
contribute to the security of PKI systems.

But I feel that perhaps the weight of opinion is against me :-(.

Cheers.
--
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

Date: Fri, 23 Mar 2001 11:28:10 +0100
From: Bodo Moeller <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: PKAlgs: 02: DSA Signature Keys needs re-wording

On Fri, Mar 23, 2001 at 09:53:19AM +0100, [email-masked] wrote:

> Some further comments:
> 
> section 2.2.2 states:
> When the id-dsa-with-sha1 algorithm identifier appears as the algo-
>    rithm field in an AlgorithmIdentifier, the encoding SHALL omit the
>    parameters field.
> 
> This seems to contradict the intended contents of section 2.3.2 ?

No.  Section 2.3 is on algorithm identifiers for *keys* contained in
certificates; section 2.2 is on algorithm identifiers for *signatures*.
To verify a signature, you must already have the key, and that is
where you obtain the parameters from.

A couple of days ago I misunderstood the draft exactly as you do now
(except that I had looked at ECDSA where you now look at DSA :-).
So maybe it's not just me and the draft should have some additional
clarification in the text.  The confusion is caused by the use of
'AlgorithmIdentifiers' for two different purposes: in the
'signatureAlgorithm' field and in the 'subjectPublicKeyInfo' field.

Proposed change for the DSA case, section 2.2.2: Replace

   When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in an AlgorithmIdentifier, the encoding SHALL omit the
   parameters field.  [...]

by

   When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in a signatureAlgorithm field, the encoding SHALL omit the
   parameters field.  [...]

(Similarly for ECDSA.)

(But note that the 'id-dsa-with-sha1' algorithm identifier is never
actually used in 'subjectPublicKeyInfo' fields, so even when taken
out of context the original wording from 2.2.2 is not wrong
-- in 'subjectPublicKeyInfo' fields, you'd see the 'id-dsa' algorithm
identifier instead.)

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

From: "Manger, James H" <[email-masked]>
To: [email-masked]
Subject: RE: Logotypes in certificates
Date: Fri, 23 Mar 2001 19:59:44 +1100

> [Aram Perez] So which is the real logo?

So which is your real name? "A. Perez", "Aram Perez" or "Mr Aram Perez"

Both questions are irrelevant.  An entity does not have to have a unique
logo.  To be useful, it is sufficient that the logo unambiguously identifies
an entity (within the context of use).

> [Michael Zolotarev] we touch the slippery path of using graphical
> images as a formal constituent of trust establishement

A logo does not establish trust.  A logo aids identification.  A logo can
help you recognise an entity you already trust.

Images (e.g. logos) are a widely used form of identification (and for good
reason, as they are very human-friendly (ease to use)).  I suggest PKIX
should change to support logos, rather than trying to changes our five
senses.

> [Stefan Santesson] logotypes could be provided as a policy qualifier

How on earth does a logo qualify the policy under which a certificate was
issued?  Using this field sounds like a major hack.

From: [email-masked]
Reply-To: <[email-masked]>
Sender: "Stefan Heiss" <[email-masked]>
To: <[email-masked]>
Subject: PKAlgs: 02: DSA Signature Keys needs re-wording
Date: Fri, 23 Mar 2001 09:53:19 +0100
Importance: Normal
Disposition-Notification-To: "Stefan Heiss" <[email-masked]>

Some further comments:

section 2.2.2 states:
When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in an AlgorithmIdentifier, the encoding SHALL omit the
   parameters field.

This seems to contradict the intended contents of section 2.3.2 ?

Some more minor editorials:
p.3: For each algorithm, the appropriate alternatives for the the keyUsage
...
                                                              ^
p.11: g specifies the generator of the multiplicative subgroup of order g;
                  ^----- (maybe better: "a generator" ?)
^----- should be "q"
p.11: q specifies the prime factor of p-1;
                  ^----- (maybe better: "a prime factor" ?)

p.16:
Maybe it would be nice to extend the following lines (similar to the
following definitions
of gnBasis, etc.):
   prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
   Prime-p ::= INTEGER    -- Field size p (p in bits)
   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
   Characteristic-two ::= SEQUENCE {
   ...

   prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
   -- type for parameters field for prime-field is Prime-p
   Prime-p ::= INTEGER    -- Field size p (p in bits)
   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
   -- type for parameters field for characteristic-two-field is
Characteristic-two
   Characteristic-two ::= SEQUENCE {
   ...

p.12,p.13,p.18  ... MAY assert either encipherOnly and decipherOnly.
                                                   ^----- or

> Sent: Friday, March 23, 2001 7:52 AM
> To: [email-masked]
> Subject: PKAlgs: 02: DSA Signature Keys needs re-wording
>
>
> Comments on draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.3.2
> "DSA Signature
> Keys":
>
> The paragraph beginning "If the DSA algorithm parameters are
> absent" has 3
> sentences.  The 2nd and 3rd contradict each other (at least the 2nd is
> useless in light of the 3rd).  The next paragraph repeats the
> 1st and 3rd
> sentences.
> Delete something.  Perhaps replace the two paragraphs with
> "The DSA domain
> parameters may be omitted if and only if the certificate is
> signed using a
> DSA key that has the same parameters.".
>
> The DSA signature values r & s should not be mentioned in
> this section.
> They are appropriately, clearly and completely defined in
> section 2.2.2 "DSA
> Signature Algorithm"; with an OID, parameters (omit),
> Dss-Sig-Value syntax
> and mapping to a bit string.
> Delete the paragraph beginning "When signing, DSA algorithm
> generates", the
> definition of Dss-Sig-Value and the paragraph beginning "The encoded
> signature is conveyed".
>
>
> Minor editorials:
> Ecdsa-Sig-Value is ECDSA-Sig-Value in the ASN.1 module.
> RSAPublicKey, DSAPublicKey and DHPublicKey are not in the
> ASN.1 module.
> Comment with Dss-Parms in ASN.1 module should be "for DSA
> parameters", not
> "for DSA public key".
>

From: "Manger, James H" <[email-masked]>
To: [email-masked]
Subject: PKAlgs: 02: DSA Signature Keys needs re-wording
Date: Fri, 23 Mar 2001 17:51:42 +1100

Comments on draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.3.2 "DSA Signature
Keys":

The paragraph beginning "If the DSA algorithm parameters are absent" has 3
sentences.  The 2nd and 3rd contradict each other (at least the 2nd is
useless in light of the 3rd).  The next paragraph repeats the 1st and 3rd
sentences.
Delete something.  Perhaps replace the two paragraphs with "The DSA domain
parameters may be omitted if and only if the certificate is signed using a
DSA key that has the same parameters.".

The DSA signature values r & s should not be mentioned in this section.
They are appropriately, clearly and completely defined in section 2.2.2 "DSA
Signature Algorithm"; with an OID, parameters (omit), Dss-Sig-Value syntax
and mapping to a bit string.
Delete the paragraph beginning "When signing, DSA algorithm generates", the
definition of Dss-Sig-Value and the paragraph beginning "The encoded
signature is conveyed".

Minor editorials:
Ecdsa-Sig-Value is ECDSA-Sig-Value in the ASN.1 module.
RSAPublicKey, DSAPublicKey and DHPublicKey are not in the ASN.1 module.
Comment with Dss-Parms in ASN.1 module should be "for DSA parameters", not
"for DSA public key".

-----draft-ietf-pkix-ipki-pkalgs-02.txt
2.3.2  DSA Signature Keys

   The Digital Signature Algorithm (DSA) is defined in the Digital Sig-
   nature Standard (DSS) [FIPS 186]. The DSA OID supported by this pro-
   file is

        id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040)
                  x9cm(4) 1 }

   The id-dsa algorithm syntax includes optional domain parameters.
   These parameters are commonly referred to as p, q, and g.  When omit-
   ted, the parameters component MUST be omitted entirely. That is, the
   AlgorithmIdentifier MUST be a SEQUENCE of one component: the OBJECT
   IDENTIFIER id-dsa.

   If the DSA domain parameters are present in the subjectPublicKeyInfo
   AlgorithmIdentifier, the parameters are included using the following
   ASN.1 structure:

        Dss-Parms  ::=  SEQUENCE  {
            p             INTEGER,
            q             INTEGER,
            g             INTEGER  }

   If the DSA algorithm parameters are absent from the subjectPublicKey-
   Info AlgorithmIdentifier and the CA signed the subject certificate
   using DSA, then the certificate issuer's DSA parameters apply to the
   subject's DSA key.  If the DSA domain parameters are absent from the
   subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the sub-
   ject certificate using a signature algorithm other than DSA, then the
   subject's DSA domain parameters are distributed by other means.  If
   the subjectPublicKeyInfo AlgorithmIdentifier field omits the parame-
   ters component and the CA signed the subject with a signature algo-
   rithm other than DSA, then clients MUST reject the certificate.

   The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
   within a certificate where the parameters may be used. If the DSA
   domain parameters are absent from the subjectPublicKeyInfo Algorith-
   mIdentifier and the CA signed the subject certificate using DSA, then
   the certificate issuer's DSA domain parameters apply to the subject's
   DSA key.  If the DSA domain parameters are absent from the sub-
   jectPublicKeyInfo AlgorithmIdentifier and the CA signed the certifi-
   cate using a signature algorithm other than DSA, then clients shall
   not validate the certificate.

   When signing, DSA algorithm generates two values.  These values are
   commonly referred to as r and s.  To easily transfer these two values
   as one signature, they are ASN.1 encoded using the following ASN.1
   structure:

        Dss-Sig-Value  ::=  SEQUENCE  {
            r             INTEGER,
            s             INTEGER  }

   The encoded signature is conveyed as the value of the BIT STRING sig-
   nature in a Certificate or CertificateList.

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

        DSAPublicKey ::= INTEGER -- public key, Y

Date: Thu, 22 Mar 2001 22:05:11 -0800
From: Aram Perez <[email-masked]>
Subject: Re: Logotypes in certificates
To: Dean Povey <[email-masked]>
Cc: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--MS_Mac_OE_3068143512_561796_MIME_Part
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

So which is the the real logo?

Regards,
Aram Perez

--MS_Mac_OE_3068143512_561796_MIME_Part
Content-type: image/gif; name="visa2.gif";
 x-mac-creator="3842494D";
 x-mac-type="47494666"
Content-disposition: attachment
Content-transfer-encoding: base64

--MS_Mac_OE_3068143512_561796_MIME_Part
Content-type: image/gif; name="visa1.gif";
 x-mac-creator="3842494D";
 x-mac-type="47494666"
Content-disposition: attachment
Content-transfer-encoding: base64

R0lGODlhJAAWAMQAAAAAAP///006PVhzmwkqU624xb3H083U3eXp7nuNogAzZpmsvP+ZAP5m
AcVYE6BPIMzMzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACwAAAAAJAAWAAAFzGAgjmRpnmigrGzrvvArxnQNz3Ze43rv8r6gCEE8GInFQxEJKSiRiCcU
UUIMrlTrALEYLAKJ1SBBDVwHhZTIsKIOCFsFobAgKAYrUYHAT6gDCG1sCkYrB29+RCJ4eH5q
VgQGiGBwlHdldV6Vj4xtZgRfZnJbKgoGewN/n3ZfB556cnSsb6RqCXykt1tXC2GgeCx2qmEK
oW8LgXx2CXUKRINlKQgGByMHBll0C9XX0UYnDOHi4+Tl5uUi5+rr5uns7+vu8PPk8vT3qvmq
IQA7

--MS_Mac_OE_3068143512_561796_MIME_Part
Content-type: image/gif; name="visa3.gif";
 x-mac-creator="6F676C65";
 x-mac-type="47494666"
Content-disposition: attachment
Content-transfer-encoding: base64

R0lGODlhJQAXAMQAAP/////Mmf+ZAMz//8zM/8zMzJnMzJmZzJmZmWaZzGaZmWZmmTNmmTNm
ZjMzZgAzZgAAZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACwAAAAAJQAXAAAF6uAjjmRpnqgIrGzrvjCsQmltPxCg3jyqP7+ecAekDXs5lQKBODidzOez
KY1OmQjFz1XosgiFVVhcILS6ZpeqdRCFCw8HYPEoGEhaQPvBeK1bDXUADA8HPwSBBwULYQMO
I35ALnQGbX1tCwCPmSwKDwqPA2qSLZ4HgQaDhXoiDmEEcQSPYyx/LG2PfQNuYoQNAJ4LsoIt
tit3vHeXqbhwJanFpCzOeQsQiiUH1gp2iaMwBtAAlaIFBwoJYeRiB2m1QAHx8vP09fb0WwL6
+/z9/v/98gEcSDCgioIICQpMyJDflhgQI8o4QlFECAA7

--MS_Mac_OE_3068143512_561796_MIME_Part--

Sender: [email-masked]
Date: Fri, 23 Mar 2001 01:08:39 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: "[email-masked]" <[email-masked]>
Subject: Re: it gets worse -- Microsoft warns of hijacked certificates

Ed Gerck wrote:
> 
> "A field in every certificate should indicate the CRL Distribution Point
> (CDP) - the location from which the CRL can be obtained. The problem is
> that VeriSign code-signing certificates leave the CDP information blank.

My intention always was that in current PKIX specs too many things
are optional.

Instead of discussing additional optional extensions (e.g. logos) we
should discuss how to build a secure and easy-to-implement PKI
system by making more details mandantory or leave them out
completely.

Ciao, Michael.

Date: Thu, 22 Mar 2001 15:33:16 -0800
From: Ed Gerck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: it gets worse -- Microsoft warns of hijacked certificates

 http://news.cnet.com/news/0-1003-200-5222484.html?tag=tp_pr

It gets worse. As many developers in PKI have pointed out
over more than 4 years (see www.mcg.org.br/certover.pdf),
even though CAs such as VeriSign periodically generate a Certificate
Revocation List (CRL), which lists all the certificates that should be
considered invalid, this does not work for several reasons paradoxically
built into the system. Why?

As Microsoft has ignored in all these years, but now proves as its own
medicine, one reason is that VeriSign certificates do not support what they
should comply with. In Microsoft's own words:

"A field in every certificate should indicate the CRL Distribution Point
(CDP) – the location from which the CRL can be obtained. The problem is
that VeriSign code-signing certificates leave the CDP information blank.
As a result, even though VeriSign has added these two certificates to
its current CRL, it’s not possible for systems to automatically download
and check it."

The solution is a software-patch. But, what certifies the software-patch?
Maybe the guys that did this mess could also get their patch certified,
which patch would then revoke the correct certificates and leave just the
rogue ones?

Cheers -- Ed Gerck

From: Michael Zolotarev <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked]
Subject: RE: Logotypes in certificates
Date: Fri, 23 Mar 2001 10:15:29 +1100

I agree with Todd that once we touch the slippery path of using graphical
images as a formal constituent of trust establishement, the problem will
become a far more exotic one than defining a set of rules for verification
algorithm.

I feel that there is no common understanding of the logotype's intended
purpose (purpose, not handling!), and therefore the arguments are making
rounds. Following are the points which require clarification, in order to be
certain what use scenario we are talking about:

1 Logotypes are allowed in (to be referenced from) EE PKC:
1.1 Logotypes in EE PKC are there for 'informational use only'. They are not
part of the Subject's name, in whatever form. They must be ignored by
validation process. Identity with a logotype is no different from the same
identity less logotype.

1.2 Logotype in EE PKC is a valid component of the Subject's identity.
Identity with a logotype is different from the same identity less logotype.
A single PK cannot be bound to the two identities.

2 Logotypes are allowed to be referenced from CA certificates.
2.1 Logotypes are only allowed in self-signed CA certificates.

My original understanding of the proposal was 1.1-yes, 1.2-no, 2-yes,
2.1-no.

This way, logotypes have a simple purpose of branding and pleasing humal
eyes. No trust. I can reference a logotype url from my certificate, and
later remove the logotype (so that the url becomes a dead one). It should
not affect the acceptance of my certificate by formal validation procedures.

(I'm not saying that branding and eyes pleasure justify the troubles :)

Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 23, 2001 6:48 AM
To: Michael Zolotarev
Cc: 'Stefan Santesson'; Stephen Kent; Michael Zolotarev;
[email-masked]
Subject: RE: Logotypes in certificates

As I have said a number of times already, there is no use
between machines for the Logo as part of the cert. 

This is purely for human's that might want to look at a
redition of the cert in a paper-like framework, which BTW
is essentially a per-use type of decision and not ANYTHIG
having to do with the negotiability or negotiations
process of the cert itself.

As Mssr. Kemp has pointed out as well, let the
application, if it needs to, deal with displaying a Logo
as part of its opeations.

If this presists as a topic of conversation then I would
suggest that a formal specification for the "CertViewer"
is needed as part of this same scheme so that the Logo's
will render and look the same everywhere otherwise the
logo and its intended use is pointless and the fact that
it is "potentially different" on a number of platforms
will lesson the value and increase the potential
confusion factor for the use of these additions.

--
Regards,
Todd
> Now I'm really confused.
> 
> The whole problem is, as Stephen has neatly put it, that "the whole
purpose
> of including a displayable logo is precisely an attempt by a CA to gain
the
> trust of users".
> 
> A CA requires to gain trust of a user if it is not still trusted
> (obviously). Which is the case when a path construction 
> (not validation!) ended up at some self-signed CA which is not among the
> user's trusted roots set. This is the only case I can think of when a
> decision is to be made by the user, i.e. whether to trust that CA or not. 
> 
> I cannot think of any other situation when a CA would require to "gain the
> trust of users".
> 
> If so, then the scope of analysis of logotype's impact is limited to path
> construction, not to path validation. Because, again, validation begins
when
> the trust is already defined, and it is to late for the user to intervene.

> 
> Path validation algorithm is 'silent', it does not need to present
anything
> to the user. Therefore, presence of a logotype cannot possible affect the
> result of the validation, as the user is not asked about anything, or
> presented anything, at that stage.
> 
> Consiquently, I'm failing to understand how path validation parameters and
> constrains can be affected by the logotypes.
> 
> I guess there may be something fundamental I'm missing...
> 
> Regards
> Michael
>  
> 
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Friday, March 23, 2001 4:56 AM
> To: Stephen Kent; Michael Zolotarev
> Cc: [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> Steve,
> 
> There was a suggestion during a dinner yesterday that logotypes actually 
> could be provided as a policy qualifier. That would actually solve your 
> problem since you could directly tie acceptance of logotypes in 
> certificates to a particular policy.
> 
> This enables you to control the path validation problem with the use of 
> policy constraints.
> 
> /Stefan
> 
> 
> At 18:21 2001-03-21 -0500, Stephen Kent wrote:
> >Michael,
> >
> >>Though I don't favor including logotype or reference to a logotype to a
> >>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
> >>realisation was that a logotype is by no means related to the
> establishment
> >>of trust. It is 100% meant for a human eye only, and verification
> algorithm
> >>should simply ignore it, as it ingores any other proprietory extentions.
> If
> >>the verification comes up with an answer 'not validated', and the
software
> >>prompts a user saying 'couldn't validate', and the user still makes a
> >>decision to trust the cert, it is an application's problem, which
already
> >>exists now, and logotypes add no extra pitch to it.
> >
> >I think the whole purpose of including a displayable logo is precisely an

> >attempt by a CA to gain the trust of users, so I disagree with your 
> >stating point. The concern I raised is not one that is addressed by your 
> >example, i.e., my example of a "bad outcome" is a cert that carries a
logo 
> >which will be recognized by a user and thus will engender the user's 
> >confidence, but it is contained in a cert that, while valid under our
path 
> >validation controls, has nothing to do with the entity whose logo appears

> >in the cert and which is displayed to the user.
> >
> >>As an extreme, if a CA considers logotypes to be anyhow harmful, it
simply
> >>won't have a logotype in its own cert, and refuse certification of
> >>logotypes.
> >
> >As a CA I can refuse to certify a logo-equipped cert one layer down, but 
> >not farther, unless we adopt a means of representing the logo that is 
> >subject to existing controls. Tom suggested on possible means, if we put 
> >the logo in an altname field and make it a type which can be prohibited 
> >using nameConstraints.
> >
> >Steve
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
> 
>
----------------------------------------------------------------------------
----
> ---------------------------------
> The information contained in this message is confidential and is intended 
> for the addressee(s) only.  If you have received this message in error or 
> there are any problems please notify the originator immediately.  The 
> unauthorized use, disclosure, copying or alteration of this message is 
> strictly forbidden. Baltimore Technologies plc will not be liable for
direct, 
> special, indirect or consequential damages arising from alteration of the 
> contents of this message by a third party or as a result of any virus
being 
> passed on.
> 
> In addition, certain Marketing collateral may be added from time to time
to 
> promote Baltimore Technologies products, services, Global e-Security or 
> appearance at trade shows and conferences.
>  
> This footnote confirms that this email message has been swept by 
> Baltimore MIMEsweeper for Content Security threats, including
> computer viruses.

To: "Trevor Freeman" <[email-masked]>
Cc: [email-masked]
Subject: Re: Logotypes in certificates 
Date: Fri, 23 Mar 2001 08:17:05 +1000
From: Dean Povey <[email-masked]>

>Logically speaking, this is a name in that we are talking about a token
>which represents an organization. Its just a graphical token, not a
>textual token. However I full agree with Steve that like other name
>forms, we have to validate the CAs write to assert that logo. I for one
>don't see a way to make this work with graphics, and unless it lives by
>the same rules as text rules, it is open to abuse and therefore is a
>very bad idea.

This is really a very defeatist attitude.  Just because you can't enforce
technically the ability to make a logo fall within a certain `space'
doesn't mean you can't control it technically.  What constraints could the
a higher level CA possibly want to enforce on a logo later in the path
other than the right to either include one or not?  Name Constraints
already exists to restrict the range of possible spaces the DN/names would fall
into (i.e. who you can issue certs to) and the subordinate CA has to follow
the certificate policy or the whole thing falls down anyway.  

This is a really esoteric problem, and there is a simple solution - punt 
it to policy and revoke the subordinate CAs cert if they break the rules.  
Honestly you have far more to worry about if the subordinate CA is not 
following your identification/authentication rules than if they are 
including a pointer to a logo in their cert.  You can no more enforce 
these with fields in the Certificate than you can enforce constraints on 
graphical types.

The big benefit of logos is surely that it makes Joe User more involved/
aware of the security process that is occurring.  Give the propensity of 
users to ignore pop up text messages (or turn them off), this has to be a 
good thing.

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

Date: Thu, 22 Mar 2001 17:12:09 -0500
To: "Trevor Freeman" <[email-masked]>, <[email-masked]>
From: "David A. Cooper" <[email-masked]>
Subject: RE: specific policies used in conjunction with anyPolicy

Trevor,

I do not see why you think I have made a "big leap". Are you referring to my suggestion that one can assert both anyPolicy and some specific policies or that applications may choose different values for initial-any-policy-inhibit?

First, we have to acknowledge the existence of the inhibitAnyPolicy extension. If a CA includes this extension in a certificate that it issues, then the anyPolicy OID will be ignored in any certificates that follow that certificate in a certification path. If the issuers of those certificates do not specify policies other than anyPolicy in their certificates, then the certification path will either be rejected or will be accepted under no polices. So, if policies are important, and there is the possibility that a CA (or the relying party) will inhibit the processing of anyPolicy, then it will not be sufficient for CAs to assert just the anyPolicy OID. If you want it to be the case that "if you assert the all polices OID in a CA certificate, it is an operational simplification, and the administrator does not need to add any more", then you'll to get rid of inhibitAnyPolicy.

Second, while you may not be able to conceive of an instance where an application would care about the value of initial-any-policy-inhibit, it appears that Carlin Covey can. He stated that he wanted "to support applications that insist on finding a specific policy OID, and also support more liberal applications that will tolerate the anyPolicy OID." The way for an application to specify that it insists on finding a specify policy OID is to set initial-any-policy-inhibit.

At 11:58 AM 3/22/01 -0800, Trevor Freeman wrote:
>Dave,
>You have made a big leap here which I had not interpreted from the text.
>This revolved around who is driving the inputs into the path validation
>process. I can conceive instances where an application would want to
>pass in a-d. I do not think for one moment that an application would
>care about the rest, nor should they. This stuff is already way to
>complex, and interdependencies like this are a nightmare. We are on an
>uphill battle to get applications to use PK wisely in the first place
>because they think it is hard. Now you are asserting that we need to
>make PK administrators knowledgeable about what applications they are
>supporting and expect that they are intimacy aware of all their needs.

As I stated above, I was merely describing how Carlin Covey could accomplished what he wanted to do. If you think there is something wrong with what he wants to do, that is a different matter. I was merely pointing out that it is supported by the standard.

>That is not doing to happen. We need clean simple rules if this is to be
>successful. So lets start be saying if you assert the all polices OID in
>a CA certificate, it is an operational simplification, and the
>administrator does not need to add any more.

Unless the inhibitAnyPolicy extension is eliminated, this is simply not the case.

>Trevor
>From: David A. Cooper [mailto:[email-masked]] 
>Sent: Wednesday, March 21, 2001 12:32 PM
>To: [email-masked]
>Subject: Re: specific policies used in conjunction with anyPolicy
>
>Yes, you may assert both anyPolicy and specific certificate policies in
>the same certificate. This may not be specifically stated, but path
>processing algorithm (section 6.1.3) does take this possibility into
>account.
>
>The reason that this is allowed is exactly the one you stated.
>Originally there was a rule that if anyPolicy were included in the
>certificatePolicies extension, then no other policy could be included.
>This rule was removed when the inhibitAnyPolicy extension was developed.
>In the case you mention, the "strict" applications would set
>initial-any-policy-inhibit in order to ensure that the path would only
>be considered valid under policies that had been explicitly listed in
>each certificate. The more liberal applications would not set
>initial-any-policy-inhibit and would then (possibly) consider the path
>to be valid under more policies.
>
>At 01:11 PM 3/21/01 -0600, Carlin Covey wrote:
> >The certificate policies extension allows a sequence of policy OIDs.
> >One such policy OID is anyPolicy.  I assume that it is permissible in a
> >CA cert to include specific policy OIDs in addition to the anyPolicy OID.
> >The reason I would want to do this is to support applications that insist
> >on finding a specific policy OID, and also support more liberal applications
> >that will tolerate the anyPolicy OID.
> >
> >draft-ietf-pkix-new-part1-05 does not appear to prohibit using specific
> >policy OIDs and the anyPolicy OID in the same CA cert.  Is this true?

To: "David P. Kemp" <[email-masked]>
cc: [email-masked]
Subject: Re: Logotypes [not] in certificates 
Date: Fri, 23 Mar 2001 07:59:17 +1000
From: Dean Povey <[email-masked]>

>The CA is involved in certifying the identity of the end entity, but
>only the end entity itself is responsible for displaying or not
>displaying a particular logotype in its communications with other end
>entities.  Most of the postings in favor of logotypes in certificates
>have described why branding is important to users, but have failed
>to to justify the necessity of a CA's involvement in the branding
>process.

Hmm, I think the reasoning for involving the CA is pretty straight 
forward. The problem that certificates is trying to solve is to provide a 
means for a user to determine the correct public key to use to talk to a 
particular entity.  Traditionally this is done by binding this key to a 
name.  However, names are frequently ambiguous and in some cases are 
difficult to recognise.  This leads to problems where an attacker obtains 
a Certificate for a name similar to an organisation they are trying to 
target.  For a concrete examples see the recent slashdot story:

http://slashdot.org/articles/01/03/22/1947233.shtml

And MicroSoft's Bulletin:
http://www.microsoft.com/technet/security/bulletin/MS01-017.asp

Logos are much easier for humans to recognise.  By having a CA bind the
public key to a logo and having the UI use it appropriately you enable
users to make much better decisions about how they use their certificates.
How many people take the trouble to read all the Certificate fields these
days?

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

Date: Thu, 22 Mar 2001 15:22:43 -0500
To: Stefan Santesson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: Logotypes in certificates
Cc: Stephen Kent <[email-masked]>, Michael Zolotarev <[email-masked]>, [email-masked]

As every long-standing participant knows, I absolutely hate policy 
qualifiers.  That said, I find it extremely difficult to send this 
message.   Given the alternatives that have been discussed so far, I like 
this one much more.

Russ

At 06:55 PM 3/22/2001 +0100, Stefan Santesson wrote:
>Steve,
>
>There was a suggestion during a dinner yesterday that logotypes actually 
>could be provided as a policy qualifier. That would actually solve your 
>problem since you could directly tie acceptance of logotypes in 
>certificates to a particular policy.
>
>This enables you to control the path validation problem with the use of 
>policy constraints.
>
>/Stefan
>
>
>At 18:21 2001-03-21 -0500, Stephen Kent wrote:
>>Michael,
>>
>>>Though I don't favor including logotype or reference to a logotype to a
>>>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
>>>realisation was that a logotype is by no means related to the establishment
>>>of trust. It is 100% meant for a human eye only, and verification algorithm
>>>should simply ignore it, as it ingores any other proprietory extentions. If
>>>the verification comes up with an answer 'not validated', and the software
>>>prompts a user saying 'couldn't validate', and the user still makes a
>>>decision to trust the cert, it is an application's problem, which already
>>>exists now, and logotypes add no extra pitch to it.
>>
>>I think the whole purpose of including a displayable logo is precisely an 
>>attempt by a CA to gain the trust of users, so I disagree with your 
>>stating point. The concern I raised is not one that is addressed by your 
>>example, i.e., my example of a "bad outcome" is a cert that carries a 
>>logo which will be recognized by a user and thus will engender the user's 
>>confidence, but it is contained in a cert that, while valid under our 
>>path validation controls, has nothing to do with the entity whose logo 
>>appears in the cert and which is displayed to the user.
>>
>>>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
>>>won't have a logotype in its own cert, and refuse certification of
>>>logotypes.
>>
>>As a CA I can refuse to certify a logo-equipped cert one layer down, but 
>>not farther, unless we adopt a means of representing the logo that is 
>>subject to existing controls. Tom suggested on possible means, if we put 
>>the logo in an altname field and make it a type which can be prohibited 
>>using nameConstraints.
>>
>>Steve

content-class: urn:content-classes:message
Subject: RE: Logotypes in certificates
Date: Thu, 22 Mar 2001 11:58:58 -0800
From: "Trevor Freeman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Logically speaking, this is a name in that we are talking about a token
which represents an organization. Its just a graphical token, not a
textual token. However I full agree with Steve that like other name
forms, we have to validate the CAs write to assert that logo. I for one
don't see a way to make this work with graphics, and unless it lives by
the same rules as text rules, it is open to abuse and therefore is a
very bad idea.
Trevor

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2001 9:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Logotypes in certificates

"Tom Gindin" <[email-masked]> writes:

>Wouldn't Logotypes most easily be implemented as an OTHER-NAME within
one of
>the alternate name fields (probably SubjectAltName)?  If so, how would
they
>affect NameConstraints and the like?  IMHO, they would have little
effect on
>them since logos are not hierarchical names and thus couldn't easily be
>governed by NameConstraints.

That sounds like a sensible way to do it, if your cert is issued by
(say) VISA
then they'll put the VISA logo in the issuer's other-name.  I used an
other-
name for the MPEG-of-cat cert I created a few years back and both
MSIE/Windows
and Netscape accepted it (meaning they didn't reject the cert or crash)
so it
looks like a fairly clean way to do it.

Peter.

content-class: urn:content-classes:message
Subject: RE: specific policies used in conjunction with anyPolicy
Date: Thu, 22 Mar 2001 11:58:59 -0800
From: "Trevor Freeman" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, <[email-masked]>

Dave,
You have made a big leap here which I had not interpreted from the text.
This revolved around who is driving the inputs into the path validation
process. I can conceive instances where an application would want to
pass in a-d. I do not think for one moment that an application would
care about the rest, nor should they. This stuff is already way to
complex, and interdependencies like this are a nightmare. We are on an
uphill battle to get applications to use PK wisely in the first place
because they think it is hard. Now you are asserting that we need to
make PK administrators knowledgeable about what applications they are
supporting and expect that they are intimacy aware of all their needs.
That is not doing to happen. We need clean simple rules if this is to be
successful. So lets start be saying if you assert the all polices OID in
a CA certificate, it is an operational simplification, and the
administrator does not need to add any more.

Trevor

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2001 12:32 PM
To: [email-masked]
Subject: Re: specific policies used in conjunction with anyPolicy

Yes, you may assert both anyPolicy and specific certificate policies in
the same certificate. This may not be specifically stated, but path
processing algorithm (section 6.1.3) does take this possibility into
account.

The reason that this is allowed is exactly the one you stated.
Originally there was a rule that if anyPolicy were included in the
certificatePolicies extension, then no other policy could be included.
This rule was removed when the inhibitAnyPolicy extension was developed.
In the case you mention, the "strict" applications would set
initial-any-policy-inhibit in order to ensure that the path would only
be considered valid under policies that had been explicitly listed in
each certificate. The more liberal applications would not set
initial-any-policy-inhibit and would then (possibly) consider the path
to be valid under more policies.

At 01:11 PM 3/21/01 -0600, Carlin Covey wrote:
>The certificate policies extension allows a sequence of policy OIDs.
>One such policy OID is anyPolicy.  I assume that it is permissible in a
>CA cert to include specific policy OIDs in addition to the anyPolicy
OID.
>The reason I would want to do this is to support applications that
insist
>on finding a specific policy OID, and also support more liberal
applications
>that will tolerate the anyPolicy OID.
>
>draft-ietf-pkix-new-part1-05 does not appear to prohibit using specific
>policy OIDs and the anyPolicy OID in the same CA cert.  Is this true?

From: [email-masked]
To: Michael Zolotarev <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>, Stephen Kent <[email-masked]>, Michael Zolotarev <[email-masked]>, [email-masked]
Subject: RE: Logotypes in certificates
Date: Thu, 22 Mar 2001 19:48:03 +0000

As I have said a number of times already, there is no use
between machines for the Logo as part of the cert. 

This is purely for human's that might want to look at a
redition of the cert in a paper-like framework, which BTW
is essentially a per-use type of decision and not ANYTHIG
having to do with the negotiability or negotiations
process of the cert itself.

As Mssr. Kemp has pointed out as well, let the
application, if it needs to, deal with displaying a Logo
as part of its opeations.

If this presists as a topic of conversation then I would
suggest that a formal specification for the "CertViewer"
is needed as part of this same scheme so that the Logo's
will render and look the same everywhere otherwise the
logo and its intended use is pointless and the fact that
it is "potentially different" on a number of platforms
will lesson the value and increase the potential
confusion factor for the use of these additions.

--
Regards,
Todd
> Now I'm really confused.
> 
> The whole problem is, as Stephen has neatly put it, that "the whole purpose
> of including a displayable logo is precisely an attempt by a CA to gain the
> trust of users".
> 
> A CA requires to gain trust of a user if it is not still trusted
> (obviously). Which is the case when a path construction 
> (not validation!) ended up at some self-signed CA which is not among the
> user's trusted roots set. This is the only case I can think of when a
> decision is to be made by the user, i.e. whether to trust that CA or not. 
> 
> I cannot think of any other situation when a CA would require to "gain the
> trust of users".
> 
> If so, then the scope of analysis of logotype's impact is limited to path
> construction, not to path validation. Because, again, validation begins when
> the trust is already defined, and it is to late for the user to intervene. 
> 
> Path validation algorithm is 'silent', it does not need to present anything
> to the user. Therefore, presence of a logotype cannot possible affect the
> result of the validation, as the user is not asked about anything, or
> presented anything, at that stage.
> 
> Consiquently, I'm failing to understand how path validation parameters and
> constrains can be affected by the logotypes.
> 
> I guess there may be something fundamental I'm missing...
> 
> Regards
> Michael
>  
> 
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Friday, March 23, 2001 4:56 AM
> To: Stephen Kent; Michael Zolotarev
> Cc: [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> Steve,
> 
> There was a suggestion during a dinner yesterday that logotypes actually 
> could be provided as a policy qualifier. That would actually solve your 
> problem since you could directly tie acceptance of logotypes in 
> certificates to a particular policy.
> 
> This enables you to control the path validation problem with the use of 
> policy constraints.
> 
> /Stefan
> 
> 
> At 18:21 2001-03-21 -0500, Stephen Kent wrote:
> >Michael,
> >
> >>Though I don't favor including logotype or reference to a logotype to a
> >>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
> >>realisation was that a logotype is by no means related to the
> establishment
> >>of trust. It is 100% meant for a human eye only, and verification
> algorithm
> >>should simply ignore it, as it ingores any other proprietory extentions.
> If
> >>the verification comes up with an answer 'not validated', and the software
> >>prompts a user saying 'couldn't validate', and the user still makes a
> >>decision to trust the cert, it is an application's problem, which already
> >>exists now, and logotypes add no extra pitch to it.
> >
> >I think the whole purpose of including a displayable logo is precisely an 
> >attempt by a CA to gain the trust of users, so I disagree with your 
> >stating point. The concern I raised is not one that is addressed by your 
> >example, i.e., my example of a "bad outcome" is a cert that carries a logo 
> >which will be recognized by a user and thus will engender the user's 
> >confidence, but it is contained in a cert that, while valid under our path 
> >validation controls, has nothing to do with the entity whose logo appears 
> >in the cert and which is displayed to the user.
> >
> >>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
> >>won't have a logotype in its own cert, and refuse certification of
> >>logotypes.
> >
> >As a CA I can refuse to certify a logo-equipped cert one layer down, but 
> >not farther, unless we adopt a means of representing the logo that is 
> >subject to existing controls. Tom suggested on possible means, if we put 
> >the logo in an altname field and make it a type which can be prohibited 
> >using nameConstraints.
> >
> >Steve
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
> 
> --------------------------------------------------------------------------------
> ---------------------------------
> The information contained in this message is confidential and is intended 
> for the addressee(s) only.  If you have received this message in error or 
> there are any problems please notify the originator immediately.  The 
> unauthorized use, disclosure, copying or alteration of this message is 
> strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
> special, indirect or consequential damages arising from alteration of the 
> contents of this message by a third party or as a result of any virus being 
> passed on.
> 
> In addition, certain Marketing collateral may be added from time to time to 
> promote Baltimore Technologies products, services, Global e-Security or 
> appearance at trade shows and conferences.
>  
> This footnote confirms that this email message has been swept by 
> Baltimore MIMEsweeper for Content Security threats, including
> computer viruses.

From: Michael Zolotarev <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Stephen Kent <[email-masked]>, Michael Zolotarev <[email-masked]>
Cc: [email-masked]
Subject: RE: Logotypes in certificates
Date: Fri, 23 Mar 2001 05:56:12 +1100

Now I'm really confused.

The whole problem is, as Stephen has neatly put it, that "the whole purpose
of including a displayable logo is precisely an attempt by a CA to gain the
trust of users".

A CA requires to gain trust of a user if it is not still trusted
(obviously). Which is the case when a path construction 
(not validation!) ended up at some self-signed CA which is not among the
user's trusted roots set. This is the only case I can think of when a
decision is to be made by the user, i.e. whether to trust that CA or not. 

I cannot think of any other situation when a CA would require to "gain the
trust of users".

If so, then the scope of analysis of logotype's impact is limited to path
construction, not to path validation. Because, again, validation begins when
the trust is already defined, and it is to late for the user to intervene. 

Path validation algorithm is 'silent', it does not need to present anything
to the user. Therefore, presence of a logotype cannot possible affect the
result of the validation, as the user is not asked about anything, or
presented anything, at that stage.

Consiquently, I'm failing to understand how path validation parameters and
constrains can be affected by the logotypes.

I guess there may be something fundamental I'm missing...

Regards
Michael

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Friday, March 23, 2001 4:56 AM
To: Stephen Kent; Michael Zolotarev
Cc: [email-masked]
Subject: RE: Logotypes in certificates

Steve,

There was a suggestion during a dinner yesterday that logotypes actually 
could be provided as a policy qualifier. That would actually solve your 
problem since you could directly tie acceptance of logotypes in 
certificates to a particular policy.

This enables you to control the path validation problem with the use of 
policy constraints.

/Stefan

At 18:21 2001-03-21 -0500, Stephen Kent wrote:
>Michael,
>
>>Though I don't favor including logotype or reference to a logotype to a
>>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
>>realisation was that a logotype is by no means related to the
establishment
>>of trust. It is 100% meant for a human eye only, and verification
algorithm
>>should simply ignore it, as it ingores any other proprietory extentions.
If
>>the verification comes up with an answer 'not validated', and the software
>>prompts a user saying 'couldn't validate', and the user still makes a
>>decision to trust the cert, it is an application's problem, which already
>>exists now, and logotypes add no extra pitch to it.
>
>I think the whole purpose of including a displayable logo is precisely an 
>attempt by a CA to gain the trust of users, so I disagree with your 
>stating point. The concern I raised is not one that is addressed by your 
>example, i.e., my example of a "bad outcome" is a cert that carries a logo 
>which will be recognized by a user and thus will engender the user's 
>confidence, but it is contained in a cert that, while valid under our path 
>validation controls, has nothing to do with the entity whose logo appears 
>in the cert and which is displayed to the user.
>
>>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
>>won't have a logotype in its own cert, and refuse certification of
>>logotypes.
>
>As a CA I can refuse to certify a logo-equipped cert one layer down, but 
>not farther, unless we adopt a means of representing the logo that is 
>subject to existing controls. Tom suggested on possible means, if we put 
>the logo in an altname field and make it a type which can be prohibited 
>using nameConstraints.
>
>Steve

This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

Date: Thu, 22 Mar 2001 18:55:37 +0100
To: Stephen Kent <[email-masked]>, Michael Zolotarev <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Logotypes in certificates
Cc: [email-masked]

Steve,

There was a suggestion during a dinner yesterday that logotypes actually 
could be provided as a policy qualifier. That would actually solve your 
problem since you could directly tie acceptance of logotypes in 
certificates to a particular policy.

This enables you to control the path validation problem with the use of 
policy constraints.

/Stefan

At 18:21 2001-03-21 -0500, Stephen Kent wrote:
>Michael,
>
>>Though I don't favor including logotype or reference to a logotype to a
>>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
>>realisation was that a logotype is by no means related to the establishment
>>of trust. It is 100% meant for a human eye only, and verification algorithm
>>should simply ignore it, as it ingores any other proprietory extentions. If
>>the verification comes up with an answer 'not validated', and the software
>>prompts a user saying 'couldn't validate', and the user still makes a
>>decision to trust the cert, it is an application's problem, which already
>>exists now, and logotypes add no extra pitch to it.
>
>I think the whole purpose of including a displayable logo is precisely an 
>attempt by a CA to gain the trust of users, so I disagree with your 
>stating point. The concern I raised is not one that is addressed by your 
>example, i.e., my example of a "bad outcome" is a cert that carries a logo 
>which will be recognized by a user and thus will engender the user's 
>confidence, but it is contained in a cert that, while valid under our path 
>validation controls, has nothing to do with the entity whose logo appears 
>in the cert and which is displayed to the user.
>
>>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
>>won't have a logotype in its own cert, and refuse certification of
>>logotypes.
>
>As a CA I can refuse to certify a logo-equipped cert one layer down, but 
>not farther, unless we adopt a means of representing the logo that is 
>subject to existing controls. Tom suggested on possible means, if we put 
>the logo in an altname field and make it a type which can be prohibited 
>using nameConstraints.
>
>Steve

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>
Subject: Crypto-keys break question
Date: Thu, 22 Mar 2001 16:20:26 +0100

Hi 
Some Internet-banks use key-pad boxes for authentication and signing.

A popular brand uses an 8-digit input string that produces an 8-digit result
and with no timing built-in.  On the manufacturer's site there is not a single word on
crypto-graphic strength which makes me wonder how great this thing really is.

Question: This should be like a 27-bit symmetric key which should be *very* easy to break assuming
that you have a few input and  output values at hand.  Is this a correct assumption?
If so, how many seconds/minutes/hours on a standard-PC?  Any links?

Anders

Sender: [email-masked]
Date: Thu, 22 Mar 2001 09:53:35 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: Logotypes [not] in certificates

> From: Dean Povey <[email-masked]>
>
>    [much snippage]
>
> I can see three options (well actually the fourth one is to say that
> it is up to the CA policy to enforce constraints):
> 
> 1. Using an OtherName in subjectAlt has a certain logic to it. 
> 
> 2. An uglier but perhaps more pragmatic approach is to create a logo
>    attribute and shove it in a DN (preferably in altName) with either 
>    PKCS9String or IA5String type.  
> 
> 3. Possibly the most elegant approach, but one which unfortunately has the
>    most impact on current standards is to fix the general problem of
>    enforcing constraints on user certs.

A fifth option is to regard this as an application concern.  When
you get a card with the VISA logo on it from a bank, you have no
technical assurance that the bank was authorized to display that
logo.

Similarly for a UL tag on an appliance cord, a Truste logo on a web
page, or a combat medal on a uniform.

The CA is involved in certifying the identity of the end entity, but
only the end entity itself is responsible for displaying or not
displaying a particular logotype in its communications with other end
entities.  Most of the postings in favor of logotypes in certificates
have described why branding is important to users, but have failed
to to justify the necessity of a CA's involvement in the branding
process.

Date: Wed, 21 Mar 2001 18:06:45 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: WG Last Call: Algorithms draft

Folks,

This message announces Working Group Last Call for the updates to the PKIX 
Public Key Algorithms draft. The specification is currently available at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-02.txt. The 
chairs plan to request Proposed Standard status for this document, and it 
will advance with the Certs and CRL Profile.

Last Call will remain open through at least April 4, 2001.

Thanks,

Tim Polk

Date: Thu, 22 Mar 2001 07:27:59 -0500
To: Peter Williams <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Roger Younglove <[email-masked]>
Subject: RE: specific policies used in conjunction with anyPolicy
Cc: [email-masked]

It is not the usual free-for-all hopefully. All of my PKI companies are 
registered with IANA and they then keep the specific OIDs assigned to their 
CPs and CPSs in house. Each cert carries the full tree for the CP.
At 02:49 PM 03/21/2001 , Peter Williams wrote:

>Is it the usual free-for-all where noone knows anything and you just choose
>your own OID?
>
>Peter.

--------
TTFN
Roger W. Younglove, CISSP
Distinguished Member of Consulting Staff
Lucent Worldwide Services--Information Security
100 Galleria Officentre, Ste. 220
Southfield, MI 48034-8428
Numeric page: 888.935.6755
E-mail page:
[email-masked]
eFax number: 413.425.5368
www.lucent.com/netcare

Date: Thu, 22 Mar 2001 03:18:06 -0800 (PST)
From: vivek saraf <[email-masked]>
Subject: RE: How to send class info from RA to CA
To: Carlisle Adams <[email-masked]>
Cc: [email-masked], [email-masked]

Hello Carlise,

     Thanks, I got your point, i will use the issuer
key identifier extension in the certTemplate to
identify the CA.

Regards,
Vivek Saraf

--- Carlisle Adams <[email-masked]> wrote:
> Hi Vivek,
> 
> > ----------
> > From: 	vivek saraf[SMTP:[email-masked]]
> > Sent: 	Wednesday, March 21, 2001 5:08 AM
> > To: 	[email-masked]
> > Subject: 	How to send class info from RA to CA
> > 
> > Hello,
> > 
> >    I have a CA running which issues multiple
> classes
> > of certifiactes. Now when RA requests a
> certifiacte
> > for a user, the RA should specify the class for
> which
> > it is requesting, but in the PKI message i don't
> find
> > any field for sending the class information.
> > 
> > I have Free text in the PKI Header, if i use this
> it
> > will not be inter operable.
> > 
> > Can any body help me
>  
> How does the issued certificate indicate what class
> it is?  Is it by some
> extension, or is it by an indicator somehow embedded
> in the name of the
> subject or the issuer?  Whatever mechanism you
> choose to use, all you have
> to do is use the same mechanism in the certTemplate
> in the request message
> from the RA to the CA.  This is why the certTemplate
> exists; it allows the
> requester to specify to the CA exactly the cert
> contents that are important
> to them.
> 
> Carlisle.
> 
> 

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

From: [email-masked]
Reply-To: <[email-masked]>
Sender: "Stefan Heiss" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: AW: Question from a new comer about KeyUsage
Date: Thu, 22 Mar 2001 10:14:14 +0100
Importance: Normal
Disposition-Notification-To: "Stefan Heiss" <[email-masked]>

Hi Prashant,

Neither way, but 03 03 07 00 80 would formaly be correct.
(You have to count bits in the Bitstring from left to right.)

BUT this makes NO sense in this context, as bits 7 and 8
are undefined in the absence of the keyAgreement bit.
(See RFC 2459.)

Regards, Stefan

> -----Ursprüngliche Nachricht-----
> Von: Prashant Kumar [mailto:[email-masked]]
> Gesendet am: Mittwoch, 21. März 2001 18:55
> An: 'Stefan.Heiss'
> Betreff: RE: Question from a new comer about KeyUsage
>
> Stefan,
>
> Thanks a lot for your help. How will I encode
> bit 8(ie, the 9th bit) in keyusage using BER.
> Will it be.
>
> 03 03 00 00 01 or 03 03 0E 80 00.
>
> Thank you again.
>
> Regards,
> Prashant.
>
> From: Stefan Heiss [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 12:29 PM
> To: Kumar, Prashant [CENTR:437:EXCH]
> Subject: AW: Question from a new comer about KeyUsage
>
>
> 05 means: ignore the last 5 bits of following the bitstream.
> A0 is the whole bitstream, i.e. bit 0 and 2 are set.
>
> Regards Stefan
>
>
> Dr. Stefan Heiss
> BROKAT AG | Commerce Systems | Research & Development
> Ringstrasse 33 | D-04430 Dölzig
> Phone: +49 (34205) 61-648 | Fax: -535
> <http://www.brokat.com/>
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Prashant Kumar [mailto:[email-masked]]
> > Gesendet am: Mittwoch, 21. März 2001 17:26
> > An: [email-masked]
> > Betreff: Question from a new comer about KeyUsage
> >
> > In one of the Microsoft Certificate the Key usage bits are
> > set as 0x05 A0(0000 0101 1010 0000). If we open the
> > certificate using MS it claims that
> >
> > 1. Digital Signature, Key Encipherment[A0] bits are set.
> >
> > However if you go according to the RFC 2459 it actually has
> > Digital Signature, nonRepudiation, and dataEncipherment set
> > ....(Bits 0, 1 and 3) bit 8 is the right most bit...
> >
> > KeyUsage ::= BIT STRING {
> > digitalSignature (0),
> > nonRepudiation (1),
> > keyEncipherment (2),
> > dataEncipherment (3),
> > keyAgreement (4),
> > keyCertSign (5),
> > cRLSign (6),
> > encipherOnly (7),
> > decipherOnly (8) }
> >
> > Any Comments ?
> >
> > Regards,
> > Prashant.
> >
> >
>
>
>

From: "Prashant Dambe" <[email-masked]>
To: <[email-masked]>
Subject: Query about Time-to-check-back in TCP based Time-stamping
Date: Thu, 22 Mar 2001 10:17:32 +0530

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C0B2B9.4E6FFD70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Draft for Time-stamp says
TCP-based protocol is to be used for transport of TSA messages.
This protocol is suitable for cases where an=20
entity initiates a transaction and can poll to pick up the results.
The "time-to-check-back" parameter is an unsigned 32-bit integer,=20
defined to be the number of seconds that have elapsed since midnight,=20
January 1, 1970, coordinated universal time.
It provides an estimate of the time that the end entity should send=20
its next pollReq.

It means local clock has to synchronized with TS-Server clock to use
properly the time-to-check-back field.

------=_NextPart_000_001B_01C0B2B9.4E6FFD70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Draft for Time-stamp says<BR>TCP-based =
protocol is=20
to be used for transport of TSA messages.<BR>This protocol is suitable =
for cases=20
where an <BR>entity initiates a transaction and can poll to pick up the=20
results.<BR>The "time-to-check-back" parameter is an unsigned 32-bit =
integer,=20
<BR>defined to be the number of seconds that have elapsed since =
midnight,=20
<BR>January 1, 1970, coordinated universal time.<BR>It provides an =
estimate of=20
the time that the end entity should send <BR>its next =
pollReq.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR>It means local clock has to =
synchronized with=20
TS-Server clock to use<BR>properly the time-to-check-back =
field.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_001B_01C0B2B9.4E6FFD70--

To: Stephen Kent <[email-masked]>
cc: "Tom Gindin" <[email-masked]>, [email-masked]
Subject: Re: Logotypes in certificates 
Date: Thu, 22 Mar 2001 14:38:55 +1000
From: Dean Povey <[email-masked]>

While I tend to dislike things like name constraints or actually any top
down asserted constraints (they are things that can be easily controlled by
external policy controls and they make automated path building a right pain
in the butt), I can understand Stephen's concerns, and we need to come up
with a sensible approach to this.

As far as I can see there is no other sensible way to constrain logos other
than to specificaly disallow them in some future certificate(s) in the path
chain.  Everything else will have to rely on sufficient due-dilligence of
the CA to verify they are correct.  Let's face it they don't do this
already for the things they are supposed to do we are stuffed, regardless
of how many constraints a higher level CA imposes.

The path validation algorithm is complex as it is, so I would favour an 
approach that had as little effect on it as possible.  I also think that 
by and large these type of constraints don't get used very often, so I 
think we also need to consider making the most common case usage the 
easiest.

I can see three options (well actually the fourth one is to say that
it is up to the CA policy to enforce constraints):

1. Using an OtherName in subjectAlt has a certain logic to it.  I had also 
   envisioned subject only logos but there is nothing to stop issuer's 
   putting theirs in as well.  The constraints problem would logically be 
   punted to the NameConstraints extension.  

   Unfortunately X.509/RFC2459/Son-of-RFC2459 doesn't describe any
   semantics for name constraints with OtherName so vendors will have to
   fix their path validation anyway.  They may also have to fix their 
   implementations to handle the new OID -> type mapping.

2. An uglier but perhaps more pragmatic approach is to create a logo
   attribute and shove it in a DN (preferably in altName) with either 
   PKCS9String or IA5String type.  

   Unfortunately, unless I have misunderstood the way name constraints
   works for DNs the only way that I can that a CA could stop a 
   subordinate CA from issuing certificates with a logo is to require
   that CA to include a logo attribute with a known NULL value, as I can't
   think of another way of excluding a given attribute from the DN 
   namespace.

   This would probably work without changing any/much existing code. 
   However given this working groups general aversion to putting stuff in
   the DN, I can't see this being very popular.

3. Possibly the most elegant approach, but one which unfortunately has the
   most impact on current standards is to fix the general problem of
   enforcing constraints on user certs.  While logo type has been singled out,
   the scenario Stephen describes applies to any extension 
   outside a small subset which the path validation explicitly handles.

   Fixing this is relatively easy.  We define can define an 
   ExtensionsConstraints extension which looks something like:
   
   extensionsConstraints EXTENSION ::= {
        SYNTAX          ExtensionConstraintSyntax
        IDENTIFIED BY   id-ce-extensionConstraint }

   ExtensionsConstraintsSyntax ::= SEQUENCE {
     permittedExtensions     SEQUENCE OF ExtensionConstraint (1..MAX) OPTIONAL,
     excludedExtensions  [0] SEQUENCE OF ExtensionConstraint (1..MAX) OPTIONAL,
     requiredExtensions  [1] SEQUENCE OF ExtensionConstraint (1..MAX) OPTIONAL
   }
     
   ExtensionConstraint ::= SEQUENCE {
     constrainedExtensions SEQUENCE OF OBJECT IDENTIFIER (1..MAX),
     skipCerts             SkipCerts
   }

   permittedExtensions lists those extensions which are explicitly allowed
   to appear after some later point in the certificate path.

   excludedExtensions lists those extensions which explicitly disallowed
   to appear after some later point in the certificate path.

   requiredExtensions lists those extensions which MUST appear at some 
   later point in the certificate path.

   Each of these lists contains one more ExtensionConstraint which lists 
   the OIDs for which the constraint applies and the number of Certificates
   to skip before applying the constraint (ala PolicyConstraints).
   
   We then define the logo indicator as a simple extension as indicated
   earlier and then the CA is free to exclude it (or any other extension
   they don't trust a subordinate CA with).

   If you wanted to go further you could deprecate PolicyConstraints as 
   this new extension fully supports it.

   I like this approach best as it is simple, general and fixes this 
   problem for most simple cases.  It also allows some more explicit 
   expression of policy in the Certificate in a machine interpretable way.
   The big downside of course is that this means creating a path validation
   process incompatible with X.509 and changing a bunch of implementations
   which is never fun.

Anyway just tossing ideas around.

Cheers.
-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

content-class: urn:content-classes:message
Subject: RE: Logotypes in certificates
Date: Wed, 21 Mar 2001 18:53:59 -0800
From: "David Cross" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>

Steve:

-->No, the argument is not the same.  We have the nameConstraints 
extension as a technical means of preventing a CA and subordinate CAs 
from issuing certs with names outside of a well defined range. We do 
not have a means to enforce similar controls re logos. That's the 
whole point of my concern.

I agree this is a valid concern and should be addressed before moving
forward.
 
David B. Cross

Date: Thu, 22 Mar 2001 01:31:37 +0100
From: Hans Schupp <[email-masked]>
Organization: SECUDE GmbH
To: [email-masked]
Cc: [email-masked]
Subject: Re: Question from a new comer about KeyUsage

This is a cryptographically signed message in MIME format.

--------------msD1F5F76654892AC11FCD042A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Prashant Kumar wrote:

> In one of the Microsoft Certificate the Key usage bits are
> set as 0x05 A0(0000 0101 1010 0000). If we open the
> certificate using MS it claims that
> 
> 1. Digital Signature, Key Encipherment[A0] bits are set.
> 
> However if you go according to the RFC 2459 it actually has
> Digital Signature, nonRepudiation, and dataEncipherment set
> ....(Bits 0, 1 and 3) bit 8 is the right most bit...

You left out the fact, that KeyUsage is encoded as a BIT STRING, which
has a special meaning for the first byte. The 0x05 only says: the 5 last
bits of the following byte are unused, i.e. from the byte 10100000 only
the part 101xxxxx is meaningful.
Take this and you get exactly the bits "digitalSignature" and
"keyEncipherment". MS is not always wrong ;-)

regards, Hans
--
Hans Schupp, SECUDE GmbH, +49-6151-82897-0
_________________________________________________
CeBIT Hannover 22.-28.03.2001, hall 2 / booth B18
--------------msD1F5F76654892AC11FCD042A
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

--------------msD1F5F76654892AC11FCD042A--

Date: Wed, 21 Mar 2001 18:21:53 -0500
To: Michael Zolotarev <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Logotypes in certificates
Cc: [email-masked]

Michael,

>Though I don't favor including logotype or reference to a logotype to a
>cert, considering it as a pure marketing trick (sorry, Stefan :), but my
>realisation was that a logotype is by no means related to the establishment
>of trust. It is 100% meant for a human eye only, and verification algorithm
>should simply ignore it, as it ingores any other proprietory extentions. If
>the verification comes up with an answer 'not validated', and the software
>prompts a user saying 'couldn't validate', and the user still makes a
>decision to trust the cert, it is an application's problem, which already
>exists now, and logotypes add no extra pitch to it.

I think the whole purpose of including a displayable logo is 
precisely an attempt by a CA to gain the trust of users, so I 
disagree with your stating point. The concern I raised is not one 
that is addressed by your example, i.e., my example of a "bad 
outcome" is a cert that carries a logo which will be recognized by a 
user and thus will engender the user's confidence, but it is 
contained in a cert that, while valid under our path validation 
controls, has nothing to do with the entity whose logo appears in the 
cert and which is displayed to the user.

>As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
>won't have a logotype in its own cert, and refuse certification of
>logotypes.

As a CA I can refuse to certify a logo-equipped cert one layer down, 
but not farther, unless we adopt a means of representing the logo 
that is subject to existing controls. Tom suggested on possible 
means, if we put the logo in an altname field and make it a type 
which can be prohibited using nameConstraints.

Steve

Date: Wed, 21 Mar 2001 18:03:54 -0500
To: "Tom Gindin" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Logotypes in certificates
Cc: [email-masked]

Tom,

>      Wouldn't Logotypes most easily be implemented as an OTHER-NAME within
>one of the alternate name fields (probably SubjectAltName)?  If so, how
>would they affect NameConstraints and the like?  IMHO, they would have
>little effect on them since logos are not hierarchical names and thus
>couldn't easily be governed by NameConstraints.
>      Since they are naming (or at least identifying) information about the
>subject or issuer, I don't see why they should be in a different extension.
>IMO, the standard way of displaying these should be to display the logo
>along with the text of the highest-precedence ID for that entity anyway.
>Binding them together in the same extension would encourage that.

I think the answer to your first question is no, but we need to hear 
from Stefan about what he envisioned. I was assuming a new extension. 
If logos were stuffed into an OtherName, the best we could do is to 
prohibit them by ruling out use of that name type in the subject alt 
name field via nameConstraints. Now maybe we're getting some handle 
on control that works with the current path validation algorithm, but 
it's not much.

We need to see a more concrete proposal before we can proceed with a 
reasoned, technical evaluation of the potential for this proposed 
field.

Steve

Date: Wed, 21 Mar 2001 17:59:50 -0500
To: Ambarish Malpani <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Logotypes in certificates
Cc: [email-masked]

Ambarish,

>Steve,
>     This is the same argument as a CA issuing a cert to a
>subordinate, who issues incorrect certificates with it - e.g.
>issues a certificate for the domain www.amazon.com to say BN.
>
>Either a CA controls/audits subordinate CAs, or has enough
>reason to trust them, or the value of that hierarchy is
>pretty useless.
>
>I don't think logos in certificates affect this either way.

No, the argument is not the same.  We have the nameConstraints 
extension as a technical means of preventing a CA and subordinate CAs 
from issuing certs with names outside of a well defined range. We do 
not have a means to enforce similar controls re logos. That's the 
whole point of my concern.

Steve

Date: Wed, 21 Mar 2001 09:44:39 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft meeting minutes, please comment

--============_-1226908307==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

PKIX WG Meeting 3/20-01
Edited by Steve Kent (WG co-chairs)

The PKIX WG met once during the 50th IETF. A total of approximately 
155 individuals participated in the meeting.

Tim quickly reviewed the agenda and document status, noting that 
there are many  I-Ds in progress. (see slides)

Two new RFCs:
	RFC 3029	Data Validation and Certification Server (Experimental)
	RFC 3039	Qualified Certificates (Proposed Standard)

In the IESG Review Process:
	Timestamp Protocol
		(missing IANA considerations section)
	Attribute Certificate Profile
		(missing IANA considerations section and another issue)

Soon to be Submitted to IESG:
	PKIX Roadmap (Informational)
	Permanent Identifier (Experimental?)
	Repository Locator Service (Experimental)

In WG Last Call:
	Son-of-RFC 2459
	Public Algorithms and Identifiers
	CRMF & CMP
CMP/CRMF Interoperability results?

Close to WG last call:
	OCSPv1 bis

Evolving Specifications
	Technical NR (being revised)
	OCSPv2
	Additional LDAP Schema
	Attribute Certificate Acquisition Protocol
	CP/CPS Framework
	DPD/DPV requirements

New Work
	Impersonation Certificates
	Group Name

Status of RFC 2459bis- Russ Housley (RSA Labs)
	Fixed path length computation. Fix "who can issue CRLs" 
problem by allowing a CA certificate to contain EITHER the 
KeyCertSign OR cRLSign bits. Thus only CAs (syntactically speaking) 
issue CRLs, bit it allows creation of an entity that is marked as a 
CA, but which is restricted to signing CRLs. (slides)

OCSPv1 - Ambarish Malpani (ValiCert)
	Moving OCSPv1 to Draft Standard. Interoperability efforts 
going well, including PKI Forum work. Also some minor clarifications 
of the text. Make RSA mandatory, drop required support for DSA. 
(slides)

CMC - Jim Schaad (???)
	Updating document, symmetric key distribution ambiguity, 
minor editorial corrections. Hope to complete updates and get 
interoperability test data for progression to Draft in about 6 
months. (no slides)

Impersonation Certificates - Stephen Tuecke (Argonne Labs)
	Renamed proxy certificates. Motivation is single signon 
delegation support. Intent is to bind a new key pair to a subject alt 
name and to an extension that labels this as a proxy certificate. 
However, there are conflicts between this proposal and the existing 
and revised profile (and X.509). Specifically, the EE is acting like 
a CA, syntactically, but the EE certificate does not have the 
basicConstraints flag set to mark it as a CA. Thus the path 
validation algorithm would reject these proxy certificates. (slides)

DPD/DPV Requirements - Steve Kent (BBN)
	Presentation described revised proposals for DPD and DPV 
requests and responses, using ASN.1 strawmen examples. Ended with a 
plan for progress on the topic, resulting in selection of a protocol 
before the next IETF meeting in August.  Steve Farrell expressed 
concern that the DPD request is too complex, contains unnecessary 
controls, based on a model that does not require returned paths to be 
ones that will necessarily be able to be validated by the client. 
(slides)

OCSPv2 - Michael Myers (VeriSign)
	Expansion of OCSPv1 to create a candidate protocol for the 
DPD & DPV functions. Includes a facility to support nonce relay, by 
concatenating new nonces with old ones. Emphasis on reuse of OCSPv1 
structures wherever possible, e.g., with regard to status responses. 
There are fewer controls on path construction for DPD vs. DPD, based 
on assumptions about relative capability of clients and on perception 
of likely complexity of certificate graphs. (slides)

DPD/DPV - Denis Pinkas (Bull)
	For DPV, major focus is valid/invalid response, plus optional 
proof returned when needed, e.g., for NR. Can have a small response 
with Y/N response and hash as a link to the supporting info. Suggests 
just a single path and revocation status data should be returned. For 
DPD need a path returned always, unlike DPV. Suggests partial 
revocation status data might be returned, if complete data not 
available. (Both DPD + DPV specify the target by either supplying a 
certificate or an Issuer name and serial number.) Suggestion that CA 
and EE certificates may not want the same revocation status data, but 
Mike Myers disagrees with this distinction. Proposal for partial 
responses, e.g., incomplete paths. Argument against DPV support for a 
posteriori validation when the time frame is outside of the 
certificate validity period. Finally, argues for stateless servers, 
i.e., no retry facility in DPD. (slides)

SCVP - Ambarish Malpani (ValiCert)
	Removed XML syntax, and will use CMS as secure enveloping 
mechanism. (one slide)

Group Name - Mike St. Johns (??)
	Motivation is to support a commonly employed OS naming 
convention in EE certificates, instead of having to map from a DN. 
Possible uses in attribute certificates too. Currently proposed as an 
OtherName but open to suggestions for encoding. (slides)

Policy Requirements for TSAs - Denis Pinkas (Bull)
	This is a new ETSI work item. Will complement existing ETSI 
standards on electronic signature formats, qualified certificates, 
and a document addressing policy for CAs issuing qualified 
certificates. TSA policy will be based on RFC 2527 and ETSI 456. 
Welcome participation and inputs from PKIX and SMIME WG members. 
(slides)

--============_-1226908307==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>draft meeting minutes, please
comment</title></head><body>
<div><font size="+1" color="#000000">PKIX WG Meeting 3/20-01<br>
Edited by Steve Kent (WG co-chairs)<br>
<br>
The PKIX WG met once during the 50th IETF. A total of approximately
155 individuals participated in the meeting.<br>
<br>
<br>
Tim quickly reviewed the agenda and document status, noting that there
are many&nbsp; I-Ds in progress. (see slides)<br>
<br>
Two new RFCs:<br>
<x-tab>&nbsp; </x-tab>RFC
3029<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Data
Validation and Certification Server (Experimental)<br>
<x-tab> </x-tab>RFC 3039<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>Qualified Certificates (Proposed Standard)<br>
<br>
In the IESG Review Process:<br>
<x-tab>&nbsp;&nbsp; </x-tab>Timestamp Protocol<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>(missing IANA considerations section)<br>
<x-tab>&nbsp;&nbsp; </x-tab>Attribute Certificate Profile<br>
<x-tab>&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>(missing IANA considerations section and another issue)<br>
<br>
Soon to be Submitted to IESG:<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>PKIX Roadmap (Informational)<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>Permanent Identifier
(Experimental?)<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>Repository Locator Service
(Experimental)<br>
<br>
In WG Last Call:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Son-of-RFC
2459<br>
<x-tab> </x-tab>Public Algorithms and Identifiers<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>CRMF &amp; CMP<br>
CMP/CRMF Interoperability results?<br>
<br>
Close to WG last call:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>OCSPv1 bis<br>
<br>
Evolving Specifications<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Technical NR
(being revised)<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>OCSPv2<br>
<x-tab>&nbsp; </x-tab>Additional LDAP Schema<br>
<x-tab>&nbsp; </x-tab>Attribute Certificate Acquisition Protocol<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>CP/CPS Framework<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>DPD/DPV
requirements<br>
<br>
New Work<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>Impersonation Certificates<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Group Name<br>
<br>
Status of RFC 2459bis- Russ Housley (RSA Labs)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Fixed path
length computation. Fix "who can issue CRLs" problem by allowing a
CA certificate to contain EITHER the KeyCertSign OR cRLSign bits. Thus
only CAs (syntactically speaking) issue CRLs, bit it allows creation
of an entity that is marked as a CA, but which is restricted to
signing CRLs. (slides)<br>
<br>
OCSPv1 - Ambarish Malpani (ValiCert)<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>Moving OCSPv1 to Draft Standard.
Interoperability efforts going well, including PKI Forum work. Also
some minor clarifications of the text. Make RSA mandatory, drop
required support for DSA. (slides)<br>
<br>
CMC - Jim Schaad (???)<br>
<x-tab>&nbsp;&nbsp; </x-tab>Updating document, symmetric key
distribution ambiguity, minor editorial corrections. Hope to complete
updates and get interoperability test data for progression to Draft in
about 6 months. (no slides)<br>
<br>
Impersonation Certificates - Stephen Tuecke (Argonne Labs)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Renamed proxy certificates.
Motivation is single signon delegation support. Intent is to bind a
new key pair to a subject alt name and to an extension that labels
this as a proxy certificate. However, there are conflicts between this
proposal and the existing and revised profile (and X.509).
Specifically, the EE is acting like a CA, syntactically, but the EE
certificate does not have the basicConstraints flag set to mark it as
a CA. Thus the path validation algorithm would reject these proxy
certificates. (slides)<br>
<br>
DPD/DPV Requirements - Steve Kent (BBN)<br>
<x-tab>&nbsp; </x-tab>Presentation described revised proposals for DPD
and DPV requests and responses, using ASN.1 strawmen examples. Ended
with a plan for progress on the topic, resulting in selection of a
protocol before the next IETF meeting in August.&nbsp; Steve Farrell
expressed concern that the DPD request is too complex, contains
unnecessary controls, based on a model that does not require returned
paths to be ones that will necessarily be able to be validated by the
client. (slides)<br>
<br>
OCSPv2 - Michael Myers (VeriSign)<br>
<x-tab>&nbsp; </x-tab>Expansion of OCSPv1 to create a candidate
protocol for the DPD &amp; DPV functions. Includes a facility to
support nonce relay, by concatenating new nonces with old ones.
Emphasis on reuse of OCSPv1 structures wherever possible, e.g., with
regard to status responses. There are fewer controls on path
construction for DPD vs. DPD, based on assumptions about relative
capability of clients and on perception of likely complexity of
certificate graphs. (slides)<br>
<br>
DPD/DPV - Denis Pinkas (Bull)<br>
<x-tab>&nbsp;&nbsp;&nbsp; </x-tab>For DPV, major focus is
valid/invalid response, plus optional proof returned when needed,
e.g., for NR. Can have a small response with Y/N response and hash as
a link to the supporting info. Suggests just a single path and
revocation status data should be returned. For DPD need a path
returned always, unlike DPV. Suggests partial revocation status data
might be returned, if complete data not available. (Both DPD + DPV
specify the target by either supplying a certificate or an Issuer name
and serial number.) Suggestion that CA and EE certificates may not
want the same revocation status data, but Mike Myers disagrees with
this distinction. Proposal for partial responses, e.g., incomplete
paths. Argument against DPV support for a posteriori validation when
the time frame is outside of the certificate validity period. Finally,
argues for stateless servers, i.e., no retry facility in DPD.
(slides)</font></div>
<div><font size="+1" color="#000000"><br>
SCVP - Ambarish Malpani (ValiCert)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Removed XML syntax, and
will use CMS as secure enveloping mechanism. (one slide)<br>
<br>
Group Name - Mike St. Johns (??)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>Motivation
is to support a commonly employed OS naming convention in EE
certificates, instead of having to map from a DN. Possible uses in
attribute certificates too. Currently proposed as an OtherName but
open to suggestions for encoding. (slides)<br>
<br>
Policy Requirements for TSAs - Denis Pinkas (Bull)<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </x-tab>This is a new ETSI work
item. Will complement existing ETSI standards on electronic signature
formats, qualified certificates, and a document addressing policy for
CAs issuing qualified certificates. TSA policy will be based on RFC
2527 and ETSI 456.&nbsp; Welcome participation and inputs from PKIX
and SMIME WG members. (slides)</font><br>
<font size="+1" color="#000000"></font></div>
</body>
</html>
--============_-1226908307==_ma============--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: specific policies used in conjunction with anyPolicy
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 22 Mar 2001 09:55:42 (NZST)

"Carlin Covey" <[email-masked]> writes:

>Peter and Peter,
>
>Are you distinct?  I'm a bit fuzzy myself.  ;>)

We're both the same person.

Now that that's been cleared up, I'd like to correct a few statements I made in
the PKI book I co-authored a few years back...

Peter :-).

From: Hal Lockhart <[email-masked]>
To: "'Carlin Covey'" <[email-masked]>, Michael Sierchio <[email-masked]>, Peter Williams <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: specific policies used in conjunction with anyPolicy
Date: Wed, 21 Mar 2001 16:31:42 -0500

Maybe you should issue them OIDs.

> Sent: Wednesday, March 21, 2001 4:29 PM
> To: Michael Sierchio; Peter Williams
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: specific policies used in conjunction with anyPolicy
> 
> 
> Peter and Peter,
> 
> Are you distinct?  I'm a bit fuzzy myself.  ;>)
> 
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Michael Sierchio
> Sent: Wednesday, March 21, 2001 2:26 PM
> To: Peter Williams
> Cc: [email-masked]'; [email-masked]; 
> [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: specific policies used in conjunction with anyPolicy
> 
> 
> Peter Williams wrote:
> >
> > Is it the usual free-for-all where noone knows anything and you just
> choose
> > your own OID?
> 
> Are Peter Williams and Peter Gutmann distinct persons?
> 

From: "Carlin Covey" <[email-masked]>
To: "Michael Sierchio" <[email-masked]>, "Peter Williams" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: specific policies used in conjunction with anyPolicy
Date: Wed, 21 Mar 2001 15:29:22 -0600
Importance: Normal

Peter and Peter,

Are you distinct?  I'm a bit fuzzy myself.  ;>)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Michael Sierchio
Sent: Wednesday, March 21, 2001 2:26 PM
To: Peter Williams
Cc: [email-masked]'; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: specific policies used in conjunction with anyPolicy

Peter Williams wrote:
>
> Is it the usual free-for-all where noone knows anything and you just
choose
> your own OID?

Are Peter Williams and Peter Gutmann distinct persons?

Date: Wed, 21 Mar 2001 15:32:05 -0500
To: [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: Re: specific policies used in conjunction with anyPolicy

Yes, you may assert both anyPolicy and specific certificate policies in the same certificate. This may not be specifically stated, but path processing algorithm (section 6.1.3) does take this possibility into account.

The reason that this is allowed is exactly the one you stated. Originally there was a rule that if anyPolicy were included in the certificatePolicies extension, then no other policy could be included. This rule was removed when the inhibitAnyPolicy extension was developed. In the case you mention, the "strict" applications would set initial-any-policy-inhibit in order to ensure that the path would only be considered valid under policies that had been explicitly listed in each certificate. The more liberal applications would not set initial-any-policy-inhibit and would then (possibly) consider the path to be valid under more policies.

At 01:11 PM 3/21/01 -0600, Carlin Covey wrote:
>The certificate policies extension allows a sequence of policy OIDs.
>One such policy OID is anyPolicy.  I assume that it is permissible in a
>CA cert to include specific policy OIDs in addition to the anyPolicy OID.
>The reason I would want to do this is to support applications that insist
>on finding a specific policy OID, and also support more liberal applications
>that will tolerate the anyPolicy OID.
>
>draft-ietf-pkix-new-part1-05 does not appear to prohibit using specific
>policy OIDs and the anyPolicy OID in the same CA cert.  Is this true?

Sender: [email-masked]
Date: Wed, 21 Mar 2001 12:26:02 -0800
From: Michael Sierchio <[email-masked]>
To: Peter Williams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: specific policies used in conjunction with anyPolicy

Peter Williams wrote:
> 
> Is it the usual free-for-all where noone knows anything and you just choose
> your own OID?

Are Peter Williams and Peter Gutmann distinct persons?

Content-return: allowed
Date: Wed, 21 Mar 2001 11:49:13 -0800
From: Peter Williams <[email-masked]>
Subject: RE: specific policies used in conjunction with anyPolicy
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Cc: [email-masked]

Is it the usual free-for-all where noone knows anything and you just choose
your own OID?

Peter.

From: Hal Lockhart <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Logotypes in certificates
Date: Wed, 21 Mar 2001 14:26:47 -0500

I'm confused. I thought the proposal was to allow a logotype that
corresponds to the Subject not the Issuer.

Hal

> Sent: Thursday, March 22, 2001 12:56 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> "Tom Gindin" <[email-masked]> writes:
> 
> >Wouldn't Logotypes most easily be implemented as an 
> OTHER-NAME within one of
> >the alternate name fields (probably SubjectAltName)?  If so, 
> how would they
> >affect NameConstraints and the like?  IMHO, they would have 
> little effect on
> >them since logos are not hierarchical names and thus 
> couldn't easily be
> >governed by NameConstraints.
> 
> That sounds like a sensible way to do it, if your cert is 
> issued by (say) VISA
> then they'll put the VISA logo in the issuer's other-name.  I 
> used an other-
> name for the MPEG-of-cat cert I created a few years back and 
> both MSIE/Windows
> and Netscape accepted it (meaning they didn't reject the cert 
> or crash) so it
> looks like a fairly clean way to do it.
> 
> Peter.
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re:  specific policies used in conjunction with anyPolicy
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 22 Mar 2001 07:25:30 (NZST)

"Carlin Covey" <[email-masked]> writes:

>The certificate policies extension allows a sequence of policy OIDs. One such
>policy OID is anyPolicy.  I assume that it is permissible in a CA cert to
>include specific policy OIDs in addition to the anyPolicy OID. The reason I
>would want to do this is to support applications that insist on finding a
>specific policy OID, and also support more liberal applications that will
>tolerate the anyPolicy OID.

Speaking of policy OIDs, is there any centralised registry which tracks these
anywhere (apart from picking over the standard OID scrap-heap in Norway)?  I'd
like this information for two reasons, firstly so I can add some of the
policies to the dumpasn1 config database, and secondly because there doesn't
seem to be any organised way to notify anyone of policies or OIDs.  Is it the
usual free-for-all where noone knows anything and you just choose your own OID?

Peter.

From: "Carlin Covey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: specific policies used in conjunction with anyPolicy
Date: Wed, 21 Mar 2001 13:11:10 -0600
Importance: Normal

Russ or Tim (or anyone else with an opinion),

The certificate policies extension allows a sequence of policy OIDs.
One such policy OID is anyPolicy.  I assume that it is permissible in a
CA cert to include specific policy OIDs in addition to the anyPolicy OID.
The reason I would want to do this is to support applications that insist
on finding a specific policy OID, and also support more liberal applications
that will tolerate the anyPolicy OID.

draft-ietf-pkix-new-part1-05 does not appear to prohibit using specific
policy OIDs and the anyPolicy OID in the same CA cert.  Is this true?

- Carlin Covey
  Cylink Corporation

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: RE: Logotypes in certificates
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Thu, 22 Mar 2001 05:56:23 (NZST)

"Tom Gindin" <[email-masked]> writes:

>Wouldn't Logotypes most easily be implemented as an OTHER-NAME within one of
>the alternate name fields (probably SubjectAltName)?  If so, how would they
>affect NameConstraints and the like?  IMHO, they would have little effect on
>them since logos are not hierarchical names and thus couldn't easily be
>governed by NameConstraints.

That sounds like a sensible way to do it, if your cert is issued by (say) VISA
then they'll put the VISA logo in the issuer's other-name.  I used an other-
name for the MPEG-of-cat cert I created a few years back and both MSIE/Windows
and Netscape accepted it (meaning they didn't reject the cert or crash) so it
looks like a fairly clean way to do it.

Peter.

Date: Wed, 21 Mar 2001 09:55:48 -0800
From: [email-masked] (Terry Hayes)
To: Ambarish Malpani <[email-masked]>
CC: "'Stephen Kent'" <[email-masked]>, Dean Povey <[email-masked]>, [email-masked]
Subject: Re: Logotypes in certificates

Ambarish,

I think that Steve is after a technical method to restrict the types of 
certificates that a subordinate CA can issue.  You can, as you point 
out, use legal methods and auditing to do this, but in some cases it may 
be better to have a technical solution that makes incorrect certificates 
invalid, or not useful.

Name constraints is one such technical means.  Using it we can restrict 
the names in certificates to a particular DN subset, or to a particular 
DNS domain.  It won't help with the case you give, but it does allow 
delegation of authority to a CA for valicert.com or netscape.com (for 
example!)

One possible technical solution for logtypes is the certificate policies 
extension.  By defining application level processing to require a 
certain certificate policy in the certificate (or one of a set of 
policies), the application can be confident that the trust point (root 
CA) has granted authority to include logotypes in the certificate.  
certificate policies has the correct hierarchical structure and 
processing rules to enforce this.

Terry

Ambarish Malpani wrote:

> Steve,
>     This is the same argument as a CA issuing a cert to a
> subordinate, who issues incorrect certificates with it - e.g.
> issues a certificate for the domain www.amazon.com to say BN.
> 
> Either a CA controls/audits subordinate CAs, or has enough
> reason to trust them, or the value of that hierarchy is
> pretty useless.
> 
> I don't think logos in certificates affect this either way.
> 
> Regards,
> Ambarish
> 
>> From: Stephen Kent [mailto:[email-masked]]
>> Sent: Tuesday, March 20, 2001 8:57 PM
>> To: Dean Povey
>> Cc: [email-masked]
>> Subject: Re: Logotypes in certificates
>> 
>> 
>> Dean and Stefan,
>> 
>> As a security kinda' guy, I always approach this from the "what will 
>> the bad giy do" perspective.  From that perspective, I worry that a 
>> TTP CA will cerfity company X, putting the company X logo in the 
>> cert. Then company X will issue a cert to a subordinate CA, and put 
>> in that cert an inappropriate logo. It is not realistic for an app to 
>> display a chain of logos, and expect a user to pay attention, any 
>> more that if one displayed a chain of DNs.  I still maintain that we 
>> can agree on what would be a reasonable set of circumstances in which 
>> the logo extension would be useful and safe, but I don't see a 
>> technical means of enforcing these circumstances without changes to 
>> the path validation algorithm. I am open to suggestions that provide 
>> the necessary controls and don't have this unfortunate side effect, 
>> but I have yet to see an example of such.
>> 
>> Steve
>> 

From: Michael Zolotarev <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, Dean Povey <[email-masked]>
Cc: [email-masked]
Subject: RE: Logotypes in certificates
Date: Thu, 22 Mar 2001 04:51:46 +1100

Though I don't favor including logotype or reference to a logotype to a
cert, considering it as a pure marketing trick (sorry, Stefan :), but my
realisation was that a logotype is by no means related to the establishment
of trust. It is 100% meant for a human eye only, and verification algorithm
should simply ignore it, as it ingores any other proprietory extentions. If
the verification comes up with an answer 'not validated', and the software
prompts a user saying 'couldn't validate', and the user still makes a
decision to trust the cert, it is an application's problem, which already
exists now, and logotypes add no extra pitch to it.

As an extreme, if a CA considers logotypes to be anyhow harmful, it simply
won't have a logotype in its own cert, and refuse certification of
logotypes.

Michael
-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Thursday, March 22, 2001 4:07 AM
To: 'Stephen Kent'; Dean Povey
Cc: [email-masked]
Subject: RE: Logotypes in certificates

Steve,
    This is the same argument as a CA issuing a cert to a
subordinate, who issues incorrect certificates with it - e.g.
issues a certificate for the domain www.amazon.com to say BN.

Either a CA controls/audits subordinate CAs, or has enough
reason to trust them, or the value of that hierarchy is
pretty useless.

I don't think logos in certificates affect this either way.

Regards,
Ambarish

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 8:57 PM
> To: Dean Povey
> Cc: [email-masked]
> Subject: Re: Logotypes in certificates
> 
> 
> Dean and Stefan,
> 
> As a security kinda' guy, I always approach this from the "what will 
> the bad giy do" perspective.  From that perspective, I worry that a 
> TTP CA will cerfity company X, putting the company X logo in the 
> cert. Then company X will issue a cert to a subordinate CA, and put 
> in that cert an inappropriate logo. It is not realistic for an app to 
> display a chain of logos, and expect a user to pay attention, any 
> more that if one displayed a chain of DNs.  I still maintain that we 
> can agree on what would be a reasonable set of circumstances in which 
> the logo extension would be useful and safe, but I don't see a 
> technical means of enforcing these circumstances without changes to 
> the path validation algorithm. I am open to suggestions that provide 
> the necessary controls and don't have this unfortunate side effect, 
> but I have yet to see an example of such.
> 
> Steve
> 

This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

Importance: Normal
Subject: RE: Logotypes in certificates
To: Ambarish Malpani <[email-masked]>
Cc: "'Stephen Kent'" <[email-masked]>, Dean Povey <[email-masked]>, [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Wed, 21 Mar 2001 12:47:14 -0500

     Wouldn't Logotypes most easily be implemented as an OTHER-NAME within
one of the alternate name fields (probably SubjectAltName)?  If so, how
would they affect NameConstraints and the like?  IMHO, they would have
little effect on them since logos are not hierarchical names and thus
couldn't easily be governed by NameConstraints.
     Since they are naming (or at least identifying) information about the
subject or issuer, I don't see why they should be in a different extension.
IMO, the standard way of displaying these should be to display the logo
along with the text of the highest-precedence ID for that entity anyway.
Binding them together in the same extension would encourage that.

          Tom Gindin

Ambarish Malpani <[email-masked]> on 03/21/2001 12:06:35 PM

To:   "'Stephen Kent'" <[email-masked]>, Dean Povey <[email-masked]>
cc:   [email-masked]
Subject:  RE: Logotypes in certificates

Steve,
    This is the same argument as a CA issuing a cert to a
subordinate, who issues incorrect certificates with it - e.g.
issues a certificate for the domain www.amazon.com to say BN.

Either a CA controls/audits subordinate CAs, or has enough
reason to trust them, or the value of that hierarchy is
pretty useless.

I don't think logos in certificates affect this either way.

Regards,
Ambarish

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 8:57 PM
> To: Dean Povey
> Cc: [email-masked]
> Subject: Re: Logotypes in certificates
>
>
> Dean and Stefan,
>
> As a security kinda' guy, I always approach this from the "what will
> the bad giy do" perspective.  From that perspective, I worry that a
> TTP CA will cerfity company X, putting the company X logo in the
> cert. Then company X will issue a cert to a subordinate CA, and put
> in that cert an inappropriate logo. It is not realistic for an app to
> display a chain of logos, and expect a user to pay attention, any
> more that if one displayed a chain of DNs.  I still maintain that we
> can agree on what would be a reasonable set of circumstances in which
> the logo extension would be useful and safe, but I don't see a
> technical means of enforcing these circumstances without changes to
> the path validation algorithm. I am open to suggestions that provide
> the necessary controls and don't have this unfortunate side effect,
> but I have yet to see an example of such.
>
> Steve
>

Content-return: allowed
Date: Wed, 21 Mar 2001 09:06:35 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Logotypes in certificates
To: "'Stephen Kent'" <[email-masked]>, Dean Povey <[email-masked]>
Cc: [email-masked]

Steve,
    This is the same argument as a CA issuing a cert to a
subordinate, who issues incorrect certificates with it - e.g.
issues a certificate for the domain www.amazon.com to say BN.

Either a CA controls/audits subordinate CAs, or has enough
reason to trust them, or the value of that hierarchy is
pretty useless.

I don't think logos in certificates affect this either way.

Regards,
Ambarish

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 8:57 PM
> To: Dean Povey
> Cc: [email-masked]
> Subject: Re: Logotypes in certificates
> 
> 
> Dean and Stefan,
> 
> As a security kinda' guy, I always approach this from the "what will 
> the bad giy do" perspective.  From that perspective, I worry that a 
> TTP CA will cerfity company X, putting the company X logo in the 
> cert. Then company X will issue a cert to a subordinate CA, and put 
> in that cert an inappropriate logo. It is not realistic for an app to 
> display a chain of logos, and expect a user to pay attention, any 
> more that if one displayed a chain of DNs.  I still maintain that we 
> can agree on what would be a reasonable set of circumstances in which 
> the logo extension would be useful and safe, but I don't see a 
> technical means of enforcing these circumstances without changes to 
> the path validation algorithm. I am open to suggestions that provide 
> the necessary controls and don't have this unfortunate side effect, 
> but I have yet to see an example of such.
> 
> Steve
> 

Date: Wed, 21 Mar 2001 08:45:26 -0800
From: [email-masked] (Terry Hayes)
To: Carlisle Adams <[email-masked]>
CC: "'vivek saraf'" <[email-masked]>, [email-masked]
Subject: Re: How to send class info from RA to CA

--------------050505060604090700090909
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

As Carlisle has indicated, the certificate template field can include 
data that will indicate the "class" of the request.  A prime candidate 
for this purpose is the certificatePolices extension.  The policy (or 
policies) included in this field should be a good indicator of the type 
of certificate desired.

Terry

Carlisle Adams wrote:

> Hi Vivek,
> 
>       ----------
>       From:   vivek saraf[SMTP:[email-masked]]
>       Sent:   Wednesday, March 21, 2001 5:08 AM
>       To:     [email-masked]
>       Subject:        How to send class info from RA to CA
>       
>       Hello,
>       
>          I have a CA running which issues multiple classes
>       of certifiactes. Now when RA requests a certifiacte
>       for a user, the RA should specify the class for which
>       it is requesting, but in the PKI message i don't find
>       any field for sending the class information.
>       
>       I have Free text in the PKI Header, if i use this it
>       will not be inter operable.
>       
>       Can any body help me
>       
>  
> How does the issued certificate indicate what class it is?  Is it by 
> some extension, or is it by an indicator somehow embedded in the name 
> of the subject or the issuer?  Whatever mechanism you choose to use, 
> all you have to do is use the same mechanism in the certTemplate in 
> the request message from the RA to the CA.  This is why the 
> certTemplate exists; it allows the requester to specify to the CA 
> exactly the cert contents that are important to them.
> 
> Carlisle.
> 

--------------050505060604090700090909
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html><head></head><body>As Carlisle has indicated, the certificate template
field can include data that will indicate the "class" of the request.&nbsp; A
prime candidate for this purpose is the certificatePolices extension.&nbsp; The
policy (or policies) included in this field should be a good indicator of
the type of certificate desired.<br>
<br>
Terry<br>
<br>
Carlisle Adams wrote:<br>
<blockquote type="cite" cite="mid:[email-masked]">
  <p><font color="#0000ff" size="2" face="Times New Roman">Hi Vivek,</font></p>
  <ul>
<p><font size="2" face="MS Sans Serif">----------</font><br><b><font size="2" face="MS Sans Serif">From:</font></b> &nbsp; <font size="2" face="MS Sans Serif">vivek saraf[<a class="moz-txt-link-abbreviated" href="mailto:SMTP:[email-masked]">SMTP:[email-masked]</a>]</font><br><b><font size="2" face="MS Sans Serif">Sent:</font></b> &nbsp; <font size="2" face="MS Sans Serif">Wednesday, March 21, 2001 5:08 AM</font><br><b><font size="2" face="MS Sans Serif">To:</font></b> &nbsp;&nbsp;&nbsp; <font size="2" face="MS Sans Serif"><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></font><br><b><font size="2" face="MS Sans Serif">Subject:</font></b> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size="2" face="MS Sans Serif">How to send class info from RA to CA</font></p><p><font size="2" face="Arial">Hello,</font></p><p><font size="2" face="Arial">&nbsp;&nbsp; I have a CA running which issues multiple classes</font><br><font si!
ze="2" face="Arial">of certifiactes. Now when RA requests a certifiacte</font><br><font size="2" face="Arial">for a user, the RA should specify the class for which</font><br><font size="2" face="Arial">it is requesting, but in the PKI message i don't find</font><br><font size="2" face="Arial">any field for sending the class information.</font></p><p><font size="2" face="Arial">I have Free text in the PKI Header, if i use this it</font><br><font size="2" face="Arial">will not be inter operable.</font></p><p><font size="2" face="Arial">Can any body help me</font></p>
  </ul>
  <p><font color="#0000ff" size="2" face="Times New Roman">&nbsp;</font><br><font color="#0000ff" size="2" face="Times New Roman">
How does the issued certificate indicate what class it is?&nbsp; Is it by some
extension, or is it by an indicator somehow embedded in the name of the subject
or the issuer?&nbsp; Whatever mechanism you choose to use, all you have to do
is use the same mechanism in the certTemplate in the request message from
the RA to the CA.&nbsp; This is why the certTemplate exists; it allows the requester
to specify to the CA exactly the cert contents that are important to them.</font></p>
  <p><font color="#0000ff" size="2" face="Times New Roman">Carlisle.</font></p>
  </blockquote>
  <br>
</body></html>
--------------050505060604090700090909--

From: Carlisle Adams <[email-masked]>
To: "'vivek saraf'" <[email-masked]>
Cc: [email-masked]
Subject: RE: How to send class info from RA to CA
Date: Wed, 21 Mar 2001 11:25:14 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B223.82465220
Content-Type: text/plain

Hi Vivek,

> ----------
> From: 	vivek saraf[SMTP:[email-masked]]
> Sent: 	Wednesday, March 21, 2001 5:08 AM
> To: 	[email-masked]
> Subject: 	How to send class info from RA to CA
> 
> Hello,
> 
>    I have a CA running which issues multiple classes
> of certifiactes. Now when RA requests a certifiacte
> for a user, the RA should specify the class for which
> it is requesting, but in the PKI message i don't find
> any field for sending the class information.
> 
> I have Free text in the PKI Header, if i use this it
> will not be inter operable.
> 
> Can any body help me
 
How does the issued certificate indicate what class it is?  Is it by some
extension, or is it by an indicator somehow embedded in the name of the
subject or the issuer?  Whatever mechanism you choose to use, all you have
to do is use the same mechanism in the certTemplate in the request message
from the RA to the CA.  This is why the certTemplate exists; it allows the
requester to specify to the CA exactly the cert contents that are important
to them.

Carlisle.

------_=_NextPart_001_01C0B223.82465220
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: How to send class info from RA to CA</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Vivek,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">vivek =
saraf[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Wednesday, March 21, 2001 5:08 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">How to send class info from RA to CA</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; I have a CA running which =
issues multiple classes</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of certifiactes. Now when RA requests =
a certifiacte</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for a user, the RA should specify the =
class for which</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it is requesting, but in the PKI =
message i don't find</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">any field for sending the class =
information.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have Free text in the PKI Header, if =
i use this it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will not be inter operable.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can any body help me</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">How does =
the issued certificate indicate what class it is?&nbsp; Is it by some =
extension, or is it by an indicator somehow embedded in the name of the =
subject or the issuer?&nbsp; Whatever mechanism you choose to use, all =
you have to do is use the same mechanism in the certTemplate in the =
request message from the RA to the CA.&nbsp; This is why the =
certTemplate exists; it allows the requester to specify to the CA =
exactly the cert contents that are important to them.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B223.82465220--

From: Carlisle Adams <[email-masked]>
To: "'Ari Kermaier'" <[email-masked]>
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-rfc2510bis-03
Date: Wed, 21 Mar 2001 11:18:39 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B222.96F9CF40
Content-Type: text/plain

Hi Ari,

> ----------
> From: 	Ari Kermaier[SMTP:[email-masked]]
> Sent: 	Thursday, March 15, 2001 12:35 AM
> To: 	[email-masked]
> Cc: 	Carlisle Adams
> Subject: 	draft-ietf-pkix-rfc2510bis-03
> 
> Dear All,
> 
> I'm seeking clarification of the challenge-response proof-of-possession 
> protocol in CMP. The POP challenge is defined in section 3.2.8 as follows:
> 
>       Challenge ::= SEQUENCE {
>           owf                 AlgorithmIdentifier  OPTIONAL,
>           -- MUST be present in the first Challenge; MAY be omitted in any
>           -- subsequent Challenge in POPODecKeyChallContent (if omitted,
>           -- then the owf used in the immediately preceding Challenge is
>           -- to be used).
>           witness             OCTET STRING,
>           -- the result of applying the one-way function (owf) to a
>           -- randomly-generated INTEGER, A.  [Note that a different
>           -- INTEGER MUST be used for each Challenge.]
>           challenge           OCTET STRING
>           -- the encryption (under the public key for which the cert.
>           -- request is being made) of Rand, where Rand is specified as
>           --   Rand ::= SEQUENCE {
>           --      int      INTEGER,
>           --       - the randomly-generated INTEGER A (above)
>           --      sender   GeneralName
>           --       - the sender's name (as included in PKIHeader)
>           --   }
>       }
> 
> 1) What is the purpose of including the sender's name in the sequence to
> be 
> encrypted? Does it guard against some sort of attack?
 
The easy answer is that all this structure does is encode the protocol given
on page 404 of "Handbook of Applied Cryptography" and, as we are all well
aware, it is unwise to make arbitrary changes to security protocols --
typically, all parameters present in a secure protocol are there for a
reason and should not be removed.

The "real" answer is that this prevents someone else from stealing the
witness and the challenge and presenting them to the receiver as his own
Challenge.  The witness is there to prove that the sender actually did know
the random number beforehand (in order to preclude chosen text attacks), but
it does not provide this value if it can be stolen and presented
successfully by someone else who doesn't know the number.  Therefore, when
the receiver decrypts "challenge", she hashes "int" and matches it up with
"witness", but she also looks at "sender" to verify that it matches up with
the actual sender of the message.

> 2) Since it is quite possible that the DER encoding of the Rand sequence 
> will have length greater than k-11 octets, where k is the length of the
> RSA 
> public modulus (for the RSA key case), what method should be used for 
> performing this encryption and formatting the contents of the challenge 
> OCTET STRING?
 
I don't think Rand will typically be too long to be used for RSA.  The
random integer itself need not be long (64 bits would be lots; even 32 may
be sufficient for this purpose).  Therefore, using a 1024-bit modulus you
would still have well over 100 octets for the "sender" field.  If, in some
environment, names are so long that they really can't fit (e.g., very long
DNs), then perhaps whatever portion will fit should be used (as long as it
includes at least the common name, of course).

> Any help would be most appreciated.
 
Hope this helps!

Carlisle.

------_=_NextPart_001_01C0B222.96F9CF40
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: draft-ietf-pkix-rfc2510bis-03</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Ari,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Ari =
Kermaier[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Thursday, March 15, 2001 12:35 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">draft-ietf-pkix-rfc2510bis-03</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dear All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'm seeking clarification of the =
challenge-response proof-of-possession </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">protocol in CMP. The POP challenge is =
defined in section 3.2.8 as follows:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Challenge ::=3D SEQUENCE {</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
owf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; AlgorithmIdentifier&nbsp; OPTIONAL,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- MUST be present in the first Challenge; MAY be omitted in any</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- subsequent Challenge in POPODecKeyChallContent (if omitted,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- then the owf used in the immediately preceding Challenge is</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- to be used).</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
witness&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; OCTET STRING,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- the result of applying the one-way function (owf) to a</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- randomly-generated INTEGER, A.&nbsp; [Note that a different</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- INTEGER MUST be used for each Challenge.]</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
challenge&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OCTET STRING</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- the encryption (under the public key for which the cert.</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-- request is being made) of Rand, where Rand is specified as</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp; Rand ::=3D SEQUENCE {</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
INTEGER,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - the randomly-generated INTEGER =
A (above)</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sender&nbsp;&nbsp; GeneralName</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - the sender's name (as included =
in PKIHeader)</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
--&nbsp;&nbsp; }</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
}</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1) What is the purpose of including =
the sender's name in the sequence to be </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">encrypted? Does it guard against some =
sort of attack?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The easy =
answer is that all this structure does is encode the protocol given on =
page 404 of &quot;Handbook of Applied Cryptography&quot; and, as we are =
all well aware, it is unwise to make arbitrary changes to security =
protocols -- typically, all parameters present in a secure protocol are =
there for a reason and should not be removed.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The =
&quot;real&quot; answer is that this prevents someone else from =
stealing the witness and the challenge and presenting them to the =
receiver as his own Challenge.&nbsp; The witness is there to prove that =
the sender actually did know the random number beforehand (in order to =
preclude chosen text attacks), but it does not provide this value if it =
can be stolen and presented successfully by someone else who doesn't =
know the number.&nbsp; Therefore, when the receiver decrypts =
&quot;challenge&quot;, she hashes &quot;int&quot; and matches it up =
with &quot;witness&quot;, but she also looks at &quot;sender&quot; to =
verify that it matches up with the actual sender of the =
message.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">2) Since it is quite possible that the =
DER encoding of the Rand sequence </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will have length greater than k-11 =
octets, where k is the length of the RSA </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">public modulus (for the RSA key =
case), what method should be used for </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">performing this encryption and =
formatting the contents of the challenge </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">OCTET STRING?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I don't =
think Rand will typically be too long to be used for RSA.&nbsp; The =
random integer itself need not be long (64 bits would be lots; even 32 =
may be sufficient for this purpose).&nbsp; Therefore, using a 1024-bit =
modulus you would still have well over 100 octets for the =
&quot;sender&quot; field.&nbsp; If, in some environment, names are so =
long that they really can't fit (e.g., very long DNs), then perhaps =
whatever portion will fit should be used (as long as it includes at =
least the common name, of course).</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Any help would be most =
appreciated.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hope this =
helps!</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B222.96F9CF40--

Reply-To: <[email-masked]>
From: "Prashant Kumar" <[email-masked]>
To: <[email-masked]>
Subject: Question from a new comer about KeyUsage
Date: Wed, 21 Mar 2001 11:26:02 -0500
Importance: Normal

In one of the Microsoft Certificate the Key usage bits are 
set as 0x05 A0(0000 0101 1010 0000). If we open the 
certificate using MS it claims that

1. Digital Signature, Key Encipherment[A0] bits are set.

However if you go according to the RFC 2459 it actually has
Digital Signature, nonRepudiation, and dataEncipherment set
....(Bits 0, 1 and 3) bit 8 is the right most bit... 

KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5), 
cRLSign (6),
encipherOnly (7),
decipherOnly (8) } 

Any Comments ?

Regards,
Prashant.

Date: Wed, 21 Mar 2001 02:08:35 -0800 (PST)
From: vivek saraf <[email-masked]>
Subject: How to send class info from RA to CA
To: [email-masked]

Hello,

   I have a CA running which issues multiple classes
of certifiactes. Now when RA requests a certifiacte
for a user, the RA should specify the class for which
it is requesting, but in the PKI message i don't find
any field for sending the class information.

I have Free text in the PKI Header, if i use this it
will not be inter operable.

Can any body help me

Regards,
Vivek Saraf

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Date: Tue, 20 Mar 2001 23:56:53 -0500
To: Dean Povey <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Logotypes in certificates
Cc: [email-masked]

Dean and Stefan,

As a security kinda' guy, I always approach this from the "what will 
the bad giy do" perspective.  From that perspective, I worry that a 
TTP CA will cerfity company X, putting the company X logo in the 
cert. Then company X will issue a cert to a subordinate CA, and put 
in that cert an inappropriate logo. It is not realistic for an app to 
display a chain of logos, and expect a user to pay attention, any 
more that if one displayed a chain of DNs.  I still maintain that we 
can agree on what would be a reasonable set of circumstances in which 
the logo extension would be useful and safe, but I don't see a 
technical means of enforcing these circumstances without changes to 
the path validation algorithm. I am open to suggestions that provide 
the necessary controls and don't have this unfortunate side effect, 
but I have yet to see an example of such.

Steve

To: Stefan Santesson <[email-masked]>
cc: Stephen Kent <[email-masked]>, Tim Moses <[email-masked]>, [email-masked]
Subject: Re: Logotypes in certificates 
Date: Wed, 21 Mar 2001 14:09:47 +1000
From: Dean Povey <[email-masked]>

>
>I also suppose that the only way a logotype could undermine the naming 
>schema is if logotypes have such significant impact on entity recognition, 
>that users in general would se the logo and not notice that the DN is in 
>conflict with the logotype.
>
>If this is correct then you acknowledge the importance of logotypes as 
>instrument of recognition, which speaks for that we should find a way to 
>handle logotypes in certificates and not the opposite.

Surely it would be the responsibility of the CA to determine the logo -> 
DN mapping.  From a software perspective the path validation algorithm 
should not be affected. The logo is just there to help the user make a 
better decision about whether to trust the certificate.

Cheers.

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

Date: Tue, 20 Mar 2001 23:06:38 +0100
To: Stephen Kent <[email-masked]>, Tim Moses <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Logotypes in certificates
Cc: [email-masked]

Steve,

I think you comment is valid, but I challenge your conclusion that we 
better not use logotypes with certificates.

I think we agree that a logo in a certificate doesn't affect path 
validation processing technically (they are not part of the process), with 
or without name constraints. So when you talk about logotypes undermining 
the name constraints function I suppose you identify the case when:

1) A CA have a DN which doesn't violate name constraints from any cross 
certifying CA
2) This CA use a logotype which in fact does conflict with the same name 
constraints
3) A user looks at the logotype and ignores the DN.

For this to be true, the certificate must contain conflicting information. 
I.e. the certificate must contain a DN and a logotype which doesn't match.

I wander what CA, being certified by a significant trust anchor, that would 
do this and at the same time sign and seal this information fraud with its 
own signature? The CA simply couldn't get away with it!

I also suppose that the only way a logotype could undermine the naming 
schema is if logotypes have such significant impact on entity recognition, 
that users in general would se the logo and not notice that the DN is in 
conflict with the logotype.

If this is correct then you acknowledge the importance of logotypes as 
instrument of recognition, which speaks for that we should find a way to 
handle logotypes in certificates and not the opposite.

Personally I think that a conflict between a logotypes and a names in 
certificates can be handled on a contractual/legal level and should not 
stop us from using them in certificates.

/Stefan

At 12:34 2001-03-20 -0500, you wrote:
>At 8:58 AM -0500 3/20/01, Tim Moses wrote:
>>Colleagues - I am supportive of the idea of including branding 
>>information in certificates.  I recognize Steve's concern.  But, I 
>>suggest that there should be no impact on processing rules ... other than 
>>... in applications where the relying party is a human, the logo from the 
>>very first certificate in the path should be displayed to him/her.  When 
>>a relying party accepts a trust anchor, their experience should be 
>>identical regardless of the details of the remainder of the path.  Best 
>>regards.  Tim.
>
>Tim,
>
>My comment re validation processing arises because of the possible 
>undermining of name constraints, as I noted earlier. So, for example, I 
>might be comfortable accepting a cert with a logo reference IF the cert 
>path validation did not include a name constraints extension. But, how do 
>I enforce this sort of rule without changing the path validation algorithm?
>
>Steve

From: "Gary Visser" <[email-masked]>
To: "IETF-PKIX" <[email-masked]>
Subject: RE: Time-stamping.
Date: Tue, 20 Mar 2001 11:28:40 -0800
Importance: Normal

This is a multi-part message in MIME format.

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

Peasant Dambe wrote:
> Time-stamping of the dataum does not bind the time-stamped data to
paticular user.
> So where it will be used as it does not bind creator identity.
Correct, but the timestamp is bound to a particular entity. This entity is
providing a service similar to a public notary, someone who can attest to
the fact that the datum existed prior to a specific point in time.

> Any one can claim that  I am the author of the document.
Sure they can make the claim, but can they prove it? If you time-stamped the
document, you are claiming to have 'seen' a digest of the document, not that
you are its author. As an entity that timestamps documents I will go into a
court of law and attest to the fact that an agent of mine saw a digest of a
document at a particular point in time, provided of course that I have
determined that my agent has not been compromised. I will not make any
claims regarding the content or author of the document.

> Until there is specifically identification of the creator inside the
document itself.
> One way to do this is to to sign over dataum plus time-stamped -data.
> And if the time-stamped signature value is placed as unsigned attribute,
> it can be also replaced and it is undetectable in current specification.
> So in the current draft IS time-stamp generated fully secured?
I do not believe that the draft says you can not include the timestamp as a
signed attribute.
So you are free to do this in your systems. Others may also choose to do
this.
But the timestamp is a separate entity from the datum and need not be a
signed attribute.
An alternative that provides basically the same level of trust, is to
require that the timestamp be available from the author or timestamp
authority separate from the datum.
If the draft required that the timestamp be a signed attribute, then you
would not, for example, be able to append timestamps to messages within the
mail server as they are being delivered.

Keep in mind that these standards are not enough to build a 'fully secured'
system. You must apply and adhere to a security policy to make the system as
'fully' secured as needed. I believe that the authors of these standards go
to great lengths to ensure that no particular security policy is mandated by
the standard. Thereby allowing you to build a system that meets your
requirements.

Gary Visser
Timestamp.com

-----Original Message-----
From: Prashant Dambe [mailto:[email-masked]]
Sent: Tuesday, March 20, 2001 3:23 AM
To: [email-masked]
Subject: Time-stamping.

Time-stamping of the dataum does not bind the time-stamped data to paticular
user.
So where it will be used as it does not bind creator identity. Any one can
claim that  I am the author of the document. Until there is specifically
identification
of the creator inside the document itself.
One way to do this is to to sign over dataum plus time-stamped -data.
In this case user can replace the signature put its own signature.
So Is not that time-stampng of signature value is necessary.
And if the time-stamped signature value is placed as unsigned attribute,
it can be also replaced and it is undetectable in current specification.
So in the current draft IS time-stamp generated fully secured?

Prashant Dambe

------=_NextPart_000_0008_01C0B130.E9ED3F40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =

size=3D2>Peasant Dambe wrote:</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D580000115-20032001>&gt; </SPAN>Time-stamping of the dataum does =
not bind=20
the time-stamped data to paticular user.</FONT></FONT></FONT></DIV>
<DIV><SPAN class=3D580000115-20032001>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D580000115-20032001>&gt; </SPAN>So where it will be used as it =
does not=20
bind creator identity.</FONT></FONT></FONT></DIV><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>Correct, but the timestamp is bound to a =
particular=20
entity. This entity is providing a service similar to a public notary, =
someone=20
who can attest to the fact that the datum existed prior to a specific =
point in=20
time.</FONT></FONT></FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
color=3D#000000>&gt; Any one can </FONT><FONT face=3DArial =
size=3D2>claim that&nbsp; I=20
am the author of the document. </FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
face=3DArial size=3D2>Sure they can make the claim, but can they prove =
it? If you=20
time-stamped the document, you are claiming to have 'seen' a digest of =
the=20
document, not that you are its author. As an entity that timestamps =
documents I=20
will go into a court of law and attest to the fact that an agent of mine =
saw a=20
digest of a document at a particular point in time, provided of course =
that I=20
have determined that my agent has not been compromised. I will not make =
any=20
claims regarding the content or author of the=20
document.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
face=3DArial size=3D2></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
face=3DArial size=3D2>&gt; Until there is specifically identification =
</FONT><FONT=20
face=3DArial size=3D2>of the creator inside the document=20
itself.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D580000115-20032001>&gt; </SPAN>One way to do this is to to sign =
over=20
dataum plus time-stamped -data.</FONT></FONT></FONT></DIV></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial><FONT =
size=3D2><SPAN=20
class=3D580000115-20032001>&gt; </SPAN>And if the time-stamped signature =
value is=20
placed as unsigned attribute,</FONT></FONT></DIV>
<DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D580000115-20032001>&gt; </SPAN>it=20
can be also replaced and it is undetectable in current=20
specification.</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D580000115-20032001>&gt; </SPAN>So=20
in the current draft IS time-stamp generated&nbsp;fully=20
secured?</FONT></FONT></DIV></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
color=3D#000000>I do not believe&nbsp;that the draft says you can not =
include the=20
timestamp as a signed attribute.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial size=3D2>So you =
are free to=20
do this in your systems. Others may also choose to do =
this.</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial size=3D2>But =
the timestamp is=20
a separate entity from the datum and need not be a signed=20
attribute.</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial size=3D2>An =
alternative that=20
provides basically the same level of trust, is to require that the =
timestamp be=20
available from the author or timestamp authority separate from the=20
datum.</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
color=3D#000000>If the draft required that the timestamp be a signed =
attribute,=20
then you would not, for example, be able to append timestamps to =
messages within=20
the mail server as they are being delivered.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial size=3D2>Keep =
in mind that=20
these standards are not enough to build a 'fully secured' system. You =
must apply=20
and adhere to a security policy to make the system as 'fully' secured as =
needed.=20
I believe that the authors of these standards go to great lengths to =
ensure that=20
no particular security policy is&nbsp;mandated by the standard. Thereby =
allowing=20
you to build a system that meets your requirements.</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
color=3D#000000></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial color=3D#0000ff =
size=3D2><FONT=20
color=3D#000000></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial size=3D2>Gary=20
Visser</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial=20
size=3D2>Timestamp.com</FONT></SPAN></DIV>
<DIV><SPAN class=3D580000115-20032001><FONT face=3DArial=20
size=3D2>&nbsp;</DIV></FONT></SPAN></SPAN></DIV>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Prashant Dambe=20
[mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, March 20, 2001 =
3:23=20
AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B>=20
Time-stamping.<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Time-stamping of the dataum does not =
bind the=20
time-stamped data to paticular user.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So where it will be used as it does not =
bind=20
creator identity. Any one can </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>claim that&nbsp; I am the author of the =
document.=20
Until there is specifically identification</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>of the creator inside the document=20
itself.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>One way to do this is to to sign over =
dataum plus=20
time-stamped -data.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In this case user can replace the =
signature put its=20
own signature.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So Is not that time-stampng of =
signature value is=20
necessary.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>And if the time-stamped signature value =
is placed=20
as unsigned attribute,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>it can be also replaced and it is =
undetectable in=20
current specification.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So in the current draft IS time-stamp=20
generated&nbsp;fully secured?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Prashant =
Dambe</FONT></DIV></BODY></HTML>

------=_NextPart_000_0008_01C0B130.E9ED3F40--

Date: Tue, 20 Mar 2001 12:34:13 -0500
To: Tim Moses <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Logotypes in certificates
Cc: [email-masked]

At 8:58 AM -0500 3/20/01, Tim Moses wrote:
>Colleagues - I am supportive of the idea of including branding 
>information in certificates.  I recognize Steve's concern.  But, I 
>suggest that there should be no impact on processing rules ... other 
>than ... in applications where the relying party is a human, the 
>logo from the very first certificate in the path should be displayed 
>to him/her.  When a relying party accepts a trust anchor, their 
>experience should be identical regardless of the details of the 
>remainder of the path.  Best regards.  Tim.

Tim,

My comment re validation processing arises because of the possible 
undermining of name constraints, as I noted earlier. So, for example, 
I might be comfortable accepting a cert with a logo reference IF the 
cert path validation did not include a name constraints extension. 
But, how do I enforce this sort of rule without changing the path 
validation algorithm?

Steve

From: [email-masked]
Subject: Re: Matching CertIDs between OCSP requests and responses
To: Jeff Jacoby <[email-masked]>
Cc: [email-masked]
Date: Tue, 20 Mar 2001 16:40:13 +0000

Jeff, all,

I believe that if something is DER, then its components should also be.
However, I'm willing to be corrected if someone else wishes to comment.

You're right in your observations that people aren't as strict as they
might be in how they write the specifications.  I have certainly found the
phrasing in certain areas unclear or ambiguous.  This is also true of how
the specifications are then implemented - I've found several minor
transgressions of RFC 2456/2560 that simply required me to relax our code a
little.

On the whole, DER is what people are using, so you'd be best to stick to
that.  My advice would be that as far as is possible (and safe) you should
be strict in what you encode, and generous in what you decode.  And there
is no substitute for interoperability testing.

Jonathan
------------
Dr Jonathan Tuliani
www.symbian.com

                    Jeff Jacoby                                                                                       
                    <jjacoby@rsasec        To:     [email-masked]                                                  
                    urity.com>             cc:                                                                        
                                           Subject:     Re: Matching CertIDs between OCSP requests and responses      
                    20/03/01 16:17                                                                                    

Jonathan,

[some snippage]

Reading both 2560 and the draft for v2, I see this regarding DER
encoding:

 1. Before calculainting hashs and signatures DER is specified in
    various sections

 2. In section 4.1.1 Request Syntax,  aside from items noted in 1.
above,
    there is no other mention of a DER encoding requirment for requests
or
    any part of the request

 3. In section 4.2.1 ASN.1 Specification of the OCSP Response, there is
    an explicit statement that DER shall be used for encoding of
BasicOCSPResonse

 4. Appendix A OCSP over HTTP, there are explicit statements that DER is
to
    be used (but no use of "SHALL" or "MUST") for both request and
responses

On point 3 alone -- and this may show off my ignorance of ASN.1 -- does
saying
that BasicOCSPResponse must be DER encoded ALSO mean all subbordinate
components
must be DER encoded as well?

On points 2 and 4 together, it seems that if I use another transport
protocol
I'm allowed to encode my requests in BER.  Is this right?

Jeff

Date: Tue, 20 Mar 2001 08:17:10 -0800
From: Jeff Jacoby <[email-masked]>
Organization: RSA Security, Inc.
To: [email-masked]
Subject: Re: Matching CertIDs between OCSP requests and responses

Jonathan,

[some snippage]

Reading both 2560 and the draft for v2, I see this regarding DER
encoding:

 1. Before calculainting hashs and signatures DER is specified in 
    various sections

 2. In section 4.1.1 Request Syntax,  aside from items noted in 1.
above,
    there is no other mention of a DER encoding requirment for requests
or
    any part of the request

 3. In section 4.2.1 ASN.1 Specification of the OCSP Response, there is
    an explicit statement that DER shall be used for encoding of
BasicOCSPResonse

 4. Appendix A OCSP over HTTP, there are explicit statements that DER is
to
    be used (but no use of "SHALL" or "MUST") for both request and
responses

On point 3 alone -- and this may show off my ignorance of ASN.1 -- does
saying 
that BasicOCSPResponse must be DER encoded ALSO mean all subbordinate
components
must be DER encoded as well?

On points 2 and 4 together, it seems that if I use another transport
protocol
I'm allowed to encode my requests in BER.  Is this right?

Jeff

Date: Tue, 20 Mar 2001 16:44:11 +0100
To: [email-masked], Tim Moses <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Logotypes in certificates
Cc: [email-masked]

Todd,

I may have misunderstood you but the proposal to include logotype 
information is definitely about certificate content.

The proposal suggests a method to contain relevant information about 
logotypes in certificates in a way that allows a client to get, validate 
and display the logo to an end user.

How the client does that is not the major issue, just to provide the 
possibility.

/Stefan

At 15:20 2001-03-20 +0000, [email-masked] wrote:

>--
>Regards,
>Todd
> > Colleagues - I am supportive of the idea of including branding information
> > in certificates.  I recognize Steve's concern.  But, I suggest that there
> > should be no impact on processing rules ... other than ... in applications
> > where the relying party is a human, the logo from the very first 
> certificate
> > in the path should be displayed to him/her.  When a relying party accepts a
> > trust anchor, their experience should be identical regardless of the 
> details
> > of the remainder of the path.  Best regards.  Tim.
>
>
>This this is an instance wherein you are talking about
>is the end-use model for the cert and not the cert
>content. It is important to differentiate the two
>since use of a cert is more an applications level effort.
>
>The concept in "displaying" squat to anyone takes the
>issue out of the "content" and into the "use of" realms
>which seems to be more "application oriented" than ANYTHING,
>and as such not something that PKIX should be
>concerning itself with unless it is going to change again
>and start to publish certified use models for its wares.
>
>In which case the structure and accountability of PKIX for
>what it is producing must also change significantly more
>towards the ISO standards I think.
>
>
> >
> >
> > From: Stephen Kent [mailto:[email-masked]]
> > Sent: Monday, March 19, 2001 11:47 AM
> > To: Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: Logotypes in certificates
> >
> >
> > Stefan,
> >
> > I have mixed feelings about this proposal. We have, in the
> > NameConstraints extension, a powerful mechanism for making cross
> > certification a safe thing to do. If one were to include a logotype
> > extension in a cert that was issued by a CA who had been cross
> > certified using name constraints, it holds the potential for
> > seriously undermining the controls imposed by NameConstraints.
> >
> > There is an issue here that merits discussion: the logotype is
> > presumably useful only when people are being asked to accept/reject
> > certs, in addition to or in lieu of the many software-based controls
> > that v3 certs offer. If the use is in lieu of use of more extensive
> > software-based controls, there may not be a conflict, since the
> > context is probably that of a TTP CA where NameConstraints and
> > similar controls are of minimal use. However, if the syntactic
> > controls are also in use, a logotype extension may be of limited
> > value and might easily degrade security.
> >
> > So, I would be opposed to PKIX approving this sort of extension (even
> > as a separate RFC from 2459bis) without imposing significant
> > constraints on the contexts in which it is to be used, including
> > limitations on its use in conjunction with other extensions, e.g.,
> > NameConstraints. What worries me even more, is that we might have to
> > extend/modify the validation procedure to enforce such
> > inter-extension constraints, which would then affect 2459bis!
> >
> > Steve

Date: Tue, 20 Mar 2001 16:46:37 +0100
From: Joerg Seidel <[email-masked]>
Organization: timeproof GmbH
To: Jean-Marc Desperrier <[email-masked]>
CC: [email-masked]
Subject: Re: ESSCertID in TSP

Jean-Marc Desperrier wrote:
> 
> On day A, Alice borrows Bob2000$.
> She writes a statement "I owe Bob 2000$", digitally signs it, time-stamps the
> signature and gives it to Bob , saying : "See, I owe you 2000$, and this
> horodated statement proves it, digital signature, time-stamp, everything.
> 
> The next day, Alice borrows Bob 2000$ again.
> Alice writes a second statement "I owe Bob 2000$", digitally signs it,
> time-stamps the signature and gives it to Bob, saying : "See, I owe you 2000$
> again, and this new time-stamp "proves" that this is what I owe you today".
> 
> Of course it's very clear to everyone who has a good understanding of
> time-stamp, that this new time-stamping proves _nothing_.

Yes, now I see your point. You are totally right. The problem arises
because the timestamp proves only that the signature was made before a
given date, not at the date.

There are serveral ways to solve this problem. One of them is to
timestamp the document, sign the timestamp and timestamp the signature.
This proves that the signature was made between the two timestamp times.
Another is, as you stated already, to include the time in the document
or as a signed attribute in the signature.

What about this one:
"I owe the owner of this document 2000$". It is equivalent to a cheque
in the real world, but it has the value zero in any case, because there
is no way to identify the original. The signer can always claim that he
never gave the original to anyone - just copies.

Regards
Jörg
-- 
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

From: [email-masked]
To: Tim Moses <[email-masked]>
Cc: [email-masked]
Subject: RE: Logotypes in certificates
Date: Tue, 20 Mar 2001 15:20:14 +0000

--
Regards,
Todd
> Colleagues - I am supportive of the idea of including branding information
> in certificates.  I recognize Steve's concern.  But, I suggest that there
> should be no impact on processing rules ... other than ... in applications
> where the relying party is a human, the logo from the very first certificate
> in the path should be displayed to him/her.  When a relying party accepts a
> trust anchor, their experience should be identical regardless of the details
> of the remainder of the path.  Best regards.  Tim.

This this is an instance wherein you are talking about 
is the end-use model for the cert and not the cert 
content. It is important to differentiate the two 
since use of a cert is more an applications level effort.

The concept in "displaying" squat to anyone takes the 
issue out of the "content" and into the "use of" realms
which seems to be more "application oriented" than ANYTHING,
and as such not something that PKIX should be 
concerning itself with unless it is going to change again
and start to publish certified use models for its wares.

In which case the structure and accountability of PKIX for 
what it is producing must also change significantly more 
towards the ISO standards I think.

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Monday, March 19, 2001 11:47 AM
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> Stefan,
> 
> I have mixed feelings about this proposal. We have, in the 
> NameConstraints extension, a powerful mechanism for making cross 
> certification a safe thing to do. If one were to include a logotype 
> extension in a cert that was issued by a CA who had been cross 
> certified using name constraints, it holds the potential for 
> seriously undermining the controls imposed by NameConstraints.
> 
> There is an issue here that merits discussion: the logotype is 
> presumably useful only when people are being asked to accept/reject 
> certs, in addition to or in lieu of the many software-based controls 
> that v3 certs offer. If the use is in lieu of use of more extensive 
> software-based controls, there may not be a conflict, since the 
> context is probably that of a TTP CA where NameConstraints and 
> similar controls are of minimal use. However, if the syntactic 
> controls are also in use, a logotype extension may be of limited 
> value and might easily degrade security.
> 
> So, I would be opposed to PKIX approving this sort of extension (even 
> as a separate RFC from 2459bis) without imposing significant 
> constraints on the contexts in which it is to be used, including 
> limitations on its use in conjunction with other extensions, e.g., 
> NameConstraints. What worries me even more, is that we might have to 
> extend/modify the validation procedure to enforce such 
> inter-extension constraints, which would then affect 2459bis!
> 
> Steve

From: Tim Moses <[email-masked]>
To: [email-masked]
Subject: RE: Logotypes in certificates
Date: Tue, 20 Mar 2001 08:58:10 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B145.CC223EB0
Content-Type: text/plain;
	charset="iso-8859-1"

Colleagues - I am supportive of the idea of including branding information
in certificates.  I recognize Steve's concern.  But, I suggest that there
should be no impact on processing rules ... other than ... in applications
where the relying party is a human, the logo from the very first certificate
in the path should be displayed to him/her.  When a relying party accepts a
trust anchor, their experience should be identical regardless of the details
of the remainder of the path.  Best regards.  Tim.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, March 19, 2001 11:47 AM
To: Stefan Santesson
Cc: [email-masked]
Subject: RE: Logotypes in certificates

Stefan,

I have mixed feelings about this proposal. We have, in the 
NameConstraints extension, a powerful mechanism for making cross 
certification a safe thing to do. If one were to include a logotype 
extension in a cert that was issued by a CA who had been cross 
certified using name constraints, it holds the potential for 
seriously undermining the controls imposed by NameConstraints.

There is an issue here that merits discussion: the logotype is 
presumably useful only when people are being asked to accept/reject 
certs, in addition to or in lieu of the many software-based controls 
that v3 certs offer. If the use is in lieu of use of more extensive 
software-based controls, there may not be a conflict, since the 
context is probably that of a TTP CA where NameConstraints and 
similar controls are of minimal use. However, if the syntactic 
controls are also in use, a logotype extension may be of limited 
value and might easily degrade security.

So, I would be opposed to PKIX approving this sort of extension (even 
as a separate RFC from 2459bis) without imposing significant 
constraints on the contexts in which it is to be used, including 
limitations on its use in conjunction with other extensions, e.g., 
NameConstraints. What worries me even more, is that we might have to 
extend/modify the validation procedure to enforce such 
inter-extension constraints, which would then affect 2459bis!

Steve

------_=_NextPart_001_01C0B145.CC223EB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Logotypes in certificates</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Colleagues - I am supportive of the idea of including =
branding information in certificates.&nbsp; I recognize Steve's =
concern.&nbsp; But, I suggest that there should be no impact on =
processing rules ... other than ... in applications where the relying =
party is a human, the logo from the very first certificate in the path =
should be displayed to him/her.&nbsp; When a relying party accepts a =
trust anchor, their experience should be identical regardless of the =
details of the remainder of the path.&nbsp; Best regards.&nbsp; =
Tim.</FONT></P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stephen Kent [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, March 19, 2001 11:47 AM</FONT>
<BR><FONT SIZE=3D2>To: Stefan Santesson</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Logotypes in certificates</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Stefan,</FONT>
</P>

<P><FONT SIZE=3D2>I have mixed feelings about this proposal. We have, =
in the </FONT>
<BR><FONT SIZE=3D2>NameConstraints extension, a powerful mechanism for =
making cross </FONT>
<BR><FONT SIZE=3D2>certification a safe thing to do. If one were to =
include a logotype </FONT>
<BR><FONT SIZE=3D2>extension in a cert that was issued by a CA who had =
been cross </FONT>
<BR><FONT SIZE=3D2>certified using name constraints, it holds the =
potential for </FONT>
<BR><FONT SIZE=3D2>seriously undermining the controls imposed by =
NameConstraints.</FONT>
</P>

<P><FONT SIZE=3D2>There is an issue here that merits discussion: the =
logotype is </FONT>
<BR><FONT SIZE=3D2>presumably useful only when people are being asked =
to accept/reject </FONT>
<BR><FONT SIZE=3D2>certs, in addition to or in lieu of the many =
software-based controls </FONT>
<BR><FONT SIZE=3D2>that v3 certs offer. If the use is in lieu of use of =
more extensive </FONT>
<BR><FONT SIZE=3D2>software-based controls, there may not be a =
conflict, since the </FONT>
<BR><FONT SIZE=3D2>context is probably that of a TTP CA where =
NameConstraints and </FONT>
<BR><FONT SIZE=3D2>similar controls are of minimal use. However, if the =
syntactic </FONT>
<BR><FONT SIZE=3D2>controls are also in use, a logotype extension may =
be of limited </FONT>
<BR><FONT SIZE=3D2>value and might easily degrade security.</FONT>
</P>

<P><FONT SIZE=3D2>So, I would be opposed to PKIX approving this sort of =
extension (even </FONT>
<BR><FONT SIZE=3D2>as a separate RFC from 2459bis) without imposing =
significant </FONT>
<BR><FONT SIZE=3D2>constraints on the contexts in which it is to be =
used, including </FONT>
<BR><FONT SIZE=3D2>limitations on its use in conjunction with other =
extensions, e.g., </FONT>
<BR><FONT SIZE=3D2>NameConstraints. What worries me even more, is that =
we might have to </FONT>
<BR><FONT SIZE=3D2>extend/modify the validation procedure to enforce =
such </FONT>
<BR><FONT SIZE=3D2>inter-extension constraints, which would then affect =
2459bis!</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B145.CC223EB0--

Date: Tue, 20 Mar 2001 13:22:43 +0100
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: Joerg Seidel <[email-masked]>
CC: [email-masked]
Subject: Re: ESSCertID in TSP

Joerg Seidel wrote:

> Jean-Marc Desperrier wrote:
> > With such a use of time-stamp, if the base over wich the hash is
> > calculated does not include any reference to the local time, the
> > implementor has a hugh risk of time-stamping twice the same data, and
> > yet expect after the inclusion of the time-stamp to hold some guaranty
> > that the two items are separate entities.
>
> The serial number and usually also the time of the timestamp will be
> different.

Maybe my point wasn't clear enough.

I'll try to devise a stupid, but simple example.
This is not an attack against time-stamping, but against what happen when you
don't know how to use it properly.

On day A, Alice borrows Bob2000$.
She writes a statement "I owe Bob 2000$", digitally signs it, time-stamps the
signature and gives it to Bob , saying : "See, I owe you 2000$, and this
horodated statement proves it, digital signature, time-stamp, everything.

The next day, Alice borrows Bob 2000$ again.
Alice writes a second statement "I owe Bob 2000$", digitally signs it,
time-stamps the signature and gives it to Bob, saying : "See, I owe you 2000$
again, and this new time-stamp "proves" that this is what I owe you today".

Of course it's very clear to everyone who has a good understanding of
time-stamp, that this new time-stamping proves _nothing_.

The TSA does not identify who submits the TSP request. It could have been
either Bob restamping the message he got the previous day, or Alice stamping
her "new" message.
Even if the TSA identifies who submits the request, there's nothing wrong in
Alice restamping her message of the previous day.

I even feel that a TSA that would, when receiving a request, check in it's log
if a time-stamp for the same hash has already been generated, and resend that
time-stamp if that's the case, would be doing nothing wrong (if the request
includes a new nonce, of course it will have to generate a new time-stamp).

Date: Tue, 20 Mar 2001 13:22:30 +0100
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: ietf-pkix <[email-masked]>
Subject: Re: Time-stamping.

Prashant Dambe wrote:

> Time-stamping of the dataum does not bind the time-stamped data to
> paticular user.So where it will be used as it does not bind creator
> identity. Any one canclaim that  I am the author of the document.
> Until there is specifically identificationof the creator inside the
> document itself.

So you need to include identification of the creator inside the document
you wish to time-stamp.

This part is plain evidence.
 > One way to do this is to to sign over dataum plus time-stamped
-data.> In this case user can replace the signature put its own
signature.> So Is not that time-stampng of signature value is
necessary.> And if the time-stamped signature value is placed as
unsigned attribute,> it can be also replaced and it is undetectable in
current specification.> So in the current draft IS time-stamp generated
fully secured?

Yes, if properly used.
But some clarification about how to use it properly might be needed.

As I discuss in my other message, you need, in most cases, to insert
inside the text that you wish to time-stamp, a reference to the time at
which you claim that the statement is true, before signing and then
time-stamping it.
No one should accept as valid a message without such a statement.
This reference does not need to be time-stamped, this is what you author
of the document, claim, and when you claim it.

In SMIME, this will be required by the standard.
There's the same requirement in "Technical Requirements for a
non-Repudiation Service".

From: "Prashant Dambe" <[email-masked]>
To: <[email-masked]>
Subject: Time-stamping.
Date: Tue, 20 Mar 2001 16:53:15 +0530

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C0B15E.4195C370
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Time-stamping of the dataum does not bind the time-stamped data to =
paticular user.
So where it will be used as it does not bind creator identity. Any one =
can=20
claim that  I am the author of the document. Until there is specifically =
identification
of the creator inside the document itself.
One way to do this is to to sign over dataum plus time-stamped -data.
In this case user can replace the signature put its own signature.
So Is not that time-stampng of signature value is necessary.
And if the time-stamped signature value is placed as unsigned attribute,
it can be also replaced and it is undetectable in current specification.
So in the current draft IS time-stamp generated fully secured?

Prashant Dambe

------=_NextPart_000_0017_01C0B15E.4195C370
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Time-stamping of the dataum does not =
bind the=20
time-stamped data to paticular user.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So where it will be used as it does not =
bind=20
creator identity. Any one can </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>claim that&nbsp; I am the author of the =
document.=20
Until there is specifically identification</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>of the creator inside the document=20
itself.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>One way to do this is to to sign over =
dataum plus=20
time-stamped -data.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In this case user can replace the =
signature put its=20
own signature.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So Is not that time-stampng of =
signature value is=20
necessary.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>And if the time-stamped signature value =
is placed=20
as unsigned attribute,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>it can be also replaced and it is =
undetectable in=20
current specification.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So in the current draft IS time-stamp=20
generated&nbsp;fully secured?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Prashant =
Dambe</FONT></DIV></BODY></HTML>

------=_NextPart_000_0017_01C0B15E.4195C370--

Date: Tue, 20 Mar 2001 10:58:19 +0100
From: Joerg Seidel <[email-masked]>
Organization: timeproof GmbH
To: Jean-Marc Desperrier <[email-masked]>
CC: [email-masked]
Subject: Re: ESSCertID in TSP

Comments inline.

Jean-Marc Desperrier wrote:
> 
> Also the recent "Time-stamp issue" thread a lead me to te conclusion
> that some hints should be included in the draft about the correct way to
> generate a hash value that is intended to be time-stamped.
> 
> Without a proper warning that a timestamp states that some data existed
> before a given time, but does _not_ date the data as in "this is a
> transaction that was generated at this date", the temptation for user ot
> the TSP service to directly use a time-stamp to guaranty this, will
> exist.

Agree. The draft states:

"The TSA is a TTP that creates time stamp tokens in order to indicate 
that a datum existed at a particular point in time."

This could be changed to

"The TSA is a TTP that creates time stamp tokens in order to indicate
that a datum existed at a particular point in time. This token does not
indicate that the datum was generated at that time."

But I don't feel like this change is important enough to further delay
the RFC.

> With such a use of time-stamp, if the base over wich the hash is
> calculated does not include any reference to the local time, the
> implementor has a hugh risk of time-stamping twice the same data, and
> yet expect after the inclusion of the time-stamp to hold some guaranty
> that the two items are separate entities.

The serial number and usually also the time of the timestamp will be
different.

> Time-stamped signed data will have exactly the same behaviour, because
> the signature algorithm is deterministic.
> The same data will always generate the same signature (at least in RSA
> with standard padding algorithm)

IMO not a problem the timestamps will be different. See above.

> Therefore the standard should warn that the data to be time-stamped
> should be "new", that is it must include enough data to guarantee it to
> be unique, and that the user will not generate twice the same exact
> request.

If a user feels such a need he should use a nonce in the request.
Whether this is necessary depends on the application.

Regards
Jörg
-- 
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

From: Gschwend Bruno <[email-masked]>
To: [email-masked]
Subject: unsubscribe
Date: Tue, 20 Mar 2001 07:49:20 +0100

unsubscribe

cc: Rich Salz <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Logotypes in certificates 
Date: Tue, 20 Mar 2001 12:06:26 +1000
From: Dean Povey <[email-masked]>

>I should have explained.  It only works if the browser does something 
>sensible like displays the logo in a prominent place where the user will 
>notice and which can't be recreated by just straight HTML.  Kind of like 
>the way the lock clicks on to tell you you have a secure connection.  
>Presumably the CA will perform some due-dilligence when certifying company 
>logos.

To make the scheme clearer, one of the other authors on the first paper I
mentioned has recommended a more recent paper with more detail.

A. Jøsang, M.A. Patton and A. Ho. Authentication for Humans. In the
Proceedings of the 9th International Conference on Telecommunication Systems.
Dallas, March 2001. http://security.dstc.edu.au/papers/authum.pdf

Cheers.
-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

To: Rich Salz <[email-masked]>
cc: [email-masked]
Subject: Re: Logotypes in certificates 
Date: Tue, 20 Mar 2001 11:20:38 +1000
From: Dean Povey <[email-masked]>

>> Adding some sort of visual identifier, such as a company logo to a
>> certificate and displaying this in a prominent place in the browser would
>> go a long way to ameliorating this problem.
>
>And what's to prevent the badguy from just copying the info out of a
>real cert?  Fear of violating the trademark law?
>	/r$

I should have explained.  It only works if the browser does something 
sensible like displays the logo in a prominent place where the user will 
notice and which can't be recreated by just straight HTML.  Kind of like 
the way the lock clicks on to tell you you have a secure connection.  
Presumably the CA will perform some due-dilligence when certifying company 
logos.

Cheers

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

Date: Mon, 19 Mar 2001 19:59:06 -0500
From: Rich Salz <[email-masked]>
To: Dean Povey <[email-masked]>
CC: [email-masked]
Subject: Re: Logotypes in certificates

> Adding some sort of visual identifier, such as a company logo to a
> certificate and displaying this in a prominent place in the browser would
> go a long way to ameliorating this problem.

And what's to prevent the badguy from just copying the info out of a
real cert?  Fear of violating the trademark law?
	/r$

Date: Mon, 19 Mar 2001 19:24:13 -0500
From: jim <[email-masked]>
To: Dean Povey <[email-masked]>
CC: Stephen Kent <[email-masked]>, Stefan Santesson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Logotypes in certificates

As long as we are each throwing in TWO CENTS, do we have to consider the difference
between licensed and public domain fonts and their use in the logotype.  After all,
Adobe and Bitstream might be perturbed and want a piece of the action if one of
their fonts is used in this manner.  Then there would be an investigation and a
court case to determine which font was used and the key management issue of opening
the messages would perturbate the whole scheme. ...   ASCII character sets, please.
Jim

Dean Povey wrote:

> >There is an issue here that merits discussion: the logotype is
> >presumably useful only when people are being asked to accept/reject
> >certs, in addition to or in lieu of the many software-based controls
> >that v3 certs offer. If the use is in lieu of use of more extensive
> >software-based controls, there may not be a conflict, since the
> >context is probably that of a TTP CA where NameConstraints and
> >similar controls are of minimal use. However, if the syntactic
> >controls are also in use, a logotype extension may be of limited
> >value and might easily degrade security.
>
> The following paper motivates the need for an extension similar to that
> proposed and shows a basic attack on SSL using a web browser that having
> logos/visual cues in certificates helps mitigate.
>
> A. Jøsang, I.G. Pedersen and D. Povey. PKI seeks a trusting relationship.
> In Proceedings of the Fifth Australasian Conference on Information Security and
> Privacy (ACISP 2000), Brisbane, July 2000. Springer.
> http://security.dstc.edu.au/papers/pkitrust.pdf
>
> The basic idea is this:
>
> 1. The user is fooled into connecting to the attacker using a false URL
>    on a portal or by some other means (a sophisticated attack could
>    intercept the request and use HTTP redirects on unsecured HTTP leading
>    to get them to connect to the attacker's web server.
>
> 2. The attacker's web page masquerades as a legitimate business.  They
>    could do this by simply replicating a target site's web page.  They then
>    present a service to buy goods or perform some transaction using an
>    SSL secure connection.
>
> 3. The user connects to the secure connection, accepts the SSL certificate
>    and then submits their credit card details/bank account
>    PIN to the attacker.
>
> Note that this attack will only work if:
>
>   1. The user doesn't realise that the URL of the site they are connecting
>      to is the wrong one for the legitimate business.  In practice this
>      will probably be true even if the attacker takes no steps to hide or
>      mask this fact.  However the attacker can easily register domain names
>      that could plausibly represent the target site (e.g. for Bank Of America
>      which of the following is correct: www.bankofamerica.com, www.bom.com,
>      bom.commerce.net, www.bankofamerica.us, www.bankofamerica.tv etc.).
>      Presumably most CAs will issue you an SSL server cert if you can prove
>      ownership of the domain.
>
>   2. The user doesn't bother to check the details of the Certificate. Note this
>      involves some effort and knowledge on behalf of the user, most users
>      would just see the little lock icon and happily enter their details.
>
> The problem is caused by lack of feedback from the security mechanism about
> the trust aspects of the transaction.  While the browser goes to a lot of
> trouble to verify the cryptographic aspects of the SSL connection, the link
> between the authentication and the actual organisation the user thinks they
> are contacting is quite tenuous.
>
> Adding some sort of visual identifier, such as a company logo to a
> certificate and displaying this in a prominent place in the browser would
> go a long way to ameliorating this problem.
>
> However, I for one would be more interested in seeing this in a separate
> I-D/RFC rather than son-of-2459.  I also agree that is seems silly to stuff
> the image in the certificate, instead something along the lines of:
>
> SubjectLogo ::= SEQUENCE {
>   location        GeneralName,
>   digestAlgorithm AlgorithmIdentifier,
>   digest          OCTET STRING
> }
>
> seems appropriate. If you really want to go for a space save you could
> make the digestAlgorithm OPTIONAL and have it use whatever is used to
> generate the signature if it is not present.
>
> Which begs the question, having a signed embedded reference (as opposed to
> something like SubjectDirectoryAttributes) to arbitrary external content in
> a Certificate seems to me to be wholly useful thing to want to do (e.g.
> CPS, user agreement, photo of user's cat etc).  So is it worth perhaps
> generalising something like the above to support this, e.g.
>
> SubjectAuthenticatedReferences ::= SEQUENCE OF AuthenticatedReference
>
> AuthenticatedReference ::= SEQUENCE {
>   location        GeneralName,
>   digestAlgorithm AlgorithmIdentifier,
>   digest          OCTET STRING
> }
>
> or numerous permutations thereof.  Or perhaps such a beast exists already?
>
> Just my $0.02.
>
> --
> Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit
> Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
> Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
> Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit

To: Stephen Kent <[email-masked]>
cc: Stefan Santesson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Logotypes in certificates 
Date: Tue, 20 Mar 2001 10:04:51 +1000
From: Dean Povey <[email-masked]>

>There is an issue here that merits discussion: the logotype is 
>presumably useful only when people are being asked to accept/reject 
>certs, in addition to or in lieu of the many software-based controls 
>that v3 certs offer. If the use is in lieu of use of more extensive 
>software-based controls, there may not be a conflict, since the 
>context is probably that of a TTP CA where NameConstraints and 
>similar controls are of minimal use. However, if the syntactic 
>controls are also in use, a logotype extension may be of limited 
>value and might easily degrade security.

The following paper motivates the need for an extension similar to that 
proposed and shows a basic attack on SSL using a web browser that having
logos/visual cues in certificates helps mitigate.

A. Jøsang, I.G. Pedersen and D. Povey. PKI seeks a trusting relationship.
In Proceedings of the Fifth Australasian Conference on Information Security and
Privacy (ACISP 2000), Brisbane, July 2000. Springer. 
http://security.dstc.edu.au/papers/pkitrust.pdf

The basic idea is this:

1. The user is fooled into connecting to the attacker using a false URL 
   on a portal or by some other means (a sophisticated attack could 
   intercept the request and use HTTP redirects on unsecured HTTP leading
   to get them to connect to the attacker's web server.

2. The attacker's web page masquerades as a legitimate business.  They 
   could do this by simply replicating a target site's web page.  They then
   present a service to buy goods or perform some transaction using an
   SSL secure connection.

3. The user connects to the secure connection, accepts the SSL certificate
   and then submits their credit card details/bank account 
   PIN to the attacker.

Note that this attack will only work if:

  1. The user doesn't realise that the URL of the site they are connecting
     to is the wrong one for the legitimate business.  In practice this 
     will probably be true even if the attacker takes no steps to hide or
     mask this fact.  However the attacker can easily register domain names
     that could plausibly represent the target site (e.g. for Bank Of America 
     which of the following is correct: www.bankofamerica.com, www.bom.com,
     bom.commerce.net, www.bankofamerica.us, www.bankofamerica.tv etc.).
     Presumably most CAs will issue you an SSL server cert if you can prove
     ownership of the domain.

  2. The user doesn't bother to check the details of the Certificate. Note this 
     involves some effort and knowledge on behalf of the user, most users
     would just see the little lock icon and happily enter their details.

The problem is caused by lack of feedback from the security mechanism about
the trust aspects of the transaction.  While the browser goes to a lot of
trouble to verify the cryptographic aspects of the SSL connection, the link
between the authentication and the actual organisation the user thinks they
are contacting is quite tenuous.

Adding some sort of visual identifier, such as a company logo to a
certificate and displaying this in a prominent place in the browser would
go a long way to ameliorating this problem.

However, I for one would be more interested in seeing this in a separate
I-D/RFC rather than son-of-2459.  I also agree that is seems silly to stuff
the image in the certificate, instead something along the lines of:

SubjectLogo ::= SEQUENCE {
  location        GeneralName,              
  digestAlgorithm AlgorithmIdentifier,
  digest          OCTET STRING 
}

seems appropriate. If you really want to go for a space save you could
make the digestAlgorithm OPTIONAL and have it use whatever is used to
generate the signature if it is not present.

Which begs the question, having a signed embedded reference (as opposed to
something like SubjectDirectoryAttributes) to arbitrary external content in
a Certificate seems to me to be wholly useful thing to want to do (e.g.
CPS, user agreement, photo of user's cat etc).  So is it worth perhaps
generalising something like the above to support this, e.g.

SubjectAuthenticatedReferences ::= SEQUENCE OF AuthenticatedReference

AuthenticatedReference ::= SEQUENCE {
  location        GeneralName,              
  digestAlgorithm AlgorithmIdentifier,
  digest          OCTET STRING 
}

or numerous permutations thereof.  Or perhaps such a beast exists already?

Just my $0.02.

-- 
Dean Povey,         | e-m: [email-masked] | JCSI:  Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI:  C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |        systems
Brisbane, Australia | www: security.dstc.com | Oscar: C++ PKI toolkit 

From: Andrew Hoag <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Trevor Freeman <[email-masked]>, David Cross <[email-masked]>, [email-masked]
Subject: RE: Logotypes in certificates
Date: Mon, 19 Mar 2001 15:12:52 -0800

The other issue being implied here is that of affinity and branding. 

Clearly we generally approach certificates from a security & risk management
perspective, but there are other commercial drivers as well. Most notably,
using a certificate that provides some sort of tie to the issuer or
authenticating entity. This is the same reason you may get a Visa card from
your airline frequent flyer program. 

Certainly in many usage cases it is beneficial, for both the company
providing certificates and to the end-user, to provide some sort of improved
UI for viewing certificates, including binding of a logo. 

A standard method for providing this type of user-friendly data would be
very helpful towards greater commercial use & applications of certificates.

Andrew Hoag

> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Sunday, March 18, 2001 9:07 PM
> To: Trevor Freeman; David Cross; [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> Hi Trevor,
> 
> Thank you for this challenging question. This is a hard one 
> and I will try 
> to answer.
> 
> I think we are into the hen and egg problem.
> I see at least 3 big reasons why most users don't know what a 
> certificate is.
> - PKI hasn't yet reached into the bedroom of normal users.
> - Applications doesn't encourage users to se the certificate 
> content and;
> - If they do, there isn't so much interesting to see anyway 
> because the 
> display interface is normally not very user friendly.
> 
> I simply ask you to look beyond the horizon and try to grasp 
> a glimpse of 
> the future.
> 
> In a mature PKI, when a human user receives a signed message, the 
> applications will probably provide the user with a simple 
> button to view 
> signature details.
> 
> What is then interesting here?
> - Signature algorithm ?
> - Key length ?
> - Or maybe just WHO SIGNED THIS and
> - DO I TRUST THIS SIGNATURE?!
> 
> If the user has just a minor curiosity about who signed this, and who 
> stands behind the identification of this person, what better then to 
> display the signers certificate.
> 
> But I challenge you to display this in a interesting and 
> meaningful way to 
> the user if you cut of the possibility to tie logotypes to 
> the process.
> 
> If you denies this option you are STUCK with a pure text 
> interface, and 
> that won't do. Not if this is to grow out of the technical community.
> 
> At least this is what I see and the response I get from many 
> people I talk 
> to, among them initiated peoples related to European 
> electronic signature 
> legislation and standardization.
> 
> /Stefan
> 
> 
> At 10:42 2001-03-18 -0800, Trevor Freeman wrote:
> >Hi Stefan,
> >The fundamental gap here is that most users don't know what a
> >certificate is, and are happy that they just get a simple icon if
> >everything is ok or not rather than some UI detailing the 
> content of the
> >credential. Most users never look as the certificate UI.
> >Trevor
> >
> >From: Stefan Santesson [mailto:[email-masked]]
> >Sent: Saturday, March 17, 2001 4:14 PM
> >To: David Cross; [email-masked]
> >Subject: RE: Logotypes in certificates
> >
> >
> >David,
> >
> >Comment in line;
> >
> >At 18:46 2001-03-16 -0800, David Cross wrote:
> > >Stefan:
> > >
> > >Some comments -
> > >
> > >First:  I do not think that this should be considered for son of
> > >RFC2459
> > >- we do not want to hold this up to consider this proposal.
> >
> >That's OK with me.
> >
> > >
> > >Second:  I do not see how applications will make use of this
> > >information.  How do you see it being used?
> >
> >Well first I would like to state that I now of several 
> applications that
> >
> >would use this information if it was available. This is typically any
> >application which includes a function to display a certificates to a
> >human
> >user. These applications will seek to have a display format 
> which makes
> >sense to the user. These applications can, if logotype data 
> is present,
> >choose to download these logotypes and display them to the 
> user when a
> >certificate is displayed.
> >
> >Applications don't caring about logos won't be effected 
> since they just
> >ignore this information without problem. The logo is only a display
> >function and has no part in any DN or alternative name.
> >
> >We will surely implement this in certificates if this gets to be
> >supported
> >by any standard.
> >
> >/Stefan
> >
> > >
> > >Third:  People are complaining about size of certs now, this will
> > >expand that issue
> >
> >Everything is a tradeoff. In this case we can meet an 
> important business
> >
> >need with just a few bytes. I think this is one of those cases that
> >definitely is worth it.
> >
> >/Stefan
> >
> > >
> > >
> > >David B. Cross
> > >
> > >
> > >         From: Stefan Santesson [mailto:[email-masked]]
> > >         Sent: Thursday, March 15, 2001 3:22 PM
> > >         To: [email-masked]
> > >         Subject: Logotypes in certificates
> > >
> > >
> > >         In last PKIX meeting in San Diego I presented 
> some thoughts on
> >
> > >creating a new extension for inclusion of logotype information in
> > >certificates.
> > >
> > >         Last in this mail I include a primary suggested 
> outline for
> > >such extension.
> > >
> > >         But first a short summary of the rationale:
> > >
> > >         At a first glance it may seem irrelevant to 
> include logotype
> > >information in certificates and a natural first reaction 
> is "OH NO...
> > >NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> > >
> > >         The fact is though that at the ETSI meeting this 
> week (In the
> > >group that handles European standards related to electronic
> > >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE
> > >DATA WOULD BE VERY USEFUL.
> > >
> > >         Why is that so?
> > >
> > >         The answer is that logotypes are carriers of trust and are
> > >widely recognized tools for trust recognition. Have you 
> ever thought
> > >why EVERY physical instrument of trust, from loyalty cards, credit
> > >cards to Passports, contain trust symbols in the form of logotypes.
> > >
> > >         Are certificates different? ABSOLUTELY NOT!!
> > >
> > >         If PKI is to take off in the private market, the 
> certificates
> > >must be user friendly and carry the same functionality (in 
> electronic
> > >form) as ID-cards, passports and other physical ID:s do in physical
> > >form. And logotypes are a FUNDAMENTAL part of that.
> > >
> > >         Without logotypes, certificates can only be handled and
> > >presented as textual information for technically oriented 
> users. This
> > >is the reality I see.
> > >
> > >         What is your observation?
> > >
> > >         How can we then do this?
> > >
> > >         Technically speaking, we don't have to include the actual
> > >logotype image and we don't have to destroy legacy applications.
> > >         I would suggest that we use the same mechanism that we
> > >specified for biometric data in RFC 3039 where a 
> non-critical extension
> >
> > >can include for each logotype:
> > >
> > >         -  type of logo
> > >         -  type of hash algorithm
> > >         -  hash of logotype data
> > >         -  URI to location of data
> > >
> > >         This will only take a few bytes but will allow new
> > >applications to import relevant logotypes, signed by the 
> issuer of the
> > >certificate, to be displayed to the user.
> > >
> > >         So... What to do with this?
> > >
> > >         If this is to be proceeded at all, It could be 
> part of son of
> > >RFC 2459, it could be part of a new RFC 3039 and it could be a new
> > >draft or merged with some other work. I'm open for suggestions.
> > >
> > >         I hope to be able to meet with many of you and 
> discuss this in
> >
> > >Minneapolis next week.
> > >
> > >         /Stefan Santesson
> > >
> > >
> > >         logotypeInfo  EXTENSION ::= {
> > >                   SYNTAX             LogotypeSyntax
> > >                   IDENTIFIED BY      id-pe-logotypeInfo }
> > >
> > >               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> > >
> > >               LogotypeSyntax ::= SEQUENCE OF LogotypeData
> > >
> > >               LogotypeData ::= SEQUENCE {
> > >                   typeOfLogotype       TypeOflogotype,
> > >                   hashAlgorithm        AlgorithmIdentifier,
> > >                   logotypeDataHash     OCTET STRING,
> > >                   sourceDataUri        IA5String OPTIONAL }
> > >
> > >               TypeOflogotype ::= CHOICE {
> > >                   predefinedLogotypeType    
> PredefinedLogotypeType,
> > >                   LogotypeTypeID            OBJECT IDENTIFIER }
> > >
> > >               PredefinedLogotypeType ::= INTEGER {
> > >                   subject-organization-logotype(0),
> > >                   issuer-organization-logotype(1)
> > >                   CA-network-logotype(2)}
> > >                   (subject-organization-logotype|
> > >                    issuer-organization-logotype|
> > >                     CA-network-logotype,...)
> > >
> > >
> > >         The predefined logotype types are
> > >
> > >         subject-organization-logotype, if used, SHALL be used to
> > >include a logotype of the subject organization. The 
> logotype SHALL be
> > >consistent with, and require the presence of, an organization name
> > >stored in the organization attribute in the subject field.
> > >
> > >         issuer-organization-logotype, if used, SHALL be used to
> > >include a logotype of the issuer organization. The 
> logotype SHALL be
> > >consistent with, and require the presence of, an organization name
> > >stored in the organization attribute in the issuer field.
> > >
> > >         CA-network-logotype, if used, SHALL be used to include a
> > >logotype used by a network of CA services, provided by one 
> or several
> > >independent CA's, within which the issuer claims to issue this
> > >certificate.
> > >
> > >
> 

Date: Mon, 19 Mar 2001 11:46:46 -0500
To: Stefan Santesson <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Logotypes in certificates
Cc: <[email-masked]>

Stefan,

I have mixed feelings about this proposal. We have, in the 
NameConstraints extension, a powerful mechanism for making cross 
certification a safe thing to do. If one were to include a logotype 
extension in a cert that was issued by a CA who had been cross 
certified using name constraints, it holds the potential for 
seriously undermining the controls imposed by NameConstraints.

There is an issue here that merits discussion: the logotype is 
presumably useful only when people are being asked to accept/reject 
certs, in addition to or in lieu of the many software-based controls 
that v3 certs offer. If the use is in lieu of use of more extensive 
software-based controls, there may not be a conflict, since the 
context is probably that of a TTP CA where NameConstraints and 
similar controls are of minimal use. However, if the syntactic 
controls are also in use, a logotype extension may be of limited 
value and might easily degrade security.

So, I would be opposed to PKIX approving this sort of extension (even 
as a separate RFC from 2459bis) without imposing significant 
constraints on the contexts in which it is to be used, including 
limitations on its use in conjunction with other extensions, e.g., 
NameConstraints. What worries me even more, is that we might have to 
extend/modify the validation procedure to enforce such 
inter-extension constraints, which would then affect 2459bis!

Steve

To: "parag salvi" <[email-masked]>
cc: [email-masked]
Subject: Re: CA Tool 
Date: Tue, 20 Mar 2001 08:16:04 +1000
From: Dean Povey <[email-masked]>

>
>Hi All,
>
>Is there any CA tool available where I can specify what extension I want in 
>the CA and with what values ?
>

uPKI (http://security.dstc.com/products/upki/) comes with a tool that 
allows you to generate certificates and specify arbitrary extensions. 
OpenSSL (http://www.openssl.org/) is another option.

Dean.

Date: Mon, 19 Mar 2001 22:44:00 +0100
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: ESSCertID in TSP

The TSP draft has several reference to an "ESSCertID attribute", saying
it's defined in ESS (RFC2634).

But as far as I see RFC2634 does not define an ESSCertID attribute.

It defines a SigningCertificate attribute, that can include one or
several ESSCertID structures.

Only the SigningCertificate has an OID assigned to it in RFC2634, not
the ESSCertID alone.

Therefore to be more explicit, I think the wording should modified to :
"a ESSCertID identifier inside a SigningCertificate attribute".

Also the recent "Time-stamp issue" thread a lead me to te conclusion
that some hints should be included in the draft about the correct way to
generate a hash value that is intended to be time-stamped.

Without a proper warning that a timestamp states that some data existed
before a given time, but does _not_ date the data as in "this is a
transaction that was generated at this date", the temptation for user ot
the TSP service to directly use a time-stamp to guaranty this, will
exist.

With such a use of time-stamp, if the base over wich the hash is
calculated does not include any reference to the local time, the
implementor has a hugh risk of time-stamping twice the same data, and
yet expect after the inclusion of the time-stamp to hold some guaranty
that the two items are separate entities.
Time-stamped signed data will have exactly the same behaviour, because
the signature algorithm is deterministic.
The same data will always generate the same signature (at least in RSA
with standard padding algorithm)

Therefore the standard should warn that the data to be time-stamped
should be "new", that is it must include enough data to guarantee it to
be unique, and that the user will not generate twice the same exact
request.
Except of course when this is deliberate.

One of the easiest way to guaranty that being to include local time in
the data before hashing it.

From: Sharon Boeyen <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, [email-masked]
Subject: 3rd message
Date: Mon, 19 Mar 2001 15:57:03 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0B0B7.2646ECE0
Content-Type: text/plain;
	charset="iso-8859-1"

> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 5:38 PM
> To: 'Peter Gutmann'; [email-masked]
> Subject: RE: DER encoding of KeyUsage BIT STRING
> 
> 
> 
> SSLeay/OpenSSL does that. Seems to work pretty well with most
> things.
> 
> Regards,
> Ambarish
> 
> > From: Peter Gutmann [mailto:[email-masked]]
> > Sent: Tuesday, March 06, 2001 11:52 AM
> > To: [email-masked]
> > Subject: Re: DER encoding of KeyUsage BIT STRING
> > 
> > 
> > 
> > 
> > John Thielens <[email-masked]> writes:
> > 
> > >Ordinarily, I wouldn't even notice.  But in this case, the 
> > certificate goes
> > >through a toolkit that parses the certificate into an 
> > internal canonical form
> > >and then regenerates its own DER encoded certificate, 
> > thereby changing the
> > >second encoding into the first.
> > 
> > Is there really a toolkit out there which does that?  
> > Wouldn't that break about
> > 90% of the certificates in existence?
> > 
> > (I'm not just being facetious with that question, I can't 
> > imagine how anyone
> >  could field a toolkit which recodes certs into correct DER 
> > without finding
> >  that almost everything they try fails to work after the 
> > recoding.  Which
> >  toolkit is this?  I should probably put a warning about this 
> > in the style
> >  guide).
> > 
> > >1) the "unusual" CA is at fault for generating an improper 
> > DER encoding with
> > >trailing 0's explicit in a BIT STRING.
> > 
> > Yes, look up the rules for named bit strings in X.680/690 (I 
> > don't have a copy
> > handy at the moment so I can't quote chapter and verse).  
> > OTOH the CA isn't
> > that unusual, a lot of CAs and implementations do this (thus 
> > my surprise that
> > the toolkit managed to get past any field testing with that 
> > behaviour).
> > 
> > Peter.
> > 
> 

------_=_NextPart_001_01C0B0B7.2646ECE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>3rd message</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Ambarish Malpani [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, March 06, 2001 5:38 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Peter Gutmann'; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: DER encoding of KeyUsage BIT =
STRING</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; SSLeay/OpenSSL does that. Seems to work pretty =
well with most</FONT>
<BR><FONT SIZE=3D2>&gt; things.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; Ambarish</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; 339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Peter Gutmann [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked].=
nz</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Tuesday, March 06, 2001 11:52 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: DER encoding of KeyUsage BIT =
STRING</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; John Thielens &lt;[email-masked]&gt; =
writes:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Ordinarily, I wouldn't even =
notice.&nbsp; But in this case, the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificate goes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;through a toolkit that parses the =
certificate into an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; internal canonical form</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;and then regenerates its own DER =
encoded certificate, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; thereby changing the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;second encoding into the first.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Is there really a toolkit out there which =
does that?&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Wouldn't that break about</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 90% of the certificates in =
existence?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (I'm not just being facetious with that =
question, I can't </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; imagine how anyone</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; could field a toolkit which recodes =
certs into correct DER </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; without finding</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; that almost everything they try =
fails to work after the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; recoding.&nbsp; Which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; toolkit is this?&nbsp; I should =
probably put a warning about this </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in the style</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp; guide).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;1) the &quot;unusual&quot; CA is at =
fault for generating an improper </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; DER encoding with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;trailing 0's explicit in a BIT =
STRING.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Yes, look up the rules for named bit =
strings in X.680/690 (I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; don't have a copy</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; handy at the moment so I can't quote =
chapter and verse).&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; OTOH the CA isn't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that unusual, a lot of CAs and =
implementations do this (thus </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; my surprise that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the toolkit managed to get past any field =
testing with that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; behaviour).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Peter.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0B0B7.2646ECE0--

From: [email-masked]
Subject: Re: Matching CertIDs between OCSP requests and responses
To: Jeff Jacoby <[email-masked]>
Cc: [email-masked]
Date: Mon, 19 Mar 2001 17:40:52 +0000

Jeff,

Under BER there are several ways to encode a given value of certain data
types, but DER is a subset of this in which every detail of the encoding is
unambiguously specified (if you're strict about your DER, of course).  The
OCSP spec specifies DER, so in a bug-free world every byte should match.

Regards,

Jonathan
------------
Dr Jonathan Tuliani
www.symbian.com

                    Jeff Jacoby                                                                                       
                    <jjacoby@rsasec        To:     [email-masked]                                                  
                    urity.com>             cc:                                                                        
                                           Subject:     Re: Matching CertIDs between OCSP requests and responses      
                    19/03/01 17:28                                                                                    

Peter,

[email-masked] wrote:

[snip]

> Unless you check the returned ID data there's no way you can detect
> this.  What
> I'm doing is a binary compare of request and response ID data, if they
> differ I
> don't trust the response.

Pardon my naivte, but couldn't the responder apply a different BER/DER
encoding to CertID in its response, yet keeping the actual encoded
values
within a CertID identical?

Jeff

Date: Mon, 19 Mar 2001 09:28:38 -0800
From: Jeff Jacoby <[email-masked]>
Organization: RSA Security, Inc.
To: [email-masked]
Subject: Re: Matching CertIDs between OCSP requests and responses

Peter, 

[email-masked] wrote:

[snip]

> Unless you check the returned ID data there's no way you can detect
> this.  What
> I'm doing is a binary compare of request and response ID data, if they
> differ I
> don't trust the response.

Pardon my naivte, but couldn't the responder apply a different BER/DER
encoding to CertID in its response, yet keeping the actual encoded
values 
within a CertID identical?

Jeff

To: [email-masked]
Date: Sun, 18 Mar 2001 22:49:23 -0800
From: "chandrasekaran natarajan" <[email-masked]>
Reply-To: [email-masked]
Subject: CAs Publishing delta-CRLs
Organization: Lycos Mail  (http://mail.lycos.com:80)

hello,
 
Can any one let me know some CAs which also
publish delta-CRLs in their LDAP directories or over
http/https/ftp.  
 
If  yes,please also let me know the web links
for the same.
 
Thanks and Regards
 
Chandar

Get 250 color business cards for FREE! at Lycos Mail
http://mail.lycos.com/freemail/vistaprint_index.html

Date: Mon, 19 Mar 2001 06:45:23 +0100
To: Eric Murray <[email-masked]>, Trevor Freeman <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Logotypes in certificates
Cc: [email-masked]

Hi Eric,

Thank you for interesting thoughts. Yes this is a challenging subject.

Let me first ask you to consider the case if we didn't use handwritten 
signatures today. Imagine that I now suggested that we start using a method 
to close contracts and deals where involved parties freely chooses any 
personal written symbol and let that represent them and their acceptance of 
a contract.

Can you imagine what philosophic debates that would cause? How easy it 
would be to forge and how hard it will be to prove who really signed a 
document!!! Pretty much the kind of challenges you just raised with respect 
to logotypes.

Identification and naming are not exact science. It is just like signatures 
- It is a phenomena which has evolved over long periods of times as it has 
proved its value despite its imperfection.

What we try to do with certificates is not to make this world more perfect, 
but to REFLECT that world and DOCUMENT the processes that makes up the 
fundament of trust in our lives and societies.

You can fool any PKI structure if you don't require the CA to 1) Be trusted 
and 2) prove that trustworthiness by being signed by a trusted ROOT CA.

Given that, we don't ask any CA to do more than to INVESTIGATE and DOCUMENT 
what it already out there, I don't see the problem. Personally I see no 
problem for a CA to validate a logotype of an organization since what a CA 
does is merely to identify the organization and then document what that 
legal entity CLAIMS to be its logotype.

If that claim is wrong, then there is legal ways to deal with that.

International conflicts of logos are there with or without certificates.

Logos are NOT replacements of DN:s and names of any kind, they are just 
complementing concepts of symbols developed over long period of time, 
proven valuable to the society as a carrier of trust, despite its imperfection.

/Stefan

At 16:07 2001-03-18 -0800, Eric Murray wrote:
>On Sun, Mar 18, 2001 at 10:42:12AM -0800, Trevor Freeman wrote:
> > Hi Stefan,
> > The fundamental gap here is that most users don't know what a
> > certificate is, and are happy that they just get a simple icon if
> > everything is ok or not rather than some UI detailing the content of the
> > credential. Most users never look as the certificate UI.
>
>
>Agreed.
>
>
>I don't think that the logo extension would add that much data to the
>cert.  There's already a whole load of junk people can put in certs,
>what's another 1-200 bytes?
>
>
>
>I am however concerned with how certs with the logo extension
>would be issued.
>
>Evil Trent is setting up a site to spoof the Bank of Alice web site.
>Since Trent knows that the BofA customers all use the logo extension
>to verify that they're really connected to Alice, he spoofs
>the logo.  Trent creates a logo which is very similar to the BofA
>logo, but with one pixel in the corner different.
>
>When Trent goes to Verisign, do they check the logo before they sign
>the cert?  How much do they check it- that it's hash is different from
>all the other logos in their database?  If that's the case, Trent's
>visually-identical logo is "different" and Trent gets his cert.
>
>Trent puts up his spoof site, redirects traffic to it, and cleans out a
>number of accounts.  Eventually Alice will find out that Trent is using a
>logo that's too similar to Alice's.  There's already laws for this sort
>of thing, so Alice can eventually prevail in the courts and get Trent
>to stop using the confusing logo.  Before that happens, Trent moves to
>some small country with weak extradition laws.
>
>With DNs this is simple(er)- Verisign just won't sign a cert request
>from Trent that says it's from Alice.  Of course "says it's from Alice"
>is interpreted different by different CAs and to be 100% correct
>you have to know each CA's naming convention.  But generally it's not
>possible to get a Subject DN that's close enough to an existing issued
>cert to spoof it.
>
>How would this be handled with logos?  There's a body of law for
>similarity of logos and trademarks, would that be followed?  Or would
>someone at Verisign (or pick any CA) just look at the logos and reject any
>that're "too similar".  There's probably also an international law problem
>here- what if I get a cert issued with my logo, which is trademarked
>in the US, and there's another very similar logo trademarked in the UK
>for an entirely unrelated company?  Normally I and the other company
>would not be competing in each other's territories, but now with the
>net, we are, and our logos clash.  Who figures this out?  This problem
>sounds very similar to the domain name situation, which as we all know,
>is a bit of a mess.
>
>I think that these issues (and probably more in the same vein)
>should be thought through before going ahead with this.

From: "Michael Myers" <[email-masked]>
To: "Eric Murray" <[email-masked]>, "Trevor Freeman" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Logotypes in certificates
Date: Sun, 18 Mar 2001 21:27:03 -0800
Importance: Normal

In my opinion, this issue is better addressed in a more industry-focused
forum.

Mike

Date: Mon, 19 Mar 2001 06:06:49 +0100
To: "Trevor Freeman" <[email-masked]>, "David Cross" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Logotypes in certificates

Hi Trevor,

Thank you for this challenging question. This is a hard one and I will try 
to answer.

I think we are into the hen and egg problem.
I see at least 3 big reasons why most users don't know what a certificate is.
- PKI hasn't yet reached into the bedroom of normal users.
- Applications doesn't encourage users to se the certificate content and;
- If they do, there isn't so much interesting to see anyway because the 
display interface is normally not very user friendly.

I simply ask you to look beyond the horizon and try to grasp a glimpse of 
the future.

In a mature PKI, when a human user receives a signed message, the 
applications will probably provide the user with a simple button to view 
signature details.

What is then interesting here?
- Signature algorithm ?
- Key length ?
- Or maybe just WHO SIGNED THIS and
- DO I TRUST THIS SIGNATURE?!

If the user has just a minor curiosity about who signed this, and who 
stands behind the identification of this person, what better then to 
display the signers certificate.

But I challenge you to display this in a interesting and meaningful way to 
the user if you cut of the possibility to tie logotypes to the process.

If you denies this option you are STUCK with a pure text interface, and 
that won't do. Not if this is to grow out of the technical community.

At least this is what I see and the response I get from many people I talk 
to, among them initiated peoples related to European electronic signature 
legislation and standardization.

/Stefan

At 10:42 2001-03-18 -0800, Trevor Freeman wrote:
>Hi Stefan,
>The fundamental gap here is that most users don't know what a
>certificate is, and are happy that they just get a simple icon if
>everything is ok or not rather than some UI detailing the content of the
>credential. Most users never look as the certificate UI.
>Trevor
>
>From: Stefan Santesson [mailto:[email-masked]]
>Sent: Saturday, March 17, 2001 4:14 PM
>To: David Cross; [email-masked]
>Subject: RE: Logotypes in certificates
>
>
>David,
>
>Comment in line;
>
>At 18:46 2001-03-16 -0800, David Cross wrote:
> >Stefan:
> >
> >Some comments -
> >
> >First:  I do not think that this should be considered for son of
> >RFC2459
> >- we do not want to hold this up to consider this proposal.
>
>That's OK with me.
>
> >
> >Second:  I do not see how applications will make use of this
> >information.  How do you see it being used?
>
>Well first I would like to state that I now of several applications that
>
>would use this information if it was available. This is typically any
>application which includes a function to display a certificates to a
>human
>user. These applications will seek to have a display format which makes
>sense to the user. These applications can, if logotype data is present,
>choose to download these logotypes and display them to the user when a
>certificate is displayed.
>
>Applications don't caring about logos won't be effected since they just
>ignore this information without problem. The logo is only a display
>function and has no part in any DN or alternative name.
>
>We will surely implement this in certificates if this gets to be
>supported
>by any standard.
>
>/Stefan
>
> >
> >Third:  People are complaining about size of certs now, this will
> >expand that issue
>
>Everything is a tradeoff. In this case we can meet an important business
>
>need with just a few bytes. I think this is one of those cases that
>definitely is worth it.
>
>/Stefan
>
> >
> >
> >David B. Cross
> >
> >
> >         From: Stefan Santesson [mailto:[email-masked]]
> >         Sent: Thursday, March 15, 2001 3:22 PM
> >         To: [email-masked]
> >         Subject: Logotypes in certificates
> >
> >
> >         In last PKIX meeting in San Diego I presented some thoughts on
>
> >creating a new extension for inclusion of logotype information in
> >certificates.
> >
> >         Last in this mail I include a primary suggested outline for
> >such extension.
> >
> >         But first a short summary of the rationale:
> >
> >         At a first glance it may seem irrelevant to include logotype
> >information in certificates and a natural first reaction is "OH NO...
> >NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> >
> >         The fact is though that at the ETSI meeting this week (In the
> >group that handles European standards related to electronic
> >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE
> >DATA WOULD BE VERY USEFUL.
> >
> >         Why is that so?
> >
> >         The answer is that logotypes are carriers of trust and are
> >widely recognized tools for trust recognition. Have you ever thought
> >why EVERY physical instrument of trust, from loyalty cards, credit
> >cards to Passports, contain trust symbols in the form of logotypes.
> >
> >         Are certificates different? ABSOLUTELY NOT!!
> >
> >         If PKI is to take off in the private market, the certificates
> >must be user friendly and carry the same functionality (in electronic
> >form) as ID-cards, passports and other physical ID:s do in physical
> >form. And logotypes are a FUNDAMENTAL part of that.
> >
> >         Without logotypes, certificates can only be handled and
> >presented as textual information for technically oriented users. This
> >is the reality I see.
> >
> >         What is your observation?
> >
> >         How can we then do this?
> >
> >         Technically speaking, we don't have to include the actual
> >logotype image and we don't have to destroy legacy applications.
> >         I would suggest that we use the same mechanism that we
> >specified for biometric data in RFC 3039 where a non-critical extension
>
> >can include for each logotype:
> >
> >         -  type of logo
> >         -  type of hash algorithm
> >         -  hash of logotype data
> >         -  URI to location of data
> >
> >         This will only take a few bytes but will allow new
> >applications to import relevant logotypes, signed by the issuer of the
> >certificate, to be displayed to the user.
> >
> >         So... What to do with this?
> >
> >         If this is to be proceeded at all, It could be part of son of
> >RFC 2459, it could be part of a new RFC 3039 and it could be a new
> >draft or merged with some other work. I'm open for suggestions.
> >
> >         I hope to be able to meet with many of you and discuss this in
>
> >Minneapolis next week.
> >
> >         /Stefan Santesson
> >
> >
> >         logotypeInfo  EXTENSION ::= {
> >                   SYNTAX             LogotypeSyntax
> >                   IDENTIFIED BY      id-pe-logotypeInfo }
> >
> >               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> >
> >               LogotypeSyntax ::= SEQUENCE OF LogotypeData
> >
> >               LogotypeData ::= SEQUENCE {
> >                   typeOfLogotype       TypeOflogotype,
> >                   hashAlgorithm        AlgorithmIdentifier,
> >                   logotypeDataHash     OCTET STRING,
> >                   sourceDataUri        IA5String OPTIONAL }
> >
> >               TypeOflogotype ::= CHOICE {
> >                   predefinedLogotypeType    PredefinedLogotypeType,
> >                   LogotypeTypeID            OBJECT IDENTIFIER }
> >
> >               PredefinedLogotypeType ::= INTEGER {
> >                   subject-organization-logotype(0),
> >                   issuer-organization-logotype(1)
> >                   CA-network-logotype(2)}
> >                   (subject-organization-logotype|
> >                    issuer-organization-logotype|
> >                     CA-network-logotype,...)
> >
> >
> >         The predefined logotype types are
> >
> >         subject-organization-logotype, if used, SHALL be used to
> >include a logotype of the subject organization. The logotype SHALL be
> >consistent with, and require the presence of, an organization name
> >stored in the organization attribute in the subject field.
> >
> >         issuer-organization-logotype, if used, SHALL be used to
> >include a logotype of the issuer organization. The logotype SHALL be
> >consistent with, and require the presence of, an organization name
> >stored in the organization attribute in the issuer field.
> >
> >         CA-network-logotype, if used, SHALL be used to include a
> >logotype used by a network of CA services, provided by one or several
> >independent CA's, within which the issuer claims to issue this
> >certificate.
> >
> >

Date: Sun, 18 Mar 2001 16:07:44 -0800
From: Eric Murray <[email-masked]>
To: Trevor Freeman <[email-masked]>
Cc: [email-masked]
Subject: Re: Logotypes in certificates

On Sun, Mar 18, 2001 at 10:42:12AM -0800, Trevor Freeman wrote:
> Hi Stefan,
> The fundamental gap here is that most users don't know what a
> certificate is, and are happy that they just get a simple icon if
> everything is ok or not rather than some UI detailing the content of the
> credential. Most users never look as the certificate UI.

Agreed.

I don't think that the logo extension would add that much data to the
cert.  There's already a whole load of junk people can put in certs,
what's another 1-200 bytes?

I am however concerned with how certs with the logo extension
would be issued.

Evil Trent is setting up a site to spoof the Bank of Alice web site.
Since Trent knows that the BofA customers all use the logo extension
to verify that they're really connected to Alice, he spoofs
the logo.  Trent creates a logo which is very similar to the BofA
logo, but with one pixel in the corner different.

When Trent goes to Verisign, do they check the logo before they sign
the cert?  How much do they check it- that it's hash is different from
all the other logos in their database?  If that's the case, Trent's
visually-identical logo is "different" and Trent gets his cert.

Trent puts up his spoof site, redirects traffic to it, and cleans out a
number of accounts.  Eventually Alice will find out that Trent is using a
logo that's too similar to Alice's.  There's already laws for this sort
of thing, so Alice can eventually prevail in the courts and get Trent
to stop using the confusing logo.  Before that happens, Trent moves to
some small country with weak extradition laws.

With DNs this is simple(er)- Verisign just won't sign a cert request
from Trent that says it's from Alice.  Of course "says it's from Alice"
is interpreted different by different CAs and to be 100% correct
you have to know each CA's naming convention.  But generally it's not
possible to get a Subject DN that's close enough to an existing issued
cert to spoof it.

How would this be handled with logos?  There's a body of law for
similarity of logos and trademarks, would that be followed?  Or would
someone at Verisign (or pick any CA) just look at the logos and reject any
that're "too similar".  There's probably also an international law problem
here- what if I get a cert issued with my logo, which is trademarked
in the US, and there's another very similar logo trademarked in the UK
for an entirely unrelated company?  Normally I and the other company
would not be competing in each other's territories, but now with the
net, we are, and our logos clash.  Who figures this out?  This problem
sounds very similar to the domain name situation, which as we all know,
is a bit of a mess.

I think that these issues (and probably more in the same vein)
should be thought through before going ahead with this.

From: Michael Zolotarev <[email-masked]>
To: "'Trevor Freeman'" <[email-masked]>, Ambarish Malpani <[email-masked]>, Stefan Santesson <[email-masked]>, David Cross <[email-masked]>
Cc: [email-masked]
Subject: RE: Logotypes in certificates
Date: Mon, 19 Mar 2001 10:43:25 +1100

Time for a compromise?
Define an OID for a signed(!) logotype and keep it in LDAP together with a
cert. Whoever can retrieve the cert, can fetch the logotype as well. The
content of the cert does not have to be affected.
Leave the rest of exotic cases (i.e. there is no LDAP) to be sorted out on a
one-by-one base, if a real requirement ever shapes up.

M

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Monday, March 19, 2001 9:38 AM
To: Ambarish Malpani; Stefan Santesson; David Cross
Cc: [email-masked]
Subject: RE: Logotypes in certificates

Hi Ambarish,
Well this is software, and anything is possible! However you are now
suggesting that users will benefit from a second icon on there toolbar
in addition to the icon which denotes an SSL protected session. When in
reality users only just about understand what the existing icon means
and don't understand how, and what trusted or not trusted constitutes in
the CA world. 
Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Sunday, March 18, 2001 11:38 AM
To: Trevor Freeman; Stefan Santesson; David Cross; [email-masked]
Subject: RE: Logotypes in certificates

Hi Trevor,
    Isn't it possible that IE/Communicator show the logo next to the
lock symbol when displaying securely downloaded pages? Doesn't require
the user to do something different and let's you associate the site with
a logo that you are familiar with.

Might help with the kinds of attacks where people try to send you to
paypai.com rather than paypal.com

Regards,
Ambarish

> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Sunday, March 18, 2001 10:42 AM
> To: Stefan Santesson; David Cross; [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> Hi Stefan,
> The fundamental gap here is that most users don't know what a 
> certificate is, and are happy that they just get a simple icon if 
> everything is ok or not rather than some UI detailing the content of 
> the credential. Most users never look as the certificate UI.
> Trevor
> 
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Saturday, March 17, 2001 4:14 PM
> To: David Cross; [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> David,
> 
> Comment in line;
> 
> At 18:46 2001-03-16 -0800, David Cross wrote:
> >Stefan:
> >
> >Some comments -
> >
> >First:  I do not think that this should be considered for son of
> >RFC2459
> >- we do not want to hold this up to consider this proposal.
> 
> That's OK with me.
> 
> >
> >Second:  I do not see how applications will make use of this
> >information.  How do you see it being used?
> 
> Well first I would like to state that I now of several
> applications that
> 
> would use this information if it was available. This is typically any
> application which includes a function to display a certificates to a
> human 
> user. These applications will seek to have a display format 
> which makes 
> sense to the user. These applications can, if logotype data 
> is present, 
> choose to download these logotypes and display them to the 
> user when a 
> certificate is displayed.
> 
> Applications don't caring about logos won't be effected since
> they just 
> ignore this information without problem. The logo is only a display 
> function and has no part in any DN or alternative name.
> 
> We will surely implement this in certificates if this gets to be 
> supported by any standard.
> 
> /Stefan
> 
> >
> >Third:  People are complaining about size of certs now, this will
> >expand that issue
> 
> Everything is a tradeoff. In this case we can meet an
> important business
> 
> need with just a few bytes. I think this is one of those cases that
> definitely is worth it.
> 
> /Stefan
> 
> >
> >
> >David B. Cross
> >
> >
> >         From: Stefan Santesson [mailto:[email-masked]]
> >         Sent: Thursday, March 15, 2001 3:22 PM
> >         To: [email-masked]
> >         Subject: Logotypes in certificates
> >
> >
> >         In last PKIX meeting in San Diego I presented some
> thoughts on
> 
> >creating a new extension for inclusion of logotype information in
> >certificates.
> >
> >         Last in this mail I include a primary suggested outline for
> >such extension.
> >
> >         But first a short summary of the rationale:
> >
> >         At a first glance it may seem irrelevant to include
> logotype
> >information in certificates and a natural first reaction is
> "OH NO...
> >NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> >
> >         The fact is though that at the ETSI meeting this
> week (In the
> >group that handles European standards related to electronic
> >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE 
> >DATA WOULD BE VERY USEFUL.
> >
> >         Why is that so?
> >
> >         The answer is that logotypes are carriers of trust and are
> >widely recognized tools for trust recognition. Have you ever thought 
> >why EVERY physical instrument of trust, from loyalty cards, credit 
> >cards to Passports, contain trust symbols in the form of logotypes.
> >
> >         Are certificates different? ABSOLUTELY NOT!!
> >
> >         If PKI is to take off in the private market, the
> certificates
> >must be user friendly and carry the same functionality (in electronic
> >form) as ID-cards, passports and other physical ID:s do in physical
> >form. And logotypes are a FUNDAMENTAL part of that.
> >
> >         Without logotypes, certificates can only be handled and
> >presented as textual information for technically oriented 
> users. This
> >is the reality I see.
> >
> >         What is your observation?
> >
> >         How can we then do this?
> >
> >         Technically speaking, we don't have to include the actual
> >logotype image and we don't have to destroy legacy applications.
> >         I would suggest that we use the same mechanism that we 
> >specified for biometric data in RFC 3039 where a 
> non-critical extension
> 
> >can include for each logotype:
> >
> >         -  type of logo
> >         -  type of hash algorithm
> >         -  hash of logotype data
> >         -  URI to location of data
> >
> >         This will only take a few bytes but will allow new
> >applications to import relevant logotypes, signed by the 
> issuer of the
> >certificate, to be displayed to the user.
> >
> >         So... What to do with this?
> >
> >         If this is to be proceeded at all, It could be part
> of son of
> >RFC 2459, it could be part of a new RFC 3039 and it could be a new
> >draft or merged with some other work. I'm open for suggestions.
> >
> >         I hope to be able to meet with many of you and
> discuss this in
> 
> >Minneapolis next week.
> >
> >         /Stefan Santesson
> >
> >
> >         logotypeInfo  EXTENSION ::= {
> >                   SYNTAX             LogotypeSyntax
> >                   IDENTIFIED BY      id-pe-logotypeInfo }
> >
> >               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> >
> >               LogotypeSyntax ::= SEQUENCE OF LogotypeData
> >
> >               LogotypeData ::= SEQUENCE {
> >                   typeOfLogotype       TypeOflogotype,
> >                   hashAlgorithm        AlgorithmIdentifier,
> >                   logotypeDataHash     OCTET STRING,
> >                   sourceDataUri        IA5String OPTIONAL }
> >
> >               TypeOflogotype ::= CHOICE {
> >                   predefinedLogotypeType    PredefinedLogotypeType,
> >                   LogotypeTypeID            OBJECT IDENTIFIER }
> >
> >               PredefinedLogotypeType ::= INTEGER {
> >                   subject-organization-logotype(0),
> >                   issuer-organization-logotype(1)
> >                   CA-network-logotype(2)}
> >                   (subject-organization-logotype|
> >                    issuer-organization-logotype|
> >                     CA-network-logotype,...)
> >
> >
> >         The predefined logotype types are
> >
> >         subject-organization-logotype, if used, SHALL be used to
> >include a logotype of the subject organization. The logotype 
> SHALL be
> >consistent with, and require the presence of, an organization name
> >stored in the organization attribute in the subject field.
> >
> >         issuer-organization-logotype, if used, SHALL be used to
> >include a logotype of the issuer organization. The logotype SHALL be 
> >consistent with, and require the presence of, an organization name 
> >stored in the organization attribute in the issuer field.
> >
> >         CA-network-logotype, if used, SHALL be used to include a
> >logotype used by a network of CA services, provided by one 
> or several
> >independent CA's, within which the issuer claims to issue this
> >certificate.
> >
> >
> 

This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

content-class: urn:content-classes:message
Subject: RE: Logotypes in certificates
Date: Sun, 18 Mar 2001 14:38:02 -0800
From: "Trevor Freeman" <[email-masked]>
To: "Ambarish Malpani" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "David Cross" <[email-masked]>
Cc: <[email-masked]>

Hi Ambarish,
Well this is software, and anything is possible! However you are now
suggesting that users will benefit from a second icon on there toolbar
in addition to the icon which denotes an SSL protected session. When in
reality users only just about understand what the existing icon means
and don't understand how, and what trusted or not trusted constitutes in
the CA world. 
Trevor

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Sunday, March 18, 2001 11:38 AM
To: Trevor Freeman; Stefan Santesson; David Cross; [email-masked]
Subject: RE: Logotypes in certificates

Hi Trevor,
    Isn't it possible that IE/Communicator show the logo next to the
lock symbol when displaying securely downloaded pages? Doesn't require
the user to do something different and let's you associate the site with
a logo that you are familiar with.

Might help with the kinds of attacks where people try to send you to
paypai.com rather than paypal.com

Regards,
Ambarish

> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Sunday, March 18, 2001 10:42 AM
> To: Stefan Santesson; David Cross; [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> Hi Stefan,
> The fundamental gap here is that most users don't know what a 
> certificate is, and are happy that they just get a simple icon if 
> everything is ok or not rather than some UI detailing the content of 
> the credential. Most users never look as the certificate UI.
> Trevor
> 
> From: Stefan Santesson [mailto:[email-masked]]
> Sent: Saturday, March 17, 2001 4:14 PM
> To: David Cross; [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> David,
> 
> Comment in line;
> 
> At 18:46 2001-03-16 -0800, David Cross wrote:
> >Stefan:
> >
> >Some comments -
> >
> >First:  I do not think that this should be considered for son of
> >RFC2459
> >- we do not want to hold this up to consider this proposal.
> 
> That's OK with me.
> 
> >
> >Second:  I do not see how applications will make use of this
> >information.  How do you see it being used?
> 
> Well first I would like to state that I now of several
> applications that
> 
> would use this information if it was available. This is typically any
> application which includes a function to display a certificates to a
> human 
> user. These applications will seek to have a display format 
> which makes 
> sense to the user. These applications can, if logotype data 
> is present, 
> choose to download these logotypes and display them to the 
> user when a 
> certificate is displayed.
> 
> Applications don't caring about logos won't be effected since
> they just 
> ignore this information without problem. The logo is only a display 
> function and has no part in any DN or alternative name.
> 
> We will surely implement this in certificates if this gets to be 
> supported by any standard.
> 
> /Stefan
> 
> >
> >Third:  People are complaining about size of certs now, this will
> >expand that issue
> 
> Everything is a tradeoff. In this case we can meet an
> important business
> 
> need with just a few bytes. I think this is one of those cases that
> definitely is worth it.
> 
> /Stefan
> 
> >
> >
> >David B. Cross
> >
> >
> >         From: Stefan Santesson [mailto:[email-masked]]
> >         Sent: Thursday, March 15, 2001 3:22 PM
> >         To: [email-masked]
> >         Subject: Logotypes in certificates
> >
> >
> >         In last PKIX meeting in San Diego I presented some
> thoughts on
> 
> >creating a new extension for inclusion of logotype information in
> >certificates.
> >
> >         Last in this mail I include a primary suggested outline for
> >such extension.
> >
> >         But first a short summary of the rationale:
> >
> >         At a first glance it may seem irrelevant to include
> logotype
> >information in certificates and a natural first reaction is
> "OH NO...
> >NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> >
> >         The fact is though that at the ETSI meeting this
> week (In the
> >group that handles European standards related to electronic
> >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE 
> >DATA WOULD BE VERY USEFUL.
> >
> >         Why is that so?
> >
> >         The answer is that logotypes are carriers of trust and are
> >widely recognized tools for trust recognition. Have you ever thought 
> >why EVERY physical instrument of trust, from loyalty cards, credit 
> >cards to Passports, contain trust symbols in the form of logotypes.
> >
> >         Are certificates different? ABSOLUTELY NOT!!
> >
> >         If PKI is to take off in the private market, the
> certificates
> >must be user friendly and carry the same functionality (in electronic
> >form) as ID-cards, passports and other physical ID:s do in physical
> >form. And logotypes are a FUNDAMENTAL part of that.
> >
> >         Without logotypes, certificates can only be handled and
> >presented as textual information for technically oriented 
> users. This
> >is the reality I see.
> >
> >         What is your observation?
> >
> >         How can we then do this?
> >
> >         Technically speaking, we don't have to include the actual
> >logotype image and we don't have to destroy legacy applications.
> >         I would suggest that we use the same mechanism that we 
> >specified for biometric data in RFC 3039 where a 
> non-critical extension
> 
> >can include for each logotype:
> >
> >         -  type of logo
> >         -  type of hash algorithm
> >         -  hash of logotype data
> >         -  URI to location of data
> >
> >         This will only take a few bytes but will allow new
> >applications to import relevant logotypes, signed by the 
> issuer of the
> >certificate, to be displayed to the user.
> >
> >         So... What to do with this?
> >
> >         If this is to be proceeded at all, It could be part
> of son of
> >RFC 2459, it could be part of a new RFC 3039 and it could be a new
> >draft or merged with some other work. I'm open for suggestions.
> >
> >         I hope to be able to meet with many of you and
> discuss this in
> 
> >Minneapolis next week.
> >
> >         /Stefan Santesson
> >
> >
> >         logotypeInfo  EXTENSION ::= {
> >                   SYNTAX             LogotypeSyntax
> >                   IDENTIFIED BY      id-pe-logotypeInfo }
> >
> >               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> >
> >               LogotypeSyntax ::= SEQUENCE OF LogotypeData
> >
> >               LogotypeData ::= SEQUENCE {
> >                   typeOfLogotype       TypeOflogotype,
> >                   hashAlgorithm        AlgorithmIdentifier,
> >                   logotypeDataHash     OCTET STRING,
> >                   sourceDataUri        IA5String OPTIONAL }
> >
> >               TypeOflogotype ::= CHOICE {
> >                   predefinedLogotypeType    PredefinedLogotypeType,
> >                   LogotypeTypeID            OBJECT IDENTIFIER }
> >
> >               PredefinedLogotypeType ::= INTEGER {
> >                   subject-organization-logotype(0),
> >                   issuer-organization-logotype(1)
> >                   CA-network-logotype(2)}
> >                   (subject-organization-logotype|
> >                    issuer-organization-logotype|
> >                     CA-network-logotype,...)
> >
> >
> >         The predefined logotype types are
> >
> >         subject-organization-logotype, if used, SHALL be used to
> >include a logotype of the subject organization. The logotype 
> SHALL be
> >consistent with, and require the presence of, an organization name
> >stored in the organization attribute in the subject field.
> >
> >         issuer-organization-logotype, if used, SHALL be used to
> >include a logotype of the issuer organization. The logotype SHALL be 
> >consistent with, and require the presence of, an organization name 
> >stored in the organization attribute in the issuer field.
> >
> >         CA-network-logotype, if used, SHALL be used to include a
> >logotype used by a network of CA services, provided by one 
> or several
> >independent CA's, within which the issuer claims to issue this
> >certificate.
> >
> >
> 

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "IETF-PKIX \(E-mail\)" <[email-masked]>
Subject: Updates to CMC draft.
Date: Sun, 18 Mar 2001 16:26:42 -0600
Importance: Normal

I have released a new CMC draft to the mailing list. This message details
the main changes in the draft from the RFC.

1.  A new success/failure status structure has been defined to allow for
secondary protocols to add new failure codes.  This was found
necessary/desirable when creating the Symmetric Key Distribution draft in
the S/MIME working group.

2.  A number of typos, edits and some unclear language was updated based on
the mail messages that I have received.

jim

From: "Michael Myers" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Matching CertIDs between OCSP requests and responses
Date: Thu, 15 Mar 2001 15:45:54 -0800
Importance: Normal
Status: O
To: [email-masked]

Jonathan,

Apologies for not getting back sooner.  I see things have been busy.
Anyway, an RFC 2560 server is compliant even if it behaves in the manner you
describe.  There are no normative requirements in RFC 2560 to the contrary.
However, I'm of the opinion that a robust client should be capable of
handling this potential error condition.  This condition, along with several
other processing considerations that contribute to interoperability, could
be better addressed.  We will be working on these issues in the v2 context
over the next few months.  Perhaps you would care to join us in that,
particularly from the thin client perspective.  In any case, thanks for the
catch.  Hope this helps.

Mike

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 8:40 AM
> To: Michael Myers
> Cc: [email-masked]
> Subject: RE: Matching CertIDs between OCSP requests and responses
>
>
>
> Mike,
>
> Thanks for the reply.  I think my use of the phrase 'server error' was
> perhaps misleading:  what I mean is, has the server behaved in a
> non-compliant manner if a certificate from the request is missing from the
> response (or, for that matter, if the response contains
> information about a
> certificate not present in the request).  That is, is doing so an improper
> response?
>
> The idea of non-global errors is interesting, I hadn't thought about that.
> It might be useful where multiple certificates are present in the request.
> The most likely case I can think of is where the OCSP server is acting in
> request-forwarding mode, splitting a request and farming it out to several
> other servers, which in turn may return differing error states.  It would
> be a pity to simply throw out the valid information and return an error
> just because one of the second-level servers did.
>
> Regards,
>
> Jonathan
>
>
>
>
>
>                     "Michael
>
>                     Myers"               To:
> <[email-masked]>,
>                     <myers@coasts        <[email-masked]>
>
>                     ide.net>             cc:
>
>                                          Subject:     RE:
> Matching CertIDs between OCSP
>                     14/03/01             requests and responses
>
>                     16:38
>
>
>
>
>
>
>
>
>
> Jonathan,
>
> You are correct in your assumptions.  One point of clarification however.
>
> Server errors appear in the mandatory responseStatus field of OCSPResponse
> and not the optional responseBytes field in order to ensure that a server
> will produce *some* type of feedback in the event of an error.
>
> OCSPResponse ::= SEQUENCE {
>     responseStatus     OCSPResponseStatus,
>     responseBytes      [0]  EXPLICIT ResponseBytes OPTIONAL }
>
> Given that, such errors speak to the server's response as a whole and not
> to
> individual certificates in the instance when multiple certificates are
> identified in a single request and corresponding response (the latter via
> SingleResponse syntax).
>
> In other words, we assumed that the type of server problems enumerated in
> OCSPResponseStatus would be global with respect a request regardless of
> whether or not that request addressed a single certificate or multiple
> certificates.
>
> In the context of the v2 work, I'd be very interested to hear if your
> implementation experience leads to a need for error states at the
> SingleResponse level.
>
> Your point regarding certificate identification matching in the v2 case is
> well noted.
>
> Mike
>
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, March 14, 2001 4:25 AM
> > To: [email-masked]
> > Subject: Matching CertIDs between OCSP requests and responses
> >
> >
> > All,
> >
> > Another OCSP (v1) question:  Can a client assume that the OCSP response
> > CertID terms will precisely match those from the request?  That is, can
> it
> > assume
> > 1 - that every certificate in the request will be in the response (i.e.
> > it's a server error otherwise)
> > 2 - that the hashing algorithm in the response CertIDs will be the same
> as
> > that which was used in the request (that is, the CertID data will match
> > byte-for-byte between request and response).
> >
> > I guess given the variety of identifiers available alongside
> > CertID in OCSP
> > v2 that the issue of matching identifiers between request and response
> > raised in point 2 above will be even more critical there.  But
> that's for
> > other people to worry about - it's v1 I'm interested in for now.
> >
> > Thanks,
> >
> > Jonathan
> > ----------------
> > Dr Jonathan Tuliani
> > www.symbian.com
> >
> >
> >
> > Symbian Ltd is a company registered in England and Wales with
> > registered number 01796587 and registered office at 19 Harcourt
> > Street, London, W1H 4HF, UK.
> > This message is intended only for use by the named addressee and
> > may contain privileged and/or confidential information. If you
> > are not the named addressee you should not disseminate, copy or
> > take any action in reliance on it. If you have received this
> > message in error please notify [email-masked] and delete
> > the message and any attachments accompanying it immediately.
> > Symbian does not accept liability for any corruption,
> > interception, amendment, tampering or viruses occuring to this
> > message in transit or for any message sent by its employees which
> > is not in compliance with Symbian corporate policy.

From: [email-masked]
Subject: RE: Matching CertIDs between OCSP requests and responses
Cc: [email-masked], [email-masked]
Date: Thu, 15 Mar 2001 16:55:32 +0000
Status: O
To: [email-masked]

I think that the ability to specify multiple certificates is useful, in
particular for validating a non-trivial certificate chain.  In this case,
it makes sense to trust the chain only as much as the least trusted
certificate in the chain.

However, the delegated OCSP signing model isn't ideally suited to
certificate chains - you have to use the trusted authority OCSP signing
model instead.  This subject has been discussed on this list previously.

Jonathan
----------------
Dr Jonathan Tuliani
www.symbian.com

                    [email-masked]                                                            
                    land.ac.nz             To:     [email-masked]                           
                    (Peter Gutmann)        cc:                                                 
                    Sent by:               Subject:     RE: Matching CertIDs between OCSP      
                    [email-masked]        requests and responses                              
                    land.ac.nz                                                                 

                    16/03/01 05:20                                                             
                    Please respond                                                             
                    to pgut001                                                                 

[email-masked]

>The idea of non-global errors is interesting, I hadn't thought about that.
It
>might be useful where multiple certificates are present in the request.

Is anyone (apart from Identrus, who do it for political/economic rather
than
technical reasons) doing this to any extent?  There is anecdotal evidence
which
suggests that implementors are using only one cert per query, having
multiple
certs per query is hideous in terms of handling responses (let's see now,
this
one is OK, this one isn't, we don't know about this one... no, the third
one,
not the second one... no that one's OK, you want the one next to it... etc
etc).  Although my code supports the ability to query multiple certs at
once, I
haven't enabled it because handling mixed responses is just too messy, it's
much, *much* easier to work with if you do it on the basis of "Is this cert
revoked or not?" rather than "Tell me whatever you can about this bundle of
stuff, and I'll try and figure out what's what from your response".

Peter.

From: [email-masked]
Subject: Re: Matching CertIDs between OCSP requests and responses
Cc: [email-masked], [email-masked]
Date: Thu, 15 Mar 2001 16:48:25 +0000
Status: O
To: [email-masked]

What I'm getting at is a slightly different issue with OCSP v2.  This has
several means for the request and response to identify the certificate:

ReqCert  ::= CHOICE {
   certID            CertID,
   issuerSerial      [0] IssuerandSerialNumber,
   pKCert            [1] Certificate,
   name              [2] GeneralName,
   certHash          [3] OCTET STRING}

However, there doesn't seem to be any condition requiring the response to
use the same method as was used in the request.  The request could use an
IssuerAndSerialNumber, and the response could then identify the same
certificate using CertID.  Should the response be forced to use the same
technique as the request?  How does this affect response pre-computation?

Jonathan

                    [email-masked]                                                            
                    land.ac.nz             To:     [email-masked]                
                    (Peter Gutmann)        cc:     [email-masked]                           
                    Sent by:               Subject:     Re: Matching CertIDs between OCSP      
                    [email-masked]        requests and responses                              
                    land.ac.nz                                                                 

                    16/03/01 05:31                                                             
                    Please respond                                                             
                    to pgut001                                                                 

[email-masked] writes:

>Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it
doesn't
>say that they MUST use it.  Suppose I send a request, in which my CertID
has
>used SHA1.  Suppose the responder then replies, but uses MD5 to form the
>CertID term corresponding to the same certificate.  Then the matching of
the
>CertID term between request and response becomes less trivial than a
simple
>binary comparison.

Anecdotal evidence (that chap again) suggests that everyone uses SHA1
exclusively.  Have you tried submitting a request hashed with MD5 to see
how
many servers you can break?

>As mentioned earlier, the complexity of matching certificate identifiers
>between request and response increases in v2, where there are so many
other
>ways to identify a certificate.

Yes, but they're all unique (there's only one way to encode an
issuerAndSerialNumber, certificate, etc), a binary compare should do for
this.

I'll do a bit of experimenting next week, but I'd be very surprised if a
binary
compare failed for any responder.

Peter.

From: [email-masked] (Peter Gutmann)
Subject: Re:  Matching CertIDs between OCSP requests and responses
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 16 Mar 2001 05:07:11 (NZDT)
Status: O
To: [email-masked]

[email-masked] writes:

>Another OCSP (v1) question:  Can a client assume that the OCSP response CertID
>terms will precisely match those from the request?  

I would hope they do, otherwise there's a trivial attack which completely
defeats OCSP:

- You submit a request for a check of cert X (which has been revoked)
- What arrives at the CA is a request for a check of cert Y (which hasn't)
- You get back a response of "OK"

Unless you check the returned ID data there's no way you can detect this.  What
I'm doing is a binary compare of request and response ID data, if they differ I
don't trust the response.

(There's a second, slightly less trivial attack which you can perform if nonces
 aren't used, once I can determine experimentally how well-supported these are
 in practice (the "no critical extensions" requirement in the spec doesn't help
 much with this) I'll see if I can make them mandatory in my code).

Peter.

From: [email-masked]
Subject: Re: Matching CertIDs between OCSP requests and responses
Cc: [email-masked], [email-masked]
Date: Thu, 15 Mar 2001 16:15:13 +0000
Status: O
To: [email-masked]

Peter, all,

Yes, clearly clients must match certificate identifiers between request and
response.  However, the problem I was trying to highlight was just how this
matching should be performed.

Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it
doesn't say that they MUST use it.  Suppose I send a request, in which my
CertID has used SHA1.  Suppose the responder then replies, but uses MD5 to
form the CertID term corresponding to the same certificate.  Then the
matching of the CertID term between request and response becomes less
trivial than a simple binary comparison.

As mentioned earlier, the complexity of matching certificate identifiers
between request and response increases in v2, where there are so many other
ways to identify a certificate.

The question is: can we trust the responder to use the same form of
certificate identifier as the client specified, so that the trivial binary
comparison of certificate identifier in the client is valid?

This problem is particularly acute in the situation where the responses are
pre-computed rather than being formatted on receipt of the request.

Regards,

Jonathan
---------------
Dr Jonathan Tuliani
www.symbian.com

                    [email-masked]                                                            
                    land.ac.nz             To:     [email-masked]                
                    (Peter Gutmann)        cc:     [email-masked]                           
                    Sent by:               Subject:     Re: Matching CertIDs between OCSP      
                    [email-masked]        requests and responses                              
                    land.ac.nz                                                                 

                    16/03/01 05:07                                                             
                    Please respond                                                             
                    to pgut001                                                                 

[email-masked] writes:

>Another OCSP (v1) question:  Can a client assume that the OCSP response
CertID
>terms will precisely match those from the request?

I would hope they do, otherwise there's a trivial attack which completely
defeats OCSP:

- You submit a request for a check of cert X (which has been revoked)
- What arrives at the CA is a request for a check of cert Y (which hasn't)
- You get back a response of "OK"

Unless you check the returned ID data there's no way you can detect this.
What
I'm doing is a binary compare of request and response ID data, if they
differ I
don't trust the response.

(There's a second, slightly less trivial attack which you can perform if
nonces
 aren't used, once I can determine experimentally how well-supported these
are
 in practice (the "no critical extensions" requirement in the spec doesn't
help
 much with this) I'll see if I can make them mandatory in my code).

Peter.

From: [email-masked] (Peter Gutmann)
Subject: Re: Matching CertIDs between OCSP requests and responses
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 16 Mar 2001 05:31:04 (NZDT)
Status: O
To: [email-masked]

[email-masked] writes:

>Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it doesn't
>say that they MUST use it.  Suppose I send a request, in which my CertID has
>used SHA1.  Suppose the responder then replies, but uses MD5 to form the
>CertID term corresponding to the same certificate.  Then the matching of the
>CertID term between request and response becomes less trivial than a simple
>binary comparison.

Anecdotal evidence (that chap again) suggests that everyone uses SHA1
exclusively.  Have you tried submitting a request hashed with MD5 to see how
many servers you can break?

>As mentioned earlier, the complexity of matching certificate identifiers
>between request and response increases in v2, where there are so many other
>ways to identify a certificate.

Yes, but they're all unique (there's only one way to encode an
issuerAndSerialNumber, certificate, etc), a binary compare should do for this.

I'll do a bit of experimenting next week, but I'd be very surprised if a binary
compare failed for any responder.

Peter.

Content-return: allowed
Date: Sun, 18 Mar 2001 11:37:41 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Logotypes in certificates
To: "'Trevor Freeman'" <[email-masked]>, Stefan Santesson <[email-masked]>, David Cross <[email-masked]>, [email-masked]

Hi Trevor,
    Isn't it possible that IE/Communicator show the logo next to
the lock symbol when displaying securely downloaded pages? Doesn't
require the user to do something different and let's you associate
the site with a logo that you are familiar with.

Might help with the kinds of attacks where people try to send
you to paypai.com rather than paypal.com

Regards,
Ambarish

> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Sunday, March 18, 2001 10:42 AM
> To: Stefan Santesson; David Cross; [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> Hi Stefan,
> The fundamental gap here is that most users don't know what a
> certificate is, and are happy that they just get a simple icon if
> everything is ok or not rather than some UI detailing the 
> content of the
> credential. Most users never look as the certificate UI.
> Trevor
> 
> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Saturday, March 17, 2001 4:14 PM
> To: David Cross; [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> David,
> 
> Comment in line;
> 
> At 18:46 2001-03-16 -0800, David Cross wrote:
> >Stefan:
> >
> >Some comments -
> >
> >First:  I do not think that this should be considered for son of 
> >RFC2459
> >- we do not want to hold this up to consider this proposal.
> 
> That's OK with me.
> 
> >
> >Second:  I do not see how applications will make use of this 
> >information.  How do you see it being used?
> 
> Well first I would like to state that I now of several 
> applications that
> 
> would use this information if it was available. This is typically any 
> application which includes a function to display a certificates to a
> human 
> user. These applications will seek to have a display format 
> which makes 
> sense to the user. These applications can, if logotype data 
> is present, 
> choose to download these logotypes and display them to the 
> user when a 
> certificate is displayed.
> 
> Applications don't caring about logos won't be effected since 
> they just 
> ignore this information without problem. The logo is only a display 
> function and has no part in any DN or alternative name.
> 
> We will surely implement this in certificates if this gets to be
> supported 
> by any standard.
> 
> /Stefan
> 
> >
> >Third:  People are complaining about size of certs now, this will 
> >expand that issue
> 
> Everything is a tradeoff. In this case we can meet an 
> important business
> 
> need with just a few bytes. I think this is one of those cases that 
> definitely is worth it.
> 
> /Stefan
> 
> >
> >
> >David B. Cross
> >
> >
> >         From: Stefan Santesson [mailto:[email-masked]]
> >         Sent: Thursday, March 15, 2001 3:22 PM
> >         To: [email-masked]
> >         Subject: Logotypes in certificates
> >
> >
> >         In last PKIX meeting in San Diego I presented some 
> thoughts on
> 
> >creating a new extension for inclusion of logotype information in 
> >certificates.
> >
> >         Last in this mail I include a primary suggested outline for 
> >such extension.
> >
> >         But first a short summary of the rationale:
> >
> >         At a first glance it may seem irrelevant to include 
> logotype 
> >information in certificates and a natural first reaction is 
> "OH NO... 
> >NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> >
> >         The fact is though that at the ETSI meeting this 
> week (In the 
> >group that handles European standards related to electronic 
> >signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE 
> >DATA WOULD BE VERY USEFUL.
> >
> >         Why is that so?
> >
> >         The answer is that logotypes are carriers of trust and are 
> >widely recognized tools for trust recognition. Have you ever thought 
> >why EVERY physical instrument of trust, from loyalty cards, credit 
> >cards to Passports, contain trust symbols in the form of logotypes.
> >
> >         Are certificates different? ABSOLUTELY NOT!!
> >
> >         If PKI is to take off in the private market, the 
> certificates 
> >must be user friendly and carry the same functionality (in electronic
> >form) as ID-cards, passports and other physical ID:s do in physical 
> >form. And logotypes are a FUNDAMENTAL part of that.
> >
> >         Without logotypes, certificates can only be handled and 
> >presented as textual information for technically oriented 
> users. This 
> >is the reality I see.
> >
> >         What is your observation?
> >
> >         How can we then do this?
> >
> >         Technically speaking, we don't have to include the actual 
> >logotype image and we don't have to destroy legacy applications.
> >         I would suggest that we use the same mechanism that we 
> >specified for biometric data in RFC 3039 where a 
> non-critical extension
> 
> >can include for each logotype:
> >
> >         -  type of logo
> >         -  type of hash algorithm
> >         -  hash of logotype data
> >         -  URI to location of data
> >
> >         This will only take a few bytes but will allow new 
> >applications to import relevant logotypes, signed by the 
> issuer of the 
> >certificate, to be displayed to the user.
> >
> >         So... What to do with this?
> >
> >         If this is to be proceeded at all, It could be part 
> of son of 
> >RFC 2459, it could be part of a new RFC 3039 and it could be a new 
> >draft or merged with some other work. I'm open for suggestions.
> >
> >         I hope to be able to meet with many of you and 
> discuss this in
> 
> >Minneapolis next week.
> >
> >         /Stefan Santesson
> >
> >
> >         logotypeInfo  EXTENSION ::= {
> >                   SYNTAX             LogotypeSyntax
> >                   IDENTIFIED BY      id-pe-logotypeInfo }
> >
> >               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> >
> >               LogotypeSyntax ::= SEQUENCE OF LogotypeData
> >
> >               LogotypeData ::= SEQUENCE {
> >                   typeOfLogotype       TypeOflogotype,
> >                   hashAlgorithm        AlgorithmIdentifier,
> >                   logotypeDataHash     OCTET STRING,
> >                   sourceDataUri        IA5String OPTIONAL }
> >
> >               TypeOflogotype ::= CHOICE {
> >                   predefinedLogotypeType    PredefinedLogotypeType,
> >                   LogotypeTypeID            OBJECT IDENTIFIER }
> >
> >               PredefinedLogotypeType ::= INTEGER {
> >                   subject-organization-logotype(0),
> >                   issuer-organization-logotype(1)
> >                   CA-network-logotype(2)}
> >                   (subject-organization-logotype|
> >                    issuer-organization-logotype|
> >                     CA-network-logotype,...)
> >
> >
> >         The predefined logotype types are
> >
> >         subject-organization-logotype, if used, SHALL be used to 
> >include a logotype of the subject organization. The logotype 
> SHALL be 
> >consistent with, and require the presence of, an organization name 
> >stored in the organization attribute in the subject field.
> >
> >         issuer-organization-logotype, if used, SHALL be used to 
> >include a logotype of the issuer organization. The logotype SHALL be 
> >consistent with, and require the presence of, an organization name 
> >stored in the organization attribute in the issuer field.
> >
> >         CA-network-logotype, if used, SHALL be used to include a 
> >logotype used by a network of CA services, provided by one 
> or several 
> >independent CA's, within which the issuer claims to issue this 
> >certificate.
> >
> >
> 

content-class: urn:content-classes:message
Subject: RE: Logotypes in certificates
Date: Sun, 18 Mar 2001 10:42:12 -0800
From: "Trevor Freeman" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "David Cross" <[email-masked]>, <[email-masked]>

Hi Stefan,
The fundamental gap here is that most users don't know what a
certificate is, and are happy that they just get a simple icon if
everything is ok or not rather than some UI detailing the content of the
credential. Most users never look as the certificate UI.
Trevor

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Saturday, March 17, 2001 4:14 PM
To: David Cross; [email-masked]
Subject: RE: Logotypes in certificates

David,

Comment in line;

At 18:46 2001-03-16 -0800, David Cross wrote:
>Stefan:
>
>Some comments -
>
>First:  I do not think that this should be considered for son of 
>RFC2459
>- we do not want to hold this up to consider this proposal.

That's OK with me.

>
>Second:  I do not see how applications will make use of this 
>information.  How do you see it being used?

Well first I would like to state that I now of several applications that

would use this information if it was available. This is typically any 
application which includes a function to display a certificates to a
human 
user. These applications will seek to have a display format which makes 
sense to the user. These applications can, if logotype data is present, 
choose to download these logotypes and display them to the user when a 
certificate is displayed.

Applications don't caring about logos won't be effected since they just 
ignore this information without problem. The logo is only a display 
function and has no part in any DN or alternative name.

We will surely implement this in certificates if this gets to be
supported 
by any standard.

/Stefan

>
>Third:  People are complaining about size of certs now, this will 
>expand that issue

Everything is a tradeoff. In this case we can meet an important business

need with just a few bytes. I think this is one of those cases that 
definitely is worth it.

/Stefan

>David B. Cross
>         From: Stefan Santesson [mailto:[email-masked]]
>         Sent: Thursday, March 15, 2001 3:22 PM
>         To: [email-masked]
>         Subject: Logotypes in certificates
>
>
>         In last PKIX meeting in San Diego I presented some thoughts on

>creating a new extension for inclusion of logotype information in 
>certificates.
>
>         Last in this mail I include a primary suggested outline for 
>such extension.
>
>         But first a short summary of the rationale:
>
>         At a first glance it may seem irrelevant to include logotype 
>information in certificates and a natural first reaction is "OH NO... 
>NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
>
>         The fact is though that at the ETSI meeting this week (In the 
>group that handles European standards related to electronic 
>signatures). IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE 
>DATA WOULD BE VERY USEFUL.
>
>         Why is that so?
>
>         The answer is that logotypes are carriers of trust and are 
>widely recognized tools for trust recognition. Have you ever thought 
>why EVERY physical instrument of trust, from loyalty cards, credit 
>cards to Passports, contain trust symbols in the form of logotypes.
>
>         Are certificates different? ABSOLUTELY NOT!!
>
>         If PKI is to take off in the private market, the certificates 
>must be user friendly and carry the same functionality (in electronic
>form) as ID-cards, passports and other physical ID:s do in physical 
>form. And logotypes are a FUNDAMENTAL part of that.
>
>         Without logotypes, certificates can only be handled and 
>presented as textual information for technically oriented users. This 
>is the reality I see.
>
>         What is your observation?
>
>         How can we then do this?
>
>         Technically speaking, we don't have to include the actual 
>logotype image and we don't have to destroy legacy applications.
>         I would suggest that we use the same mechanism that we 
>specified for biometric data in RFC 3039 where a non-critical extension

>can include for each logotype:
>
>         -  type of logo
>         -  type of hash algorithm
>         -  hash of logotype data
>         -  URI to location of data
>
>         This will only take a few bytes but will allow new 
>applications to import relevant logotypes, signed by the issuer of the 
>certificate, to be displayed to the user.
>
>         So... What to do with this?
>
>         If this is to be proceeded at all, It could be part of son of 
>RFC 2459, it could be part of a new RFC 3039 and it could be a new 
>draft or merged with some other work. I'm open for suggestions.
>
>         I hope to be able to meet with many of you and discuss this in

>Minneapolis next week.
>
>         /Stefan Santesson
>
>
>         logotypeInfo  EXTENSION ::= {
>                   SYNTAX             LogotypeSyntax
>                   IDENTIFIED BY      id-pe-logotypeInfo }
>
>               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
>
>               LogotypeSyntax ::= SEQUENCE OF LogotypeData
>
>               LogotypeData ::= SEQUENCE {
>                   typeOfLogotype       TypeOflogotype,
>                   hashAlgorithm        AlgorithmIdentifier,
>                   logotypeDataHash     OCTET STRING,
>                   sourceDataUri        IA5String OPTIONAL }
>
>               TypeOflogotype ::= CHOICE {
>                   predefinedLogotypeType    PredefinedLogotypeType,
>                   LogotypeTypeID            OBJECT IDENTIFIER }
>
>               PredefinedLogotypeType ::= INTEGER {
>                   subject-organization-logotype(0),
>                   issuer-organization-logotype(1)
>                   CA-network-logotype(2)}
>                   (subject-organization-logotype|
>                    issuer-organization-logotype|
>                     CA-network-logotype,...)
>
>
>         The predefined logotype types are
>
>         subject-organization-logotype, if used, SHALL be used to 
>include a logotype of the subject organization. The logotype SHALL be 
>consistent with, and require the presence of, an organization name 
>stored in the organization attribute in the subject field.
>
>         issuer-organization-logotype, if used, SHALL be used to 
>include a logotype of the issuer organization. The logotype SHALL be 
>consistent with, and require the presence of, an organization name 
>stored in the organization attribute in the issuer field.
>
>         CA-network-logotype, if used, SHALL be used to include a 
>logotype used by a network of CA services, provided by one or several 
>independent CA's, within which the issuer claims to issue this 
>certificate.
>
>

content-class: urn:content-classes:message
Subject: RE: Logotypes in certificates
Date: Sun, 18 Mar 2001 10:38:00 -0800
From: "Trevor Freeman" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "David Cross" <[email-masked]>, <[email-masked]>

Date: Sun, 18 Mar 2001 11:16:23 -0500
From: Rich Salz <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: [email-masked]
Subject: Re: Logotypes in certificates

I don't understand the need.  Why is it important to brand a data
structure that *nobody ever looks at without a computer controlling the
display*?

Whatever.  Define some extension write it up and submit your own RFc.
	/r$

Date: Sun, 18 Mar 2001 02:56:10 -0800 (PST)
From: vivek saraf <[email-masked]>
Subject: CA key update
To: [email-masked]

Hello All,

Consider the following 

Old CA : Validity T1 - T5

Old user : Validity T2 - T4

New CA : Validity T3 - T7 ( After the key update )

New User : Validity T3 - T6

So during the period T3-t4 the old user and the new
user wants to comunicate. How the validation of the CA
certificates will be done.

The old user dosn't have the new CA certificate

Regards,
Vivek

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

Date: Sun, 18 Mar 2001 01:13:43 +0100
To: "David Cross" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Logotypes in certificates

David,

Comment in line;

At 18:46 2001-03-16 -0800, David Cross wrote:
>Stefan:
>
>Some comments -
>
>First:  I do not think that this should be considered for son of RFC2459
>- we do not want to hold this up to consider this proposal.

That's OK with me.

>
>Second:  I do not see how applications will make use of this
>information.  How do you see it being used?

Well first I would like to state that I now of several applications that 
would use this information if it was available. This is typically any 
application which includes a function to display a certificates to a human 
user. These applications will seek to have a display format which makes 
sense to the user. These applications can, if logotype data is present, 
choose to download these logotypes and display them to the user when a 
certificate is displayed.

Applications don't caring about logos won't be effected since they just 
ignore this information without problem. The logo is only a display 
function and has no part in any DN or alternative name.

We will surely implement this in certificates if this gets to be supported 
by any standard.

/Stefan

>
>Third:  People are complaining about size of certs now, this will expand
>that issue

Everything is a tradeoff. In this case we can meet an important business 
need with just a few bytes. I think this is one of those cases that 
definitely is worth it.

/Stefan

>David B. Cross
>         From: Stefan Santesson [mailto:[email-masked]]
>         Sent: Thursday, March 15, 2001 3:22 PM
>         To: [email-masked]
>         Subject: Logotypes in certificates
>
>
>         In last PKIX meeting in San Diego I presented some thoughts on
>creating a new extension for inclusion of logotype information in
>certificates.
>
>         Last in this mail I include a primary suggested outline for such
>extension.
>
>         But first a short summary of the rationale:
>
>         At a first glance it may seem irrelevant to include logotype
>information in certificates and a natural first reaction is "OH NO...
>NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
>
>         The fact is though that at the ETSI meeting this week (In the
>group that handles European standards related to electronic signatures).
>IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE DATA WOULD BE
>VERY USEFUL.
>
>         Why is that so?
>
>         The answer is that logotypes are carriers of trust and are
>widely recognized tools for trust recognition. Have you ever thought why
>EVERY physical instrument of trust, from loyalty cards, credit cards to
>Passports, contain trust symbols in the form of logotypes.
>
>         Are certificates different? ABSOLUTELY NOT!!
>
>         If PKI is to take off in the private market, the certificates
>must be user friendly and carry the same functionality (in electronic
>form) as ID-cards, passports and other physical ID:s do in physical
>form. And logotypes are a FUNDAMENTAL part of that.
>
>         Without logotypes, certificates can only be handled and
>presented as textual information for technically oriented users. This is
>the reality I see.
>
>         What is your observation?
>
>         How can we then do this?
>
>         Technically speaking, we don't have to include the actual
>logotype image and we don't have to destroy legacy applications.
>         I would suggest that we use the same mechanism that we specified
>for biometric data in RFC 3039 where a non-critical extension can
>include for each logotype:
>
>         -  type of logo
>         -  type of hash algorithm
>         -  hash of logotype data
>         -  URI to location of data
>
>         This will only take a few bytes but will allow new applications
>to import relevant logotypes, signed by the issuer of the certificate,
>to be displayed to the user.
>
>         So... What to do with this?
>
>         If this is to be proceeded at all, It could be part of son of
>RFC 2459, it could be part of a new RFC 3039 and it could be a new draft
>or merged with some other work. I'm open for suggestions.
>
>         I hope to be able to meet with many of you and discuss this in
>Minneapolis next week.
>
>         /Stefan Santesson
>
>
>         logotypeInfo  EXTENSION ::= {
>                   SYNTAX             LogotypeSyntax
>                   IDENTIFIED BY      id-pe-logotypeInfo }
>
>               id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
>
>               LogotypeSyntax ::= SEQUENCE OF LogotypeData
>
>               LogotypeData ::= SEQUENCE {
>                   typeOfLogotype       TypeOflogotype,
>                   hashAlgorithm        AlgorithmIdentifier,
>                   logotypeDataHash     OCTET STRING,
>                   sourceDataUri        IA5String OPTIONAL }
>
>               TypeOflogotype ::= CHOICE {
>                   predefinedLogotypeType    PredefinedLogotypeType,
>                   LogotypeTypeID            OBJECT IDENTIFIER }
>
>               PredefinedLogotypeType ::= INTEGER {
>                   subject-organization-logotype(0),
>                   issuer-organization-logotype(1)
>                   CA-network-logotype(2)}
>                   (subject-organization-logotype|
>                    issuer-organization-logotype|
>                     CA-network-logotype,...)
>
>
>         The predefined logotype types are
>
>         subject-organization-logotype, if used, SHALL be used to include
>a logotype of the subject organization. The logotype SHALL be consistent
>with, and require the presence of, an organization name stored in the
>organization attribute in the subject field.
>
>         issuer-organization-logotype, if used, SHALL be used to include
>a logotype of the issuer organization. The logotype SHALL be consistent
>with, and require the presence of, an organization name stored in the
>organization attribute in the issuer field.
>
>         CA-network-logotype, if used, SHALL be used to include a
>logotype used by a network of CA services, provided by one or several
>independent CA's, within which the issuer claims to issue this
>certificate.
>
>

Date: Sun, 18 Mar 2001 01:01:09 +0100
To: "David Cross" <[email-masked]>, "Michael Zolotarev" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: RE: Logotypes in certificates

Well,

I didn't really suggest inclusion in son of rfc 2459. It was mora like a 
question.

Personally I think it could be done in it's own document and maybe merged 
later into others.

I have negative feelings about the approach to just point to a signed logo, 
but lets discuss it openly.

I think I would like to have the logotype signed by the certificate and I 
suggest that you should not be allowed to update or change any information 
signed and identified by a certificate. If you have an physical ID-card, 
any logotypes are fixed. The present logotypes reflects the logotypes valid 
at the time of issuance.

/Stefan

At 13:11 2001-03-17 -0800, David Cross wrote:
>Sounds like a reasonable suggestion.  Still, I would not want this in
>son-of-RFC2459.
>
>David B. Cross
>
>
>
>
>
>From: Michael Zolotarev [mailto:[email-masked]]
>Sent: Friday, March 16, 2001 7:09 PM
>To: David Cross; Stefan Santesson; [email-masked]
>Subject: RE: Logotypes in certificates
>
>
>Probably a better alternative to including a logotype into a certificate
>would be to include a reference to a [signed] logotype. As an extension,
>containing a uri of a logotype which is stored somewhere. The drawback
>is that it requires the verifier to be connected, obviously. But
>certificate verification normally assumes that you are connected. The
>size of a logotype won't matter much.
>
>Naturally, a logotype should be signed by the same entity which issued
>the certificate which contains the reference to the logotype. it also
>allows flexible update of logotype if necessary, should a change be made
>within validity period of the certificate (i.e. a new photo required
>because I've grown a bead).
>
>Michael

From: "Grant, Alistair" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: Matching CertIDs between OCSP requests and responses
Date: Sun, 18 Mar 2001 10:39:11 +1100

Hi Jonathan,

Do you happen to know when the signing model with multiple CertIDs was
discussed?

I am thinking about this at the moment, but don't remember any discussion on
the PKIX list.

Thanks very much.

Cheers,

Alistair Grant
Computer Associates
Development Manager, eTrust R&D
Phone:		+61 3 9825 5692
Mobile:		+61 408 565 080
E-Mail:		[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 16, 2001 3:56 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Matching CertIDs between OCSP requests and responses

I think that the ability to specify multiple certificates is useful, in
particular for validating a non-trivial certificate chain.  In this case,
it makes sense to trust the chain only as much as the least trusted
certificate in the chain.

However, the delegated OCSP signing model isn't ideally suited to
certificate chains - you have to use the trusted authority OCSP signing
model instead.  This subject has been discussed on this list previously.

Jonathan
----------------
Dr Jonathan Tuliani
www.symbian.com

content-class: urn:content-classes:message
Subject: RE: Logotypes in certificates
Date: Sat, 17 Mar 2001 13:11:42 -0800
From: "David Cross" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>, <[email-masked]>

Sounds like a reasonable suggestion.  Still, I would not want this in
son-of-RFC2459.

David B. Cross

-----Original Message-----
From: Michael Zolotarev [mailto:[email-masked]] 
Sent: Friday, March 16, 2001 7:09 PM
To: David Cross; Stefan Santesson; [email-masked]
Subject: RE: Logotypes in certificates

Probably a better alternative to including a logotype into a certificate
would be to include a reference to a [signed] logotype. As an extension,
containing a uri of a logotype which is stored somewhere. The drawback
is that it requires the verifier to be connected, obviously. But
certificate verification normally assumes that you are connected. The
size of a logotype won't matter much.

Naturally, a logotype should be signed by the same entity which issued
the certificate which contains the reference to the logotype. it also
allows flexible update of logotype if necessary, should a change be made
within validity period of the certificate (i.e. a new photo required
because I've grown a bead).

Michael

From: "Anders Rundgren" <[email-masked]>
To: "David Cross" <[email-masked]>, "Stefan Santesson" <[email-masked]>, <[email-masked]>
Subject: Re: Logotypes in certificates
Date: Sat, 17 Mar 2001 21:02:23 +0100

David,
> Second:  I do not see how applications will make use of this
> information.  How do you see it being used?

I assume that the logo is a replacement for VISA on plastic card that when added to SET certificates
could be displayed in your electronic wallet. Naah, I meant in your mobile phone that will be
the wallet.  Sooner or later...

> Third:  People are complaining about size of certs now, this will expand
> that issue

This is the same as with everything in the computer business.  Once a word-
processing document of 100K was considered big.  Now you don't raise an
eye-brow on a 2M ditto!  The URI will as Stefan said only use a few bytes BTW.

Anders

From: Michael Zolotarev <[email-masked]>
To: David Cross <[email-masked]>, Stefan Santesson <[email-masked]>, [email-masked]
Subject: RE: Logotypes in certificates
Date: Sat, 17 Mar 2001 14:09:07 +1100

Probably a better alternative to including a logotype into a certificate
would be to include a reference to a [signed] logotype. As an extension,
containing a uri of a logotype which is stored somewhere. The drawback is
that it requires the verifier to be connected, obviously. But certificate
verification normally assumes that you are connected. The size of a logotype
won't matter much.

Naturally, a logotype should be signed by the same entity which issued the
certificate which contains the reference to the logotype. it also allows
flexible update of logotype if necessary, should a change be made within
validity period of the certificate (i.e. a new photo required because I've
grown a bead).

Michael

> From: David Cross [mailto:[email-masked]]
> Sent: Saturday, 17 March 2001 13:46
> To: Stefan Santesson; [email-masked]
> Subject: RE: Logotypes in certificates
> 
> 
> Stefan:
>  
> Some comments -
>  
> First:  I do not think that this should be considered for son 
> of RFC2459
> - we do not want to hold this up to consider this proposal.
>  
> Second:  I do not see how applications will make use of this
> information.  How do you see it being used?
>  
> Third:  People are complaining about size of certs now, this 
> will expand
> that issue
>  
> 
> David B. Cross
> 
> 
> 	From: Stefan Santesson [mailto:[email-masked]] 
> 	Sent: Thursday, March 15, 2001 3:22 PM
> 	To: [email-masked]
> 	Subject: Logotypes in certificates
> 	
> 	
> 	In last PKIX meeting in San Diego I presented some thoughts on
> creating a new extension for inclusion of logotype information in
> certificates.
> 	
> 	Last in this mail I include a primary suggested outline for such
> extension.
> 	
> 	But first a short summary of the rationale:
> 	
> 	At a first glance it may seem irrelevant to include logotype
> information in certificates and a natural first reaction is "OH NO...
> NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
> 	
> 	The fact is though that at the ETSI meeting this week (In the
> group that handles European standards related to electronic 
> signatures).
> IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE DATA WOULD BE
> VERY USEFUL.
> 	
> 	Why is that so?
> 	
> 	The answer is that logotypes are carriers of trust and are
> widely recognized tools for trust recognition. Have you ever 
> thought why
> EVERY physical instrument of trust, from loyalty cards, 
> credit cards to
> Passports, contain trust symbols in the form of logotypes.
> 	
> 	Are certificates different? ABSOLUTELY NOT!! 
> 	
> 	If PKI is to take off in the private market, the certificates
> must be user friendly and carry the same functionality (in electronic
> form) as ID-cards, passports and other physical ID:s do in physical
> form. And logotypes are a FUNDAMENTAL part of that.
> 	
> 	Without logotypes, certificates can only be handled and
> presented as textual information for technically oriented 
> users. This is
> the reality I see. 
> 	
> 	What is your observation?
> 	
> 	How can we then do this?
> 	
> 	Technically speaking, we don't have to include the actual
> logotype image and we don't have to destroy legacy applications.
> 	I would suggest that we use the same mechanism that we specified
> for biometric data in RFC 3039 where a non-critical extension can
> include for each logotype:
> 	
> 	-  type of logo
> 	-  type of hash algorithm
> 	-  hash of logotype data 
> 	-  URI to location of data
> 	
> 	This will only take a few bytes but will allow new applications
> to import relevant logotypes, signed by the issuer of the certificate,
> to be displayed to the user. 
> 	
> 	So... What to do with this?
> 	
> 	If this is to be proceeded at all, It could be part of son of
> RFC 2459, it could be part of a new RFC 3039 and it could be 
> a new draft
> or merged with some other work. I'm open for suggestions.
> 	
> 	I hope to be able to meet with many of you and discuss this in
> Minneapolis next week.
> 	
> 	/Stefan Santesson
> 	
> 	   
> 	logotypeInfo  EXTENSION ::= {
> 	          SYNTAX             LogotypeSyntax
> 	          IDENTIFIED BY      id-pe-logotypeInfo }
> 	
> 	      id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
> 	
> 	      LogotypeSyntax ::= SEQUENCE OF LogotypeData
> 	
> 	      LogotypeData ::= SEQUENCE {
> 	          typeOfLogotype       TypeOflogotype,
> 	          hashAlgorithm        AlgorithmIdentifier,
> 	          logotypeDataHash     OCTET STRING,
> 	          sourceDataUri        IA5String OPTIONAL }
> 	
> 	      TypeOflogotype ::= CHOICE {
> 	          predefinedLogotypeType    PredefinedLogotypeType,
> 	          LogotypeTypeID            OBJECT IDENTIFIER }
> 	
> 	      PredefinedLogotypeType ::= INTEGER { 
> 	          subject-organization-logotype(0),
> 	          issuer-organization-logotype(1)
> 	          CA-network-logotype(2)} 
> 	          (subject-organization-logotype|
> 	           issuer-organization-logotype|
> 	            CA-network-logotype,...)
> 	
> 	
> 	The predefined logotype types are
> 	
> 	subject-organization-logotype, if used, SHALL be used to include
> a logotype of the subject organization. The logotype SHALL be 
> consistent
> with, and require the presence of, an organization name stored in the
> organization attribute in the subject field.
> 	
> 	issuer-organization-logotype, if used, SHALL be used to include
> a logotype of the issuer organization. The logotype SHALL be 
> consistent
> with, and require the presence of, an organization name stored in the
> organization attribute in the issuer field.
> 	
> 	CA-network-logotype, if used, SHALL be used to include a
> logotype used by a network of CA services, provided by one or several
> independent CA's, within which the issuer claims to issue this
> certificate.
> 	
> 	
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 

-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

In addition, certain Marketing collateral may be added from time to time to 
promote Baltimore Technologies products, services, Global e-Security or 
appearance at trade shows and conferences.
 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

content-class: urn:content-classes:message
Subject: RE: Logotypes in certificates
Date: Fri, 16 Mar 2001 18:46:26 -0800
From: "David Cross" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>

Stefan:
 
Some comments -
 
First:  I do not think that this should be considered for son of RFC2459
- we do not want to hold this up to consider this proposal.
 
Second:  I do not see how applications will make use of this
information.  How do you see it being used?
 
Third:  People are complaining about size of certs now, this will expand
that issue

David B. Cross

	-----Original Message-----
	From: Stefan Santesson [mailto:[email-masked]] 
	Sent: Thursday, March 15, 2001 3:22 PM
	To: [email-masked]
	Subject: Logotypes in certificates

	In last PKIX meeting in San Diego I presented some thoughts on
creating a new extension for inclusion of logotype information in
certificates.
	
	Last in this mail I include a primary suggested outline for such
extension.
	
	But first a short summary of the rationale:
	
	At a first glance it may seem irrelevant to include logotype
information in certificates and a natural first reaction is "OH NO...
NOT ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!"
	
	The fact is though that at the ETSI meeting this week (In the
group that handles European standards related to electronic signatures).
IT WAS GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE DATA WOULD BE
VERY USEFUL.
	
	Why is that so?
	
	The answer is that logotypes are carriers of trust and are
widely recognized tools for trust recognition. Have you ever thought why
EVERY physical instrument of trust, from loyalty cards, credit cards to
Passports, contain trust symbols in the form of logotypes.
	
	Are certificates different? ABSOLUTELY NOT!! 
	
	If PKI is to take off in the private market, the certificates
must be user friendly and carry the same functionality (in electronic
form) as ID-cards, passports and other physical ID:s do in physical
form. And logotypes are a FUNDAMENTAL part of that.
	
	Without logotypes, certificates can only be handled and
presented as textual information for technically oriented users. This is
the reality I see. 
	
	What is your observation?
	
	How can we then do this?
	
	Technically speaking, we don't have to include the actual
logotype image and we don't have to destroy legacy applications.
	I would suggest that we use the same mechanism that we specified
for biometric data in RFC 3039 where a non-critical extension can
include for each logotype:
	
	-  type of logo
	-  type of hash algorithm
	-  hash of logotype data 
	-  URI to location of data
	
	This will only take a few bytes but will allow new applications
to import relevant logotypes, signed by the issuer of the certificate,
to be displayed to the user. 
	
	So... What to do with this?
	
	If this is to be proceeded at all, It could be part of son of
RFC 2459, it could be part of a new RFC 3039 and it could be a new draft
or merged with some other work. I'm open for suggestions.
	
	I hope to be able to meet with many of you and discuss this in
Minneapolis next week.
	
	/Stefan Santesson

	logotypeInfo  EXTENSION ::= {
	          SYNTAX             LogotypeSyntax
	          IDENTIFIED BY      id-pe-logotypeInfo }
	
	      id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}
	
	      LogotypeSyntax ::= SEQUENCE OF LogotypeData
	
	      LogotypeData ::= SEQUENCE {
	          typeOfLogotype       TypeOflogotype,
	          hashAlgorithm        AlgorithmIdentifier,
	          logotypeDataHash     OCTET STRING,
	          sourceDataUri        IA5String OPTIONAL }
	
	      TypeOflogotype ::= CHOICE {
	          predefinedLogotypeType    PredefinedLogotypeType,
	          LogotypeTypeID            OBJECT IDENTIFIER }
	
	      PredefinedLogotypeType ::= INTEGER { 
	          subject-organization-logotype(0),
	          issuer-organization-logotype(1)
	          CA-network-logotype(2)} 
	          (subject-organization-logotype|
	           issuer-organization-logotype|
	            CA-network-logotype,...)

	The predefined logotype types are
	
	subject-organization-logotype, if used, SHALL be used to include
a logotype of the subject organization. The logotype SHALL be consistent
with, and require the presence of, an organization name stored in the
organization attribute in the subject field.
	
	issuer-organization-logotype, if used, SHALL be used to include
a logotype of the issuer organization. The logotype SHALL be consistent
with, and require the presence of, an organization name stored in the
organization attribute in the issuer field.
	
	CA-network-logotype, if used, SHALL be used to include a
logotype used by a network of CA services, provided by one or several
independent CA's, within which the issuer claims to issue this
certificate.

From: "parag salvi" <[email-masked]>
To: [email-masked]
Subject: CA Tool
Date: Fri, 16 Mar 2001 16:02:43 -0800

Hi All,

Is there any CA tool available where I can specify what extension I want in 
the CA and with what values ?

Thanks,
Parag

>From: "Jim Schaad" <[email-masked]>
>Reply-To: <[email-masked]>
>To: <[email-masked]>
>CC: "Tim Polk \(E-mail\)" <[email-masked]>
>Subject: draft-ietf-pkix-new-part1-05.txt
>Date: Fri, 16 Mar 2001 12:07:55 -0800
>
>More ASN.1 errors and comments:
>
>PKIX1Implicit88
>1. Imports from the old Explicit module number.
>
>PKIX1Algorithms88
>1. Module number for id-algorithms-88 is missing.
>2. ECParameters has a trailing comma on cofactor that needs to be omitted
>
>
>jim
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Cc: "Tim Polk \(E-mail\)" <[email-masked]>
Subject: draft-ietf-pkix-new-part1-05.txt
Date: Fri, 16 Mar 2001 12:07:55 -0800
Importance: Normal

More ASN.1 errors and comments:

PKIX1Implicit88
1. Imports from the old Explicit module number.

PKIX1Algorithms88 
1. Module number for id-algorithms-88 is missing.
2. ECParameters has a trailing comma on cofactor that needs to be omitted

jim

Content-return: allowed
Date: Thu, 15 Mar 2001 11:56:18 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Matching CertIDs between OCSP requests and responses
To: "[email-masked]'" <[email-masked]>, [email-masked]

Peter, we do use multiple certs in a query for multiple reasons:

a. To query the status of a whole chain at a time

b. To query the status of all certs in something like an address
book, to figure out which certs that I have in my address book
are still good.

Regards,
Ambarish

> Sent: Thursday, March 15, 2001 9:21 PM
> To: [email-masked]
> Subject: RE: Matching CertIDs between OCSP requests and responses
> 
> 
> [email-masked]
> 
> >The idea of non-global errors is interesting, I hadn't 
> thought about that. It
> >might be useful where multiple certificates are present in 
> the request. 
> 
> Is anyone (apart from Identrus, who do it for 
> political/economic rather than
> technical reasons) doing this to any extent?  There is 
> anecdotal evidence which
> suggests that implementors are using only one cert per query, 
> having multiple
> certs per query is hideous in terms of handling responses 
> (let's see now, this
> one is OK, this one isn't, we don't know about this one... 
> no, the third one,
> not the second one... no that one's OK, you want the one next 
> to it... etc
> etc).  Although my code supports the ability to query 
> multiple certs at once, I
> haven't enabled it because handling mixed responses is just 
> too messy, it's
> much, *much* easier to work with if you do it on the basis of 
> "Is this cert
> revoked or not?" rather than "Tell me whatever you can about 
> this bundle of
> stuff, and I'll try and figure out what's what from your response".
> 
> Peter.
> 

Date: Thu, 15 Mar 2001 23:44:28 +0000
From: Dr S N Henson <[email-masked]>
Organization: S N Henson
To: [email-masked]
Subject: Re: Matching CertIDs between OCSP requests and responses

Peter Gutmann wrote:
> 
> [email-masked] writes:
> 
> >As mentioned earlier, the complexity of matching certificate identifiers
> >between request and response increases in v2, where there are so many other
> >ways to identify a certificate.
> 
> Yes, but they're all unique (there's only one way to encode an
> issuerAndSerialNumber, certificate, etc), a binary compare should do for this.
> 
> I'll do a bit of experimenting next week, but I'd be very surprised if a binary
> compare failed for any responder.
> 

One responder I tested didn't get this right but that was due to a
responder bug.

Wrt multiple certificates in request I've come across two different
kinds of anomalous behaviour.

One just rejects it with malformedRequest. Another includes status
information about the first certificate and nothing for the remainder.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Matching CertIDs between OCSP requests and responses
Date: Thu, 15 Mar 2001 15:45:54 -0800
Importance: Normal

Jonathan,

Apologies for not getting back sooner.  I see things have been busy.
Anyway, an RFC 2560 server is compliant even if it behaves in the manner you
describe.  There are no normative requirements in RFC 2560 to the contrary.
However, I'm of the opinion that a robust client should be capable of
handling this potential error condition.  This condition, along with several
other processing considerations that contribute to interoperability, could
be better addressed.  We will be working on these issues in the v2 context
over the next few months.  Perhaps you would care to join us in that,
particularly from the thin client perspective.  In any case, thanks for the
catch.  Hope this helps.

Mike

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 8:40 AM
> To: Michael Myers
> Cc: [email-masked]
> Subject: RE: Matching CertIDs between OCSP requests and responses
>
>
>
> Mike,
>
> Thanks for the reply.  I think my use of the phrase 'server error' was
> perhaps misleading:  what I mean is, has the server behaved in a
> non-compliant manner if a certificate from the request is missing from the
> response (or, for that matter, if the response contains
> information about a
> certificate not present in the request).  That is, is doing so an improper
> response?
>
> The idea of non-global errors is interesting, I hadn't thought about that.
> It might be useful where multiple certificates are present in the request.
> The most likely case I can think of is where the OCSP server is acting in
> request-forwarding mode, splitting a request and farming it out to several
> other servers, which in turn may return differing error states.  It would
> be a pity to simply throw out the valid information and return an error
> just because one of the second-level servers did.
>
> Regards,
>
> Jonathan
>
>
>
>
>
>                     "Michael
>
>                     Myers"               To:
> <[email-masked]>,
>                     <myers@coasts        <[email-masked]>
>
>                     ide.net>             cc:
>
>                                          Subject:     RE:
> Matching CertIDs between OCSP
>                     14/03/01             requests and responses
>
>                     16:38
>
>
>
>
>
>
>
>
>
> Jonathan,
>
> You are correct in your assumptions.  One point of clarification however.
>
> Server errors appear in the mandatory responseStatus field of OCSPResponse
> and not the optional responseBytes field in order to ensure that a server
> will produce *some* type of feedback in the event of an error.
>
> OCSPResponse ::= SEQUENCE {
>     responseStatus     OCSPResponseStatus,
>     responseBytes      [0]  EXPLICIT ResponseBytes OPTIONAL }
>
> Given that, such errors speak to the server's response as a whole and not
> to
> individual certificates in the instance when multiple certificates are
> identified in a single request and corresponding response (the latter via
> SingleResponse syntax).
>
> In other words, we assumed that the type of server problems enumerated in
> OCSPResponseStatus would be global with respect a request regardless of
> whether or not that request addressed a single certificate or multiple
> certificates.
>
> In the context of the v2 work, I'd be very interested to hear if your
> implementation experience leads to a need for error states at the
> SingleResponse level.
>
> Your point regarding certificate identification matching in the v2 case is
> well noted.
>
> Mike
>
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, March 14, 2001 4:25 AM
> > To: [email-masked]
> > Subject: Matching CertIDs between OCSP requests and responses
> >
> >
> > All,
> >
> > Another OCSP (v1) question:  Can a client assume that the OCSP response
> > CertID terms will precisely match those from the request?  That is, can
> it
> > assume
> > 1 - that every certificate in the request will be in the response (i.e.
> > it's a server error otherwise)
> > 2 - that the hashing algorithm in the response CertIDs will be the same
> as
> > that which was used in the request (that is, the CertID data will match
> > byte-for-byte between request and response).
> >
> > I guess given the variety of identifiers available alongside
> > CertID in OCSP
> > v2 that the issue of matching identifiers between request and response
> > raised in point 2 above will be even more critical there.  But
> that's for
> > other people to worry about - it's v1 I'm interested in for now.
> >
> > Thanks,
> >
> > Jonathan
> > ----------------
> > Dr Jonathan Tuliani
> > www.symbian.com
> >
> >
> >
> > Symbian Ltd is a company registered in England and Wales with
> > registered number 01796587 and registered office at 19 Harcourt
> > Street, London, W1H 4HF, UK.
> > This message is intended only for use by the named addressee and
> > may contain privileged and/or confidential information. If you
> > are not the named addressee you should not disseminate, copy or
> > take any action in reliance on it. If you have received this
> > message in error please notify [email-masked] and delete
> > the message and any attachments accompanying it immediately.
> > Symbian does not accept liability for any corruption,
> > interception, amendment, tampering or viruses occuring to this
> > message in transit or for any message sent by its employees which
> > is not in compliance with Symbian corporate policy.

Date: Fri, 16 Mar 2001 00:22:19 +0100
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Logotypes in certificates

--=====================_12792724==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

In last PKIX meeting in San Diego I presented some thoughts on creating a 
new extension for inclusion of logotype information in certificates.

Last in this mail I include a primary suggested outline for such extension.

But first a short summary of the rationale:

At a first glance it may seem irrelevant to include logotype information in 
certificates and a natural first reaction is "OH NO... NOT ANOTHER THING TO 
INCLUDE!! DON'T WE HAVE ENOUGH?!!!"

The fact is though that at the ETSI meeting this week (In the group that 
handles European standards related to electronic signatures). IT WAS 
GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE DATA WOULD BE VERY USEFUL.

Why is that so?

The answer is that logotypes are carriers of trust and are widely 
recognized tools for trust recognition. Have you ever thought why EVERY 
physical instrument of trust, from loyalty cards, credit cards to 
Passports, contain trust symbols in the form of logotypes.

Are certificates different? ABSOLUTELY NOT!!

If PKI is to take off in the private market, the certificates must be user 
friendly and carry the same functionality (in electronic form) as ID-cards, 
passports and other physical ID:s do in physical form. And logotypes are a 
FUNDAMENTAL part of that.

Without logotypes, certificates can only be handled and presented as 
textual information for technically oriented users. This is the reality I see.

What is your observation?

How can we then do this?

Technically speaking, we don't have to include the actual logotype image 
and we don't have to destroy legacy applications.
I would suggest that we use the same mechanism that we specified for 
biometric data in RFC 3039 where a non-critical extension can include for 
each logotype:

-  type of logo
-  type of hash algorithm
-  hash of logotype data
-  URI to location of data

This will only take a few bytes but will allow new applications to import 
relevant logotypes, signed by the issuer of the certificate, to be 
displayed to the user.

So... What to do with this?

If this is to be proceeded at all, It could be part of son of RFC 2459, it 
could be part of a new RFC 3039 and it could be a new draft or merged with 
some other work. I'm open for suggestions.

I hope to be able to meet with many of you and discuss this in Minneapolis 
next week.

/Stefan Santesson

logotypeInfo  EXTENSION ::= {
           SYNTAX             LogotypeSyntax
           IDENTIFIED BY      id-pe-logotypeInfo }

       id-pe-logotypeInfo OBJECT IDENTIFIER  ::= {id-pe XX}

       LogotypeSyntax ::= SEQUENCE OF LogotypeData

       LogotypeData ::= SEQUENCE {
           typeOfLogotype       TypeOflogotype,
           hashAlgorithm        AlgorithmIdentifier,
           logotypeDataHash     OCTET STRING,
           sourceDataUri        IA5String OPTIONAL }

       TypeOflogotype ::= CHOICE {
           predefinedLogotypeType    PredefinedLogotypeType,
           LogotypeTypeID            OBJECT IDENTIFIER }

       PredefinedLogotypeType ::= INTEGER {
           subject-organization-logotype(0),
           issuer-organization-logotype(1)
           CA-network-logotype(2)}
           (subject-organization-logotype|
            issuer-organization-logotype|
             CA-network-logotype,...)

The predefined logotype types are

subject-organization-logotype, if used, SHALL be used to include a logotype 
of the subject organization. The logotype SHALL be consistent with, and 
require the presence of, an organization name stored in the organization 
attribute in the subject field.

issuer-organization-logotype, if used, SHALL be used to include a logotype 
of the issuer organization. The logotype SHALL be consistent with, and 
require the presence of, an organization name stored in the organization 
attribute in the issuer field.

CA-network-logotype, if used, SHALL be used to include a logotype used by a 
network of CA services, provided by one or several independent CA's, within 
which the issuer claims to issue this certificate.

--=====================_12792724==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
In last PKIX meeting in San Diego I presented some thoughts on creating a
new extension for inclusion of logotype information in 
certificates.<br>
<br>
Last in this mail I include a primary suggested outline for such
extension.<br>
<br>
But first a short summary of the rationale:<br>
<br>
At a first glance it may seem irrelevant to include logotype information
in certificates and a natural first reaction is &quot;OH NO... NOT
ANOTHER THING TO INCLUDE!! DON'T WE HAVE ENOUGH?!!!&quot;<br>
<br>
The fact is though that at the ETSI meeting this week (In the group that
handles European standards related to electronic signatures). IT WAS
GENERALLY RECOGNIZED THAT INCLUSION OF LOGOTYPE DATA WOULD BE VERY
USEFUL.<br>
<br>
Why is that so?<br>
<br>
The answer is that logotypes are carriers of trust and are widely
recognized tools for trust recognition. Have you ever thought why EVERY
physical instrument of trust, from loyalty cards, credit cards to
Passports, contain trust symbols in the form of logotypes.<br>
<br>
Are certificates different? ABSOLUTELY NOT!! <br>
<br>
If PKI is to take off in the private market, the certificates must be
user friendly and carry the same functionality (in electronic form) as
ID-cards, passports and other physical ID:s do in physical form. And
logotypes are a FUNDAMENTAL part of that.<br>
<br>
Without logotypes, certificates can only be handled and presented as
textual information for technically oriented users. This is the reality I
see. <br>
<br>
What is your observation?<br>
<br>
How can we then do this?<br>
<br>
Technically speaking, we don't have to include the actual logotype image
and we don't have to destroy legacy applications.<br>
I would suggest that we use the same mechanism that we specified for
biometric data in RFC 3039 where a non-critical extension can include for
each logotype:<br>
<br>
-&nbsp; type of logo<br>
-&nbsp; type of hash algorithm<br>
-&nbsp; hash of logotype data <br>
-&nbsp; URI to location of data<br>
<br>
This will only take a few bytes but will allow new applications to import
relevant logotypes, signed by the issuer of the certificate, to be
displayed to the user. <br>
<br>
So... What to do with this?<br>
<br>
If this is to be proceeded at all, It could be part of son of RFC 2459,
it could be part of a new RFC 3039 and it could be a new draft or merged
with some other work. I'm open for suggestions.<br>
<br>
I hope to be able to meet with many of you and discuss this in
Minneapolis next week.<br>
<br>
/Stefan Santesson<br>
<br>
<font face="Courier New, Courier">&nbsp;&nbsp; <br>
logotypeInfo&nbsp; EXTENSION ::= {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
LogotypeSyntax<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IDENTIFIED
BY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; id-pe-logotypeInfo }<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; id-pe-logotypeInfo OBJECT IDENTIFIER&nbsp;
::= {id-pe XX}<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LogotypeSyntax ::= SEQUENCE OF
LogotypeData<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LogotypeData ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
typeOfLogotype&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TypeOflogotype,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
hashAlgorithm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AlgorithmIdentifier,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
logotypeDataHash&nbsp;&nbsp;&nbsp;&nbsp; OCTET STRING,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sourceDataUri&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IA5String
OPTIONAL }<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TypeOflogotype ::= CHOICE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
predefinedLogotypeType&nbsp;&nbsp;&nbsp; PredefinedLogotypeType,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
LogotypeTypeID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OBJECT IDENTIFIER }<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PredefinedLogotypeType ::= INTEGER { 
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
subject-organization-logotype(0),<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
issuer-organization-logotype(1)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CA-network-logotype(2)} <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(subject-organization-logotype|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
issuer-organization-logotype</font><font face="Courier New, Courier" size=2>|<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</font><font face="Courier New, Courier">CA-network-logotype,...)<br>
<br>
<br>
The predefined logotype types are<br>
<br>
subject-organization-logotype, if used, SHALL be used to include a
logotype of the subject organization. The logotype SHALL be consistent
with, and require the presence of, an organization name stored in the
organization attribute in the subject field.<br>
<br>
issuer-organization-logotype, if used, SHALL be used to include a
logotype of the issuer organization. The logotype SHALL be consistent
with, and require the presence of, an organization name stored in the
organization attribute in the issuer field.<br>
<br>
CA-network-logotype, if used, SHALL be used to include a logotype used by
a network of CA services, provided by one or several independent CA’s,
within which the issuer claims to issue this certificate.<br>
<br>
</font></html>

--=====================_12792724==_.ALT--

Content-return: allowed
Date: Thu, 15 Mar 2001 14:32:29 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Matching CertIDs between OCSP requests and responses
To: "[email-masked]'" <[email-masked]>, [email-masked]

Peter, we do use multiple certs in a query for multiple reasons:

a. To query the status of a whole chain at a time

b. To query the status of all certs in something like an address
book, to figure out which certs that I have in my address book
are still good.

Regards,
Ambarish

> Sent: Thursday, March 15, 2001 9:21 PM
> To: [email-masked]
> Subject: RE: Matching CertIDs between OCSP requests and responses
> 
> 
> [email-masked]
> 
> >The idea of non-global errors is interesting, I hadn't 
> thought about that. It
> >might be useful where multiple certificates are present in 
> the request. 
> 
> Is anyone (apart from Identrus, who do it for 
> political/economic rather than
> technical reasons) doing this to any extent?  There is 
> anecdotal evidence which
> suggests that implementors are using only one cert per query, 
> having multiple
> certs per query is hideous in terms of handling responses 
> (let's see now, this
> one is OK, this one isn't, we don't know about this one... 
> no, the third one,
> not the second one... no that one's OK, you want the one next 
> to it... etc
> etc).  Although my code supports the ability to query 
> multiple certs at once, I
> haven't enabled it because handling mixed responses is just 
> too messy, it's
> much, *much* easier to work with if you do it on the basis of 
> "Is this cert
> revoked or not?" rather than "Tell me whatever you can about 
> this bundle of
> stuff, and I'll try and figure out what's what from your response".
> 
> Peter.
> 

Date: Thu, 15 Mar 2001 12:29:47 -0500
To: Bodo Moeller <[email-masked]>, [email-masked]
From: Tim Polk <[email-masked]>
Subject: Re: draft-ietf-pkix-ipki-pkalgs-02.txt: ECDSA

Bodo,

The parameter specifications in these sections are not actually related, as 
we are performing different functions

In section 2.2.3, we are specifying an ECDSA *signature*.  As with DSA, the 
public key and parameters used to verify the signature may be obtained in 
three different ways:
(1) the parameters and public key may be in the subjectPublicKeyInfo in the 
end certificate in a certification path;
(2) the public key may be in the end certificate and the parameters may be 
obtained through parameter inheritance (from an intermediate certificate in 
the certification path); or
(3) through an out-of-band mechanism.

In this case, the ecdsa-with-SHA1 OID algorithm identifier is used in the 
algorithm identifier field.  Since the parameters MUST be obtained 
separately from the signature, the parameters field associated with the 
signature cannot contain useful information.  As a result, the parameters 
field is required to be NULL.

In section 2.3.5, we are specifying an ECDSA *public key* in the 
subjectPublicKeyInfo field.  (Note that we use a different OID, 
id-ecPublicKey.)  In this case, the parameters field may contain the EC 
paramters or indicate that parameters are to be obtained through parameter 
inheritance.  There are two mechanisms to specify parameters for EC: (1) 
directly by specifying the value of each parameter or (2) indirectly by 
specifying a named curve through an object identifier.  The second option 
may be encoded in a smaller number of bytes.  These mechanisms correspond 
to ecParameters and namedCurve, respectively, in the list of choices for 
parameters.   The third choice, implicitlyCA, is used to indicate that 
parameters are to be obtained through parameter inheritance.

Hope that helps.

Tim Polk

At 10:38 AM 3/12/01 +0100, Bodo Moeller wrote:
>According to draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.2.3,
>
>    When the ecdsa-with-SHA1 algorithm identifier is used the parameters
>    MUST be NULL.
>
>However section 2.3.5 specifies what the parameters should look like:
>
>    ECDSA and ECDH require use of certain parameters with the public key.
>    The parameters may be inherited from the issuer, implicitly included
>    through reference to a "named curve," or explicitly included in the
>    certificate.
>
>       ecpkParameters ::= CHOICE {
>         ecParameters  ECParameters,
>         namedCurve    OBJECT IDENTIFIER,
>         implicitlyCA  NULL }
>
>Presumably 2.2.3 was meant to say that parameters are not OPTIONAL
>for ecdsa-with-SHA1, and that hence they must be NULL if there
>is no explicit value.
>
>
>--
>Bodo Möller <[email-masked]>
>PGP 
>http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
>* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
>* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

From: [email-masked]
Subject: RE: Matching CertIDs between OCSP requests and responses
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 15 Mar 2001 16:55:32 +0000

I think that the ability to specify multiple certificates is useful, in
particular for validating a non-trivial certificate chain.  In this case,
it makes sense to trust the chain only as much as the least trusted
certificate in the chain.

However, the delegated OCSP signing model isn't ideally suited to
certificate chains - you have to use the trusted authority OCSP signing
model instead.  This subject has been discussed on this list previously.

Jonathan
----------------
Dr Jonathan Tuliani
www.symbian.com

                    [email-masked]                                                            
                    land.ac.nz             To:     [email-masked]                           
                    (Peter Gutmann)        cc:                                                 
                    Sent by:               Subject:     RE: Matching CertIDs between OCSP      
                    [email-masked]        requests and responses                              
                    land.ac.nz                                                                 

                    16/03/01 05:20                                                             
                    Please respond                                                             
                    to pgut001                                                                 

[email-masked]

>The idea of non-global errors is interesting, I hadn't thought about that.
It
>might be useful where multiple certificates are present in the request.

Is anyone (apart from Identrus, who do it for political/economic rather
than
technical reasons) doing this to any extent?  There is anecdotal evidence
which
suggests that implementors are using only one cert per query, having
multiple
certs per query is hideous in terms of handling responses (let's see now,
this
one is OK, this one isn't, we don't know about this one... no, the third
one,
not the second one... no that one's OK, you want the one next to it... etc
etc).  Although my code supports the ability to query multiple certs at
once, I
haven't enabled it because handling mixed responses is just too messy, it's
much, *much* easier to work with if you do it on the basis of "Is this cert
revoked or not?" rather than "Tell me whatever you can about this bundle of
stuff, and I'll try and figure out what's what from your response".

Peter.

From: [email-masked]
Subject: Re: Matching CertIDs between OCSP requests and responses
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 15 Mar 2001 16:48:25 +0000

What I'm getting at is a slightly different issue with OCSP v2.  This has
several means for the request and response to identify the certificate:

ReqCert  ::= CHOICE {
   certID            CertID,
   issuerSerial      [0] IssuerandSerialNumber,
   pKCert            [1] Certificate,
   name              [2] GeneralName,
   certHash          [3] OCTET STRING}

However, there doesn't seem to be any condition requiring the response to
use the same method as was used in the request.  The request could use an
IssuerAndSerialNumber, and the response could then identify the same
certificate using CertID.  Should the response be forced to use the same
technique as the request?  How does this affect response pre-computation?

Jonathan

                    [email-masked]                                                            
                    land.ac.nz             To:     [email-masked]                
                    (Peter Gutmann)        cc:     [email-masked]                           
                    Sent by:               Subject:     Re: Matching CertIDs between OCSP      
                    [email-masked]        requests and responses                              
                    land.ac.nz                                                                 

                    16/03/01 05:31                                                             
                    Please respond                                                             
                    to pgut001                                                                 

[email-masked] writes:

>Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it
doesn't
>say that they MUST use it.  Suppose I send a request, in which my CertID
has
>used SHA1.  Suppose the responder then replies, but uses MD5 to form the
>CertID term corresponding to the same certificate.  Then the matching of
the
>CertID term between request and response becomes less trivial than a
simple
>binary comparison.

Anecdotal evidence (that chap again) suggests that everyone uses SHA1
exclusively.  Have you tried submitting a request hashed with MD5 to see
how
many servers you can break?

>As mentioned earlier, the complexity of matching certificate identifiers
>between request and response increases in v2, where there are so many
other
>ways to identify a certificate.

Yes, but they're all unique (there's only one way to encode an
issuerAndSerialNumber, certificate, etc), a binary compare should do for
this.

I'll do a bit of experimenting next week, but I'd be very surprised if a
binary
compare failed for any responder.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Matching CertIDs between OCSP requests and responses
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 16 Mar 2001 05:31:04 (NZDT)

[email-masked] writes:

>Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it doesn't
>say that they MUST use it.  Suppose I send a request, in which my CertID has
>used SHA1.  Suppose the responder then replies, but uses MD5 to form the
>CertID term corresponding to the same certificate.  Then the matching of the
>CertID term between request and response becomes less trivial than a simple
>binary comparison.

Anecdotal evidence (that chap again) suggests that everyone uses SHA1
exclusively.  Have you tried submitting a request hashed with MD5 to see how
many servers you can break?

>As mentioned earlier, the complexity of matching certificate identifiers
>between request and response increases in v2, where there are so many other
>ways to identify a certificate.

Yes, but they're all unique (there's only one way to encode an
issuerAndSerialNumber, certificate, etc), a binary compare should do for this.

I'll do a bit of experimenting next week, but I'd be very surprised if a binary
compare failed for any responder.

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: RE: Matching CertIDs between OCSP requests and responses
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 16 Mar 2001 05:20:44 (NZDT)

[email-masked]

>The idea of non-global errors is interesting, I hadn't thought about that. It
>might be useful where multiple certificates are present in the request. 

Is anyone (apart from Identrus, who do it for political/economic rather than
technical reasons) doing this to any extent?  There is anecdotal evidence which
suggests that implementors are using only one cert per query, having multiple
certs per query is hideous in terms of handling responses (let's see now, this
one is OK, this one isn't, we don't know about this one... no, the third one,
not the second one... no that one's OK, you want the one next to it... etc
etc).  Although my code supports the ability to query multiple certs at once, I
haven't enabled it because handling mixed responses is just too messy, it's
much, *much* easier to work with if you do it on the basis of "Is this cert
revoked or not?" rather than "Tell me whatever you can about this bundle of
stuff, and I'll try and figure out what's what from your response".

Peter.

From: [email-masked]
Subject: Re: Matching CertIDs between OCSP requests and responses
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 15 Mar 2001 16:15:13 +0000

Peter, all,

Yes, clearly clients must match certificate identifiers between request and
response.  However, the problem I was trying to highlight was just how this
matching should be performed.

Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it
doesn't say that they MUST use it.  Suppose I send a request, in which my
CertID has used SHA1.  Suppose the responder then replies, but uses MD5 to
form the CertID term corresponding to the same certificate.  Then the
matching of the CertID term between request and response becomes less
trivial than a simple binary comparison.

As mentioned earlier, the complexity of matching certificate identifiers
between request and response increases in v2, where there are so many other
ways to identify a certificate.

The question is: can we trust the responder to use the same form of
certificate identifier as the client specified, so that the trivial binary
comparison of certificate identifier in the client is valid?

This problem is particularly acute in the situation where the responses are
pre-computed rather than being formatted on receipt of the request.

Regards,

Jonathan
---------------
Dr Jonathan Tuliani
www.symbian.com

                    [email-masked]                                                            
                    land.ac.nz             To:     [email-masked]                
                    (Peter Gutmann)        cc:     [email-masked]                           
                    Sent by:               Subject:     Re: Matching CertIDs between OCSP      
                    [email-masked]        requests and responses                              
                    land.ac.nz                                                                 

                    16/03/01 05:07                                                             
                    Please respond                                                             
                    to pgut001                                                                 

[email-masked] writes:

>Another OCSP (v1) question:  Can a client assume that the OCSP response
CertID
>terms will precisely match those from the request?

I would hope they do, otherwise there's a trivial attack which completely
defeats OCSP:

- You submit a request for a check of cert X (which has been revoked)
- What arrives at the CA is a request for a check of cert Y (which hasn't)
- You get back a response of "OK"

Unless you check the returned ID data there's no way you can detect this.
What
I'm doing is a binary compare of request and response ID data, if they
differ I
don't trust the response.

(There's a second, slightly less trivial attack which you can perform if
nonces
 aren't used, once I can determine experimentally how well-supported these
are
 in practice (the "no critical extensions" requirement in the spec doesn't
help
 much with this) I'll see if I can make them mandatory in my code).

Peter.

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re:  Matching CertIDs between OCSP requests and responses
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 16 Mar 2001 05:07:11 (NZDT)

[email-masked] writes:

>Another OCSP (v1) question:  Can a client assume that the OCSP response CertID
>terms will precisely match those from the request?  

I would hope they do, otherwise there's a trivial attack which completely
defeats OCSP:

- You submit a request for a check of cert X (which has been revoked)
- What arrives at the CA is a request for a check of cert Y (which hasn't)
- You get back a response of "OK"

Unless you check the returned ID data there's no way you can detect this.  What
I'm doing is a binary compare of request and response ID data, if they differ I
don't trust the response.

(There's a second, slightly less trivial attack which you can perform if nonces
 aren't used, once I can determine experimentally how well-supported these are
 in practice (the "no critical extensions" requirement in the spec doesn't help
 much with this) I'll see if I can make them mandatory in my code).

Peter.

Date: Thu, 15 Mar 2001 14:43:55 +0100
From: Joerg Seidel <[email-masked]>
Organization: timeproof GmbH
To: Prashant Dambe <[email-masked]>
CC: [email-masked]
Subject: Re: Time-stamp issue

Prashant,

Prashant Dambe wrote:
> In the time critical situation this will not work. Suppose Time-stamp is
> taken at some time t1. At time t1 signer cert
> is valid (not revoked / not expired) and after some time t2 original
> time-stamp has been replaced with time inside
> TS as t2. At at time t2 suppose signer cert is not valid (revoked/expired)
> in this case, original evidence which says
> that cert is valid at t1 so you can trust the signature and also data at the
> time t1. But if Timestamp token is replaced
> indicates that revoked certicate can not be used to validate the signature
> which is one of purpose of time-stamp.
> In this case you can not say wheather time-stamp is trusted or replaced. If
> you assume it was valid TS then it
> will leads to wrong results.

No, it does not. Because the correct statement is: "I don't know whether
this signature is valid or not.". This is simply, because someone
removed the proof that it was made before expiration time. Adding a
later timestamp doesn't change this situation.

> Also vice-versa of above situation is also
> possible.
> So at least , if the attack is detected it will not lead to wrong results.

As stated above there are no wrong results.

Joerg
-- 
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

From: Michael Zolotarev <[email-masked]>
To: Prashant Dambe <[email-masked]>, Joerg Seidel <[email-masked]>
Cc: [email-masked]
Subject: RE: Time-stamp issue
Date: Thu, 15 Mar 2001 23:37:58 +1100

Folks,

As I have noted in my previous email, the substitution of the timestamp
makes no sence for neither the signer, no the verifier, as presumably both
of them are keen to preserve NR qualities of the signature and corresponding
verification process.

It leaves us with the Man-in-the-middle and an attacker modifying the
signature/timestamp when it is kept in some local storage. As for the M-i-M
(a timestamp replaced when the signature was in transit), the attack will be
instantly obvious by comparing the dates. Not to mention that the signature
must be sent much later after it has been originally created, in order for
the attacker to be able to obtain newer timestamp.

For the local storage case, I think it leaves it up to the owner of the
signature with attached timestamp how to protect it from been maliciously
modified.

Michael

> From: Prashant Dambe [mailto:[email-masked]]
> Sent: Thursday, 15 March 2001 22:53
> To: Joerg Seidel
> Cc: [email-masked]
> Subject: Re: Time-stamp issue
> 
> 
> In the time critical situation this will not work. Suppose 
> Time-stamp is
> taken at some time t1. At time t1 signer cert
> is valid (not revoked / not expired) and after some time t2 original
> time-stamp has been replaced with time inside
> TS as t2. At at time t2 suppose signer cert is not valid 
> (revoked/expired)
> in this case, original evidence which says
> that cert is valid at t1 so you can trust the signature and 
> also data at the
> time t1. But if Timestamp token is replaced
> indicates that revoked certicate can not be used to validate 
> the signature
> which is one of purpose of time-stamp.
> In this case you can not say wheather time-stamp is trusted 
> or replaced. If
> you assume it was valid TS then it
> will leads to wrong results. Also vice-versa of above 
> situation is also
> possible.
> So at least , if the attack is detected it will not lead to 
> wrong results.
> 
> ----- Original Message -----
> From: Joerg Seidel <[email-masked]>
> To: Prashant Dambe <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, March 15, 2001 4:57 PM
> Subject: Re: Time-stamp issue
> 
> 
> Prashant,
> 
> Prashant Dambe wrote:
> > As timestamp token is placed as unsigned attribute, one of the
> > possible attack is that
> > if Time-stamp token it self is replaced with the Time-stamp token of
> > the same signature value
> > inside CMS  i.e If the same signature is time-stamped after 
> some later
> > time and Time-stamp in the
> > original CMS is replaced,it not possibled to detect that orignal
> > time-stamp has been replaced.
> > So putting time-stamp as unsigned attribute not works fine in all
> > cases.
> 
> This is not an attack which leads to false evidence. Even the new
> timestamp states correctly that the signature was made before 
> the given
> time. Just you destroy some evidence, which is something you 
> always can
> do.
> 
> Regards
> Joerg
> --
> __________________________________________________________________
> 
> Jörg Seidel                             phone  +49-40-76629-1911
> Director Technology                     fax    +49-40-76629-551
> timeproof GmbH
> Harburger Schloßstraße 6-12             mailto:[email-masked]
> DE 21079 Hamburg                        http://www.timeproof.de
> __________________________________________________________________
> 
> 
> 
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 

Date: Thu, 15 Mar 2001 12:58:30 +0100
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: Re: Time-stamp issue

Prashant Dambe wrote:

> But what happens in the following scenario.As timestamp token is
> placed as unsigned attribute, one of the possible attack is thatif
> Time-stamp token it self is replaced with the Time-stamp token of the
> same signature valueinside CMS  i.e If the same signature is
> time-stamped after some later time and Time-stamp in theoriginal CMS
> is replaced,it not possibled to detect that orignal time-stamp has
> been replaced.

[I'm saying the same thing as Joerg, but more explicitly]

-- Yes, this attack would be possible, but in that case anyway you have
a serious problem.
The person that could do that, coud also do a "del *.*" or "rm -r *" on
your data, and getting out any signed message to prove anything would be
difficult for you after that.

If you think it's possible that someone changes data on your local
storage, are not able to avoid this, but still want to see it happened,
you need to sign it once more.

-- A time-stamp proves a data existed at a certain date, but can not
prove anything about how long before that time it started to exist, and
no change in the protocol will modify that.

If you manage to get back the original time-stamp (for example from the
TSA logs), you will have proven your data did exist at that earlier
date.

-- There's no way to change this situation, except signing the data
again, as I already wrote.

I might be wrong , but I believe you think it would be better if the
time-stamp was calculated over the content of the signed message, and
then included as a signed attributes, before signing the message, as it
would provide this intrusion detection feature

But this would not be the time-stamping of the signature of your message
anymore.

Anyone could remove your signature of the message, put his own, and
claim to be the author, keeping your original time-stamp inside the
message.

----------- About Zolotarev's answer :
- Yes, including a CMS signingTime attribute is a good idea, if a good
date is available locally.
There can be cases where none is available, so we can talk about this
cases.

- "the verifier attaches a timestamp as an evidenceof his own
verification process -
"I have obtained and verified that signature at that time, and the
signature was valid".

What are we talking about ? A TSA in the TSP protocol signs a hash and
does no such verification.
Appendix A of TSP does not describe any such verification.

If a TSA does this, it will need to include an extension in the
time-stamp to say it did it, and so that the difference with the
"normal" time-stamps it produces can be made, and it will need also to
define a request protocol to get the full signature message, and not
just the hash in this case.
But we are strongly getting away of the TSP in this case.

The attack by itself is perfectly feasible in TSP.

From: "Prashant Dambe" <[email-masked]>
To: "Joerg Seidel" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Time-stamp issue
Date: Thu, 15 Mar 2001 17:23:00 +0530

In the time critical situation this will not work. Suppose Time-stamp is
taken at some time t1. At time t1 signer cert
is valid (not revoked / not expired) and after some time t2 original
time-stamp has been replaced with time inside
TS as t2. At at time t2 suppose signer cert is not valid (revoked/expired)
in this case, original evidence which says
that cert is valid at t1 so you can trust the signature and also data at the
time t1. But if Timestamp token is replaced
indicates that revoked certicate can not be used to validate the signature
which is one of purpose of time-stamp.
In this case you can not say wheather time-stamp is trusted or replaced. If
you assume it was valid TS then it
will leads to wrong results. Also vice-versa of above situation is also
possible.
So at least , if the attack is detected it will not lead to wrong results.

----- Original Message -----
From: Joerg Seidel <[email-masked]>
To: Prashant Dambe <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 15, 2001 4:57 PM
Subject: Re: Time-stamp issue

Prashant,

Prashant Dambe wrote:
> As timestamp token is placed as unsigned attribute, one of the
> possible attack is that
> if Time-stamp token it self is replaced with the Time-stamp token of
> the same signature value
> inside CMS  i.e If the same signature is time-stamped after some later
> time and Time-stamp in the
> original CMS is replaced,it not possibled to detect that orignal
> time-stamp has been replaced.
> So putting time-stamp as unsigned attribute not works fine in all
> cases.

This is not an attack which leads to false evidence. Even the new
timestamp states correctly that the signature was made before the given
time. Just you destroy some evidence, which is something you always can
do.

Regards
Joerg
--
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

Date: Thu, 15 Mar 2001 12:27:25 +0100
From: Joerg Seidel <[email-masked]>
Organization: timeproof GmbH
To: Prashant Dambe <[email-masked]>
CC: [email-masked]
Subject: Re: Time-stamp issue

Prashant,

Prashant Dambe wrote:
> As timestamp token is placed as unsigned attribute, one of the
> possible attack is that
> if Time-stamp token it self is replaced with the Time-stamp token of
> the same signature value
> inside CMS  i.e If the same signature is time-stamped after some later
> time and Time-stamp in the
> original CMS is replaced,it not possibled to detect that orignal
> time-stamp has been replaced.
> So putting time-stamp as unsigned attribute not works fine in all
> cases.

This is not an attack which leads to false evidence. Even the new
timestamp states correctly that the signature was made before the given
time. Just you destroy some evidence, which is something you always can
do.

Regards
Joerg
-- 
__________________________________________________________________

Jörg Seidel                             phone  +49-40-76629-1911
Director Technology                     fax    +49-40-76629-551
timeproof GmbH                          
Harburger Schloßstraße 6-12             mailto:[email-masked]
DE 21079 Hamburg                        http://www.timeproof.de
__________________________________________________________________

From: Michael Zolotarev <[email-masked]>
To: Prashant Dambe <[email-masked]>, [email-masked]
Subject: RE: Time-stamp issue
Date: Thu, 15 Mar 2001 21:13:07 +1100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0AD38.87FAAC60
Content-Type: text/plain;
	charset="iso-8859-1"

Prashant,
 
A signature may also contain the CMS signingTime attribute, which is defined
as an authenticated attribute. if a signer adds the SigningTime attribute to
the signature, and then attaches a timestamp, the time in the timestamp must
be close enough to the time specified by the attribute. All assuming that a
timestamp is obtained soon after signing, of course.
 
Therefore, replacing a 'correct' timestamp with the one generated later in
the future, will be easily detectable.
 
But in general, I dont' think that the threat is there at all:
 
A timestamp can be attached to the signature by either the signer or by a
verifier. Why would the signer want to twick his own signature? I dont'
think he would. Now, the verifier: the verifier attaches a timestamp as an
evidence of his own verification process - "I have obtained and verified
that signature at that time, and the signature was valid". What would be a
reason for the verifier to play with his own evidence? I don't see any
practical reason for it.
 
Regards
Michael

-----Original Message-----
From: Prashant Dambe [mailto:[email-masked]]
Sent: Thursday, 15 March 2001 20:26
To: [email-masked]
Subject: Time-stamp issue

As specified in the draft-ietf-pkix-time-stamp-13.txt.
APPENDIX A - Signature Timestamp attribute using CMS
One of the major use of time stamping is to time stamp a digital signature
to prove that the digital signature was created before 
a given time. Should the corresponding public key certificate be revoked
this allows to know whether the signature was created before or after ther
evocation date.
A sensible place to store a time stamp is in a [CMS] structure as an
unsigned attribute.
 
But what happens in the following scenario.
As timestamp token is placed as unsigned attribute, one of the possible
attack is that 
if Time-stamp token it self is replaced with the Time-stamp token of the
same signature value
inside CMS  i.e If the same signature is time-stamped after some later time
and Time-stamp in the 
original CMS is replaced,it not possibled to detect that orignal time-stamp
has been replaced.
So putting time-stamp as unsigned attribute not works fine in all cases.
 
Thanks
Prashant Dambe.

This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

------_=_NextPart_001_01C0AD38.87FAAC60
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.50.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2>Prashant,</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff size=2>A 
signature may also contain the CMS&nbsp;signingTime attribute, which is defined 
as an authenticated attribute. if a signer adds the SigningTime attribute to the 
signature, and then attaches a timestamp, the time in the timestamp must be 
close enough to the time specified by the attribute. All&nbsp;assuming that a 
timestamp is obtained soon after signing, of course.</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2>Therefore, replacing a 'correct' timestamp with the one generated later 
in the future, will be easily detectable.</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff size=2>But in 
general, I dont' think that the threat is there at all:</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff size=2>A 
timestamp can be attached to the signature&nbsp;by either the signer or by a 
verifier. Why would the signer want to twick his own signature? I dont' think he 
would. Now, the verifier: the verifier attaches a timestamp as an evidence of 
his own verification process - "I have obtained and verified that signature at 
that time, and the signature was valid". What would be a reason for the verifier 
to play with his own evidence? I don't see any practical reason for 
it.</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2>Regards</FONT></SPAN></DIV>
<DIV><SPAN class=217215809-15032001><FONT face=Arial color=#0000ff 
size=2>Michael</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Prashant Dambe 
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, 15 March 2001 
  20:26<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Time-stamp 
  issue<BR><BR></FONT></DIV>
  <DIV><FONT face=Arial size=2>As specified in the 
  draft-ietf-pkix-time-stamp-13.txt.</FONT></DIV>
  <DIV><FONT face=Arial size=2>APPENDIX A - Signature Timestamp attribute using 
  CMS</FONT></DIV>
  <DIV><FONT face=Arial size=2>One of the major use of time stamping is to time 
  stamp a digital signature to prove that the digital signature was created 
  before <BR>a given time. Should the corresponding public key certificate be 
  revoked this allows to know whether the signature was created before or after 
  ther evocation date.</FONT></DIV>
  <DIV><FONT face=Arial size=2>A sensible place to store a time stamp is in a 
  [CMS] structure as an unsigned attribute.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>But what happens in the following 
  scenario.</FONT></DIV>
  <DIV><FONT face=Arial size=2>As timestamp token is placed as unsigned 
  attribute, one of the possible attack is that </FONT></DIV>
  <DIV><FONT face=Arial size=2>if Time-stamp token it self is replaced with the 
  Time-stamp token of the same signature value</FONT></DIV>
  <DIV><FONT face=Arial size=2>inside CMS&nbsp;&nbsp;i.e If the same signature 
  is time-stamped after some later time and Time-stamp in the </FONT></DIV>
  <DIV><FONT face=Arial size=2>original CMS is replaced,</FONT><FONT face=Arial 
  size=2>it not possibled to detect that orignal time-stamp has been 
  replaced.</FONT></DIV>
  <DIV><FONT face=Arial size=2>So putting time-stamp as unsigned attribute not 
  works fine in all cases.</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>Thanks</FONT></DIV>
  <DIV><FONT face=Arial size=2>Prashant Dambe.</FONT></DIV><CODE><FONT 
  size=3><BR><BR>This footnote confirms that this email message has been swept 
  by<BR>MIMEsweeper for the presence of computer 
viruses.<BR></BLOCKQUOTE></FONT></CODE></BODY></HTML>

------_=_NextPart_001_01C0AD38.87FAAC60--

From: "Prashant Dambe" <[email-masked]>
To: <[email-masked]>
Subject: Time-stamp issue
Date: Thu, 15 Mar 2001 14:56:17 +0530

This is a multi-part message in MIME format.

------=_NextPart_000_002E_01C0AD60.16F00BF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As specified in the draft-ietf-pkix-time-stamp-13.txt.
APPENDIX A - Signature Timestamp attribute using CMS
One of the major use of time stamping is to time stamp a digital =
signature to prove that the digital signature was created before=20
a given time. Should the corresponding public key certificate be revoked =
this allows to know whether the signature was created before or after =
the revocation date.
A sensible place to store a time stamp is in a [CMS] structure as an =
unsigned attribute.

But what happens in the following scenario.
As timestamp token is placed as unsigned attribute, one of the possible =
attack is that=20
if Time-stamp token it self is replaced with the Time-stamp token of the =
same signature value
inside CMS  i.e  If the same signature is time-stamped after some later =
time and Time-stamp in the=20
original CMS is replaced,it not possibled to detect that orignal =
time-stamp has been replaced.
So putting time-stamp as unsigned attribute not works fine in all cases.

Thanks
Prashant Dambe.

------=_NextPart_000_002E_01C0AD60.16F00BF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>As specified in the=20
draft-ietf-pkix-time-stamp-13.txt.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>APPENDIX A - Signature Timestamp =
attribute using=20
CMS</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>One of the major use of time stamping =
is to time=20
stamp a digital signature to prove that the digital signature was =
created before=20
<BR>a given time. Should the corresponding public key certificate be =
revoked=20
this allows to know whether the signature was created before or after =
the=20
revocation date.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>A sensible place to store a time stamp =
is in a=20
[CMS] structure as an unsigned attribute.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>But what happens in the following=20
scenario.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>As timestamp token is placed as =
unsigned attribute,=20
one of the possible attack is that </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>if Time-stamp token it self is replaced =
with the=20
Time-stamp token of the same signature value</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>inside CMS&nbsp;&nbsp;i.e  If the same =
signature is=20
time-stamped after some later time and Time-stamp in the </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>original CMS is replaced,</FONT><FONT =
face=3DArial=20
size=3D2>it not possibled to detect that orignal time-stamp has been=20
replaced.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>So putting time-stamp as unsigned =
attribute not=20
works fine in all cases.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Prashant =
Dambe.</FONT></DIV></BODY></HTML>

------=_NextPart_000_002E_01C0AD60.16F00BF0--

Date: Thu, 15 Mar 2001 00:35:13 -0500
To: [email-masked]
From: Ari Kermaier <[email-masked]>
Subject: draft-ietf-pkix-rfc2510bis-03
Cc: Carlisle Adams <[email-masked]>

Dear All,

I'm seeking clarification of the challenge-response proof-of-possession 
protocol in CMP. The POP challenge is defined in section 3.2.8 as follows:

      Challenge ::= SEQUENCE {
          owf                 AlgorithmIdentifier  OPTIONAL,
          -- MUST be present in the first Challenge; MAY be omitted in any
          -- subsequent Challenge in POPODecKeyChallContent (if omitted,
          -- then the owf used in the immediately preceding Challenge is
          -- to be used).
          witness             OCTET STRING,
          -- the result of applying the one-way function (owf) to a
          -- randomly-generated INTEGER, A.  [Note that a different
          -- INTEGER MUST be used for each Challenge.]
          challenge           OCTET STRING
          -- the encryption (under the public key for which the cert.
          -- request is being made) of Rand, where Rand is specified as
          --   Rand ::= SEQUENCE {
          --      int      INTEGER,
          --       - the randomly-generated INTEGER A (above)
          --      sender   GeneralName
          --       - the sender's name (as included in PKIHeader)
          --   }
      }

1) What is the purpose of including the sender's name in the sequence to be 
encrypted? Does it guard against some sort of attack?

2) Since it is quite possible that the DER encoding of the Rand sequence 
will have length greater than k-11 octets, where k is the length of the RSA 
public modulus (for the RSA key case), what method should be used for 
performing this encryption and formatting the contents of the challenge 
OCTET STRING?

Any help would be most appreciated.

Ari Kermaier
Phaos Technology

From: [email-masked]
To: <[email-masked]>
Subject: Tires of Cable TV raising there rates!!!
Date: Wed, 14 Mar 2001 16:22:54 -0600
Reply-To: [email-masked]

Tired of Cable TV raising their rates!!!
   Get Satellite TV
   YES ---YOU CAN WATCH DIFFERENT CHANNELS ON MULTIPLE TV'S
   YES ---YOU CAN GET LOCAL STATIONS
   Order Dish Network System with a one year plan, get FREE two receivers
   and the 18" Dish with FREE basic professional installation.

   Why Bother? For $40.99 Get both receivers and the Top 100 Stations!
   With only one receiver and the Dish $35.99  Local Channels add $5.00

   You will be charged a one time $49.99 fee when you order which includes
   your  first months service for FREE.
   THAT S IT!
   FLIP TO SATELLITE... ITS DIGITAL.. ITS GREAT...
   YOU'LL LOVE IT.
   Ready? Order by phone 1-888-235-5285 or e-mail us [email-masked]

   REQUIREMENT- 1. One year service commitment.
   2. Major credit Card
   3. Southwest exposure to the sky.

   to be remove from future mailings e-mail us with the word "remove" in the  subject lineat --- [email-masked]

Tired of Cable TV raising their rates!!!
   Get Satellite TV
   YES ---YOU CAN WATCH DIFFERENT CHANNELS ON MULTIPLE TV'S
   YES ---YOU CAN GET LOCAL STATIONS
   Order Dish Network System with a one year plan, get FREE two receivers
   and the 18" Dish with FREE basic professional installation.

   Why Bother? For $40.99 Get both receivers and the Top 100 Stations!

From: [email-masked]
Subject: RE: Matching CertIDs between OCSP requests and responses
To: "Michael Myers" <[email-masked]>
Cc: [email-masked]
Date: Wed, 14 Mar 2001 16:40:15 +0000

Mike,

Thanks for the reply.  I think my use of the phrase 'server error' was
perhaps misleading:  what I mean is, has the server behaved in a
non-compliant manner if a certificate from the request is missing from the
response (or, for that matter, if the response contains information about a
certificate not present in the request).  That is, is doing so an improper
response?

The idea of non-global errors is interesting, I hadn't thought about that.
It might be useful where multiple certificates are present in the request.
The most likely case I can think of is where the OCSP server is acting in
request-forwarding mode, splitting a request and farming it out to several
other servers, which in turn may return differing error states.  It would
be a pity to simply throw out the valid information and return an error
just because one of the second-level servers did.

Regards,

Jonathan

                    "Michael                                                                 
                    Myers"               To:     <[email-masked]>,             
                    <myers@coasts        <[email-masked]>                                 
                    ide.net>             cc:                                                 
                                         Subject:     RE: Matching CertIDs between OCSP      
                    14/03/01             requests and responses                              
                    16:38                                                                    

Jonathan,

You are correct in your assumptions.  One point of clarification however.

Server errors appear in the mandatory responseStatus field of OCSPResponse
and not the optional responseBytes field in order to ensure that a server
will produce *some* type of feedback in the event of an error.

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

Given that, such errors speak to the server's response as a whole and not
to
individual certificates in the instance when multiple certificates are
identified in a single request and corresponding response (the latter via
SingleResponse syntax).

In other words, we assumed that the type of server problems enumerated in
OCSPResponseStatus would be global with respect a request regardless of
whether or not that request addressed a single certificate or multiple
certificates.

In the context of the v2 work, I'd be very interested to hear if your
implementation experience leads to a need for error states at the
SingleResponse level.

Your point regarding certificate identification matching in the v2 case is
well noted.

Mike

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 4:25 AM
> To: [email-masked]
> Subject: Matching CertIDs between OCSP requests and responses
>
>
> All,
>
> Another OCSP (v1) question:  Can a client assume that the OCSP response
> CertID terms will precisely match those from the request?  That is, can
it
> assume
> 1 - that every certificate in the request will be in the response (i.e.
> it's a server error otherwise)
> 2 - that the hashing algorithm in the response CertIDs will be the same
as
> that which was used in the request (that is, the CertID data will match
> byte-for-byte between request and response).
>
> I guess given the variety of identifiers available alongside
> CertID in OCSP
> v2 that the issue of matching identifiers between request and response
> raised in point 2 above will be even more critical there.  But that's for
> other people to worry about - it's v1 I'm interested in for now.
>
> Thanks,
>
> Jonathan
> ----------------
> Dr Jonathan Tuliani
> www.symbian.com
>
>
>
> Symbian Ltd is a company registered in England and Wales with
> registered number 01796587 and registered office at 19 Harcourt
> Street, London, W1H 4HF, UK.
> This message is intended only for use by the named addressee and
> may contain privileged and/or confidential information. If you
> are not the named addressee you should not disseminate, copy or
> take any action in reliance on it. If you have received this
> message in error please notify [email-masked] and delete
> the message and any attachments accompanying it immediately.
> Symbian does not accept liability for any corruption,
> interception, amendment, tampering or viruses occuring to this
> message in transit or for any message sent by its employees which
> is not in compliance with Symbian corporate policy.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Matching CertIDs between OCSP requests and responses
Date: Wed, 14 Mar 2001 08:38:31 -0800
Importance: Normal

Jonathan,

You are correct in your assumptions.  One point of clarification however.

Server errors appear in the mandatory responseStatus field of OCSPResponse
and not the optional responseBytes field in order to ensure that a server
will produce *some* type of feedback in the event of an error.

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

Given that, such errors speak to the server's response as a whole and not to
individual certificates in the instance when multiple certificates are
identified in a single request and corresponding response (the latter via
SingleResponse syntax).

In other words, we assumed that the type of server problems enumerated in
OCSPResponseStatus would be global with respect a request regardless of
whether or not that request addressed a single certificate or multiple
certificates.

In the context of the v2 work, I'd be very interested to hear if your
implementation experience leads to a need for error states at the
SingleResponse level.

Your point regarding certificate identification matching in the v2 case is
well noted.

Mike

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 14, 2001 4:25 AM
> To: [email-masked]
> Subject: Matching CertIDs between OCSP requests and responses
>
>
> All,
>
> Another OCSP (v1) question:  Can a client assume that the OCSP response
> CertID terms will precisely match those from the request?  That is, can it
> assume
> 1 - that every certificate in the request will be in the response (i.e.
> it's a server error otherwise)
> 2 - that the hashing algorithm in the response CertIDs will be the same as
> that which was used in the request (that is, the CertID data will match
> byte-for-byte between request and response).
>
> I guess given the variety of identifiers available alongside
> CertID in OCSP
> v2 that the issue of matching identifiers between request and response
> raised in point 2 above will be even more critical there.  But that's for
> other people to worry about - it's v1 I'm interested in for now.
>
> Thanks,
>
> Jonathan
> ----------------
> Dr Jonathan Tuliani
> www.symbian.com
>
>
>
> Symbian Ltd is a company registered in England and Wales with
> registered number 01796587 and registered office at 19 Harcourt
> Street, London, W1H 4HF, UK.
> This message is intended only for use by the named addressee and
> may contain privileged and/or confidential information. If you
> are not the named addressee you should not disseminate, copy or
> take any action in reliance on it. If you have received this
> message in error please notify [email-masked] and delete
> the message and any attachments accompanying it immediately.
> Symbian does not accept liability for any corruption,
> interception, amendment, tampering or viruses occuring to this
> message in transit or for any message sent by its employees which
> is not in compliance with Symbian corporate policy.

From: [email-masked]
Subject: Matching CertIDs between OCSP requests and responses
To: [email-masked]
Cc: 
Date: Wed, 14 Mar 2001 12:24:32 +0000

All,

Another OCSP (v1) question:  Can a client assume that the OCSP response
CertID terms will precisely match those from the request?  That is, can it
assume
1 - that every certificate in the request will be in the response (i.e.
it's a server error otherwise)
2 - that the hashing algorithm in the response CertIDs will be the same as
that which was used in the request (that is, the CertID data will match
byte-for-byte between request and response).

I guess given the variety of identifiers available alongside CertID in OCSP
v2 that the issue of matching identifiers between request and response
raised in point 2 above will be even more critical there.  But that's for
other people to worry about - it's v1 I'm interested in for now.

Thanks,

Jonathan
----------------
Dr Jonathan Tuliani
www.symbian.com

Date: Wed, 14 Mar 2001 01:26:06 -0800 (PST)
From: Hahaha <[email-masked]>
Subject: Snowhite and the Seven Dwarfs - The REAL story!

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

Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and
polite with Snowhite. When they go out work at mornign, they promissed a 
*huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven
Dwarfs enter...

----VEIFKPA7CPQ78LIVGPYN
Content-Type: application/octet-stream; name="sexy virgin.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="sexy virgin.scr"

----VEIFKPA7CPQ78LIVGPYN--

Date: Wed, 14 Mar 2001 03:49:26 -0500 (EST)
From: "'IT Virus Filter'" <[email-masked]>
To: <[email-masked]>
Subject: Suspicious email message intercepted

Hello-

You are receiving this message because an email message with a
suspicious attachment was intercepted by the POP server.  It
is possible that the message was actually valid, and simply
shared some common features with email viruses such as the
'lovebug' virus.

	Replies to [email-masked] are not read; this
is an automated process to facilitate forwarding the executable
attachment. You must follow these instructions exactly in order
for the software to forward the email.

If you can confirm that this is indeed a valid email message,
and not a virus, then simply respond to this message, pasting the
following information into the Subject: field (copied exactly, all
on one line, starting with "Message re-delivery ..."):

Message re-delivery request -200103140843-AAA16647-above-proper-com-_16451_0

Some identifying information about the message:
	Sender:		Hahaha <[email-masked]>
	Subject:	Enanito si, pero con que pedazo!
	Attachment:	"enano.exe"

We realize that this process is somewhat cumbersome, but, given the
amount of damage that can be caused by email viruses, this is less
disruptive in the long run.

Please send email to <[email-masked]> if you have any questions
or concerns.

Thank you-
Genuity IT

Date: Wed, 14 Mar 2001 00:43:13 -0800 (PST)
From: Hahaha <[email-masked]>
Subject: Enanito si, pero con que pedazo!

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

Faltaba apenas un dia para su aniversario de de 18 años. Blanca de Nieve fuera
siempre muy bien cuidada por los enanitos. Ellos le prometieron una *grande*
sorpresa para su fiesta de compleaños. Al entardecer, llegaron. Tenian un brillo
incomun en los ojos...

----VEVOXQV4LEV
Content-Type: application/octet-stream; name="enano.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="enano.exe"

----VEVOXQV4LEV--

Date: Tue, 13 Mar 2001 14:13:53 -0500
To: Ambarish Malpani <[email-masked]>, "'Dr S N Henson'" <[email-masked]>, [email-masked]
From: Ari Kermaier <[email-masked]>
Subject: RE: Computation of issuerKeyHash in OCSP

We did interop vs. Valicert OCSP responder using the hash of the bytes of 
the DER encoding of the publicKey, and had no trouble. (This should be 
identical to the BIT STRING value from the subjectPublicKeyInfo minus 
header and unused bits, and is considerably simpler to think about.)

Ari Kermaier
Phaos Technology

>Peter, Steve, (and many other people),
>     I am sorry, I screwed up.
>
>     We are hashing the bit string *without* the number of
>unused bits. This is what we have been using in all the interop
>testing that we have done up to now.
>
>I apologize for my mistake.
>
>Regards,
>Ambarish
>
> > From: Dr S N Henson [mailto:[email-masked]]
> > Sent: Monday, March 12, 2001 3:40 PM
> > To: [email-masked]
> > Subject: Re: Computation of issuerKeyHash in OCSP
> >
> >
> > Peter Gutmann wrote:
> > >
> > > Ambarish Malpani <[email-masked]> writes:
> > >
> > > >I have done interop testing of the OCSP responder with
> > Netscape, CertCo, Xeti
> > > >(now part of Critical Path), Computer Associates and a
> > bunch of other folks. I
> > > >would be very surprised if anybody was stripping out the
> > byte that represented
> > > >the number of unused bits.
> > >
> > > That would explain why my previously-working code was
> > getting a status of
> > > "unknown" all of a sudden... dammit, make one little update
> > to your code
> > > without thinking and... :-).
> > >
> >
> > I was stripping the number of unused bits out too: well with
> > OpenSSL/SSLeay that's the more natural thing to do(*). It is
> > also one of
> > the recommended mechanisms in RFC2459 (4.2.1.2) and I didn't
> > notice the
> > difference.
> >
> > AFAICS using the number of unused bits will just mean that a '0' is
> > prepended to the data hashed for any valid encoding.
> >
> > I was getting valid responses from the responders I'd tried which
> > suggests that either they are ignoring the issuerKeyHash or they are
> > also ignoring the number of unused bits.
> >
> > (*) In case anyone is curious... the OpenSSL/SSLeay structure
> > for a BIT
> > STRING consists of a buffer, a length value and some flags. The buffer
> > is the BIT STRING *without* the number of unused bits. The
> > actual number
> > of unused bits is stored in part of the flags field.
> >
> > Steve.
> > --
> > Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> > Personal Email: [email-masked]
> > Senior crypto engineer, Celo Communications: http://www.celocom.com/
> > Core developer of the   OpenSSL project: http://www.openssl.org/
> > Business Email: [email-masked] PGP key: via homepage.
> >

Date: Mon, 12 Mar 2001 22:01:55 -0500
From: Rich Salz <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Computation of issuerKeyHash in OCSP

> I've also got another question about the spec which comes from playing with
> various responders, the implementation requirement that "Certificates SHOULD
> NOT contain an AIA extension specifying the responder URL.  If they do contain
> a responder URL, this MUST NOT match the actual responder URL" seems to have
> been left out of the draft.  Is this an unwritten convention followed by
> implementors which is worth documenting?

If you came looking for an argument, you'll have to go down the door to
the CA people.  The OCSP responder people rarely create certificates --
too frightening.  And while it's tempting for ORP's to move their URL
about arbitrarily, it's not common.
	/r$

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Computation of issuerKeyHash in OCSP
Sender: [email-masked]
Reply-To: [email-masked]
Date: Tue, 13 Mar 2001 15:28:27 (NZDT)

Dr S N Henson <[email-masked]> writes:

>I was getting valid responses from the responders I'd tried which suggests
>that either they are ignoring the issuerKeyHash or they are also ignoring the
>number of unused bits.

If I could find a responder to get a reply from (the usual suspects seem to be
unreachable/dead at the moment) I'd like to test this to see whether you can
submit a broken issuerKeyHash, from earlier testing against one of them I found
that you did have to get the hash right (that's how I did the trial-and-error
discovery of what was required, I figured the issuer name hash couldn't be
wrong and started playing with hashing/not hashing bits of the key until I
didn't get an "unknown" response any more).  OTOH the issuerKeyHash isn't
absolutely necessary since (depending on the implementation) you can get the
same information from the issuerNameHash.

I've also got another question about the spec which comes from playing with
various responders, the implementation requirement that "Certificates SHOULD
NOT contain an AIA extension specifying the responder URL.  If they do contain
a responder URL, this MUST NOT match the actual responder URL" seems to have
been left out of the draft.  Is this an unwritten convention followed by
implementors which is worth documenting?

Peter :-).

Content-return: allowed
Date: Mon, 12 Mar 2001 17:48:32 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Computation of issuerKeyHash in OCSP
To: "'Dr S N Henson'" <[email-masked]>, [email-masked]

Peter, Steve, (and many other people),
    I am sorry, I screwed up.

    We are hashing the bit string *without* the number of
unused bits. This is what we have been using in all the interop
testing that we have done up to now.

I apologize for my mistake.

Regards,
Ambarish

> From: Dr S N Henson [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 3:40 PM
> To: [email-masked]
> Subject: Re: Computation of issuerKeyHash in OCSP
> 
> 
> Peter Gutmann wrote:
> > 
> > Ambarish Malpani <[email-masked]> writes:
> > 
> > >I have done interop testing of the OCSP responder with 
> Netscape, CertCo, Xeti
> > >(now part of Critical Path), Computer Associates and a 
> bunch of other folks. I
> > >would be very surprised if anybody was stripping out the 
> byte that represented
> > >the number of unused bits.
> > 
> > That would explain why my previously-working code was 
> getting a status of
> > "unknown" all of a sudden... dammit, make one little update 
> to your code
> > without thinking and... :-).
> > 
> 
> I was stripping the number of unused bits out too: well with
> OpenSSL/SSLeay that's the more natural thing to do(*). It is 
> also one of
> the recommended mechanisms in RFC2459 (4.2.1.2) and I didn't 
> notice the
> difference.
> 
> AFAICS using the number of unused bits will just mean that a '0' is
> prepended to the data hashed for any valid encoding.
> 
> I was getting valid responses from the responders I'd tried which
> suggests that either they are ignoring the issuerKeyHash or they are
> also ignoring the number of unused bits.
> 
> (*) In case anyone is curious... the OpenSSL/SSLeay structure 
> for a BIT
> STRING consists of a buffer, a length value and some flags. The buffer
> is the BIT STRING *without* the number of unused bits. The 
> actual number
> of unused bits is stored in part of the flags field.
> 
> Steve.
> -- 
> Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> Personal Email: [email-masked] 
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [email-masked] PGP key: via homepage.
> 

Date: Mon, 12 Mar 2001 23:39:46 +0000
From: Dr S N Henson <[email-masked]>
Organization: S N Henson
To: [email-masked]
Subject: Re: Computation of issuerKeyHash in OCSP

Peter Gutmann wrote:
> 
> Ambarish Malpani <[email-masked]> writes:
> 
> >I have done interop testing of the OCSP responder with Netscape, CertCo, Xeti
> >(now part of Critical Path), Computer Associates and a bunch of other folks. I
> >would be very surprised if anybody was stripping out the byte that represented
> >the number of unused bits.
> 
> That would explain why my previously-working code was getting a status of
> "unknown" all of a sudden... dammit, make one little update to your code
> without thinking and... :-).
> 

I was stripping the number of unused bits out too: well with
OpenSSL/SSLeay that's the more natural thing to do(*). It is also one of
the recommended mechanisms in RFC2459 (4.2.1.2) and I didn't notice the
difference.

AFAICS using the number of unused bits will just mean that a '0' is
prepended to the data hashed for any valid encoding.

I was getting valid responses from the responders I'd tried which
suggests that either they are ignoring the issuerKeyHash or they are
also ignoring the number of unused bits.

(*) In case anyone is curious... the OpenSSL/SSLeay structure for a BIT
STRING consists of a buffer, a length value and some flags. The buffer
is the BIT STRING *without* the number of unused bits. The actual number
of unused bits is stored in part of the flags field.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

Date: Mon, 12 Mar 2001 15:15:08 -0800 (PST)
From: Hahaha <[email-masked]>
Subject: Snowhite and the Seven Dwarfs - The REAL story!

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

Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and
polite with Snowhite. When they go out work at mornign, they promissed a 
*huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven
Dwarfs enter...

----VE0PYFGPUJOD2JCL6JC9AZGDIBC123ST6VSH
Content-Type: application/octet-stream; name="sexy virgin.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="sexy virgin.scr"

----VE0PYFGPUJOD2JCL6JC9AZGDIBC123ST6VSH--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Computation of issuerKeyHash in OCSP
Sender: [email-masked]
Reply-To: [email-masked]
Date: Tue, 13 Mar 2001 11:57:31 (NZDT)

Ambarish Malpani <[email-masked]> writes:

>I have done interop testing of the OCSP responder with Netscape, CertCo, Xeti
>(now part of Critical Path), Computer Associates and a bunch of other folks. I
>would be very surprised if anybody was stripping out the byte that represented
>the number of unused bits.

That would explain why my previously-working code was getting a status of
"unknown" all of a sudden... dammit, make one little update to your code
without thinking and... :-).

Peter.

Content-return: allowed
Date: Mon, 12 Mar 2001 14:15:21 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Computation of issuerKeyHash in OCSP
To: "[email-masked]'" <[email-masked]>, [email-masked]

Hi Jonathan,
    I have done interop testing of the OCSP responder with
Netscape, CertCo, Xeti (now part of Critical Path), Computer
Associates and a bunch of other folks. I would be very surprised
if anybody was stripping out the byte that represented the
number of unused bits.

With regards to the OCSPv2 identifiers, I still haven't seen or
heard of any implementations....

Hope this helps,
Regards,
Ambarish

> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 10:59 AM
> To: [email-masked]
> Subject: RE: Computation of issuerKeyHash in OCSP
> 
> 
> 
> All,
> 
> From Ambarish we have:
> 
> Yes, it is the hash of the entire BIT STRING, including the 'number of
> unused bits' octet (but excluding the tag for BIT STRING and length).
> 
> And from Peter we have:
> 
> The weird hashing is a perpetual source of trouble for implementors (I
> eventually found it out by trial and error), what you need to 
> do is take
> the BIT STRING part of the subjectPublicKeyInfo, strip off 
> the BIT STRING
> tag and the length and the unused-bits value, and hash what's left.
> 
> It's seems that different views on my original question have 
> been taken by
> different people.  I understand that the revised specs iron 
> all this out,
> but in the meantime, what do people actually do in practice?
> 
> Jonathan Tuliani
> www.Symbian.com
> 
> 
> 
> Symbian Ltd is a company registered in England and Wales with 
> registered number 01796587 and registered office at 19 
> Harcourt Street, London, W1H 4HF, UK.
> This message is intended only for use by the named addressee 
> and may contain privileged and/or confidential information. 
> If you are not the named addressee you should not 
> disseminate, copy or take any action in reliance on it. If 
> you have received this message in error please notify 
> [email-masked] and delete the message and any 
> attachments accompanying it immediately. Symbian does not 
> accept liability for any corruption, interception, amendment, 
> tampering or viruses occuring to this message in transit or 
> for any message sent by its employees which is not in 
> compliance with Symbian corporate policy.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Computation of issuerKeyHash in OCSP
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Tue, 13 Mar 2001 11:10:12 (NZDT)

"Michael Myers" <[email-masked]> writes:

>So only in the case of CertID is issuerKeyHash calculation required.  The
>issuerSerial options imports IssuerandSerialNumber syntax from CMS.  Do these
>actions address the points you raised?

Absolutely, that's why in my original reply I expressed the hope that people
would move to v2 ID's with all haste.

Peter.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Computation of issuerKeyHash in OCSP
Date: Mon, 12 Mar 2001 14:07:53 -0800
Importance: Normal

Peter,

The OCSPv2 I-D expands certificate identification as follows:

ReqCert  ::= CHOICE {
   certID            CertID,
   issuerSerial      [0] IssuerandSerialNumber,
   pKCert            [1] Certificate,
   name              [2] GeneralName,
   certHash          [3] OCTET STRING}

CertID          ::=     SEQUENCE {
   hashAlgorithm       AlgorithmIdentifier,
   issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
   issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
   serialNumber        CertificateSerialNumber }

So only in the case of CertID is issuerKeyHash calculation required.  The
issuerSerial options imports IssuerandSerialNumber syntax from CMS.  Do
these actions address the points you raised?

Mike

> Sent: Tuesday, March 13, 2001 4:50 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Computation of issuerKeyHash in OCSP
>
>
> >I'd be grateful for clarification of the following point, regarding the
> >computation of the issuerKeyHash term in the CertID information
> used in OCSP
> >(v1).
>
> The weird hashing is a perpetual source of trouble for implementors (I
> eventually found it out by trial and error), what you need to do
> is take the
> BIT STRING part of the subjectPublicKeyInfo, strip off the BIT
> STRING tag and
> the length and the unused-bits value, and hash what's left.  A much easier
> solution (and one I hope everyone adopts with all haste) is to
> use v2 ID's such
> as the standard issuerAndSerialNumber or a cert hash (aka
> thumbprint) which
> most software seems to be able to handle.
>
> Peter.
>
>

From: [email-masked]
Subject: RE: Computation of issuerKeyHash in OCSP
To: [email-masked]
Cc: 
Date: Mon, 12 Mar 2001 18:58:53 +0000

All,

>From Ambarish we have:

Yes, it is the hash of the entire BIT STRING, including the 'number of
unused bits' octet (but excluding the tag for BIT STRING and length).

And from Peter we have:

The weird hashing is a perpetual source of trouble for implementors (I
eventually found it out by trial and error), what you need to do is take
the BIT STRING part of the subjectPublicKeyInfo, strip off the BIT STRING
tag and the length and the unused-bits value, and hash what's left.

It's seems that different views on my original question have been taken by
different people.  I understand that the revised specs iron all this out,
but in the meantime, what do people actually do in practice?

Jonathan Tuliani
www.Symbian.com

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re:  Computation of issuerKeyHash in OCSP
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Tue, 13 Mar 2001 04:50:03 (NZDT)

>I'd be grateful for clarification of the following point, regarding the
>computation of the issuerKeyHash term in the CertID information used in OCSP
>(v1).

The weird hashing is a perpetual source of trouble for implementors (I
eventually found it out by trial and error), what you need to do is take the
BIT STRING part of the subjectPublicKeyInfo, strip off the BIT STRING tag and
the length and the unused-bits value, and hash what's left.  A much easier
solution (and one I hope everyone adopts with all haste) is to use v2 ID's such
as the standard issuerAndSerialNumber or a cert hash (aka thumbprint) which
most software seems to be able to handle.

Peter.

Content-return: allowed
Date: Mon, 12 Mar 2001 07:33:32 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Computation of issuerKeyHash in OCSP
To: "[email-masked]'" <[email-masked]>, [email-masked]

Hi Jonathan,
    Yes, it is the hash of the entire BIT STRING, including the
'number of unused bits' octet (but excluding the tag for BIT STRING
and length).

This has been clarified in the draft of what will go forward as
a candidate for Draft Standard.

Regards,
Ambarish

> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 2:55 AM
> To: [email-masked]
> Subject: Computation of issuerKeyHash in OCSP
> 
> 
> All,
> 
> I'd be grateful for clarification of the following point, 
> regarding the
> computation of the issuerKeyHash term in the CertID 
> information used in
> OCSP (v1).
> 
> The OCSP spec states:
> 
> 'issuerKeyHash is the hash of the Issuer's public key. The 
> hash shall be
> calculated over the value (excluding tag and length) of the 
> subject public
> key field in the issuer's certificate.'
> 
> Note that subjectPublicKey is defined as having ASN1 type BIT 
> STRING.  Can
> someone specify whether the *entire* 'value' part of this encoded bit
> string should be used, including the 'number of unused bits' octet, or
> whether the 'number of unused bits' octet should be excluded, 
> and only the
> remaining value octets should be used.
> 
> Many thanks in advance,
> 
> Jonathan Tuliani
> www.Symbian.com
> 
> 
> 
> Symbian Ltd is a company registered in England and Wales with 
> registered number 01796587 and registered office at 19 
> Harcourt Street, London, W1H 4HF, UK.
> This message is intended only for use by the named addressee 
> and may contain privileged and/or confidential information. 
> If you are not the named addressee you should not 
> disseminate, copy or take any action in reliance on it. If 
> you have received this message in error please notify 
> [email-masked] and delete the message and any 
> attachments accompanying it immediately. Symbian does not 
> accept liability for any corruption, interception, amendment, 
> tampering or viruses occuring to this message in transit or 
> for any message sent by its employees which is not in 
> compliance with Symbian corporate policy.

Date: Mon, 12 Mar 2001 16:33:19 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-new-part1-05.txt

Tim,

Would it be possible to get some indications about the differences between
version -04 and version -05 ?

... as well as the changes still to be discussed ?

Thanks,

Denis

> 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
>                           and CRL Profile
>         Author(s)       : R. Housley, W. Ford, W. Polk, D. Solo
>         Filename        : draft-ietf-pkix-new-part1-05.txt
>         Pages           : 119
>         Date            : 08-Mar-01
> 
> This is the fourth draft of a specification based upon RFC 2459.
> When complete, this specification will obsolete RFC 2459.  This
> specification includes minor edits and clarifications.  The most
> notable departures from RFC 2459 are found in Section 6, Path
> Validation.  In RFC 2459, the reader was expected to augment the path
> validation algorithm, which concentrated upon policy processing, with
> information embedded in earlier sections.  For example, parameter
> inheritance is discussed in Section 7, Algorithm Support, and can
> certainly affect the validity of a certification path.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-05.txt
> 
> Internet-Drafts are also 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-new-part1-05.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-pkix-new-part1-05.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]>

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: RFC 2511bis EncryptedValue OPTIONAL intendedAlg Field
Date: Mon, 12 Mar 2001 09:55:44 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0AB04.837FBEE0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Francois,

> ----------
> From:
> [email-masked][SMTP:[email-masked]]
> Sent: 	Monday, March 12, 2001 8:34 AM
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	RFC 2511bis EncryptedValue OPTIONAL intendedAlg Field
> 
> Hi Carlisle,
> 
> I know we exchanged few Emails on this particular issue in July last year,
> but it seems I overlooked the final question in your previous response
> below. 
> 
> Again I am not sure if I am missing something, but when thinking further
> about the wrapping and unwrapping of private keys, I have noted that the
> comment for the EncryptedValue under both Section 6.4 and Appendix C of
> RFC
> 2511bis still indicates that when the encValue field contains an encrypted
> PrivateKeyInfo, the intendedAlg field is unnecessary (since this
> information
> is included in PrivateKeyInfo) and MUST be omitted.  As indicated before,
> the information included in PrivateKeyInfo once through the PKCS #11
> C_WrapKey function is all encrypted.  This means that any information
> about
> the intended algorithm for the private key is no longer available until
> the
> PrivateKeyInfo is decrypted (i.e. unwrapped).
> 
> In response to your previous question, the C_UnwrapKey function from
> Section
> 11.14 of PKCS #11 does everything in one call and consequently all the
> necessary information it requires needs to be known at priori.  However,
> the
> problem in this case is that the C_UnwrapKey needs to know the template
> for
> the private key (i.e. the type of the private key) that will be unwrapped
> as
> part of its syntax.  The only source for this particular information would
> seem to be the EncryptedValue intendedAlg field since the PrivateKeyInfo
> privateKeyAlgorithm field is still encrypted.
> 
> Since the intendedAlg field MUST already be present when encValue contains
> some other format/encoding for the private key, I would suggest changing
> the
> intendedAlg field from OPTIONAL to mandatory for all cases or to indicate
> that it MUST also be present when the encValue field contains an encrypted
> PrivateKeyInfo.
> 
> Does this seem appropriate?
 
I have no problem with this as long as the implementors have no objections.
I can change the text to something like "The intendedAlg field MUST be
present unless this information is known a priori to both sender and
receiver by some other means."

Does this raise concerns for anyone?

Carlisle.

> Cheers,
> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> One Chrysalis Way
> Ottawa, Ontario, CANADA, K2G 6P9
> [email-masked]    Tel. (613) 723-5076 ext. 3419
> http://www.chrysalis-its.com   Fax. (613) 723-5078 
> 
> 
> From: Carlisle Adams [mailto:[email-masked]]
> Sent: Monday, July 17, 2000 14:54
> To: [email-masked]'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Re: CRMF encValue Field
> 
> 
> Hi Francois,
> 
> [snip]
> 
> > In addition, this same clarification indicates that in this case, the
> > intendedAlg field is unnecessary (since this information is included in
> > PrivateKeyInfo) and MUST be omitted. However, the algorithm identifier
> > field within the PrivateKeyInfo is encrypted, which means that the
> > "EncryptedValue" type would not contain any information in the clear
> about
> > the OID of the private key that it is carrying. Was this your intend,
> > please clarify? I also understand that including the intendedAlg field
> > would duplicate the occurrence of the parameters field, since the syntax
> > of the "AlgorithmIdentifier" type also contains a "parameters" field,
> > however by still indicating the algorithm OID, but forcing the
> > "parameters" field within the intendedAlg field to be NULL would allow
> the
> > "EncryptedValue" type to indicate what is the OID of the private key
> that
> > it is carrying, but not duplicate the parameters field. Wouldn't this
> > approach be better?
>  
> No, this approach doesn't strike me as particularly better.  It seems like
> a
> real kludge to include an AlgId for the same thing twice, but to specify
> (in
> commentary) that the parameters should be NULL for one of these and
> non-NULL
> (i.e., present) for the other.  This reduces clarity for the
> reader/implementer and may run in to trouble with some compilers that are
> expecting actual parameter values.
> 
> As for fact that the AlgId in PrivateKeyInfo is encrypted, why is this a
> concern?  Does the receiver need to know this prior to decryption?
> 
> Carlisle.
> 

------_=_NextPart_001_01C0AB04.837FBEE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: RFC 2511bis EncryptedValue OPTIONAL intendedAlg =
Field</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Francois,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked][SMTP:[email-masked]]</FO=
NT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, March 12, 2001 8:34 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]; [email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RFC 2511bis EncryptedValue OPTIONAL intendedAlg Field</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Carlisle,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I know we exchanged few Emails on this =
particular issue in July last year,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">but it seems I overlooked the final =
question in your previous response</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">below. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Again I am not sure if I am missing =
something, but when thinking further</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">about the wrapping and unwrapping of =
private keys, I have noted that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">comment for the EncryptedValue under =
both Section 6.4 and Appendix C of RFC</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">2511bis still indicates that when the =
encValue field contains an encrypted</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PrivateKeyInfo, the intendedAlg field =
is unnecessary (since this information</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is included in PrivateKeyInfo) and =
MUST be omitted.&nbsp; As indicated before,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the information included in =
PrivateKeyInfo once through the PKCS #11</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">C_WrapKey function is all =
encrypted.&nbsp; This means that any information about</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the intended algorithm for the =
private key is no longer available until the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PrivateKeyInfo is decrypted (i.e. =
unwrapped).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In response to your previous question, =
the C_UnwrapKey function from Section</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">11.14 of PKCS #11 does everything in =
one call and consequently all the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">necessary information it requires =
needs to be known at priori.&nbsp; However, the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">problem in this case is that the =
C_UnwrapKey needs to know the template for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the private key (i.e. the type of the =
private key) that will be unwrapped as</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">part of its syntax.&nbsp; The only =
source for this particular information would</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">seem to be the EncryptedValue =
intendedAlg field since the PrivateKeyInfo</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">privateKeyAlgorithm field is still =
encrypted.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Since the intendedAlg field MUST =
already be present when encValue contains</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">some other format/encoding for the =
private key, I would suggest changing the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">intendedAlg field from OPTIONAL to =
mandatory for all cases or to indicate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that it MUST also be present when the =
encValue field contains an encrypted</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PrivateKeyInfo.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Does this seem appropriate?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I have no =
problem with this as long as the implementors have no objections.&nbsp; =
I can change the text to something like &quot;The intendedAlg field =
MUST be present unless this information is known a priori to both =
sender and receiver by some other means.&quot;</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Does this =
raise concerns for anyone?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Francois</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">___________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Francois Rousseau</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Director of Standards and =
Conformance</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">One Chrysalis Way</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Ottawa, Ontario, CANADA, K2G =
6P9</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">[email-masked]&nbsp;&nbsp;&nbsp; Tel. (613) =
723-5076 ext. 3419</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A></FONT></U><FONT =
SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Fax. (613) 723-5078 </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Carlisle Adams [</FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:[email-masked]">mailto:carlisle.adams@entrust=
.com</A></FONT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Monday, July 17, 2000 =
14:54</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
[email-masked]'</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cc: [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: RE: Re: CRMF encValue =
Field</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Francois,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">[snip]</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; In addition, this same =
clarification indicates that in this case, the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; intendedAlg field is unnecessary =
(since this information is included in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; PrivateKeyInfo) and MUST be =
omitted. However, the algorithm identifier</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; field within the PrivateKeyInfo =
is encrypted, which means that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;EncryptedValue&quot; type =
would not contain any information in the clear about</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the OID of the private key that =
it is carrying. Was this your intend,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; please clarify? I also =
understand that including the intendedAlg field</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; would duplicate the occurrence =
of the parameters field, since the syntax</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; of the =
&quot;AlgorithmIdentifier&quot; type also contains a =
&quot;parameters&quot; field,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; however by still indicating the =
algorithm OID, but forcing the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;parameters&quot; field =
within the intendedAlg field to be NULL would allow the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;EncryptedValue&quot; type =
to indicate what is the OID of the private key that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; it is carrying, but not =
duplicate the parameters field. Wouldn't this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; approach be better?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">No, this approach doesn't strike me =
as particularly better.&nbsp; It seems like a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">real kludge to include an AlgId for =
the same thing twice, but to specify (in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">commentary) that the parameters =
should be NULL for one of these and non-NULL</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(i.e., present) for the other.&nbsp; =
This reduces clarity for the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">reader/implementer and may run in to =
trouble with some compilers that are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">expecting actual parameter =
values.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As for fact that the AlgId in =
PrivateKeyInfo is encrypted, why is this a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">concern?&nbsp; Does the receiver need =
to know this prior to decryption?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carlisle.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C0AB04.837FBEE0--

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RFC 2511bis EncryptedValue OPTIONAL intendedAlg Field
Date: Mon, 12 Mar 2001 08:34:44 -0500

Hi Carlisle,

I know we exchanged few Emails on this particular issue in July last year,
but it seems I overlooked the final question in your previous response
below. 

Again I am not sure if I am missing something, but when thinking further
about the wrapping and unwrapping of private keys, I have noted that the
comment for the EncryptedValue under both Section 6.4 and Appendix C of RFC
2511bis still indicates that when the encValue field contains an encrypted
PrivateKeyInfo, the intendedAlg field is unnecessary (since this information
is included in PrivateKeyInfo) and MUST be omitted.  As indicated before,
the information included in PrivateKeyInfo once through the PKCS #11
C_WrapKey function is all encrypted.  This means that any information about
the intended algorithm for the private key is no longer available until the
PrivateKeyInfo is decrypted (i.e. unwrapped).

In response to your previous question, the C_UnwrapKey function from Section
11.14 of PKCS #11 does everything in one call and consequently all the
necessary information it requires needs to be known at priori.  However, the
problem in this case is that the C_UnwrapKey needs to know the template for
the private key (i.e. the type of the private key) that will be unwrapped as
part of its syntax.  The only source for this particular information would
seem to be the EncryptedValue intendedAlg field since the PrivateKeyInfo
privateKeyAlgorithm field is still encrypted.

Since the intendedAlg field MUST already be present when encValue contains
some other format/encoding for the private key, I would suggest changing the
intendedAlg field from OPTIONAL to mandatory for all cases or to indicate
that it MUST also be present when the encValue field contains an encrypted
PrivateKeyInfo.

Does this seem appropriate?

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
One Chrysalis Way
Ottawa, Ontario, CANADA, K2G 6P9
[email-masked]    Tel. (613) 723-5076 ext. 3419
http://www.chrysalis-its.com   Fax. (613) 723-5078 

-----Original Message-----
From: Carlisle Adams [mailto:[email-masked]]
Sent: Monday, July 17, 2000 14:54
To: [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: RE: Re: CRMF encValue Field

Hi Francois,

[snip]

> In addition, this same clarification indicates that in this case, the
> intendedAlg field is unnecessary (since this information is included in
> PrivateKeyInfo) and MUST be omitted. However, the algorithm identifier
> field within the PrivateKeyInfo is encrypted, which means that the
> "EncryptedValue" type would not contain any information in the clear about
> the OID of the private key that it is carrying. Was this your intend,
> please clarify? I also understand that including the intendedAlg field
> would duplicate the occurrence of the parameters field, since the syntax
> of the "AlgorithmIdentifier" type also contains a "parameters" field,
> however by still indicating the algorithm OID, but forcing the
> "parameters" field within the intendedAlg field to be NULL would allow the
> "EncryptedValue" type to indicate what is the OID of the private key that
> it is carrying, but not duplicate the parameters field. Wouldn't this
> approach be better?
 
No, this approach doesn't strike me as particularly better.  It seems like a
real kludge to include an AlgId for the same thing twice, but to specify (in
commentary) that the parameters should be NULL for one of these and non-NULL
(i.e., present) for the other.  This reduces clarity for the
reader/implementer and may run in to trouble with some compilers that are
expecting actual parameter values.

As for fact that the AlgId in PrivateKeyInfo is encrypted, why is this a
concern?  Does the receiver need to know this prior to decryption?

Carlisle.

From: [email-masked]
Subject: Computation of issuerKeyHash in OCSP
To: [email-masked]
Cc: 
Date: Mon, 12 Mar 2001 10:55:17 +0000

All,

I'd be grateful for clarification of the following point, regarding the
computation of the issuerKeyHash term in the CertID information used in
OCSP (v1).

The OCSP spec states:

'issuerKeyHash is the hash of the Issuer's public key. The hash shall be
calculated over the value (excluding tag and length) of the subject public
key field in the issuer's certificate.'

Note that subjectPublicKey is defined as having ASN1 type BIT STRING.  Can
someone specify whether the *entire* 'value' part of this encoded bit
string should be used, including the 'number of unused bits' octet, or
whether the 'number of unused bits' octet should be excluded, and only the
remaining value octets should be used.

Many thanks in advance,

Jonathan Tuliani
www.Symbian.com

Date: Mon, 12 Mar 2001 11:04:15 +0100
From: Bodo Moeller <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-pkix-ipki-pkalgs-02.txt: ECDSA

On Mon, Mar 12, 2001 at 10:38:19AM +0100, Bodo Moeller wrote:

> According to draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.2.3,
> 
>    When the ecdsa-with-SHA1 algorithm identifier is used the parameters
>    MUST be NULL.
> 
> However section 2.3.5 specifies what the parameters should look like:
> 
>    ECDSA and ECDH require use of certain parameters with the public key.
>    The parameters may be inherited from the issuer, implicitly included
>    through reference to a "named curve," or explicitly included in the
>    certificate.
> 
>       ecpkParameters ::= CHOICE {
>         ecParameters  ECParameters,
>         namedCurve    OBJECT IDENTIFIER,
>         implicitlyCA  NULL }
> 
> Presumably 2.2.3 was meant to say that parameters are not OPTIONAL
> for ecdsa-with-SHA1, and that hence they must be NULL if there
> is no explicit value.

As the introduction to section 2.2 makes clear, the quote from 2.2.3
is intended to only apply to 'parameters' fields of
'AlgorithmIdentifier's used in 'signatureAlgorithm' fields of
certificate, but not to the 'subjectPublicKeyInfo' case.
Similarly to 2.2.3, section 2.2.2 states that

   When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in an AlgorithmIdentifier, the encoding SHALL omit the
   parameters field.  That is, the AlgorithmIdentifier shall be a
   SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.

This too is misleading because AlgorithmIdentifiers appear not only
in 'signatureAlgorithm' fields, but also in 'subjectPublicKeyInfo' fields.

So the paragraph in section 2.2.2 should say something like

   When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in a signatureAlgorithm field, the encoding SHALL omit the
   parameters field.  That is, the signatureAlgorithm field shall be a
   SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.

Similarly, the above quote from section 2.2.3 could be changed to

    When the ecdsa-with-SHA1 algorithm identifier appears as the
    algorithm field in a signatureAlgorithm field, the parameters
    MUST be NULL.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Mon, 12 Mar 2001 10:38:19 +0100
From: Bodo Moeller <[email-masked]>
To: [email-masked]
Subject: draft-ietf-pkix-ipki-pkalgs-02.txt: ECDSA

According to draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.2.3,

   When the ecdsa-with-SHA1 algorithm identifier is used the parameters
   MUST be NULL.

However section 2.3.5 specifies what the parameters should look like:

   ECDSA and ECDH require use of certain parameters with the public key.
   The parameters may be inherited from the issuer, implicitly included
   through reference to a "named curve," or explicitly included in the
   certificate.

      ecpkParameters ::= CHOICE {
        ecParameters  ECParameters,
        namedCurve    OBJECT IDENTIFIER,
        implicitlyCA  NULL }

Presumably 2.2.3 was meant to say that parameters are not OPTIONAL
for ecdsa-with-SHA1, and that hence they must be NULL if there
is no explicit value.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Sun, 11 Mar 2001 21:53:20 -0800
From: Aram Perez <[email-masked]>
Subject: KeyUsage Clarifications (was Open Issue in Part1: path length constraints)
To: PKIX <[email-masked]>

David P. Kemp wrote:

> I've never seen any benefit of the cA flag in the basicConstraints
> extension; it's just a vestigial appendix left over from when there
> was no keyUsage extension.
> 
> Consider the following certificates:
> 
> #  cA   CertSign  cRLSign    Effect
> - ----- --------  -------   ------------
> 0  F     0         0        End Entity
> 1  F     0         1        End Entity (can sign CRLs)
> 2  F     1         0        End Entity
> 3  F     1         1        End Entity (can sign CRLs)
> 4  T     0         0    (Illegal*) Is a CA but can't sign certs or CRLs
> 5  T     0         1    (Illegal*) Is a CA, can sign CRLs only
> 6  T     1         0        CA, can sign certs
> 7  T     1         1        CA, can sign certs and CRLs
> 
> * As Dave S. points out, 4.2.1.10 prohibits cert types 4 and 5.
> 
> Is there any benefit to having eight different certificate types
> instead of just four?   In my example of the online CRL signer, what is
> accomplished by setting CA=true (cert #5) instead of CA=false (cert #1)?
> You say you would set it to indicate that the CRL issuer is a CA, but
> what would the application do with that knowledge? (i.e. what would it
> do differently than if the CA flag were false?)
> 
> More generally, is there any reason why Section 4.2.1.10 should
> not also prohibit cert types 2 and 3? (in other words, require the
> keyCertSign bit to always equal the cA flag?).

A while back I requested wording that would clarify which combinations of
keyUsage bits are valid and which are not. I'm glad you are also raising the
issue, maybe something will be done about it this time.

Regards,
Aram Perez

From: David Cross <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Last Call: Son-of-2459
Date: Sat, 10 Mar 2001 12:45:40 -0800

I think we are in agreement.  I just did not want us to do down the path of
unconstraining name and policy constraints when cross certificates are
generated.

David B. Cross

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2001 7:25 AM
To: David Cross; [email-masked]
Cc: [email-masked]
Subject: RE: WG Last Call: Son-of-2459

>Steve:
>
>->Anyway, since it is clear that not all folks will issue cross certs
>as I suggested, I have to admit to liking the fallback position of
>allowing specification of name constraints as part of the validation 
>procedure, on a per trust anchor basis. The main argument I've seen 
>is the one that questions whether this should be a user configurable 
>parameter, or an administrative parameter, or whether this is a MAY 
>(vs. SHOULD/MUST), which allows vendors to ignore the facility 
>entirely.
>
>I would strongly disagree against allowing name constraints to be a 
>user configurable parameter.  This defeats the administrative value and 
>assurance that name constraints provide.
>
>David B. Cross

David, I'm not sure that I understand your point.  Name constraints only 
constrain, they can't "unconstrain".  So if the user (or the MIS department)
can specify a name constraint as a configurable parameter, that can only
tighten the noose, not loosen it.

So how does this defeat the administrative value name constraints provide?
Maybe I'm missing something, but I've always liked the idea of the user 
acting as the root CA of last resort, since as the relying party it is the
user, and normally not some third-party CA, that has to make the decision as
to 
whether or not to honor a digital signature and certificate chain.

I believe the same logic applies to policy OID constraints, by the way.

Bob

From: Felix <[email-masked]>
To: [email-masked]
Date: Sat, 10 Mar 2001 08:58:17 +0300
Subject: =?windows-1251?Q?Re:_=C2=FB_=ED=E5_=EE=E4=E8=ED,_=EA=F2=EE_=F5=EE=F7=E5=F2_=FD=F2=EE_=F1=E4=E5=EB=E0=F2=FC!?=
Reply-To: [email-masked]

Âû íå îäèí, êòî õî÷åò óëó÷øèòü ñâîå áëàãîñîñòîÿíèå!

Íå íàäî èñêàòü ñëîæíûõ ïóòåé ðåøåíèÿ âàøèõ ôèíàíñîâûõ ïðîáëåì. 
Ïîäóìàéòå ãîëîâîé, âåäü äåíüãè âåðòÿòñÿ âîêðóã  âàñ, íàäî ïðîñòî ñóìåòü èõ âçÿòü!
Òîëüêî ëåíèâûé áûâàåò áåäíûì.

Óñëîâèå - óìåòü èëè íàó÷èòüñÿ ðàáîòàòü ñ ýëåêòðîííûìè äåíåæíûìè ñ÷åòàìè è
ñîâñåì ìàëîñòü ðàçáèðàòüñÿ â áóõãàëòåðèè. Âñå.

Íå ïîëåíèòåñü, çàéäèòå íà íàø SITE, 
óâåðåí îñòàíåòåñü äîâîëüíû, èíôîðìàöèÿ åùå íèêîìó íå ìåøàëà.

http://incolor.hypermart.net/stats

mailto:[email-masked] Ôåëèêñ.

Date: Fri, 09 Mar 2001 20:11:36 -0600
To: "Carlin Covey" <[email-masked]>
From: Steve Tuecke <[email-masked]>
Subject: RE: Impersonation Certificates - proofing IC requesters
Cc: <[email-masked]>

Our intended use of ICs in the Globus Project has not been for delegating 
signature authority from one human being to another.  Instead, it has been 
used to allow a human to delegate signature authority to his or her various 
processes running throughout a distributed computing system (aka. a "Grid").

-Steve

At 04:38 PM 3/9/2001  Friday, Carlin Covey wrote:
>Thanks, Steve.  That does clarify things.
>
>So impersonation certificates are not intended to be used for
>delegating signature authority from one human being to another?
>
>Regards,
>
>Carlin
>
>_____________________________________________
>- Carlin Covey
>   Cylink Corporation
>
>From: Steve Tuecke [mailto:[email-masked]]
>Sent: Friday, March 09, 2001 1:23 PM
>To: Carlin Covey
>Cc: [email-masked]
>Subject: Re: Impersonation Certificates - proofing IC requesters
>
>
>Carlin,
>
>Some examples of when ICs are generally created (in our experience with
>GSI) might help answer your questions:
>
>    1) Creation of a local IC for single sign-on purposes: In this case, the
>creation of the IC is driven entirely by the holder of the EEC.  So there
>is no requester of the IC.  Or I suppose you could say that the requester
>is already holding the EEC and its private key, so proofing is not an issue.
>
>    2) Delegation of an IC to a remote party, for example when starting a
>remote process: This is usually done over a mutually authenticated channel
>with, for example, the remote process starter service, so the issuer knows
>the identity of the starter to whom it is delegating the IC.  In this case,
>the issuer will be checking the identity of the party to whom it is issuing
>the IC for reasons aside from (or in addition to) proofing the IC
>requester. In addition, the IC delegation is usually done as one step of
>some well defined exchange between the parties, so the issuer knows in
>advance that it wants to issue the IC, and it just need to make sure that
>it is issuing it to the right party.  In other words, the issuance of the
>IC is again mostly driven by the issuer (i.e. the holder of the EEC, or of
>an existing IC), and as part of a larger protocol exchange between the
>parties.  So proofing the IC is really just a matter of checking the
>identity coming from the authentication (which you would do anyway), and
>verifying that the IC request does not have anything unexpected in
>it.  Standard message integrity checking on the mutually authenticated
>channel between the parties will prevent man-in-the-middle attacks.
>
>    3) Certificate repository: Suppose that the EEC and its private key are
>held in some sort of certificate/key repository, which will issue an IC
>upon request from a client.  So the questions are, how does the client
>authenticate with the repository, what authorization checks does the
>repository perform before issuing the IC, and how is a man-in-the-middle
>attack prevented?  Client authentication may be handled in a variety of
>ways.  For example, the client can connect to the server and perform server
>only authentication (i.e. it knows the identity of the repository in
>advance).  It can then provide a name/password, one-time-password, or
>something else over the confidential channel.  This password is used to
>authorize the IC issuance, and the IC is delegated back to the client over
>the integrity checked channel to avoid man-in-the-middle.
>
>So I think the answer to your question is that unlike a traditional CA, in
>the situations where we have used ICs effectively, previously issued EECs
>provide for the automatic authentication necessary to allow for automatic
>proofing of the request.
>
>-Steve
>
>At 05:54 PM 3/8/2001  Thursday, Carlin Covey wrote:
> >Gentlepersons,
> >
> >draft-ietf-pkix-impersonation-00.txt describes a mechanism for
> >delegating authority from entity A (who is not a CA) to entity B
> >by issuing an "Impersonation Certificate" (IC) to entity B that
> >is signed using entity A's PKC.
> >
> >Below step 5 of section 2.4. the following text appears:
> >
> >    "The process of creating an IC is as follows:
> >
> >    1. A new public and private key pair is generated.
> >
> >    2. An unsigned IC request is created, conforming to the profile
> >       described in this document.
> >
> >    3. The IC request is signed by the private key of the EEC, or by
> >       another IC.  During this process, the unsigned IC is verified to
> >       ensure that it is valid (e.g. it is not an EEC, the IC fields are
> >       appropriately set, etc).
> >
> >    When an IC is created as part of a delegation from entity A to
> >    entity B, this process is modified by performing steps #1 and #2
> >    within entity B, then passing the IC request from entity B to entity
> >    A over an integrity checked channel, then entity A performs step #3. "
> >
> >[Carlin's comments/questions]:
> >I'm trying to understand some of the security aspects.
> >I don't see any discussion of proofing the IC requester.  How
> >does the EE authenticate the identity of the IC requester?
> >A CA or RA normally has some sort of proofing facilities
> >available that are used to authenticate the identity of a
> >human being (e.g. a database of employee information, some
> >expertise in recognizing legitimate paper identity documents,
> >etc.)  An EE is probably not well-equipped to do this sort
> >of human identity proofing.  Moreover, in the example in
> >section 2.3 the IC requester appears to be some automated
> >process.  How does the EE authenticate the identity of this
> >process?  Even if the EE can authenticate the source of the
> >IC request, how are man-in-the-middle attacks prevented
> >during the IC request process?
> >
> >- Carlin Covey
> >   Cylink Corporation

From: "Carlin Covey" <[email-masked]>
To: "Steve Tuecke" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Impersonation Certificates - finding IC's
Date: Fri, 9 Mar 2001 15:49:08 -0700
Importance: Normal

Steve,

"... not practical or desirable to pass the IC/EEC chain to the RP..."

Well, I don't have any specific scenario in mind, but there is the
wireless/low-bandwidth case that always seems to be lurking around the
corner, but never quite getting here.

I'll be at the IETF in Minneapolis.  I'd like to talk with you.

Regards,
Carlin
_______________________________________
Carlin Covey
Cylink Corporation

-----Original Message-----
From: Steve Tuecke [mailto:[email-masked]]
Sent: Friday, March 09, 2001 1:33 PM
To: Carlin Covey
Cc: [email-masked]
Subject: Re: Impersonation Certificates - finding IC's

In the Globus Toolkit, we use ICs to authenticate a TLS channel, and we
always pass the entire IC/EEC certificate chain during the authentication
handshake.  And whenever we delegate an IC, we pass the whole chain to the
RP.

I would be interested to hear a scenario where it is not practical or
desirable to pass the IC/EEC chain to the RP, or in the authentication
handshake.  And if you have any suggestions for changes that could be made
to support path discovery from a directory (or any other way), I'd love to
hear it.

I'll be in Minneapolis next week if you want to talk more about this in
person...

-Steve

At 08:04 PM 3/8/2001  Thursday, Carlin Covey wrote:
>In section 2.6 of draft-ietf-pkix-impersonation-00.txt the
>following words appear:
>
>    "To discourage mistakes in this area, this Impersonation Certificate
>    profile defines that the IC subject (actually its subjectAltName) is
>    just a pseudo-randomly generated string."
>
>[Carlin's comments/questions]:
>If the IC subject name is a pseudo-randomly generated string, how is the
>IC found in an X.500 or LDAP Directory?  Must it always be passed by the
>application to the RP rather than being found in a directory?
>
>- Carlin Covey
>   Cylink Corporation

From: "Carlin Covey" <[email-masked]>
To: "Steve Tuecke" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Impersonation Certificates - proofing IC requesters
Date: Fri, 9 Mar 2001 15:38:35 -0700
Importance: Normal

Thanks, Steve.  That does clarify things.

So impersonation certificates are not intended to be used for
delegating signature authority from one human being to another?

Regards,

Carlin

_____________________________________________
- Carlin Covey
  Cylink Corporation

-----Original Message-----
From: Steve Tuecke [mailto:[email-masked]]
Sent: Friday, March 09, 2001 1:23 PM
To: Carlin Covey
Cc: [email-masked]
Subject: Re: Impersonation Certificates - proofing IC requesters

Carlin,

Some examples of when ICs are generally created (in our experience with
GSI) might help answer your questions:

   1) Creation of a local IC for single sign-on purposes: In this case, the
creation of the IC is driven entirely by the holder of the EEC.  So there
is no requester of the IC.  Or I suppose you could say that the requester
is already holding the EEC and its private key, so proofing is not an issue.

   2) Delegation of an IC to a remote party, for example when starting a
remote process: This is usually done over a mutually authenticated channel
with, for example, the remote process starter service, so the issuer knows
the identity of the starter to whom it is delegating the IC.  In this case,
the issuer will be checking the identity of the party to whom it is issuing
the IC for reasons aside from (or in addition to) proofing the IC
requester. In addition, the IC delegation is usually done as one step of
some well defined exchange between the parties, so the issuer knows in
advance that it wants to issue the IC, and it just need to make sure that
it is issuing it to the right party.  In other words, the issuance of the
IC is again mostly driven by the issuer (i.e. the holder of the EEC, or of
an existing IC), and as part of a larger protocol exchange between the
parties.  So proofing the IC is really just a matter of checking the
identity coming from the authentication (which you would do anyway), and
verifying that the IC request does not have anything unexpected in
it.  Standard message integrity checking on the mutually authenticated
channel between the parties will prevent man-in-the-middle attacks.

   3) Certificate repository: Suppose that the EEC and its private key are
held in some sort of certificate/key repository, which will issue an IC
upon request from a client.  So the questions are, how does the client
authenticate with the repository, what authorization checks does the
repository perform before issuing the IC, and how is a man-in-the-middle
attack prevented?  Client authentication may be handled in a variety of
ways.  For example, the client can connect to the server and perform server
only authentication (i.e. it knows the identity of the repository in
advance).  It can then provide a name/password, one-time-password, or
something else over the confidential channel.  This password is used to
authorize the IC issuance, and the IC is delegated back to the client over
the integrity checked channel to avoid man-in-the-middle.

So I think the answer to your question is that unlike a traditional CA, in
the situations where we have used ICs effectively, previously issued EECs
provide for the automatic authentication necessary to allow for automatic
proofing of the request.

-Steve

At 05:54 PM 3/8/2001  Thursday, Carlin Covey wrote:
>Gentlepersons,
>
>draft-ietf-pkix-impersonation-00.txt describes a mechanism for
>delegating authority from entity A (who is not a CA) to entity B
>by issuing an "Impersonation Certificate" (IC) to entity B that
>is signed using entity A's PKC.
>
>Below step 5 of section 2.4. the following text appears:
>
>    "The process of creating an IC is as follows:
>
>    1. A new public and private key pair is generated.
>
>    2. An unsigned IC request is created, conforming to the profile
>       described in this document.
>
>    3. The IC request is signed by the private key of the EEC, or by
>       another IC.  During this process, the unsigned IC is verified to
>       ensure that it is valid (e.g. it is not an EEC, the IC fields are
>       appropriately set, etc).
>
>    When an IC is created as part of a delegation from entity A to
>    entity B, this process is modified by performing steps #1 and #2
>    within entity B, then passing the IC request from entity B to entity
>    A over an integrity checked channel, then entity A performs step #3. "
>
>[Carlin's comments/questions]:
>I'm trying to understand some of the security aspects.
>I don't see any discussion of proofing the IC requester.  How
>does the EE authenticate the identity of the IC requester?
>A CA or RA normally has some sort of proofing facilities
>available that are used to authenticate the identity of a
>human being (e.g. a database of employee information, some
>expertise in recognizing legitimate paper identity documents,
>etc.)  An EE is probably not well-equipped to do this sort
>of human identity proofing.  Moreover, in the example in
>section 2.3 the IC requester appears to be some automated
>process.  How does the EE authenticate the identity of this
>process?  Even if the EE can authenticate the source of the
>IC request, how are man-in-the-middle attacks prevented
>during the IC request process?
>
>- Carlin Covey
>   Cylink Corporation

Date: Fri, 09 Mar 2001 14:33:09 -0600
To: "Carlin Covey" <[email-masked]>
From: Steve Tuecke <[email-masked]>
Subject: Re: Impersonation Certificates - finding IC's
Cc: <[email-masked]>

In the Globus Toolkit, we use ICs to authenticate a TLS channel, and we 
always pass the entire IC/EEC certificate chain during the authentication 
handshake.  And whenever we delegate an IC, we pass the whole chain to the RP.

I would be interested to hear a scenario where it is not practical or 
desirable to pass the IC/EEC chain to the RP, or in the authentication 
handshake.  And if you have any suggestions for changes that could be made 
to support path discovery from a directory (or any other way), I'd love to 
hear it.

I'll be in Minneapolis next week if you want to talk more about this in 
person...

-Steve

At 08:04 PM 3/8/2001  Thursday, Carlin Covey wrote:
>In section 2.6 of draft-ietf-pkix-impersonation-00.txt the
>following words appear:
>
>    "To discourage mistakes in this area, this Impersonation Certificate
>    profile defines that the IC subject (actually its subjectAltName) is
>    just a pseudo-randomly generated string."
>
>[Carlin's comments/questions]:
>If the IC subject name is a pseudo-randomly generated string, how is the
>IC found in an X.500 or LDAP Directory?  Must it always be passed by the
>application to the RP rather than being found in a directory?
>
>- Carlin Covey
>   Cylink Corporation

Date: Fri, 09 Mar 2001 14:22:45 -0600
To: "Carlin Covey" <[email-masked]>
From: Steve Tuecke <[email-masked]>
Subject: Re: Impersonation Certificates - proofing IC requesters
Cc: <[email-masked]>

Carlin,

Some examples of when ICs are generally created (in our experience with 
GSI) might help answer your questions:

   1) Creation of a local IC for single sign-on purposes: In this case, the 
creation of the IC is driven entirely by the holder of the EEC.  So there 
is no requester of the IC.  Or I suppose you could say that the requester 
is already holding the EEC and its private key, so proofing is not an issue.

   2) Delegation of an IC to a remote party, for example when starting a 
remote process: This is usually done over a mutually authenticated channel 
with, for example, the remote process starter service, so the issuer knows 
the identity of the starter to whom it is delegating the IC.  In this case, 
the issuer will be checking the identity of the party to whom it is issuing 
the IC for reasons aside from (or in addition to) proofing the IC 
requester. In addition, the IC delegation is usually done as one step of 
some well defined exchange between the parties, so the issuer knows in 
advance that it wants to issue the IC, and it just need to make sure that 
it is issuing it to the right party.  In other words, the issuance of the 
IC is again mostly driven by the issuer (i.e. the holder of the EEC, or of 
an existing IC), and as part of a larger protocol exchange between the 
parties.  So proofing the IC is really just a matter of checking the 
identity coming from the authentication (which you would do anyway), and 
verifying that the IC request does not have anything unexpected in 
it.  Standard message integrity checking on the mutually authenticated 
channel between the parties will prevent man-in-the-middle attacks.

   3) Certificate repository: Suppose that the EEC and its private key are 
held in some sort of certificate/key repository, which will issue an IC 
upon request from a client.  So the questions are, how does the client 
authenticate with the repository, what authorization checks does the 
repository perform before issuing the IC, and how is a man-in-the-middle 
attack prevented?  Client authentication may be handled in a variety of 
ways.  For example, the client can connect to the server and perform server 
only authentication (i.e. it knows the identity of the repository in 
advance).  It can then provide a name/password, one-time-password, or 
something else over the confidential channel.  This password is used to 
authorize the IC issuance, and the IC is delegated back to the client over 
the integrity checked channel to avoid man-in-the-middle.

So I think the answer to your question is that unlike a traditional CA, in 
the situations where we have used ICs effectively, previously issued EECs 
provide for the automatic authentication necessary to allow for automatic 
proofing of the request.

-Steve

At 05:54 PM 3/8/2001  Thursday, Carlin Covey wrote:
>Gentlepersons,
>
>draft-ietf-pkix-impersonation-00.txt describes a mechanism for
>delegating authority from entity A (who is not a CA) to entity B
>by issuing an "Impersonation Certificate" (IC) to entity B that
>is signed using entity A's PKC.
>
>Below step 5 of section 2.4. the following text appears:
>
>    "The process of creating an IC is as follows:
>
>    1. A new public and private key pair is generated.
>
>    2. An unsigned IC request is created, conforming to the profile
>       described in this document.
>
>    3. The IC request is signed by the private key of the EEC, or by
>       another IC.  During this process, the unsigned IC is verified to
>       ensure that it is valid (e.g. it is not an EEC, the IC fields are
>       appropriately set, etc).
>
>    When an IC is created as part of a delegation from entity A to
>    entity B, this process is modified by performing steps #1 and #2
>    within entity B, then passing the IC request from entity B to entity
>    A over an integrity checked channel, then entity A performs step #3. "
>
>[Carlin's comments/questions]:
>I'm trying to understand some of the security aspects.
>I don't see any discussion of proofing the IC requester.  How
>does the EE authenticate the identity of the IC requester?
>A CA or RA normally has some sort of proofing facilities
>available that are used to authenticate the identity of a
>human being (e.g. a database of employee information, some
>expertise in recognizing legitimate paper identity documents,
>etc.)  An EE is probably not well-equipped to do this sort
>of human identity proofing.  Moreover, in the example in
>section 2.3 the IC requester appears to be some automated
>process.  How does the EE authenticate the identity of this
>process?  Even if the EE can authenticate the source of the
>IC request, how are man-in-the-middle attacks prevented
>during the IC request process?
>
>- Carlin Covey
>   Cylink Corporation

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-2797-bis-00.txt
Date: Fri, 09 Mar 2001 14:07:25 -0500
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		: Certificate Management Messages over CMS
	Author(s)	: M. Myers, X. Liu, J. Schaad, J. Weinstein
	Filename	: draft-ietf-pkix-2797-bis-00.txt
	Pages		: 
	Date		: 09-Mar-01
	
This document defines a Certificate Management protocol using CMS
(CMC).  This protocol addresses two immediate needs within the
Internet PKI community:
1. The need for an interface to public key certification products
and    services based on [CMS] and [PKCS10], and
2. The need in [SMIMEV3] for a certificate enrollment protocol for
DSA-signed certificates with Diffie-Hellman public keys.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-2797-bis-00.txt

Internet-Drafts are also 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-2797-bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

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

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

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

--OtherAccess--

--NextPart--

From: Carlisle Adams <[email-masked]>
To: [email-masked], "[email-masked]'" <[email-masked]>
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
Date: Fri, 9 Mar 2001 13:45:59 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A8C9.2F29B810
Content-Type: text/plain

Hi Magnus and Phil,

> ----------
> From: 	Phillip H. Griffin[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Friday, March 09, 2001 8:48 AM
> To: 	[email-masked]
> Cc: 	Carlisle Adams; [email-masked]; [email-masked]'
> Subject: 	Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and
> rfc2511bis-01.txt)
> 
> Magnus and Carlisle,
> A few comments below.
 
(...some text deleted...)

> Magnus Nystrom wrote:
> > 
> >  b) PKIXCRMF imports definitions from both RFC 2459 (bis) and CMS. CMS
> >     in turn, imports definitions from ITU/ISO specifications rather
> >     than PKIX RFCs. Now this would be ok, unless it was for the fact
> >     that RFC 2459bis and RC2511bis use 1988 syntax, as does CMS, but
> >     CMS imports from modules written in 1993 syntax. This creates a
> >     mess for those using commercial compilers, since UTF8Strings (used
> >     in ISO documents but defined explicitly in PKIX documents) aren't
> 
> Actually the situation is even worse than
> described here. The use in IETF modules of
> class UNIVERSAL tags is not valid ASN.1 under
> any version of the ASN.1 standards.
> 
> It is an IETF concoction made up I believe
> to allow old X.208 and X.209 based tools to
> make use of new ASN.1 types never defined 
> in those standards, but defined for years 
> and years now in the current ASN.1 standards.
 
(...some text deleted...)

> >     supported in 1988 but are in 1993, so one cannot compile these
> >     modules with either a "1988" switch or a "1993" switch. My advice
> >     would of course be to move to 1993/1997 ASN.1 altogether, but if
> 
> Agreed. This is the best possible solution.
> Not only does it eliminate the concoction
> noted above, it allows the use of other new 
> types and encoding rules by adopters of IETF
> standards.
 
I sympathize with both your positions here, and if we were starting from
scratch I'd say that it might be worthwhile to try to create a "perfect",
up-to-date ASN.1 module.  However, this specification (begun 5 years ago)
has been actively interop tested for somewhere between 1.5 and 2 years now.
By some miracle, all ten or so independent implementations were able to take
what's listed here as a '"Compilable" ASN.1 Module Using 1988 Syntax' (note
the quotes around "Compilable" in the title of this appendix!), make
whatever tweaks were necessary to get it to compile (without a word of
complaint to the authors of the spec!), and then get their implementations
to interoperate.

Revising the ASN.1 in a significant way at this point in time necessitates
re-doing all that interop testing.  I am absolutely unwilling to initiate
that pain, especially when it appears to lead to no tangible benefit.  Small
changes (like removing the "CRMF" before "DEFINITIONS", etc.):  no problem.
But a major change (like converting the entire module to 1993/1997 syntax
and getting CMS to change at the same time, etc.), is unnecessary and
counterproductive.

Carlisle.

------_=_NextPart_001_01C0A8C9.2F29B810
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis-01.txt)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi Magnus =
and Phil,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Phillip H. =
Griffin[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Reply To:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Friday, March 09, 2001 8:48 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams; [email-masked]; [email-masked]'</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis-01.txt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Magnus and Carlisle,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">A few comments below.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Magnus Nystrom wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp; b) PKIXCRMF imports =
definitions from both RFC 2459 (bis) and CMS. CMS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; in turn, =
imports definitions from ITU/ISO specifications rather</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; than =
PKIX RFCs. Now this would be ok, unless it was for the fact</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; that RFC =
2459bis and RC2511bis use 1988 syntax, as does CMS, but</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; CMS =
imports from modules written in 1993 syntax. This creates a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; mess for =
those using commercial compilers, since UTF8Strings (used</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; in ISO =
documents but defined explicitly in PKIX documents) aren't</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Actually the situation is even worse =
than</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">described here. The use in IETF =
modules of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">class UNIVERSAL tags is not valid =
ASN.1 under</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">any version of the ASN.1 =
standards.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It is an IETF concoction made up I =
believe</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to allow old X.208 and X.209 based =
tools to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">make use of new ASN.1 types never =
defined </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in those standards, but defined for =
years </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and years now in the current ASN.1 =
standards.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; supported =
in 1988 but are in 1993, so one cannot compile these</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; modules =
with either a &quot;1988&quot; switch or a &quot;1993&quot; switch. My =
advice</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp;&nbsp;&nbsp; would of =
course be to move to 1993/1997 ASN.1 altogether, but if</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Agreed. This is the best possible =
solution.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Not only does it eliminate the =
concoction</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">noted above, it allows the use of =
other new </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">types and encoding rules by adopters =
of IETF</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">standards.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I =
sympathize with both your positions here, and if we were starting from =
scratch I'd say that it might be worthwhile to try to create a =
&quot;perfect&quot;, up-to-date ASN.1 module.&nbsp; However, this =
specification (begun 5 years ago) has been actively interop tested for =
somewhere between 1.5 and 2 years now.&nbsp; By some miracle, all ten =
or so independent implementations were able to take what's listed here =
as a '&quot;Compilable&quot; ASN.1 Module Using 1988 Syntax' (note the =
quotes around &quot;Compilable&quot; in the title of this appendix!), =
make whatever tweaks were necessary to get it to compile (without a =
word of complaint to the authors of the spec!), and then get their =
implementations to interoperate.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Revising =
the ASN.1 in a significant way at this point in time necessitates =
re-doing all that interop testing.&nbsp; I am absolutely unwilling to =
initiate that pain, especially when it appears to lead to no tangible =
benefit.&nbsp; Small changes (like removing the &quot;CRMF&quot; before =
&quot;DEFINITIONS&quot;, etc.):&nbsp; no problem.&nbsp; But a major =
change (like converting the entire module to 1993/1997 syntax and =
getting CMS to change at the same time, etc.), is unnecessary and =
counterproductive.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A8C9.2F29B810--

Date: Fri, 9 Mar 2001 13:02:35 -0500
To: Dave Oshman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Separate CRL Issuance Entity Was: RE: Open Issue in Part1: path l 	ength constraints
Cc: [email-masked]

Dave,

>I would like to consider including the option to have an entity 
>other than a "cert issuing  authority" to sign CRLs. In cases where 
>a Root CA needs to issue certificates infrequently (such as we have 
>at Identrus), but needs to issue CRLs much more frequently, there 
>seems to be a case to have different certificates for these 
>purposes. I don't want to rule out having this option. If we define 
>that having the CA bit set means the capability to issue 
>certificates, this CRL signing entity should not have that bit set. 
>Is it specifically stated somewhere that the assertion of the CA bit 
>is defined as certificate issuance capability? My old X.509 (97) 
>defines a CA as: An authority trusted by one or more users to create 
>and assign certificates. 2459 doesn't provide any more help.

If one uses the KeyUsage extension and marks it critical, then there 
is a separate flag re cert signing (KeyCertSign). But, the current 
spec, has other constraints that don't allow for the CRLSign bit to 
be set and the CA flag in BasicConstraints to not be set, so we have 
a mixed bag of options now.

Steve

Date: Fri, 09 Mar 2001 11:54:20 -0500
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: Ari Kermaier <[email-masked]>
CC: [email-masked]
Subject: Re: UIDs popping up in new-part1

Perhaps a good compromise would be to remove any discussion of UIDs from
section 6 and change the end of section 4.1.2.8 to say that
"Applications conforming to this profile MAY be capable of parsing
unique identifiers and making comparisions. Applications that do not
make such comparisons SHOULD reject certificates that contain unique
identifiers to avoid accepting invalid chains."

This will allow PKIX-compliant applications to continue to accept UIDs
if they so choose, while removing any recommendation or requirement that
they do so. However, I do think that it's important to recommend that
applications that don't include UID support not accept certificates that
contain unique identifiers. Even though the PKIX profile recommends
against the use of UIDs, there may be CAs that use them. Accepting a
certificate with a UID without performing the UID comparison would be
analogous to accepting a certificate with a critical name constraints
extension without performing the required checks.

-Steve

Ari Kermaier wrote:
> 
> Steve,
> 
> My suggestion was that if the certificates contain the info required to
> do new-style certificate chain validation, then the UIDs could be
> ignored. If UIDs are deprecated, then UID mismatches shouldn't really
> matter, as long as the new chaining can be done correctly. Besides, if
> UIDs are so rarely used, a possible scenario might be where CA-1 issued
> (say, 2 years ago) a cert to CA-2 with UIDs and CA-2 issues (today) a
> cert to an EE without UIDs, relying on new chaining algorithms. Why
> should that certificate chain be rejected?
> 
> Also, it is not a fact, but rather a general impression, that nobody
> uses UIDs. It may have been a mistake to include them in previous
> profiles, but I think we're stuck with them -- we can't disinherit their
> children, we can only leave them out of family photos going forward.
> 
> ::Ari
> 
> >If we allow relying parties to ignore UIDs, won't that break backward
> >compatibility in an even more dangerous manner than requiring RPs to
> >reject certificates that contain UIDs? Ignoring UIDs would allow RPs
> >to accept chains with UID mismatches. Since UID checking was previously
> >required, this would be a potentially dangerous contravention of the
> >issuing CA's intent.
> >
> >An RP should either reject certificates containing UIDs or process
> >them properly, not simply ignore them. Since nobody uses this feature
> >and nobody can argue for why it is needed, I suggest that we require
> >RPs to reject certificates containing UIDs.
> >
> >-Steve
> >
> > >The recommendation that Section 6.1.3 be amended to remove references to
> > >UIDs makes sense; CAs conforming to the current profile should not be
> > >required to support this mechanism for certificate chaining, nor should
> > >UIDs be allowed to needlessly complicate the revised validation algorithm.
> > >
> > >However, requiring that UIDs be absent from a certificate would be a
> > >serious error, as would recommending that conforming CAs reject
> > >certificates containing UIDs. If the certificate in question contains the
> > >information required to perform chaining and validation as per the current
> > >profile, why should the CA not be free to ignore the presence of extraneous
> > >infomation? I think it would be a Very Bad Idea to break backwards
> > >compatibility for what is essentially nothing more than an aesthetic
> > >reason. A CA conforming to the current X.509 v3 profile should NOT reject a
> > >certificate that has a deprecated field from a X.509 v2 profile -- it
> > >should just ignore that field. Of course, eveyone "knows" that "nobody"
> > >uses UIDs, but that's not a good reason to break, even hypothetically,
> > >certificates that do use them unless there's a truly compelling positive or
> > >negative functional benefit.
> > >
> > >Ari Kermaier
> > >Phaos Technology
> > >
> > >>Last fall, we agreed to remove issuer and subject unique identifier
> > >>comparison from the validation algorithm. At least, I think we did. The
> > >>argument was that nobody uses unique identifiers and there's no good
> > >>reason to retain support for them.
> > >>
> > >>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
> > >>they remain in step (a) (5) of section 6.1.3, which says:
> > >>
> > >>          (5) The certificate issuer unique identifier is the
> > >>          working_issuer_UID, meaning:
> > >>
> > >>             (i) working_issuer_UID is non-null and matches the value in
> > >>             the issuerUID field, or
> > >>
> > >>             (ii) working_issuer_UID is null and the issuerUID field is
> > >>             not present.
> > >>
> > >>But working_issuer_UID is no longer set anywhere. We should either put
> > >>back the text that initializes and updates this state variable or we
> > >>should change this step so that it doesn't refer to this uninitialized
> > >>varible. I suggest that we remove support for unique identifier chaining
> > >>by changing this step to say:
> > >>
> > >>          (5) The issuerUniqueID and subjectUniqueID fields are not
> > >>          present in the certificate.
> > >>
> > >>This will ensure that compliant implementations will not accidentally
> > >>accept certificates that use these fields, since support for these
> > >>fields is no longer required. I also suggest that we change the sentence
> > >>in section 4.1.2.8 that reads "Applications conforming to this profile
> > >>SHOULD be capable of parsing unique identifiers and making
> > >>comparisons."  to read "Applications conforming to this profile SHOULD
> > >>reject certificates that contain unique identifiers."
> > >>
> > >>-Steve
> > >

Date: Fri, 09 Mar 2001 11:55:23 -0500
To: <[email-masked]>, <[email-masked]>
From: Ari Kermaier <[email-masked]>
Subject: Re: UIDs popping up in new-part1

Steve,

My suggestion was that if the certificates contain the info required to
do new-style certificate chain validation, then the UIDs could be
ignored. If UIDs are deprecated, then UID mismatches shouldn't really
matter, as long as the new chaining can be done correctly. Besides, if
UIDs are so rarely used, a possible scenario might be where CA-1 issued
(say, 2 years ago) a cert to CA-2 with UIDs and CA-2 issues (today) a
cert to an EE without UIDs, relying on new chaining algorithms. Why
should that certificate chain be rejected?

Also, it is not a fact, but rather a general impression, that nobody
uses UIDs. It may have been a mistake to include them in previous
profiles, but I think we're stuck with them -- we can't disinherit their
children, we can only leave them out of family photos going forward.

::Ari

>If we allow relying parties to ignore UIDs, won't that break backward
>compatibility in an even more dangerous manner than requiring RPs to
>reject certificates that contain UIDs? Ignoring UIDs would allow RPs
>to accept chains with UID mismatches. Since UID checking was previously
>required, this would be a potentially dangerous contravention of the
>issuing CA's intent.
>
>An RP should either reject certificates containing UIDs or process
>them properly, not simply ignore them. Since nobody uses this feature
>and nobody can argue for why it is needed, I suggest that we require
>RPs to reject certificates containing UIDs.
>
>-Steve
>
> >The recommendation that Section 6.1.3 be amended to remove references to
> >UIDs makes sense; CAs conforming to the current profile should not be
> >required to support this mechanism for certificate chaining, nor should
> >UIDs be allowed to needlessly complicate the revised validation algorithm.
> >
> >However, requiring that UIDs be absent from a certificate would be a
> >serious error, as would recommending that conforming CAs reject
> >certificates containing UIDs. If the certificate in question contains the
> >information required to perform chaining and validation as per the current
> >profile, why should the CA not be free to ignore the presence of extraneous
> >infomation? I think it would be a Very Bad Idea to break backwards
> >compatibility for what is essentially nothing more than an aesthetic
> >reason. A CA conforming to the current X.509 v3 profile should NOT reject a
> >certificate that has a deprecated field from a X.509 v2 profile -- it
> >should just ignore that field. Of course, eveyone "knows" that "nobody"
> >uses UIDs, but that's not a good reason to break, even hypothetically,
> >certificates that do use them unless there's a truly compelling positive or
> >negative functional benefit.
> >
> >Ari Kermaier
> >Phaos Technology
> >
> >>Last fall, we agreed to remove issuer and subject unique identifier
> >>comparison from the validation algorithm. At least, I think we did. The
> >>argument was that nobody uses unique identifiers and there's no good
> >>reason to retain support for them.
> >>
> >>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
> >>they remain in step (a) (5) of section 6.1.3, which says:
> >>
> >>          (5) The certificate issuer unique identifier is the
> >>          working_issuer_UID, meaning:
> >>
> >>             (i) working_issuer_UID is non-null and matches the value in
> >>             the issuerUID field, or
> >>
> >>             (ii) working_issuer_UID is null and the issuerUID field is
> >>             not present.
> >>
> >>But working_issuer_UID is no longer set anywhere. We should either put
> >>back the text that initializes and updates this state variable or we
> >>should change this step so that it doesn't refer to this uninitialized
> >>varible. I suggest that we remove support for unique identifier chaining
> >>by changing this step to say:
> >>
> >>          (5) The issuerUniqueID and subjectUniqueID fields are not
> >>          present in the certificate.
> >>
> >>This will ensure that compliant implementations will not accidentally
> >>accept certificates that use these fields, since support for these
> >>fields is no longer required. I also suggest that we change the sentence
> >>in section 4.1.2.8 that reads "Applications conforming to this profile
> >>SHOULD be capable of parsing unique identifiers and making
> >>comparisons."  to read "Applications conforming to this profile SHOULD
> >>reject certificates that contain unique identifiers."
> >>
> >>-Steve
> >

Date: Fri, 09 Mar 2001 08:48:49 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting  
To: [email-masked]
CC: Carlisle Adams <[email-masked]>, [email-masked], "[email-masked]'" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis-01.txt)

Magnus and Carlisle,
A few comments below.

Magnus Nystrom wrote:
> 
> Carlisle,
> 
> Thanks for taking our views into account. A few comments on the new
> versions of rfc2510bis and rfc2511bis:
> 
> -The waiting status issue:
>  We feel that it is a bit disturbing that no polling req/rep
>  PKIMessages are defined. The result is that the protocol does not
>  define what to do in those instances when a "waiting" status is
>  returned. It would be much more satisfying to define this within CMP
>  than rely on some underlying transport to do the polling (with what
>  PKIMessage? - and it would have to be defined for all conceivable CMP
>  transports, too...)
> 
> -While the use of an empty SubjectPublicKey to indicate the type of
>  key an end-user would like to have centrally generated seems
>  possible, it will not give the user a possibility to indicate
>  e.g. desired public exponent or modulus length. A method which is
>  more flexible would perhaps be preferable?

In rfc2510bis, for other key formats, allowing a user 
to choose domain parameters known to be viable or key
lengths of sufficient strength would also be a plus.

----

Note that in rfc2510bis under "B2. Algorithm Use 
Profile", useful references for HMAC and ECDSA 
could help readers. These are columns could 
include X9.71 and X9.62.

> -The CMPCertificate type: Looking in rfc2511-bis-01, it does not
>  appears as if there is a corresponding framework suggested to allow a
>  requester to indicate that it would like, e.g. a WTLS Certificate to
>  be returned. Is this intended? One could imagine, e.g., a
>  CertTemplateChoice.

I notice that a couple of places in rfc2510bis state
"See Appendix D and [rfc2511bis] for CertReqMessages
syntax", and that Appendix D does provide direction
for "specifying a template for a certificate other 
than an X.509v3 public-key certificate". 

The use of type AttributeTypeAndValue here seems 
quite flexible enough to handle any type of  
certificate format. This is a far less restrictive
design than using a choice type. It opens up market
possibilities rather than closing them.

> -ASN.1 modules:
> 
>  I also took a few minutes to check the ASN.1 with my syntax checker.
> 
>  RFC 2511bis: There is one simple problem and one slightly harder one.
> 
>  a) You need to remove the "CRMF" before "DEFINITIONS" - the module has
>     already been named above to "PKIXCRMF".
> 
>  b) PKIXCRMF imports definitions from both RFC 2459 (bis) and CMS. CMS
>     in turn, imports definitions from ITU/ISO specifications rather
>     than PKIX RFCs. Now this would be ok, unless it was for the fact
>     that RFC 2459bis and RC2511bis use 1988 syntax, as does CMS, but
>     CMS imports from modules written in 1993 syntax. This creates a
>     mess for those using commercial compilers, since UTF8Strings (used
>     in ISO documents but defined explicitly in PKIX documents) aren't

Actually the situation is even worse than
described here. The use in IETF modules of
class UNIVERSAL tags is not valid ASN.1 under
any version of the ASN.1 standards.

It is an IETF concoction made up I believe
to allow old X.208 and X.209 based tools to
make use of new ASN.1 types never defined 
in those standards, but defined for years 
and years now in the current ASN.1 standards.

This kludge allowed old tools to provide 
much needed national language support without
being updated or corrected, and allowed folks
with copies of X.208 and X.209 (which have not
been corrected or amended for years) to avoid 
buying the current ASN.1 standards. 

At one time, the current ASN.1 standards were
not available except for a charge, and there 
were various copies of different versions of 
X.208 and X.209 floating around for free.

But the X.680 and X.690 series standards are
currently free for download from the itu.ch 
web site. Up until a couple of weeks ago at 
least, when I last checked, all you had to do
was to enter an email address to get three
free documents. New email address, three more
standards.

>     supported in 1988 but are in 1993, so one cannot compile these
>     modules with either a "1988" switch or a "1993" switch. My advice
>     would of course be to move to 1993/1997 ASN.1 altogether, but if

Agreed. This is the best possible solution.
Not only does it eliminate the concoction
noted above, it allows the use of other new 
types and encoding rules by adopters of IETF
standards.

>     this is not possible due to PKIX policies, I'd suggest a change to
>     make CMS dependent on PKIX modules rather than external modules
>     (yes, I realize that CMS is owned by S/MIME and not by PKIX).

Not sure that this will really do more than 
cover the problem with a little sand. What 
will a compliant tool kit do if it discovers 
a value of type RELATIVE-OID in an ANY or 
embedded in an OCTET STRING? Crash and burn
is my guess. But this new type is already
being used to advantage in the new ANSI X9.84
biometrics standard and in the design of the
new compressed (see asn-1.com/x968.htm) domain
certificate syntax in ANSI X9.68:2.

>  RFC2510bis:
> 
>  c) You state that there is no PKCS #10 ASN.1 module defined; this is
>     not correct. RFC 2986 does contain a (1993) module.
> 
>  d) I would prefer if X9.68 certificates were not mentioned in this
>     document.

I would prefer that these X.509 based domain certificates
were still mentioned, but that the text be changed from
"X9.68" to "X9.68:2". Only the profile part of this series
that Magnus worked on has been dropped by the X9F1 working 
group. The other part of this series, part one, was being 
edited by Rich Ankney. I've taken this edit work on and will 
attempt to progress the work in the coming year.

>  e) Since you already import from rfc2459 modules, why not also import
>     the UTF8String definition from there?

It is no more valid really to import an invalid 
type definition than to simply define the type 
using invalid notation. It only hides the problem
for the casual reader.

>  Other than that I found the very same errors as James Manger did.
> 
> -- Magnus
> 
> On Fri, 2 Mar 2001, Carlisle Adams wrote:
> 
> > Hi,
> >
> > For those of you that are curious, 2510bis-03 and 2511bis-01 are minor
> > revisions to the previous drafts which, I believe, address all comments
> > received (both privately and on the list) in the past 3 months.  I feel that
> > both documents are now ready to progress.
> >
> > The documents can be found at the following locations:
> >
> >    http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-03.txt
> >    http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-01.txt
> >
> >
> > The changes between rfc2510bis-02 and rfc2510bis-03 are as follows:
> >
> >               p.30:  added a comment on the "waiting" status regarding the
> > possible need for a polling mechanism in the transport layer and allowing
> > the possibility of polling PKIMessages in a future version of this spec.
> > (You might recall Magnus asking for this on the PKIX list....).
> >
> >               p.33:  removed tag "[1]" from publicKeyMAC field (to align
> > with syntax in RFC 2511).
> >
> >               p.39:  changed "OCTET STRING" to "string" in comment
> > regarding utf8Pairs ("OCTET STRING" was confusing to some people).
> >
> >               p.63:  added a comment regarding the way in which a
> > requester could indicate a preference for algorithm and parameters with
> > respect to centrally-generated key pairs (Magnus also asked how this could
> > be done and I should have given him this answer, but didn't think of it at
> > the time...).
> >
> >               p.67:  removed the position-dependence requirement for
> > requests in cr and kur (at least a couple of people have asked for this on
> > the list, including Magnus).
> >
> >               p.75:  clarified what gets signed if the AltCertTemplate
> > control is used (someone asked for this on the list).
> >
> >               p.80:  (see p.30 above).
> >
> >               p.85:  (see p.39 above).
> >
> >               p.86:  added the certReqId field to CertStatus (I had done
> > this in the body of the spec, but forgot to copy it to this appendix!).
> >
> > The changes between rfc2511bis-00 and rfc2511bis-01 are as follows:
> >
> >               pp.1 and 13:  changed the work affiliation for Mike Myers.
> >
> >               p.10:  added a missing parenthesis in the second line of the
> > comment under encValue.
> >
> >               p.12:  added a reference to PKCS11.
> >
> >               p.16:  changed "OCTET STRING" to "string" in comment
> > regarding utf8Pairs ("OCTET STRING" was confusing to some people).

Phil
----
Phillip H. Griffin    Griffin Consulting
http://asn-1.com      Secure ASN.1 Design & Implementation
p:  +1-919-832-7008   1625 Glenwood Avenue
f:  +1-919-832-7390   Hayes Barton at Five Points
e:  [email-masked]    Raleigh, North Carolina 27608-2319 USA
------------------------------------------------------------

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-05.txt
Date: Fri, 09 Mar 2001 07:37:08 -0500
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 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-05.txt
	Pages		: 119
	Date		: 08-Mar-01
	
This is the fourth draft of a specification based upon RFC 2459.
When complete, this specification will obsolete RFC 2459.  This
specification includes minor edits and clarifications.  The most
notable departures from RFC 2459 are found in Section 6, Path
Validation.  In RFC 2459, the reader was expected to augment the path
validation algorithm, which concentrated upon policy processing, with
information embedded in earlier sections.  For example, parameter
inheritance is discussed in Section 7, Algorithm Support, and can
certainly affect the validity of a certification path.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-05.txt

Internet-Drafts are also 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-new-part1-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

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

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

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

--OtherAccess--

--NextPart--

From: "Carlin Covey" <[email-masked]>
To: <[email-masked]>
Subject: Impersonation Certificates - finding IC's
Date: Thu, 8 Mar 2001 19:04:40 -0700
Importance: Normal

In section 2.6 of draft-ietf-pkix-impersonation-00.txt the
following words appear:

   "To discourage mistakes in this area, this Impersonation Certificate 
   profile defines that the IC subject (actually its subjectAltName) is 
   just a pseudo-randomly generated string."

[Carlin's comments/questions]:
If the IC subject name is a pseudo-randomly generated string, how is the 
IC found in an X.500 or LDAP Directory?  Must it always be passed by the 
application to the RP rather than being found in a directory?  

- Carlin Covey
  Cylink Corporation

From: "Carlin Covey" <[email-masked]>
To: <[email-masked]>
Subject: Impersonation Certificates - proofing IC requesters
Date: Thu, 8 Mar 2001 16:54:22 -0700
Importance: Normal

Gentlepersons,

draft-ietf-pkix-impersonation-00.txt describes a mechanism for 
delegating authority from entity A (who is not a CA) to entity B 
by issuing an "Impersonation Certificate" (IC) to entity B that 
is signed using entity A's PKC.  

Below step 5 of section 2.4. the following text appears:

   "The process of creating an IC is as follows: 
    
   1. A new public and private key pair is generated. 
       
   2. An unsigned IC request is created, conforming to the profile 
      described in this document. 
       
   3. The IC request is signed by the private key of the EEC, or by 
      another IC.  During this process, the unsigned IC is verified to 
      ensure that it is valid (e.g. it is not an EEC, the IC fields are 
      appropriately set, etc). 
    
   When an IC is created as part of a delegation from entity A to 
   entity B, this process is modified by performing steps #1 and #2 
   within entity B, then passing the IC request from entity B to entity 
   A over an integrity checked channel, then entity A performs step #3. "

[Carlin's comments/questions]:
I'm trying to understand some of the security aspects.
I don't see any discussion of proofing the IC requester.  How 
does the EE authenticate the identity of the IC requester?  
A CA or RA normally has some sort of proofing facilities 
available that are used to authenticate the identity of a 
human being (e.g. a database of employee information, some 
expertise in recognizing legitimate paper identity documents, 
etc.)  An EE is probably not well-equipped to do this sort 
of human identity proofing.  Moreover, in the example in 
section 2.3 the IC requester appears to be some automated 
process.  How does the EE authenticate the identity of this 
process?  Even if the EE can authenticate the source of the 
IC request, how are man-in-the-middle attacks prevented 
during the IC request process?  

- Carlin Covey
  Cylink Corporation

Date: Thu, 08 Mar 2001 11:49:47 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: X.509, PKIX, and pathLenConstraint

Hal,

I think it is mostly an issue of timing.  I can imagine all sorts of wills/cans/should scenarios, including setting up the state medical association as an authoritative CA, or getting VeriSign, etc. to include such certifications in their certificates and keep on top of the issue, and/or using attributes certificates, XML, or whatever.  But it takes a surprisingly  long time to roll out all of these fancy options, even once a critical mass of vendors start offering them.  

The approach I suggested might be useful in the interim, I feel.

Bob

>>> Hal Lockhart <[email-masked]> 03/07/01 09:32AM >>>
I thought that this was the type of situation that Attribute Certificates
were designed to handle. Aren't you confusing Authentication with
Authorization?

Hal
=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [email-masked] 
F: 1-508-229-0338             www.entegrity.com 
=======================================================

> From: Bob Jueneman [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2001 10:58 AM
> To: [email-masked] 
> Cc: [email-masked]; [email-masked] 
> Subject: Re: X.509, PKIX, and pathLenConstraint
> 
> 
> Steve, this may be "merely" a question of semantics, but let
> me outline a user-driven scenario that may be of interest here.
> 
> Suppose that I am a hospital administrator operating a network
> that allows doctors, nurses, etc., to access various resources
> using their X.509 certificates.  And let's assume for now that
> these certificates are issued by one of the public CAs, e.g.,
> VeriSign, and not by say the state medical association.
> 
> As the hospital administrator, I am probably a lot more concerned
> with whether the doctor in question currently has hospital privileges
> than I am in whether that doctor's signature is legally binding,
> and I am certainly in a much better position to be authoritative 
> about that issue than VeriSign is -- the fact that a doctor had 
> his medical license revoked would not be cause for VeriSign to 
> revoke his certificate.
> 
> I could, of course, set up a local database, and merely look up that 
> user's status, but although that works for access control, it doesn't 
> work nearly as well for say S/MIME.
> 
> So what I might like to do is to intercept all outgoing requests for 
> CRLs or OCSP, and send to my own local CRL or OCSP responder.
> I would manage that by periodically checking the real CRL list,
> but in addition I can revoke a certificate locally as I see fit.
> All that I have to do is to ensure that my certificate is included in
> the relying party software as a trusted root, or at least is 
> chained to
> a trusted root.
> 
> BTW, since the relationship is completely independent of the
> CA that issued the certificates, there is nothing in the certificate
> that would point to my CRL responder, not even a CRLDistributionPoint.
> 
> Now, am I a CA, or not? After all, I will never be issuing 
> certificates, 
> only CRLs.
> 
> My inclination would be to say that yes, I am, but what say you?
> Does it really matter one way or the other?
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> 
> Novell, Inc -- the leading provider of Net services software
> 
> 
> 
> >>> Stephen Kent <[email-masked]> 03/06/01 04:16PM >>>
> David,
> 
> To me, the text you cite (7.3) lends further credence to the notion 
> that a CA is the entity that signs CRLs. Only the CA that issued a 
> cert could sign a CRL revoking that cert, until v3 of X.509, where 
> the introduction of indirect CRLs and CRL DPs opened up new 
> possibilities. The fundamental question is whether these features 
> create a new class of entity that can sign CRLs but not be marked (in 
> its certificate) as a CA, or whether these facilities merely allow 
> one CA to delegate CRL signing to another CA, perhaps operated under 
> the same administrative jurisdiction.
> 
> Steve
> 
> 

Date: Thu, 8 Mar 2001 18:10:51 +0100 (W. Europe Standard Time)
From: Magnus Nystrom <[email-masked]>
Reply-To: <[email-masked]>
To: Carlisle Adams <[email-masked]>
cc: <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)

Carlisle,

Thanks for taking our views into account. A few comments on the new
versions of rfc2510bis and rfc2511bis:

-The waiting status issue:
 We feel that it is a bit disturbing that no polling req/rep
 PKIMessages are defined. The result is that the protocol does not
 define what to do in those instances when a "waiting" status is
 returned. It would be much more satisfying to define this within CMP
 than rely on some underlying transport to do the polling (with what
 PKIMessage? - and it would have to be defined for all conceivable CMP
 transports, too...)

-While the use of an empty SubjectPublicKey to indicate the type of
 key an end-user would like to have centrally generated seems
 possible, it will not give the user a possibility to indicate
 e.g. desired public exponent or modulus length. A method which is
 more flexible would perhaps be preferable?

-The CMPCertificate type: Looking in rfc2511-bis-01, it does not
 appears as if there is a corresponding framework suggested to allow a
 requester to indicate that it would like, e.g. a WTLS Certificate to
 be returned. Is this intended? One could imagine, e.g., a
 CertTemplateChoice.

-ASN.1 modules:

 I also took a few minutes to check the ASN.1 with my syntax checker.

 RFC 2511bis: There is one simple problem and one slightly harder one.

 a) You need to remove the "CRMF" before "DEFINITIONS" - the module has
    already been named above to "PKIXCRMF".

 b) PKIXCRMF imports definitions from both RFC 2459 (bis) and CMS. CMS
    in turn, imports definitions from ITU/ISO specifications rather
    than PKIX RFCs. Now this would be ok, unless it was for the fact
    that RFC 2459bis and RC2511bis use 1988 syntax, as does CMS, but
    CMS imports from modules written in 1993 syntax. This creates a
    mess for those using commercial compilers, since UTF8Strings (used
    in ISO documents but defined explicitly in PKIX documents) aren't
    supported in 1988 but are in 1993, so one cannot compile these
    modules with either a "1988" switch or a "1993" switch. My advice
    would of course be to move to 1993/1997 ASN.1 altogether, but if
    this is not possible due to PKIX policies, I'd suggest a change to
    make CMS dependent on PKIX modules rather than external modules
    (yes, I realize that CMS is owned by S/MIME and not by PKIX).

 RFC2510bis:

 c) You state that there is no PKCS #10 ASN.1 module defined; this is
    not correct. RFC 2986 does contain a (1993) module.

 d) I would prefer if X9.68 certificates were not mentioned in this
    document.

 e) Since you already import from rfc2459 modules, why not also import
    the UTF8String definition from there?

 Other than that I found the very same errors as James Manger did.

-- Magnus

On Fri, 2 Mar 2001, Carlisle Adams wrote:

> Hi,
>
> For those of you that are curious, 2510bis-03 and 2511bis-01 are minor
> revisions to the previous drafts which, I believe, address all comments
> received (both privately and on the list) in the past 3 months.  I feel that
> both documents are now ready to progress.
>
> The documents can be found at the following locations:
>
>    http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-03.txt
>    http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-01.txt
>
>
> The changes between rfc2510bis-02 and rfc2510bis-03 are as follows:
>
> 		p.30:  added a comment on the "waiting" status regarding the
> possible need for a polling mechanism in the transport layer and allowing
> the possibility of polling PKIMessages in a future version of this spec.
> (You might recall Magnus asking for this on the PKIX list....).
>
> 		p.33:  removed tag "[1]" from publicKeyMAC field (to align
> with syntax in RFC 2511).
>
> 		p.39:  changed "OCTET STRING" to "string" in comment
> regarding utf8Pairs ("OCTET STRING" was confusing to some people).
>
> 		p.63:  added a comment regarding the way in which a
> requester could indicate a preference for algorithm and parameters with
> respect to centrally-generated key pairs (Magnus also asked how this could
> be done and I should have given him this answer, but didn't think of it at
> the time...).
>
> 		p.67:  removed the position-dependence requirement for
> requests in cr and kur (at least a couple of people have asked for this on
> the list, including Magnus).
>
> 		p.75:  clarified what gets signed if the AltCertTemplate
> control is used (someone asked for this on the list).
>
> 		p.80:  (see p.30 above).
>
> 		p.85:  (see p.39 above).
>
> 		p.86:  added the certReqId field to CertStatus (I had done
> this in the body of the spec, but forgot to copy it to this appendix!).
>
> The changes between rfc2511bis-00 and rfc2511bis-01 are as follows:
>
> 		pp.1 and 13:  changed the work affiliation for Mike Myers.
>
> 		p.10:  added a missing parenthesis in the second line of the
> comment under encValue.
>
> 		p.12:  added a reference to PKCS11.
>
> 		p.16:  changed "OCTET STRING" to "string" in comment
> regarding utf8Pairs ("OCTET STRING" was confusing to some people).

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: RE: Open Issue in Part1: path length constraints
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Fri, 9 Mar 2001 05:32:05 (NZDT)

"David P. Kemp" <[email-masked]> writes:

>Consider the following certificates:
>
>#  cA   CertSign  cRLSign    Effect
>- ----- --------  -------   ------------
>0  F     0         0        End Entity
>1  F     0         1        End Entity (can sign CRLs)
>2  F     1         0        End Entity
>3  F     1         1        End Entity (can sign CRLs)
>4  T     0         0    (Illegal*) Is a CA but can't sign certs or CRLs
>5  T     0         1    (Illegal*) Is a CA, can sign CRLs only
>6  T     1         0        CA, can sign certs
>7  T     1         1        CA, can sign certs and CRLs
>
>* As Dave S. points out, 4.2.1.10 prohibits cert types 4 and 5.

What about 2 and 3?  They can sign certs but they're not a CA, wouldn't this be
illegal?  (I proposed 2 in my autonomous certs draft for people who have
signing certs who want to issue their own encryption certs without going
through a CA, but apart from that special use I'm not sure what the semantics
for this combination are).

Peter.

Sender: [email-masked]
Date: Thu, 08 Mar 2001 11:10:10 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: RE: Open Issue in Part1: path length constraints

> From: "Michael Myers" <[email-masked]>
> 
> Dave,
> 
> Does your observation of a "trusted" responder interpret case 1.b below or
> were you intending to speak to some broader notion?

Michael,

I was indeed considering case 1.b, based on the text in RFC 2560
section 2.2:

  The key used to sign the response MUST belong to one of the following:
  
    -- the CA who issued the certificate in question
    -- a Trusted Responder whose whose public key is trusted by the
        requestor
    -- a CA Designated Responder (Authorized Responder) who holds a
        specially marked certificate issued directly by the CA

I admit to not making a distinction between 1.a and 1.b, because if the
CA is going to implicitly designate a trusted responder key, why in the
world would it not take the extra step of explicitly designating that
key
by issuing the special certificate.  The hard work for the CA is
deciding
who to designate, not signing the cert.  I'm not from Missouri, but if a
Trusted Responder claimed to be CA-delegated, I'd say "show me the
cert".

Dave

Sender: [email-masked]
Date: Thu, 08 Mar 2001 11:09:06 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: RE: Open Issue in Part1: path length constraints

Steve,

I've never seen any benefit of the cA flag in the basicConstraints
extension; it's just a vestigial appendix left over from when there
was no keyUsage extension.

Consider the following certificates:

#  cA   CertSign  cRLSign    Effect
- ----- --------  -------   ------------
0  F     0         0        End Entity
1  F     0         1        End Entity (can sign CRLs)
2  F     1         0        End Entity
3  F     1         1        End Entity (can sign CRLs)
4  T     0         0    (Illegal*) Is a CA but can't sign certs or CRLs
5  T     0         1    (Illegal*) Is a CA, can sign CRLs only
6  T     1         0        CA, can sign certs
7  T     1         1        CA, can sign certs and CRLs

* As Dave S. points out, 4.2.1.10 prohibits cert types 4 and 5.

Is there any benefit to having eight different certificate types
instead of just four?   In my example of the online CRL signer, what is
accomplished by setting CA=true (cert #5) instead of CA=false (cert #1)?
You say you would set it to indicate that the CRL issuer is a CA, but
what would the application do with that knowledge? (i.e. what would it
do differently than if the CA flag were false?)

More generally, is there any reason why Section 4.2.1.10 should
not also prohibit cert types 2 and 3? (in other words, require the
keyCertSign bit to always equal the cA flag?).  

Dave

> From: Stephen Kent <[email-masked]>
> 
> I agree that there is ambiguity in what we mean when we refer to a CA 
> in such circumstances, but algorithmically I have always assumed that 
> only CAs issued CRLs and we can tell whether the entity is a CA by 
> the basic constraints extension. I see there is considerable 
> sentiment to allow for non-CA flagged entities to sign CRLs, but I'm 
> not yet sure I understand why folks consider it important to not turn 
> on the CA flag in certs for such entities. After all, since we have 
> separate key usage bits for cert and CRL signing, we can construct a 
> cert for an entity that signs CRLs and not grant that entity the 
> ability to sign certs, if we so desire.

Date: Thu, 08 Mar 2001 16:01:39 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Sharon Boeyen <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Sharon,

> 509 doesn't currently state that there are only two types, but states
> that 2 types are defined in that specification. 

I would like that to be true, but it is not, since the text says:

" Authority: An entity, responsible for the issuance of certificates." 

If that sentence would be deleted or changed, then it would be OK.

Denis

> Anything could be added
> to 509 in the future, we don't need to state that explicitly (although
> my hope is that VERY VERY LITTLE still needs to be added to 509 - note
> that
> the current WD is under 10 pages and i sincerely hope it stays that way!).
> 
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Thursday, March 08, 2001 2:56 AM
> > To: Stephen Kent
> > Cc: Sharon Boeyen; [email-masked]
> > Subject: Re: Open Issue in Part1: path length constraints
> >
> >
> > Sharon,
> >
> > I read your explanations below. We do not have any problem about the
> > concepts, but there is a vocbulary problem here. It would be
> > unfortunate to
> > say that an Authority may only be a CA or an AA. An Authority
> > needs to be
> > qualified by a term: C-A (C= Certification) or A-A (A =
> > Attribute). There
> > are and will be other Authorities in a PKIX. As an example:
> > TS-A (TS = Time
> > Stamping).
> >
> > I do know that, for ISO documents, definitions only apply for
> > the given
> > document where the definition is, but rewording clause 3.3.6
> > from X.509
> > along the following would need to be considered:
> >
> > Authority: "An entity, trusted by some other entities for a
> > security related
> > service. Two types of authorities are defined in this Specification;
> > certification authority which issues public-key certificates
> > and attribute
> > authority which issues attribute certificates. Other types
> > might be defined
> > in the future."
> >
> > Denis
> >
> >
> > > Sharon,
> > >
> > > >Re the X.509 language - The main reason you see terms
> > like 'authority' and
> > > >CRL issuer instead of CA is that CRLs can also be issued for
> > > >attribute certificates.
> > > >These CRLs would be signed by Attribute Authorities (AA)
> > not by CAs.
> > > >As editor,
> > > >one my editing tasks for the 2000 509 was to replace "CA" with
> > > >"authority" wherever both CA and AA
> > > >were intended. That is the main reason you see these terms. There
> > > >really hasn't been any
> > > >discussion in 509 on non CA, AA issued CRLs that I can remember.
> > > >Taking this to the next
> > > >step, the definition of "authority" in X.509 (clause 3.3.6) is: "An
> > > >entity, responsible for the issuance of certificates. Two types are
> > > >defined in this Specification; certification authority which issues
> > > >public-key certificates and attribute authority which issues
> > > >attribute certificates." So, at least from the X.509 perspective an
> > > >authority is either a CA or an AA.
> > >
> > > Thanks for the clarification; it reaffirms my recent comments about
> > > the scope of the term "authority." That says that there is no
> > > explicit provision for non CA/AA issuance of CRLs in X.509. So, not
> > > only does PKIX have to decide if it wants to create the notion of a
> > > new sort of authority for CRL issuance, but then we have to see if
> > > X.509 will follow this approach as well.
> > >
> > > Steve
> >

From: Sharon Boeyen <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: RE: Open Issue in Part1: path length constraints
Date: Thu, 8 Mar 2001 09:41:58 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A7DD.EDB53260
Content-Type: text/plain

509 doesn't currently state that there are only two types, but states
that 2 types are defined in that specification. Anything could be added
to 509 in the future, we don't need to state that explicitly (although 
my hope is that VERY VERY LITTLE still needs to be added to 509 - note that
the current WD is under 10 pages and i sincerely hope it stays that way!). 

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, March 08, 2001 2:56 AM
> To: Stephen Kent
> Cc: Sharon Boeyen; [email-masked]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Sharon,
> 
> I read your explanations below. We do not have any problem about the
> concepts, but there is a vocbulary problem here. It would be 
> unfortunate to
> say that an Authority may only be a CA or an AA. An Authority 
> needs to be
> qualified by a term: C-A (C= Certification) or A-A (A = 
> Attribute). There
> are and will be other Authorities in a PKIX. As an example: 
> TS-A (TS = Time
> Stamping).
> 
> I do know that, for ISO documents, definitions only apply for 
> the given
> document where the definition is, but rewording clause 3.3.6 
> from X.509
> along the following would need to be considered:
> 
> Authority: "An entity, trusted by some other entities for a 
> security related
> service. Two types of authorities are defined in this Specification;
> certification authority which issues public-key certificates 
> and attribute
> authority which issues attribute certificates. Other types 
> might be defined
> in the future."
> 
> Denis
> 
>  
> > Sharon,
> > 
> > >Re the X.509 language - The main reason you see terms  
> like 'authority' and
> > >CRL issuer instead of CA is that CRLs can also be issued for
> > >attribute certificates.
> > >These CRLs would be signed by Attribute Authorities (AA) 
> not by CAs.
> > >As editor,
> > >one my editing tasks for the 2000 509 was to replace "CA" with
> > >"authority" wherever both CA and AA
> > >were intended. That is the main reason you see these terms. There
> > >really hasn't been any
> > >discussion in 509 on non CA, AA issued CRLs that I can remember.
> > >Taking this to the next
> > >step, the definition of "authority" in X.509 (clause 3.3.6) is: "An
> > >entity, responsible for the issuance of certificates. Two types are
> > >defined in this Specification; certification authority which issues
> > >public-key certificates and attribute authority which issues
> > >attribute certificates." So, at least from the X.509 perspective an
> > >authority is either a CA or an AA.
> > 
> > Thanks for the clarification; it reaffirms my recent comments about
> > the scope of the term "authority." That says that there is no
> > explicit provision for non CA/AA issuance of CRLs in X.509. So, not
> > only does PKIX have to decide if it wants to create the notion of a
> > new sort of authority for CRL issuance, but then we have to see if
> > X.509 will follow this approach as well.
> > 
> > Steve
> 

------_=_NextPart_001_01C0A7DD.EDB53260
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Open Issue in Part1: path length constraints</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>509 doesn't currently state that there are only two types, but states</FONT>
<BR><FONT SIZE=2>that 2 types are defined in that specification. Anything could be added</FONT>
<BR><FONT SIZE=2>to 509 in the future, we don't need to state that explicitly (although </FONT>
<BR><FONT SIZE=2>my hope is that VERY VERY LITTLE still needs to be added to 509 - note that</FONT>
<BR><FONT SIZE=2>the current WD is under 10 pages and i sincerely hope it stays that way!). </FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Denis Pinkas [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, March 08, 2001 2:56 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Stephen Kent</FONT>
<BR><FONT SIZE=2>&gt; Cc: Sharon Boeyen; [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Open Issue in Part1: path length constraints</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sharon,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I read your explanations below. We do not have any problem about the</FONT>
<BR><FONT SIZE=2>&gt; concepts, but there is a vocbulary problem here. It would be </FONT>
<BR><FONT SIZE=2>&gt; unfortunate to</FONT>
<BR><FONT SIZE=2>&gt; say that an Authority may only be a CA or an AA. An Authority </FONT>
<BR><FONT SIZE=2>&gt; needs to be</FONT>
<BR><FONT SIZE=2>&gt; qualified by a term: C-A (C= Certification) or A-A (A = </FONT>
<BR><FONT SIZE=2>&gt; Attribute). There</FONT>
<BR><FONT SIZE=2>&gt; are and will be other Authorities in a PKIX. As an example: </FONT>
<BR><FONT SIZE=2>&gt; TS-A (TS = Time</FONT>
<BR><FONT SIZE=2>&gt; Stamping).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I do know that, for ISO documents, definitions only apply for </FONT>
<BR><FONT SIZE=2>&gt; the given</FONT>
<BR><FONT SIZE=2>&gt; document where the definition is, but rewording clause 3.3.6 </FONT>
<BR><FONT SIZE=2>&gt; from X.509</FONT>
<BR><FONT SIZE=2>&gt; along the following would need to be considered:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Authority: &quot;An entity, trusted by some other entities for a </FONT>
<BR><FONT SIZE=2>&gt; security related</FONT>
<BR><FONT SIZE=2>&gt; service. Two types of authorities are defined in this Specification;</FONT>
<BR><FONT SIZE=2>&gt; certification authority which issues public-key certificates </FONT>
<BR><FONT SIZE=2>&gt; and attribute</FONT>
<BR><FONT SIZE=2>&gt; authority which issues attribute certificates. Other types </FONT>
<BR><FONT SIZE=2>&gt; might be defined</FONT>
<BR><FONT SIZE=2>&gt; in the future.&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Denis</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Sharon,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Re the X.509 language - The main reason you see terms&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; like 'authority' and</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;CRL issuer instead of CA is that CRLs can also be issued for</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;attribute certificates.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;These CRLs would be signed by Attribute Authorities (AA) </FONT>
<BR><FONT SIZE=2>&gt; not by CAs.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;As editor,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;one my editing tasks for the 2000 509 was to replace &quot;CA&quot; with</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&quot;authority&quot; wherever both CA and AA</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;were intended. That is the main reason you see these terms. There</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;really hasn't been any</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;discussion in 509 on non CA, AA issued CRLs that I can remember.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Taking this to the next</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;step, the definition of &quot;authority&quot; in X.509 (clause 3.3.6) is: &quot;An</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;entity, responsible for the issuance of certificates. Two types are</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;defined in this Specification; certification authority which issues</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;public-key certificates and attribute authority which issues</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;attribute certificates.&quot; So, at least from the X.509 perspective an</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;authority is either a CA or an AA.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Thanks for the clarification; it reaffirms my recent comments about</FONT>
<BR><FONT SIZE=2>&gt; &gt; the scope of the term &quot;authority.&quot; That says that there is no</FONT>
<BR><FONT SIZE=2>&gt; &gt; explicit provision for non CA/AA issuance of CRLs in X.509. So, not</FONT>
<BR><FONT SIZE=2>&gt; &gt; only does PKIX have to decide if it wants to create the notion of a</FONT>
<BR><FONT SIZE=2>&gt; &gt; new sort of authority for CRL issuance, but then we have to see if</FONT>
<BR><FONT SIZE=2>&gt; &gt; X.509 will follow this approach as well.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Steve</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A7DD.EDB53260--

From: Sharon Boeyen <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Open Issue in Part1: path length constraints
Date: Thu, 8 Mar 2001 09:38:58 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A7DD.827E7330
Content-Type: text/plain

I do think it is important that regardless of whether the entity signing a 
CRL or an OCSP response represents a CA or not, that relying parties have 
a clear path to determine whether or not to 'trust' such an indication of 
revocation status. For OCSP responders we have the AIA extension and for
CRLs
the issuer (if different than the cert issuer) can be indicated in the
crldp. 

Sharon

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 5:19 PM
> To: Sharon Boeyen
> Cc: [email-masked]
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Sharon,
> 
> >Re the X.509 language - The main reason you see terms  like 
> 'authority' and
> >CRL issuer instead of CA is that CRLs can also be issued for 
> >attribute certificates.
> >These CRLs would be signed by Attribute Authorities (AA) not by CAs. 
> >As editor,
> >one my editing tasks for the 2000 509 was to replace "CA" with 
> >"authority" wherever both CA and AA
> >were intended. That is the main reason you see these terms. There 
> >really hasn't been any
> >discussion in 509 on non CA, AA issued CRLs that I can remember. 
> >Taking this to the next
> >step, the definition of "authority" in X.509 (clause 3.3.6) is: "An 
> >entity, responsible for the issuance of certificates. Two types are 
> >defined in this Specification; certification authority which issues 
> >public-key certificates and attribute authority which issues 
> >attribute certificates." So, at least from the X.509 perspective an 
> >authority is either a CA or an AA.
> 
> Thanks for the clarification; it reaffirms my recent comments about 
> the scope of the term "authority." That says that there is no 
> explicit provision for non CA/AA issuance of CRLs in X.509. So, not 
> only does PKIX have to decide if it wants to create the notion of a 
> new sort of authority for CRL issuance, but then we have to see if 
> X.509 will follow this approach as well.
> 
> Steve
> 

------_=_NextPart_001_01C0A7DD.827E7330
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Open Issue in Part1: path length constraints</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I do think it is important that regardless of whether the entity signing a </FONT>
<BR><FONT SIZE=2>CRL or an OCSP response represents a CA or not, that relying parties have </FONT>
<BR><FONT SIZE=2>a clear path to determine whether or not to 'trust' such an indication of </FONT>
<BR><FONT SIZE=2>revocation status. For OCSP responders we have the AIA extension and for CRLs</FONT>
<BR><FONT SIZE=2>the issuer (if different than the cert issuer) can be indicated in the crldp. </FONT>
</P>

<P><FONT SIZE=2>Sharon</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Stephen Kent [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, March 07, 2001 5:19 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: Open Issue in Part1: path length constraints</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sharon,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;Re the X.509 language - The main reason you see terms&nbsp; like </FONT>
<BR><FONT SIZE=2>&gt; 'authority' and</FONT>
<BR><FONT SIZE=2>&gt; &gt;CRL issuer instead of CA is that CRLs can also be issued for </FONT>
<BR><FONT SIZE=2>&gt; &gt;attribute certificates.</FONT>
<BR><FONT SIZE=2>&gt; &gt;These CRLs would be signed by Attribute Authorities (AA) not by CAs. </FONT>
<BR><FONT SIZE=2>&gt; &gt;As editor,</FONT>
<BR><FONT SIZE=2>&gt; &gt;one my editing tasks for the 2000 509 was to replace &quot;CA&quot; with </FONT>
<BR><FONT SIZE=2>&gt; &gt;&quot;authority&quot; wherever both CA and AA</FONT>
<BR><FONT SIZE=2>&gt; &gt;were intended. That is the main reason you see these terms. There </FONT>
<BR><FONT SIZE=2>&gt; &gt;really hasn't been any</FONT>
<BR><FONT SIZE=2>&gt; &gt;discussion in 509 on non CA, AA issued CRLs that I can remember. </FONT>
<BR><FONT SIZE=2>&gt; &gt;Taking this to the next</FONT>
<BR><FONT SIZE=2>&gt; &gt;step, the definition of &quot;authority&quot; in X.509 (clause 3.3.6) is: &quot;An </FONT>
<BR><FONT SIZE=2>&gt; &gt;entity, responsible for the issuance of certificates. Two types are </FONT>
<BR><FONT SIZE=2>&gt; &gt;defined in this Specification; certification authority which issues </FONT>
<BR><FONT SIZE=2>&gt; &gt;public-key certificates and attribute authority which issues </FONT>
<BR><FONT SIZE=2>&gt; &gt;attribute certificates.&quot; So, at least from the X.509 perspective an </FONT>
<BR><FONT SIZE=2>&gt; &gt;authority is either a CA or an AA.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks for the clarification; it reaffirms my recent comments about </FONT>
<BR><FONT SIZE=2>&gt; the scope of the term &quot;authority.&quot; That says that there is no </FONT>
<BR><FONT SIZE=2>&gt; explicit provision for non CA/AA issuance of CRLs in X.509. So, not </FONT>
<BR><FONT SIZE=2>&gt; only does PKIX have to decide if it wants to create the notion of a </FONT>
<BR><FONT SIZE=2>&gt; new sort of authority for CRL issuance, but then we have to see if </FONT>
<BR><FONT SIZE=2>&gt; X.509 will follow this approach as well.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Steve</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A7DD.827E7330--

Date: Thu, 08 Mar 2001 13:25:10 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Trevor Freeman <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: Re: WG Last Call: Son-of-2459: More about delta-CRLs

Trevor,

It took me some time respond to take a look at the short thread of the three
messages along this topic. We basically agree that :

1° The current text always allows relying parties not supporting delta-CRLs
to have access to the same freshness of the information. This should be a
recommendation and not be a mandatory requirement.

2° some clarifications about the use of delta CRLs are currently missing in
the document.

Tim ? Any proposal ?

[do not miss the last comment at the end]

> Hi Dennis,
 
> We already discussed on the mailing list the sentence contained in
> section 5.2.4  Delta CRL Indicator:
 
> " When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
> that is complete for the given scope."
 
> However I noticed that in the new text, MUST has not been changed into
> SHOULD. There has been no definitive answer but many people were arguing
> for the SHOULD.
 
> TF> I agree, we don't have a clause requiring the publication of a full
> base when using OCSP. Non-delta aware client are not impacted since they
> don't know about delta publication. It is therefore impossible to
> achieve all clients having the same revocation information.
 
> Indeed, this text always allows relying parties not supporting
> delta-CRLs to
> have access to the same freshness of the information. I would still
> think that this should be a recommendation and not be a mandatory 
> requirement.
 
> However, we did not discussed that much the implications of another
> sentence: "A CRL user constructing a locally held CRL from delta-CRLs
> ...." Notice the "s" at the end of delta-CRLs.
 
> TF> There are two cases to consider here. Where the freshest CRL
> indicator is in the certificate or the CRL. In the former case, it may
> be necessary to merge multiple delta CRLs since there is no guarantee of
> a 1-2-1 relationship between base and delta. You could have delta CRLs
> partitioned by reason coded, and a base CRL for all reasons. In the
> later case where the freshet CRL indicator in in the CRL, there is an
> implicit 1-2-1 relationship between base and delta. A delta aware client
> in this case only has to search for the latest delta CRL. Each delta has
> a this update time, so a client can establish which is the latest.
> Merging the latest delta CRL with the appropriate base provided the
> answer.
 
> How is it possible to issue more than one delta-CRL referring to a given
> basic CRL and know that it is the freshest ? The text does not say
> anything. Some guidance should be given. Is the following an adequate 
> rough explanation ?
 
> TF> given the range of possibilities introduced by having freshest CRL
> in either the certificate or CRL, I would prefer some recommendations on
> what should be done. Having no guidance opens up a large number of
> permutations, and we want to progress this to draft standard, we need to
> refine our scope to what is reasonable, not what is possible.
 
> Every delta-CRL SHOULD indicate the next issuing date of the next
> delta-CRL [we have this feature]. If the next issuing date is missing, 
> then it means that no further delta-CRL will be issued and that a new 
> base CRL is now also available. The delta-CRL obtained is the freshest, 
> when the date for checking is between the issuing date and the next 
> issuing date of that delta-CRL.
 
> Ideally, but not necessarily, the base CRL SHOULD include an indicator
> saying that a delta mechanism is supported [we do not have that
> indicator].
> 
> TF> Having a freshest CRL extension in a CRL provides such an indicator.

Dave (David A.Copper) mentioned that the indicator is there, not in the CRL
but in the certificate.

"4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point)

   The freshest CRL extension identifies how delta-CRL information is
   obtained."

but it can also be in the CRL:

" 5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point)

   The freshest CRL extension identifies how delta-CRL information for
   this CRL is obtained."

So we have two indicators and you are both right. :-)

Denis.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ocspv2-02.txt,.ps
Date: Thu, 08 Mar 2001 06:58:03 -0500
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		: Online Certificate Status Protocol, version 2
	Author(s)	: M. Myers, R. Ankney, C. Adams, S. Farrell, C. Covey
	Filename	: draft-ietf-pkix-ocspv2-02.txt,.ps
	Pages		: 23
	Date		: 07-Mar-01
	
This document advances the specification of RFC 2560 [RFC2560] towards the acquisition of any data relevant to determining a digital certificate's reliability; interoperability with [RFC2560] is maintained. Such data include a certificate's revocation status, it's validation status and ancillary information supporting these assertions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspv2-02.txt

Internet-Drafts are also 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-ocspv2-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-pkalgs-02.txt
Date: Thu, 08 Mar 2001 06:57:57 -0500
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		: Algorithms and Identifiers for the Internet X.509 
                          Public Key Infrastructure Certificate and CRI Profile
	Author(s)	: L. Bassham, R. Housley, W. Polk
	Filename	: draft-ietf-pkix-ipki-pkalgs-02.txt
	Pages		: 26
	Date		: 07-Mar-01
	
This document specifies algorithm identifiers and ASN.1 encoding
formats for digital signatures and subject public keys used in the
Internet X.509 Public Key Infrastructure (PKI).  Digital signatures
are used to sign certificates and certificate revocation lists
(CRLs).  Certificates include the public key of the named subject.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-pkalgs-02.txt

Internet-Drafts are also 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-pkalgs-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

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

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

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

--OtherAccess--

--NextPart--

From: Steve Hanna <[email-masked]>
Date: Thu, 8 Mar 2001 05:43:19 -0500
To: "Ari Kermaier" <[email-masked]>, <[email-masked]>
Reply-To: <[email-masked]>
Subject: Re: UIDs popping up in new-part1

If we allow relying parties to ignore UIDs, won't that break backward
compatibility in an even more dangerous manner than requiring RPs to
reject certificates that contain UIDs? Ignoring UIDs would allow RPs
to accept chains with UID mismatches. Since UID checking was previously
required, this would be a potentially dangerous contravention of the
issuing CA's intent.

An RP should either reject certificates containing UIDs or process
them properly, not simply ignore them. Since nobody uses this feature
and nobody can argue for why it is needed, I suggest that we require
RPs to reject certificates containing UIDs.

-Steve

>The recommendation that Section 6.1.3 be amended to remove references to 
>UIDs makes sense; CAs conforming to the current profile should not be 
>required to support this mechanism for certificate chaining, nor should 
>UIDs be allowed to needlessly complicate the revised validation algorithm.
>
>However, requiring that UIDs be absent from a certificate would be a 
>serious error, as would recommending that conforming CAs reject 
>certificates containing UIDs. If the certificate in question contains the 
>information required to perform chaining and validation as per the current 
>profile, why should the CA not be free to ignore the presence of extraneous 
>infomation? I think it would be a Very Bad Idea to break backwards 
>compatibility for what is essentially nothing more than an aesthetic 
>reason. A CA conforming to the current X.509 v3 profile should NOT reject a 
>certificate that has a deprecated field from a X.509 v2 profile -- it 
>should just ignore that field. Of course, eveyone "knows" that "nobody" 
>uses UIDs, but that's not a good reason to break, even hypothetically, 
>certificates that do use them unless there's a truly compelling positive or 
>negative functional benefit.
>
>Ari Kermaier
>Phaos Technology
>
>>Last fall, we agreed to remove issuer and subject unique identifier
>>comparison from the validation algorithm. At least, I think we did. The
>>argument was that nobody uses unique identifiers and there's no good
>>reason to retain support for them.
>>
>>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
>>they remain in step (a) (5) of section 6.1.3, which says:
>>
>>          (5) The certificate issuer unique identifier is the
>>          working_issuer_UID, meaning:
>>
>>             (i) working_issuer_UID is non-null and matches the value in
>>             the issuerUID field, or
>>
>>             (ii) working_issuer_UID is null and the issuerUID field is
>>             not present.
>>
>>But working_issuer_UID is no longer set anywhere. We should either put
>>back the text that initializes and updates this state variable or we
>>should change this step so that it doesn't refer to this uninitialized
>>varible. I suggest that we remove support for unique identifier chaining
>>by changing this step to say:
>>
>>          (5) The issuerUniqueID and subjectUniqueID fields are not
>>          present in the certificate.
>>
>>This will ensure that compliant implementations will not accidentally
>>accept certificates that use these fields, since support for these
>>fields is no longer required. I also suggest that we change the sentence
>>in section 4.1.2.8 that reads "Applications conforming to this profile
>>SHOULD be capable of parsing unique identifiers and making
>>comparisons."  to read "Applications conforming to this profile SHOULD
>>reject certificates that contain unique identifiers."
>>
>>-Steve
>

Date: Thu, 08 Mar 2001 10:32:28 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Ambarish Malpani <[email-masked]>
CC: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Ambarish,

> Hi Denis,
>     I don't have an issue with a single/multiple names. 

This is fine. 

> What I was remarking is, is that IETF does have the concept 
> of a non-CA signing/providing validation responses.
> 
> We could call (a) an OCSP responder/server
>               (b) an Indirect CRL Signer
>               (c) a DPV/SCVP responder/server

Some of them might be called Authorities. 

a) Revocation Status Authority - RSA  ;-)  
  (I am yet not sure if OCSP will or will not be extended and whether we 
  will keep the same name. If OCSP only relates to revocation status, then
OCSP Responder would be fine as well).

b) Not sure how we may call that service since indirect and direct entries
   can be mixed together in the same CRL. We have "CRL Issuer" has a generic
term, whether it is direct or indirect.

c) Path Validation Authority (DPV),

d) Path Discovery Helper (DPD).

Note: I am not strong on any of the above wordings. I only care that we use
different names for different security services and that we clearly identify
which service is performed by a given "Authority", "Issuer", "Responder",
"Helper", ...

Regards,

Denis

> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Wednesday, March 07, 2001 8:34 AM
> > To: Ambarish Malpani
> > Cc: 'Stephen Kent'; [email-masked]
> > Subject: Re: Open Issue in Part1: path length constraints
> >
> >
> > Ambarish,
> >
> > > Hi Steve,
> > >     While the term "VA" might not be part of the IETF standards,
> > > it is the entity that can do the following:
> > >
> > > a. Sign OCSP responses - where you directly trust the responder
> > > b. Sign Indirect CRLs (I suppose this is a circular argument)!
> > > c. Do the Delegated Path Validation protocol.
> > >
> > > Agreed?
> >
> > Certainly not !
> >
> > This would create a confusion between:
> >
> > 1) a server simply giving the revocation status of a certificate,
> > 2) a server *advertising* revocation for others CAs,
> > 3) a server saying if a certificate is valid according to some policy.
> >
> > Please use different names!
> >
> > Denis
> >
> > > Regards,
> > > Ambarish
> > >
> > >
> > > Architect
> > 650.567.5457
> > > > From: Stephen Kent [mailto:[email-masked]]
> > > > Sent: Wednesday, March 07, 2001 7:55 AM
> > > > To: Ambarish Malpani
> > > > Cc: [email-masked]
> > > > Subject: RE: Open Issue in Part1: path length constraints
> > > >
> > > >
> > > > Ambarish,
> > > >
> > > > >Steve, we use the Indirect CRL/Indirect delta CRL format to
> > > > >propogate revocation information for particular CAs between
> > > > >our VAs (Validation Authorities).
> > > > >
> > > > >Basically, as master VA can receive information that a particular
> > > > >cert was revoked at a CA (even if the CA has not had time to
> > > > >issue a new CRL as yet). It can (and does) create a Indirect
> > > > >CRL with this information that it signs. The VA never acts
> > > > >as a CA - it never issues certs, but still needs to be
> > > > >responsible for creating and propogating revocation information
> > > > >to other VAs.
> > > > >
> > > > >While we use these indirect CRLs to propogate information just
> > > > >amongst VAs, it is not a stretch to seeing clients trust these
> > > > >indirect CRLs for their own purposes.
> > > > >
> > > > >Hope this helps justify why it does make sense for non-CAs to
> > > > >still issue CRLs.
> > > >
> > > > I understand the mechanism you are employing, and I see
> > nothing wrong
> > > > with it. However, I don't think the notion of a "VA" is
> > part of ITU
> > > > or IETF standards. Therefore, your use of it in a closed system
> > > > environment is outside the scope of these standards.
> > > >
> > > > Steve
> > > >
> >

Date: Thu, 08 Mar 2001 08:55:39 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Stephen Kent <[email-masked]>
CC: Sharon Boeyen <[email-masked]>, [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Sharon,

I read your explanations below. We do not have any problem about the
concepts, but there is a vocbulary problem here. It would be unfortunate to
say that an Authority may only be a CA or an AA. An Authority needs to be
qualified by a term: C-A (C= Certification) or A-A (A = Attribute). There
are and will be other Authorities in a PKIX. As an example: TS-A (TS = Time
Stamping).

I do know that, for ISO documents, definitions only apply for the given
document where the definition is, but rewording clause 3.3.6 from X.509
along the following would need to be considered:

Authority: "An entity, trusted by some other entities for a security related
service. Two types of authorities are defined in this Specification;
certification authority which issues public-key certificates and attribute
authority which issues attribute certificates. Other types might be defined
in the future."

Denis

> Sharon,
> 
> >Re the X.509 language - The main reason you see terms  like 'authority' and
> >CRL issuer instead of CA is that CRLs can also be issued for
> >attribute certificates.
> >These CRLs would be signed by Attribute Authorities (AA) not by CAs.
> >As editor,
> >one my editing tasks for the 2000 509 was to replace "CA" with
> >"authority" wherever both CA and AA
> >were intended. That is the main reason you see these terms. There
> >really hasn't been any
> >discussion in 509 on non CA, AA issued CRLs that I can remember.
> >Taking this to the next
> >step, the definition of "authority" in X.509 (clause 3.3.6) is: "An
> >entity, responsible for the issuance of certificates. Two types are
> >defined in this Specification; certification authority which issues
> >public-key certificates and attribute authority which issues
> >attribute certificates." So, at least from the X.509 perspective an
> >authority is either a CA or an AA.
> 
> Thanks for the clarification; it reaffirms my recent comments about
> the scope of the term "authority." That says that there is no
> explicit provision for non CA/AA issuance of CRLs in X.509. So, not
> only does PKIX have to decide if it wants to create the notion of a
> new sort of authority for CRL issuance, but then we have to see if
> X.509 will follow this approach as well.
> 
> Steve

From: Dave Oshman <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, David Simonetti <[email-masked]>
Cc: [email-masked]
Subject: Separate CRL Issuance Entity Was: RE: Open Issue in Part1: path l ength constraints
Date: Wed, 7 Mar 2001 20:44:51 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A771.5DD99EE0
Content-Type: text/plain;
	charset="iso-8859-1"

I would like to consider including the option to have an entity other than a
"cert issuing  authority" to sign CRLs. In cases where a Root CA needs to
issue certificates infrequently (such as we have at Identrus), but needs to
issue CRLs much more frequently, there seems to be a case to have different
certificates for these purposes. I don't want to rule out having this
option. If we define that having the CA bit set means the capability to
issue certificates, this CRL signing entity should not have that bit set. Is
it specifically stated somewhere that the assertion of the CA bit is defined
as certificate issuance capability? My old X.509 (97) defines a CA as: An
authority trusted by one or more users to create and assign certificates.
2459 doesn't provide any more help.

Regards,
Dave Oshman

-----Original Message-----
David,

>Steve,
>
>Stephen Kent wrote:
>
>>   I see there is considerable
>>  sentiment to allow for non-CA flagged entities to sign CRLs, but I'm
>>  not yet sure I understand why folks consider it important to not turn
>>  on the CA flag in certs for such entities. After all, since we have
>>  separate key usage bits for cert and CRL signing, we can construct a
>>  cert for an entity that signs CRLs and not grant that entity the
>>  ability to sign certs, if we so desire.
>>
>
>I don't think so.  From Section 4.2.1.10:
>
>"If the cA bit is asserted, then the keyCertSign bit in the key 
>usage extension
>(see 4.2.1.3) MUST also be asserted."

Good point; I missed that one!

So, if we adhere to this constraint we can't have an entity labelled 
as a CA but restricted to issuing only CRLs.  So, we need to 
reconcile the various parts of the document to have a consistent, 
well-defined description of what folks can/should do to separate out 
CRL signing from cert signing.

Steve

------_=_NextPart_001_01C0A771.5DD99EE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Separate CRL Issuance Entity Was: RE: Open Issue in Part1: path =
length constraints</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I would like to consider including the option to have =
an entity other than a &quot;cert issuing&nbsp; authority&quot; to sign =
CRLs. In cases where a Root CA needs to issue certificates infrequently =
(such as we have at Identrus), but needs to issue CRLs much more =
frequently, there seems to be a case to have different certificates for =
these purposes. I don't want to rule out having this option. If we =
define that having the CA bit set means the capability to issue =
certificates, this CRL signing entity should not have that bit set. Is =
it specifically stated somewhere that the assertion of the CA bit is =
defined as certificate issuance capability? My old X.509 (97) defines a =
CA as: An authority trusted by one or more users to create and assign =
certificates. 2459 doesn't provide any more help.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Dave Oshman</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>David,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Steve,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Stephen Kent wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp; I see there is =
considerable</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; sentiment to allow for non-CA flagged =
entities to sign CRLs, but I'm</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; not yet sure I understand why folks =
consider it important to not turn</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; on the CA flag in certs for such =
entities. After all, since we have</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; separate key usage bits for cert and =
CRL signing, we can construct a</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; cert for an entity that signs CRLs =
and not grant that entity the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp; ability to sign certs, if we so =
desire.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I don't think so.&nbsp; From Section =
4.2.1.10:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&quot;If the cA bit is asserted, then the =
keyCertSign bit in the key </FONT>
<BR><FONT SIZE=3D2>&gt;usage extension</FONT>
<BR><FONT SIZE=3D2>&gt;(see 4.2.1.3) MUST also be =
asserted.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Good point; I missed that one!</FONT>
</P>

<P><FONT SIZE=3D2>So, if we adhere to this constraint we can't have an =
entity labelled </FONT>
<BR><FONT SIZE=3D2>as a CA but restricted to issuing only CRLs.&nbsp; =
So, we need to </FONT>
<BR><FONT SIZE=3D2>reconcile the various parts of the document to have =
a consistent, </FONT>
<BR><FONT SIZE=3D2>well-defined description of what folks can/should do =
to separate out </FONT>
<BR><FONT SIZE=3D2>CRL signing from cert signing.</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A771.5DD99EE0--

Date: Wed, 7 Mar 2001 17:18:54 -0500
To: Sharon Boeyen <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: [email-masked]

Sharon,

>Re the X.509 language - The main reason you see terms  like 'authority' and
>CRL issuer instead of CA is that CRLs can also be issued for 
>attribute certificates.
>These CRLs would be signed by Attribute Authorities (AA) not by CAs. 
>As editor,
>one my editing tasks for the 2000 509 was to replace "CA" with 
>"authority" wherever both CA and AA
>were intended. That is the main reason you see these terms. There 
>really hasn't been any
>discussion in 509 on non CA, AA issued CRLs that I can remember. 
>Taking this to the next
>step, the definition of "authority" in X.509 (clause 3.3.6) is: "An 
>entity, responsible for the issuance of certificates. Two types are 
>defined in this Specification; certification authority which issues 
>public-key certificates and attribute authority which issues 
>attribute certificates." So, at least from the X.509 perspective an 
>authority is either a CA or an AA.

Thanks for the clarification; it reaffirms my recent comments about 
the scope of the term "authority." That says that there is no 
explicit provision for non CA/AA issuance of CRLs in X.509. So, not 
only does PKIX have to decide if it wants to create the notion of a 
new sort of authority for CRL issuance, but then we have to see if 
X.509 will follow this approach as well.

Steve

Date: Wed, 7 Mar 2001 16:40:32 -0500
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: <[email-masked]>

Mike,

>Steve,
>
>We had in fact worked this very issue both onlist and offlist during the
>OCSP drafting stage.  That work led to the consensus view of an OCSP
>Authorized Responder as defined by Section 4.2.2.2 of RFC 2560 (cf. my note
>the list on 06 March).  So it seems we already have a consensus-based notion
>of what to call a non-CA OCSP entity--at least from a standards perspective.
>
>Just trying to save the WG some cycles.

Thanks,

Steve

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
Date: Wed, 7 Mar 2001 12:40:32 -0800
Importance: Normal

Steve,

We had in fact worked this very issue both onlist and offlist during the
OCSP drafting stage.  That work led to the consensus view of an OCSP
Authorized Responder as defined by Section 4.2.2.2 of RFC 2560 (cf. my note
the list on 06 March).  So it seems we already have a consensus-based notion
of what to call a non-CA OCSP entity--at least from a standards perspective.

Just trying to save the WG some cycles.

Mike

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 8:41 AM
> To: Ambarish Malpani
> Cc: [email-masked]
> Subject: RE: Open Issue in Part1: path length constraints
>
>
> Ambarish,
>
> >Hi Steve,
> >     While the term "VA" might not be part of the IETF standards,
> >it is the entity that can do the following:
> >
> >a. Sign OCSP responses - where you directly trust the responder
> >b. Sign Indirect CRLs (I suppose this is a circular argument)!
> >c. Do the Delegated Path Validation protocol.
> >
> >Agreed?
>
> Since you made the term up, I suppose a VA can do anything :-).
>
> On a more serious note, we made an explicit provision for non-CA
> signing of OCSP responses when OCSP was created. You are an author,
> so you know this. But, you didn't seem to feel a need to create a
> name for such entities at the time, which is OK too.  CRL signing
> was, prior to v3, strictly the province of a CA. What it seems we
> have in our docs, and to a lesser extent in the X.509 docs, is a
> failure to clearly describe the intent to allow non-CA entities to
> sign CRLs. I say this based on the mix of terms in 2459, and some
> selected examples of text from X.509 that refer to an "authority"
> without naming any sort of authority other than CAs (and AAs?).
>
> So, going forward, if we want to allow non-CAs to perform this
> function, let's just get the text to be clear on this point, and if
> necessary, let's create a name for these entities, to minimize
> confusion.
>
> As for DPV, it is clear that it can be performed by a non-CA entity.
>
> Steve
>

Date: Wed, 7 Mar 2001 14:40:22 -0500
To: David Simonetti <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints
Cc: [email-masked]

David,

>Steve,
>
>Stephen Kent wrote:
>
>>   I see there is considerable
>>  sentiment to allow for non-CA flagged entities to sign CRLs, but I'm
>>  not yet sure I understand why folks consider it important to not turn
>>  on the CA flag in certs for such entities. After all, since we have
>>  separate key usage bits for cert and CRL signing, we can construct a
>>  cert for an entity that signs CRLs and not grant that entity the
>>  ability to sign certs, if we so desire.
>>
>
>I don't think so.  From Section 4.2.1.10:
>
>"If the cA bit is asserted, then the keyCertSign bit in the key 
>usage extension
>(see 4.2.1.3) MUST also be asserted."

Good point; I missed that one!

So, if we adhere to this constraint we can't have an entity labelled 
as a CA but restricted to issuing only CRLs.  So, we need to 
reconcile the various parts of the document to have a consistent, 
well-defined description of what folks can/should do to separate out 
CRL signing from cert signing.

Steve

From: Sharon Boeyen <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, Ambarish Malpani <[email-masked]>
Cc: [email-masked]
Subject: RE: Open Issue in Part1: path length constraints
Date: Wed, 7 Mar 2001 14:32:55 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A73D.6858D630
Content-Type: text/plain

Re the X.509 language - The main reason you see terms  like 'authority' and 
CRL issuer instead of CA is that CRLs can also be issued for attribute
certificates.
These CRLs would be signed by Attribute Authorities (AA) not by CAs. As
editor, 
one my editing tasks for the 2000 509 was to replace "CA" with "authority"
wherever both CA and AA 
were intended. That is the main reason you see these terms. There really
hasn't been any 
discussion in 509 on non CA, AA issued CRLs that I can remember. Taking this
to the next 
step, the definition of "authority" in X.509 (clause 3.3.6) is: "An entity,
responsible for the issuance of certificates. Two types are defined in this
Specification; certification authority which issues public-key certificates
and attribute authority which issues attribute certificates." So, at least
from the X.509 perspective an authority is either a CA or an AA.

Sharon

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 11:41 AM
> To: Ambarish Malpani
> Cc: [email-masked]
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Ambarish,
> 
> >Hi Steve,
> >     While the term "VA" might not be part of the IETF standards,
> >it is the entity that can do the following:
> >
> >a. Sign OCSP responses - where you directly trust the responder
> >b. Sign Indirect CRLs (I suppose this is a circular argument)!
> >c. Do the Delegated Path Validation protocol.
> >
> >Agreed?
> 
> Since you made the term up, I suppose a VA can do anything :-).
> 
> On a more serious note, we made an explicit provision for non-CA 
> signing of OCSP responses when OCSP was created. You are an author, 
> so you know this. But, you didn't seem to feel a need to create a 
> name for such entities at the time, which is OK too.  CRL signing 
> was, prior to v3, strictly the province of a CA. What it seems we 
> have in our docs, and to a lesser extent in the X.509 docs, is a 
> failure to clearly describe the intent to allow non-CA entities to 
> sign CRLs. I say this based on the mix of terms in 2459, and some 
> selected examples of text from X.509 that refer to an "authority" 
> without naming any sort of authority other than CAs (and AAs?).
> 
> So, going forward, if we want to allow non-CAs to perform this 
> function, let's just get the text to be clear on this point, and if 
> necessary, let's create a name for these entities, to minimize 
> confusion.
> 
> As for DPV, it is clear that it can be performed by a non-CA entity.
> 
> Steve
> 

------_=_NextPart_001_01C0A73D.6858D630
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Open Issue in Part1: path length constraints</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Re the X.509 language - The main reason you see =
terms&nbsp; like 'authority' and </FONT>
<BR><FONT SIZE=3D2>CRL issuer instead of CA is that CRLs can also be =
issued for attribute certificates.</FONT>
<BR><FONT SIZE=3D2>These CRLs would be signed by Attribute Authorities =
(AA) not by CAs. As editor, </FONT>
<BR><FONT SIZE=3D2>one my editing tasks for the 2000 509 was to replace =
&quot;CA&quot; with &quot;authority&quot; wherever both CA and AA =
</FONT>
<BR><FONT SIZE=3D2>were intended. That is the main reason you see these =
terms. There really hasn't been any </FONT>
<BR><FONT SIZE=3D2>discussion in 509 on non CA, AA issued CRLs that I =
can remember. Taking this to the next </FONT>
<BR><FONT SIZE=3D2>step, the definition of &quot;authority&quot; in =
X.509 (clause 3.3.6) is: &quot;An entity, responsible for the issuance =
of certificates. Two types are defined in this Specification; =
certification authority which issues public-key certificates and =
attribute authority which issues attribute certificates.&quot; So, at =
least from the X.509 perspective an authority is either a CA or an =
AA.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Sharon</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Stephen Kent [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, March 07, 2001 11:41 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Open Issue in Part1: path length =
constraints</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Ambarish,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Hi Steve,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; While the term =
&quot;VA&quot; might not be part of the IETF standards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;it is the entity that can do the =
following:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;a. Sign OCSP responses - where you directly =
trust the responder</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;b. Sign Indirect CRLs (I suppose this is a =
circular argument)!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;c. Do the Delegated Path Validation =
protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Agreed?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Since you made the term up, I suppose a VA can =
do anything :-).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On a more serious note, we made an explicit =
provision for non-CA </FONT>
<BR><FONT SIZE=3D2>&gt; signing of OCSP responses when OCSP was =
created. You are an author, </FONT>
<BR><FONT SIZE=3D2>&gt; so you know this. But, you didn't seem to feel =
a need to create a </FONT>
<BR><FONT SIZE=3D2>&gt; name for such entities at the time, which is OK =
too.&nbsp; CRL signing </FONT>
<BR><FONT SIZE=3D2>&gt; was, prior to v3, strictly the province of a =
CA. What it seems we </FONT>
<BR><FONT SIZE=3D2>&gt; have in our docs, and to a lesser extent in the =
X.509 docs, is a </FONT>
<BR><FONT SIZE=3D2>&gt; failure to clearly describe the intent to allow =
non-CA entities to </FONT>
<BR><FONT SIZE=3D2>&gt; sign CRLs. I say this based on the mix of terms =
in 2459, and some </FONT>
<BR><FONT SIZE=3D2>&gt; selected examples of text from X.509 that refer =
to an &quot;authority&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; without naming any sort of authority other than =
CAs (and AAs?).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, going forward, if we want to allow non-CAs =
to perform this </FONT>
<BR><FONT SIZE=3D2>&gt; function, let's just get the text to be clear =
on this point, and if </FONT>
<BR><FONT SIZE=3D2>&gt; necessary, let's create a name for these =
entities, to minimize </FONT>
<BR><FONT SIZE=3D2>&gt; confusion.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As for DPV, it is clear that it can be =
performed by a non-CA entity.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Steve</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A73D.6858D630--

From: [email-masked]
Subject: unsuscribe
To: [email-masked]
Date: Wed, 7 Mar 2001 12:45:54 -0500

unsuscribe

From: Peter Sylvester <[email-masked]>
Date: Wed, 7 Mar 2001 18:12:52 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Hospitals (changed subject)
Cc: [email-masked]

> 
> I think your example simply fails to work, i.e., using the validation 
> processing algorithm there is no way to cause clients to rely on your 
> locally generated CRLs vs. the CRLs identified by the CAs. This is a 
> scenario that motivates the use of DPV.

If the hospital has to keep a record why and when a particular
activity has been accepted, then this rather motivates me to
think about an 3029/vsd service. Why should the application 
program or the user bother about the ways ways the data are
signed. There may be policy requirements that the signatures contain
ESS attributes and other things, co-signatures etc. The DPV part
is a small piece. 

Peter

Content-return: allowed
Date: Wed, 07 Mar 2001 08:43:34 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
To: [email-masked]

Hi Steve,
    I think there is value to a non-CA providing status
information in all forms - CRLs, OCSP or DPV/SCVP. I agree that
we should clarify this.

Regards,
Ambarish

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 8:41 AM
> To: Ambarish Malpani
> Cc: [email-masked]
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Ambarish,
> 
> >Hi Steve,
> >     While the term "VA" might not be part of the IETF standards,
> >it is the entity that can do the following:
> >
> >a. Sign OCSP responses - where you directly trust the responder
> >b. Sign Indirect CRLs (I suppose this is a circular argument)!
> >c. Do the Delegated Path Validation protocol.
> >
> >Agreed?
> 
> Since you made the term up, I suppose a VA can do anything :-).
> 
> On a more serious note, we made an explicit provision for non-CA 
> signing of OCSP responses when OCSP was created. You are an author, 
> so you know this. But, you didn't seem to feel a need to create a 
> name for such entities at the time, which is OK too.  CRL signing 
> was, prior to v3, strictly the province of a CA. What it seems we 
> have in our docs, and to a lesser extent in the X.509 docs, is a 
> failure to clearly describe the intent to allow non-CA entities to 
> sign CRLs. I say this based on the mix of terms in 2459, and some 
> selected examples of text from X.509 that refer to an "authority" 
> without naming any sort of authority other than CAs (and AAs?).
> 
> So, going forward, if we want to allow non-CAs to perform this 
> function, let's just get the text to be clear on this point, and if 
> necessary, let's create a name for these entities, to minimize 
> confusion.
> 
> As for DPV, it is clear that it can be performed by a non-CA entity.
> 
> Steve
> 

Content-return: allowed
Date: Wed, 07 Mar 2001 08:41:56 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
To: [email-masked]

Hi Denis,
    I don't have an issue with a single/multiple names. What I
was remarking is, is that IETF does have the concept of a
non-CA signing/providing validation responses.

We could call (a) an OCSP responder/server
              (b) an Indirect CRL Signer
              (c) a DPV/SCVP responder/server

Regards,
Ambarish

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 8:34 AM
> To: Ambarish Malpani
> Cc: 'Stephen Kent'; [email-masked]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Ambarish,
> 
> > Hi Steve,
> >     While the term "VA" might not be part of the IETF standards,
> > it is the entity that can do the following:
> > 
> > a. Sign OCSP responses - where you directly trust the responder
> > b. Sign Indirect CRLs (I suppose this is a circular argument)!
> > c. Do the Delegated Path Validation protocol.
> > 
> > Agreed?
> 
> Certainly not !
> 
> This would create a confusion between:
> 
> 1) a server simply giving the revocation status of a certificate,
> 2) a server *advertising* revocation for others CAs,
> 3) a server saying if a certificate is valid according to some policy.
> 
> Please use different names!
> 
> Denis
> 
> > Regards,
> > Ambarish
> > 
> > 
> > Architect                                                
> 650.567.5457
> > > From: Stephen Kent [mailto:[email-masked]]
> > > Sent: Wednesday, March 07, 2001 7:55 AM
> > > To: Ambarish Malpani
> > > Cc: [email-masked]
> > > Subject: RE: Open Issue in Part1: path length constraints
> > >
> > >
> > > Ambarish,
> > >
> > > >Steve, we use the Indirect CRL/Indirect delta CRL format to
> > > >propogate revocation information for particular CAs between
> > > >our VAs (Validation Authorities).
> > > >
> > > >Basically, as master VA can receive information that a particular
> > > >cert was revoked at a CA (even if the CA has not had time to
> > > >issue a new CRL as yet). It can (and does) create a Indirect
> > > >CRL with this information that it signs. The VA never acts
> > > >as a CA - it never issues certs, but still needs to be
> > > >responsible for creating and propogating revocation information
> > > >to other VAs.
> > > >
> > > >While we use these indirect CRLs to propogate information just
> > > >amongst VAs, it is not a stretch to seeing clients trust these
> > > >indirect CRLs for their own purposes.
> > > >
> > > >Hope this helps justify why it does make sense for non-CAs to
> > > >still issue CRLs.
> > >
> > > I understand the mechanism you are employing, and I see 
> nothing wrong
> > > with it. However, I don't think the notion of a "VA" is 
> part of ITU
> > > or IETF standards. Therefore, your use of it in a closed system
> > > environment is outside the scope of these standards.
> > >
> > > Steve
> > >
> 

From: Hal Lockhart <[email-masked]>
To: "'Bob Jueneman'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: X.509, PKIX, and pathLenConstraint
Date: Wed, 7 Mar 2001 11:32:54 -0500 

I thought that this was the type of situation that Attribute Certificates
were designed to handle. Aren't you confusing Authentication with
Authorization?

Hal
=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [email-masked]
F: 1-508-229-0338             www.entegrity.com
=======================================================

> From: Bob Jueneman [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 10:58 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: X.509, PKIX, and pathLenConstraint
> 
> 
> Steve, this may be "merely" a question of semantics, but let
> me outline a user-driven scenario that may be of interest here.
> 
> Suppose that I am a hospital administrator operating a network
> that allows doctors, nurses, etc., to access various resources
> using their X.509 certificates.  And let's assume for now that
> these certificates are issued by one of the public CAs, e.g.,
> VeriSign, and not by say the state medical association.
> 
> As the hospital administrator, I am probably a lot more concerned
> with whether the doctor in question currently has hospital privileges
> than I am in whether that doctor's signature is legally binding,
> and I am certainly in a much better position to be authoritative 
> about that issue than VeriSign is -- the fact that a doctor had 
> his medical license revoked would not be cause for VeriSign to 
> revoke his certificate.
> 
> I could, of course, set up a local database, and merely look up that 
> user's status, but although that works for access control, it doesn't 
> work nearly as well for say S/MIME.
> 
> So what I might like to do is to intercept all outgoing requests for 
> CRLs or OCSP, and send to my own local CRL or OCSP responder.
> I would manage that by periodically checking the real CRL list,
> but in addition I can revoke a certificate locally as I see fit.
> All that I have to do is to ensure that my certificate is included in
> the relying party software as a trusted root, or at least is 
> chained to
> a trusted root.
> 
> BTW, since the relationship is completely independent of the
> CA that issued the certificates, there is nothing in the certificate
> that would point to my CRL responder, not even a CRLDistributionPoint.
> 
> Now, am I a CA, or not? After all, I will never be issuing 
> certificates, 
> only CRLs.
> 
> My inclination would be to say that yes, I am, but what say you?
> Does it really matter one way or the other?
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> 
> Novell, Inc -- the leading provider of Net services software
> 
> 
> 
> >>> Stephen Kent <[email-masked]> 03/06/01 04:16PM >>>
> David,
> 
> To me, the text you cite (7.3) lends further credence to the notion 
> that a CA is the entity that signs CRLs. Only the CA that issued a 
> cert could sign a CRL revoking that cert, until v3 of X.509, where 
> the introduction of indirect CRLs and CRL DPs opened up new 
> possibilities. The fundamental question is whether these features 
> create a new class of entity that can sign CRLs but not be marked (in 
> its certificate) as a CA, or whether these facilities merely allow 
> one CA to delegate CRL signing to another CA, perhaps operated under 
> the same administrative jurisdiction.
> 
> Steve
> 
> 

Date: Wed, 7 Mar 2001 11:40:33 -0500
To: Ambarish Malpani <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: [email-masked]

Ambarish,

>Hi Steve,
>     While the term "VA" might not be part of the IETF standards,
>it is the entity that can do the following:
>
>a. Sign OCSP responses - where you directly trust the responder
>b. Sign Indirect CRLs (I suppose this is a circular argument)!
>c. Do the Delegated Path Validation protocol.
>
>Agreed?

Since you made the term up, I suppose a VA can do anything :-).

On a more serious note, we made an explicit provision for non-CA 
signing of OCSP responses when OCSP was created. You are an author, 
so you know this. But, you didn't seem to feel a need to create a 
name for such entities at the time, which is OK too.  CRL signing 
was, prior to v3, strictly the province of a CA. What it seems we 
have in our docs, and to a lesser extent in the X.509 docs, is a 
failure to clearly describe the intent to allow non-CA entities to 
sign CRLs. I say this based on the mix of terms in 2459, and some 
selected examples of text from X.509 that refer to an "authority" 
without naming any sort of authority other than CAs (and AAs?).

So, going forward, if we want to allow non-CAs to perform this 
function, let's just get the text to be clear on this point, and if 
necessary, let's create a name for these entities, to minimize 
confusion.

As for DPV, it is clear that it can be performed by a non-CA entity.

Steve

Date: Wed, 7 Mar 2001 11:32:55 -0500
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509, PKIX, and pathLenConstraint
Cc: <[email-masked]>

Bob,

>Steve, this may be "merely" a question of semantics, but let
>me outline a user-driven scenario that may be of interest here.
>
>Suppose that I am a hospital administrator operating a network
>that allows doctors, nurses, etc., to access various resources
>using their X.509 certificates.  And let's assume for now that
>these certificates are issued by one of the public CAs, e.g.,
>VeriSign, and not by say the state medical association.
>
>As the hospital administrator, I am probably a lot more concerned
>with whether the doctor in question currently has hospital privileges
>than I am in whether that doctor's signature is legally binding,
>and I am certainly in a much better position to be authoritative
>about that issue than VeriSign is -- the fact that a doctor had
>his medical license revoked would not be cause for VeriSign to
>revoke his certificate.
>
>I could, of course, set up a local database, and merely look up that
>user's status, but although that works for access control, it doesn't
>work nearly as well for say S/MIME.
>
>So what I might like to do is to intercept all outgoing requests for
>CRLs or OCSP, and send to my own local CRL or OCSP responder.
>I would manage that by periodically checking the real CRL list,
>but in addition I can revoke a certificate locally as I see fit.
>All that I have to do is to ensure that my certificate is included in
>the relying party software as a trusted root, or at least is chained to
>a trusted root.
>
>BTW, since the relationship is completely independent of the
>CA that issued the certificates, there is nothing in the certificate
>that would point to my CRL responder, not even a CRLDistributionPoint.
>
>Now, am I a CA, or not? After all, I will never be issuing certificates,
>only CRLs.
>
>My inclination would be to say that yes, I am, but what say you?
>Does it really matter one way or the other?

I think your example simply fails to work, i.e., using the validation 
processing algorithm there is no way to cause clients to rely on your 
locally generated CRLs vs. the CRLs identified by the CAs. This is a 
scenario that motivates the use of DPV.

Steve

Date: Wed, 07 Mar 2001 17:34:28 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Ambarish Malpani <[email-masked]>
CC: "'Stephen Kent'" <[email-masked]>, [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Ambarish,

> Hi Steve,
>     While the term "VA" might not be part of the IETF standards,
> it is the entity that can do the following:
> 
> a. Sign OCSP responses - where you directly trust the responder
> b. Sign Indirect CRLs (I suppose this is a circular argument)!
> c. Do the Delegated Path Validation protocol.
> 
> Agreed?

Certainly not !

This would create a confusion between:

1) a server simply giving the revocation status of a certificate,
2) a server *advertising* revocation for others CAs,
3) a server saying if a certificate is valid according to some policy.

Please use different names!

Denis

> > From: Stephen Kent [mailto:[email-masked]]
> > Sent: Wednesday, March 07, 2001 7:55 AM
> > To: Ambarish Malpani
> > Cc: [email-masked]
> > Subject: RE: Open Issue in Part1: path length constraints
> >
> >
> > Ambarish,
> >
> > >Steve, we use the Indirect CRL/Indirect delta CRL format to
> > >propogate revocation information for particular CAs between
> > >our VAs (Validation Authorities).
> > >
> > >Basically, as master VA can receive information that a particular
> > >cert was revoked at a CA (even if the CA has not had time to
> > >issue a new CRL as yet). It can (and does) create a Indirect
> > >CRL with this information that it signs. The VA never acts
> > >as a CA - it never issues certs, but still needs to be
> > >responsible for creating and propogating revocation information
> > >to other VAs.
> > >
> > >While we use these indirect CRLs to propogate information just
> > >amongst VAs, it is not a stretch to seeing clients trust these
> > >indirect CRLs for their own purposes.
> > >
> > >Hope this helps justify why it does make sense for non-CAs to
> > >still issue CRLs.
> >
> > I understand the mechanism you are employing, and I see nothing wrong
> > with it. However, I don't think the notion of a "VA" is part of ITU
> > or IETF standards. Therefore, your use of it in a closed system
> > environment is outside the scope of these standards.
> >
> > Steve
> >

Reply-To: <[email-masked]>
From: "Limor Elbaz" <[email-masked]>
To: <[email-masked]>
Subject: Certificate public key length
Date: Wed, 7 Mar 2001 18:16:44 +0200
Importance: Normal

Hi,

Does someone knows what is the length of RSA/DSS signature of the root CA's?

Limor Elbaz

Discretix Technologies, Ltd.
43 Hamelacha st.
Nathania, Israel
Tel: 972-9-8858810
Fax: 972-9-8858820
Mobile: 972-56-338332
Email: [email-masked]

Content-return: allowed
Date: Wed, 07 Mar 2001 08:09:54 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
To: "'Stephen Kent'" <[email-masked]>
Cc: [email-masked]

Hi Steve,
    While the term "VA" might not be part of the IETF standards,
it is the entity that can do the following:

a. Sign OCSP responses - where you directly trust the responder
b. Sign Indirect CRLs (I suppose this is a circular argument)!
c. Do the Delegated Path Validation protocol.

Agreed?

Regards,
Ambarish

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 7:55 AM
> To: Ambarish Malpani
> Cc: [email-masked]
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Ambarish,
> 
> >Steve, we use the Indirect CRL/Indirect delta CRL format to
> >propogate revocation information for particular CAs between
> >our VAs (Validation Authorities).
> >
> >Basically, as master VA can receive information that a particular
> >cert was revoked at a CA (even if the CA has not had time to
> >issue a new CRL as yet). It can (and does) create a Indirect
> >CRL with this information that it signs. The VA never acts
> >as a CA - it never issues certs, but still needs to be
> >responsible for creating and propogating revocation information
> >to other VAs.
> >
> >While we use these indirect CRLs to propogate information just
> >amongst VAs, it is not a stretch to seeing clients trust these
> >indirect CRLs for their own purposes.
> >
> >Hope this helps justify why it does make sense for non-CAs to
> >still issue CRLs.
> 
> I understand the mechanism you are employing, and I see nothing wrong 
> with it. However, I don't think the notion of a "VA" is part of ITU 
> or IETF standards. Therefore, your use of it in a closed system 
> environment is outside the scope of these standards.
> 
> Steve
> 

Date: Wed, 7 Mar 2001 10:56:33 -0500
To: "Anders Rundgren" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Last Call: Son-of-2459 e-mail addresses in Subject
Cc: "PKIX-List" <[email-masked]>

At 8:06 AM +0100 3/7/01, Anders Rundgren wrote:
>Just downloaded a new Thawte freemail certificate and found that they
>now also have fitted the Subject with the e-mail address.  I.e. they 
>now conform
>to the de-facto standard.  If 99% do not consider Son-of-2459 be the norm,
>it is 2459 that should change and not the world.
>
>In the OASIS-group which I participate they say that: "A standard is not
>a standard until deployed".
>
>Anders

Perhaps this is an indication that your freemail certificate is worth 
what you paid for it :-).

Steve

Date: Wed, 7 Mar 2001 10:54:55 -0500
To: Ambarish Malpani <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: [email-masked]

Ambarish,

>Steve, we use the Indirect CRL/Indirect delta CRL format to
>propogate revocation information for particular CAs between
>our VAs (Validation Authorities).
>
>Basically, as master VA can receive information that a particular
>cert was revoked at a CA (even if the CA has not had time to
>issue a new CRL as yet). It can (and does) create a Indirect
>CRL with this information that it signs. The VA never acts
>as a CA - it never issues certs, but still needs to be
>responsible for creating and propogating revocation information
>to other VAs.
>
>While we use these indirect CRLs to propogate information just
>amongst VAs, it is not a stretch to seeing clients trust these
>indirect CRLs for their own purposes.
>
>Hope this helps justify why it does make sense for non-CAs to
>still issue CRLs.

I understand the mechanism you are employing, and I see nothing wrong 
with it. However, I don't think the notion of a "VA" is part of ITU 
or IETF standards. Therefore, your use of it in a closed system 
environment is outside the scope of these standards.

Steve

Date: Wed, 07 Mar 2001 08:57:45 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: X.509, PKIX, and pathLenConstraint

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_3C67AD92.AECFFE9D
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Steve, this may be "merely" a question of semantics, but let
me outline a user-driven scenario that may be of interest here.

Suppose that I am a hospital administrator operating a network
that allows doctors, nurses, etc., to access various resources
using their X.509 certificates.  And let's assume for now that
these certificates are issued by one of the public CAs, e.g.,
VeriSign, and not by say the state medical association.

As the hospital administrator, I am probably a lot more concerned
with whether the doctor in question currently has hospital privileges
than I am in whether that doctor's signature is legally binding,
and I am certainly in a much better position to be authoritative=20
about that issue than VeriSign is -- the fact that a doctor had=20
his medical license revoked would not be cause for VeriSign to=20
revoke his certificate.

I could, of course, set up a local database, and merely look up that=20
user's status, but although that works for access control, it doesn't=20
work nearly as well for say S/MIME.

So what I might like to do is to intercept all outgoing requests for=20
CRLs or OCSP, and send to my own local CRL or OCSP responder.
I would manage that by periodically checking the real CRL list,
but in addition I can revoke a certificate locally as I see fit.
All that I have to do is to ensure that my certificate is included in
the relying party software as a trusted root, or at least is chained to
a trusted root.

BTW, since the relationship is completely independent of the
CA that issued the certificates, there is nothing in the certificate
that would point to my CRL responder, not even a CRLDistributionPoint.

Now, am I a CA, or not? After all, I will never be issuing certificates,=20=

only CRLs.

My inclination would be to say that yes, I am, but what say you?
Does it really matter one way or the other?

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software

>>> Stephen Kent <[email-masked]> 03/06/01 04:16PM >>>
David,

To me, the text you cite (7.3) lends further credence to the notion=20
that a CA is the entity that signs CRLs. Only the CA that issued a=20
cert could sign a CRL revoking that cert, until v3 of X.509, where=20
the introduction of indirect CRLs and CRL DPs opened up new=20
possibilities. The fundamental question is whether these features=20
create a new class of entity that can sign CRLs but not be marked (in=20
its certificate) as a CA, or whether these facilities merely allow=20
one CA to delegate CRL signing to another CA, perhaps operated under=20
the same administrative jurisdiction.

Steve

--=_3C67AD92.AECFFE9D
Content-Type: text/x-vcard
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Bob Jueneman.vcf"

--=_3C67AD92.AECFFE9D--

Date: Wed, 07 Mar 2001 08:24:45 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: WG Last Call: Son-of-2459

>Steve:
>
>->Anyway, since it is clear that not all folks will issue cross certs 
>as I suggested, I have to admit to liking the fallback position of 
>allowing specification of name constraints as part of the validation 
>procedure, on a per trust anchor basis. The main argument I've seen 
>is the one that questions whether this should be a user configurable 
>parameter, or an administrative parameter, or whether this is a MAY 
>(vs. SHOULD/MUST), which allows vendors to ignore the facility 
>entirely.
>
>I would strongly disagree against allowing name constraints to be a user
>configurable parameter.  This defeats the administrative value and assurance
>that name constraints provide.
>
>David B. Cross

David, I'm not sure that I understand your point.  Name constraints only 
constrain, they can't "unconstrain".  So if the user (or the MIS department)
can specify a name constraint as a configurable parameter, that can only
tighten the noose, not loosen it.

So how does this defeat the administrative value name constraints provide?
Maybe I'm missing something, but I've always liked the idea of the user 
acting as the root CA of last resort, since as the relying party it is the user,
and normally not some third-party CA, that has to make the decision as to 
whether or not to honor a digital signature and certificate chain.

I believe the same logic applies to policy OID constraints, by the way.

Bob

Date: Wed, 07 Mar 2001 08:34:07 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting  
To: Carlisle Adams <[email-masked]>
CC: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked], "[email-masked]'" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis-01.txt)

> Carlisle Adams wrote:
> 
> Hi Paul,
> 
>      ----------
>      From:   Paul Hoffman / IMC[SMTP:[email-masked]]
>      Sent:   Sunday, March 04, 2001 2:33 PM
>      To:     [email-masked]
>      Subject:        RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt
>      (and rfc2511bis- 01.txt)
> 
>      At 2:31 PM -0500 3/2/01, Carlisle Adams wrote:
>      >If you (or anyone else reading this) would like to run the
>      modules
>      >through a syntax checker and give me a list of the necessary
>      >changes, I'd be happy to incorporate them.  My sense, however,
>      from
>      >what you've listed below, is that the changes required will be
>      >sufficiently minor that they can all be taken care of during the
> 
>      >last "48 HOURS NOTICE" editing cleanup window from the RFC
>      Editor.
>      >Therefore, I see no reason to hold up progression of either of
>      these
>      >documents.
> 
>      Carlisle: I take it from your comments that you don't think that
>      any
>      of Phil's suggestions need to be implemented because no one
>      tripped
>      over them. Is that correct? If so, it's fine that we don't make
>      the
>      changes, but that is *quite* different than changing them after
>      everyone has used the current code for testing.
> 
> 
> I guess I wasn't subtle enough...  :-)
> 
> Yes, that was essentially my underlying message.  I'm certainly happy
> to make changes if they need to be made in order for the code to
> compile (and I will humbly submit to your suggestion that this occur
> *before* submission to the RFC Editor), but I do wonder how serious
> this can be if no one has ever mentioned having a problem here before.

I rarely find the time to thoroughly test and
report on bust ASN.1 anymore. So I try to do so
only where correct ASN.1 is desired or mandated
by policy, say for ANSI X9 or JTC 1 standards.

For example, the recent  ISO/IEC 15945 | ITU-T 
X.843 Trusted Third Party standard relied on 
IETF CRMF and OCSP ASN.1, and both contained 
significant errors. I went through the ASN.1 
for the document text, and the ASN.1 modules, 
so that the standard could meet the ITU-T 
requirements for being published. Otherwise, 
publication of the work would have been
unnecessarily delayed.

But beyond this issue, folks with tools which 
correctly implement the ASN.1 standards can
not easily implement a specification which does
not conform to the ASN.1 standards. They must
first modify the published ASN.1 by hand. That 
is the case with this work.

Once everyone is doing a hand job on the code, 
the likelihood that they they will introduce 
errors rises, and the likelihood that they will 
all implement the same specification falls. The
amount of flux of course varies with who does the
modification and how much notation they must modify
to get the specification to work. 

Sometimes this isn't such a big deal. But it is 
never necessary to publish invalid ASN.1. There 
are free syntax checkers available. 

> The PKIX meeting is in exactly 2 weeks.  How about if I report at that
> meeting whether these drafts can be progressed as they are or whether
> yet-another-revision is required?
> 
>      Phil: do you have evidence that any ASN.1 compiler other than the
>      one
>      you listed has problems with the code as it stands now?

Just looking at the few minor glitches that I 
reported, I am absolutely certain that these 
pieces of ASN.1 do not conform to any version
of the ASN.1 standards. Therefore, I would feel
safe in claiming that this would not pass muster
using either of the two free syntax checkers that
X9 and JTC 1 rely upon. That's not to say that 
there are no tools that might accept this code.
Who knows?

Please understand that these errors are so easy to
detect that I did not rely on tools of any kind to
find them. They're basically common edit errors.
But little imperfections tend to matter to me 
anytime security work is involved. And if the goal
is to maximize the likelihood that different tools
from folks that have never cooperatively tested 
their code inter work, then ASN.1 errors do matter 
in the sense noted above.

> Unless I get concrete evidence that a "currently-employed" ASN.1
> compiler fails to compile this code, the drafts will remain
> unchanged.  (Phil may provide evidence for a compiler of his choosing
> if he wishes, but at least one set of corrections must come from one
> of the implementors that have been involved in the interop testing all
> this time.)  Does this seem fair enough?  After all, the implementors
> now have interoperable code; we shouldn't make them re-tinker all the
> way back to the ASN.1 compilation stage unless there is a good reason.

Do as you wish. No time for this myself right now.
But I would assert that having two implementations
of broken ASN.1 is not quite as good as having two
implementations of correct ASN.1. And the problems
of relying on bust ASN.1 really only begins to become
evident when N players, not working together or with
your test group, pick up the standard and attempt to 
implement the work with compliant tools. These are
the folks that are likely to be disadvantaged or to
get it wrong. They may not have the advantage of
collaboration.

Free tools are available for syntax checking whether
this is part of your quality process or not. I wish it
were. A lot of standards bodies I work with wish to 
rely on IETF standards in their work, and frequently
can not do so without first making corrections to the 
published ASN.1. 

If I had the time I'd check this for you. But I'm out
of the country for the next two weeks.

Phil
----
Phillip H. Griffin    Griffin Consulting
http://asn-1.com      Secure ASN.1 Design & Implementation
p:  +1-919-832-7008   1625 Glenwood Avenue
f:  +1-919-832-7390   Hayes Barton at Five Points
e:  [email-masked]    Raleigh, North Carolina 27608-2319 USA
------------------------------------------------------------

From: Peter Sylvester <[email-masked]>
Date: Wed, 7 Mar 2001 12:09:57 +0100 (MET)
To: [email-masked]
Subject: Re: WG Last Call: Son-of-2459

I think that I am in full support of Steve Hanna's point of
view about implementing path constraints just by using
"cross" certificats. 

If an administrator need to configure in a static way
the input constraints, then it seems sufficient to
me to do this via a standard method, i.e. by providing
a certificate. 
 
Denis wrote:

> I am a little bit puzzled with your suggestion. Usually a given application
> trusts an anchor to isssue names for some organizations. But another
> application may chooose to apply different rules. So this is not a pure
> decision from the CA, otherwise the application would have to evaluate these
> name constraints before accepting them. 

If the other application has different rules, then this is not the same
'trust anchor'. Or, the restriction of names inposed to some 'anchor' 
(if this is statique for the application)
can be expressed easily as a cross certificate 'against' that 'anchor'. 

> So I have difficulties to see how the original name contraints could be
> handled by using the cross certificates you mention. Whatever, this seems to
> be only a suggestion. :-)

This doesn't sound like a suggestion, it seems to me rather
a description of what can be done with the existing mechanisms.

Regards
Peter

From: "Anders Rundgren" <[email-masked]>
To: "PKIX-List" <[email-masked]>
Cc: <[email-masked]>
Subject: Last Call: Son-of-2459 e-mail addresses in Subject
Date: Wed, 7 Mar 2001 08:06:27 +0100

Just downloaded a new Thawte freemail certificate and found that they
now also have fitted the Subject with the e-mail address.  I.e. they now conform
to the de-facto standard.  If 99% do not consider Son-of-2459 be the norm,
it is 2459 that should change and not the world.

In the OASIS-group which I participate they say that: "A standard is not
a standard until deployed".

Anders

From: "Hiroyuki Sakakibara" <[email-masked]>
To: <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints, RE: X.509, PKIX, and pathLenConstraint
Date: Wed, 7 Mar 2001 13:32:40 +0900

Hi

The path validation algoritm, acctually,
does not check value in basicConstraints in the end cert,
whether it viorates calculated max_path_length or not.

I think that one solution is checking basicConstraints component value
in the end cert with calculated max_path_length value
outside "path validation" logic.

Because some application software always validate end-entity
certs only,
so may know that an end-entity cert(the end cert in a path) always
has cA=FALSE (or basicConstraints extension is absent).

This is not general case, but may be typical in implementing application
softs.

I think that many softwares would check keyUsage value in a end-cert in
similar way.
For example, in some secure e-mail systems,
a software would accepts only a cert with keyUsage with digitalSignature bit
on
for verifying a signature of a e-mail message.

I think that certification a path validation phase and
checking contents of the end cert
( except items which can be validated by the path validation algorithm
automatically) phase are different.

Sharon Boeyen>In the path validation process, from a path length constraints
standpoint it
Sharon Boeyen>should make no difference what the final cert is used for, nor
does it matter
Sharon Boeyen>what type of data was signed with the certified key. The
constraint on the
Sharon Boeyen>path is still the same. The final cert and the one containing
the constraint do
Sharon Boeyen>not count against the constraint. Is that point agreed? I want
to separate
Sharon Boeyen>these so I'll know if the DR is ok to progress.

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: +81-467-41-2183
FAX:   +81-467-41-2185
E-mail : [email-masked]

Date: Tue, 06 Mar 2001 20:48:48 -0500
From: David Simonetti <[email-masked]>
To: "David A. Cooper" <[email-masked]>
CC: PKIX <[email-masked]>
Subject: Re: X.509, PKIX, and pathLenConstraint

David,

You and Sharon make a good point:

"David A. Cooper" wrote:

> David,
>
> I think I'm starting to see where the problem lies. I disagree with you belief that including pathLenConstraint=0 means that "CA1 does not want CA2 to further issue CA certs". I believe that CA1 is only making a statement about which certificates it wishes its own relying parties to validate.

With this perspective, the only way that CA1 can constrain CA2 is by policy.  Thus, it should be technically feasible for CA2 to issue CA3 a certificate, where CA1 may rely upon CA3 for the purposes of issuing CRLs, but not issuing certificates.  In this way, CA3 is treated like any entity that CA2 may assign the function of issuing CRLs (or, acting as any other EE, signing any data object other than a certificate).

To achieve this, as Tim previously noted, 6.1.5 currently supports this through omission.  However, to 4.2.1.10, I suggest the addition of "intermediate", and I believe the note merits elevation to in-line text as follows:

"The pathLenConstraint field is meaningful only if cA is set to TRUE. In this case, it gives the maximum number of *intermediate* CA certificates that may follow this certificate in a certification path. One end-entity certificate will follow the final CA certificate in the path. The last certificate in a path is considered an end-entity certificate, whether the subject of the certificate is a CA or not."

Thoughts?

--
David Simonetti
Securify (www.securify.com), 410-356-2260

content-class: urn:content-classes:message
Subject: RE: WG Last Call: Son-of-2459
Date: Tue, 6 Mar 2001 16:54:48 -0800
From: "Trevor Freeman" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>

From: David Cross <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Last Call: Son-of-2459
Date: Tue, 6 Mar 2001 15:04:23 -0800 

Steve:

->Anyway, since it is clear that not all folks will issue cross certs 
as I suggested, I have to admit to liking the fallback position of 
allowing specification of name constraints as part of the validation 
procedure, on a per trust anchor basis. The main argument I've seen 
is the one that questions whether this should be a user configurable 
parameter, or an administrative parameter, or whether this is a MAY 
(vs. SHOULD/MUST), which allows vendors to ignore the facility 
entirely.

I would strongly disagree against allowing name constraints to be a user
configurable parameter.  This defeats the administrative value and assurance
that name constraints provide.

David B. Cross

From: "Manger, James H" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
Date: Wed, 7 Mar 2001 11:04:26 +1100 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A69A.2E42C0F8
Content-Type: text/plain;
	charset="iso-8859-1"

Carlisle,
 
Phil's items are EDITORIAL bugs in the ASN.1.
 
A lot of PKIX (particularly ASN.1 definitions) are cut 'n pasted from X.509,
other X.500-series standards, PKCS standards, etc.  There is little
coordination of ASN.1 modules between various standard groups (PKIX don't
IMPORT definitions from X.509, they redefine them in their own modules).
You often want to use PKIX and these other standards together, but compilers
tend not to like duplicate definitions of everything.  The solution is to
rearrange the definitions, IMPORTS and modules to fit your own system.  As
part of this rearranging process it is natural that people correct any
editorial bugs they create or find: some will report these to the editor,
other assume they are too trivial to worry about.  The rfc2510bis ASN.1
module even explicitly says each implementer must adjusted the module
themselves to IMPORT the definition of CertificateRequest.
 
ASN.1 error detected by another compiler in rfc2510bis appendix F:
 
1. The IMPORT section is not terminated with a semicolon.
2. CMP1999(1) & CMP2000(2) identifiers must start with a lowercase letter
3. "SEQUENCE of CertStatus": "OF" must be capitalised.
4. Some ASN.1 definitions appear in the text but not in the module:
confirmWaitTime, confirmWaitTimeValue, implicitConfirm,
implicitConfirmValue.  All the definitions are invalid ASN.1.
5. OIDs should be:
    implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
    confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
6. Types must start with a capital letter:
    ImplicitConfirmValue ::= NULL
    ConfirmWaitTimeValue ::= GeneralizedTime - time CA will wait until

------_=_NextPart_001_01C0A69A.2E42C0F8
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)</TITLE>

<META content="MSHTML 5.00.3105.105" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>Carlisle,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>Phil's 
items&nbsp;are&nbsp;EDITORIAL bugs in the ASN.1.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>A lot 
of PKIX (particularly ASN.1 definitions) are cut 'n pasted from 
X.509,&nbsp;other X.500-series standards, PKCS standards, etc.&nbsp; There is 
little coordination&nbsp;of ASN.1 modules between&nbsp;various standard groups 
(PKIX don't&nbsp;IMPORT definitions from X.509, they redefine them in their own 
modules).&nbsp; You often want to use PKIX and these other standards together, 
but compilers tend not to like duplicate definitions of everything.&nbsp; The 
solution is to rearrange the definitions, IMPORTS and modules to fit your own 
system.&nbsp; <FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>As part of this rearranging process it is natural that 
people correct any editorial bugs they create or find: some will report these to 
the editor, other assume they are too trivial to worry about.&nbsp; 
</SPAN></FONT></SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>The rfc2510bis ASN.1 module even explicitly says each 
implementer&nbsp;must adjusted the module themselves to&nbsp;IMPORT the 
definition of CertificateRequest.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>ASN.1 
error detected by another compiler in rfc2510bis appendix F:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>1. The 
IMPORT section is not terminated with a semicolon.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>2. 
CMP1999(1) &amp; CMP2000(2) identifiers must start with a lowercase 
letter</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>3. 
"SEQUENCE of CertStatus": "OF"&nbsp;must be capitalised.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>4.&nbsp;Some ASN.1 definitions appear in the text 
but&nbsp;not in the module: confirmWaitTime, confirmWaitTimeValue, 
implicitConfirm, implicitConfirmValue.&nbsp; All the definitions are invalid 
ASN.1.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>5. 
OIDs should be:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>&nbsp;&nbsp;&nbsp; implicitConfirm OBJECT IDENTIFIER 
::= {id-it 13}</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>&nbsp;&nbsp;&nbsp; confirmWaitTime OBJECT IDENTIFIER 
::= {id-it 14}</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=340435122-06032001>6. 
Types must start with a capital letter:</SPAN></FONT></DIV></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>&nbsp;&nbsp;&nbsp; ImplicitConfirmValue ::= 
NULL</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=340435122-06032001>&nbsp;&nbsp;&nbsp; ConfirmWaitTimeValue ::= 
GeneralizedTime - time CA will wait until</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C0A69A.2E42C0F8--

Date: Tue, 6 Mar 2001 18:16:33 -0500
To: David Chadwick <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: X.509, PKIX, and pathLenConstraint
Cc: "X.500 Directory Exploder List" <[email-masked]>, PKIX <[email-masked]>

David,

To me, the text you cite (7.3) lends further credence to the notion 
that a CA is the entity that signs CRLs. Only the CA that issued a 
cert could sign a CRL revoking that cert, until v3 of X.509, where 
the introduction of indirect CRLs and CRL DPs opened up new 
possibilities. The fundamental question is whether these features 
create a new class of entity that can sign CRLs but not be marked (in 
its certificate) as a CA, or whether these facilities merely allow 
one CA to delegate CRL signing to another CA, perhaps operated under 
the same administrative jurisdiction.

Steve

Content-return: allowed
Date: Tue, 06 Mar 2001 15:31:58 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
To: "'Stephen Kent'" <[email-masked]>, "David P. Kemp" <[email-masked]>
Cc: [email-masked]

Steve, we use the Indirect CRL/Indirect delta CRL format to
propogate revocation information for particular CAs between
our VAs (Validation Authorities).

Basically, as master VA can receive information that a particular
cert was revoked at a CA (even if the CA has not had time to
issue a new CRL as yet). It can (and does) create a Indirect
CRL with this information that it signs. The VA never acts
as a CA - it never issues certs, but still needs to be
responsible for creating and propogating revocation information
to other VAs.

While we use these indirect CRLs to propogate information just
amongst VAs, it is not a stretch to seeing clients trust these
indirect CRLs for their own purposes.

Hope this helps justify why it does make sense for non-CAs to
still issue CRLs.

Regards,
Ambarish

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 11:43 AM
> To: David P. Kemp
> Cc: [email-masked]
> Subject: RE: Open Issue in Part1: path length constraints
> 
> 
> Dave,
> 
> >Steve,
> >
> >I think of a "CA" as some people in a room with a Safekeeper.
> >If a CA wants to run its certificate signing functions on a machine
> >with no network connections, and it's CRL signing functions on a
> >network-connected machine, wouldn't that CA issue a certificate
> >to its CRL-signing key signed by its certificate-signing key?
> 
> I agree that there is ambiguity in what we mean when we refer to a CA 
> in such circumstances, but algorithmically I have always assumed that 
> only CAs issued CRLs and we can tell whether the entity is a CA by 
> the basic constraints extension. I see there is considerable 
> sentiment to allow for non-CA flagged entities to sign CRLs, but I'm 
> not yet sure I understand why folks consider it important to not turn 
> on the CA flag in certs for such entities. After all, since we have 
> separate key usage bits for cert and CRL signing, we can construct a 
> cert for an entity that signs CRLs and not grant that entity the 
> ability to sign certs, if we so desire.
> 
> As for your example, I would have expected the CA to accomplish the 
> same effect by having a second cert, with the same name, but with a 
> different key and with the key usage bits set to indicate CRL signing 
> but not cert signing. In that case, I would have expected the cert 
> for this second instance of the CA to have the CA flag set to true.
> 
> >If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> >isn't the subject of the certificate "a conforming CA"?
> 
> Not by my understanding.
> 
> >When X.509 says "keyCertSign: for verifying a CA's signature on
> >certificates", doesn't "a CA" refer to the people with the signing
> >machine, not a public key in a certificate with cA=true?
> 
> I have adopted a more restrictive interpretation, but I can be 
> persuaded otherwise IF I get a good answer to the question I posed 
> above.  Also, if we are to accommodate non-CA-flagged entities 
> signing CRLs, we need to chnage the text in 2459bis in a lot of 
> places and make this very clear up front.
> 
> Steve
> 

Content-return: allowed
Date: Tue, 06 Mar 2001 15:25:46 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: DER encoding of KeyUsage BIT STRING
To: "'Dr S N Henson'" <[email-masked]>, [email-masked]

Hi Steve,
    What I was referring to, was the fact that SSLeay/OpenSSL
does break up a structure into its component pieces and then
re-encode them to, for example verify signatures, etc.

    I know I had encountered this behavior when somebody was 
BER encoding their data for transmission (even thought they
had signed the original DER encoding of the data).

Regards,
Ambarish

> From: Dr S N Henson [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 3:11 PM
> To: [email-masked]
> Subject: Re: DER encoding of KeyUsage BIT STRING
> 
> 
> Ambarish Malpani wrote:
> > 
> > SSLeay/OpenSSL does that. Seems to work pretty well with most
> > things.
> > 
> 
> The way OpenSSL handles BIT STRINGs goes something like this...
> 
> If the BIT STRING comes from an decoding a BIT STRING then the encoded
> structure will precisely match the decoded one. This is primarily to
> avoid breaking signatures.
> 
> If the BIT STRING is created internally then the number of unused bits
> is set appropriately according to the number of trailing zeroes.
> 
> If the BIT STRING has certain flags set (which effectively mark it as
> unnamed) then the number of bits is set to zero.
> 
> None of this however applies to certificate extensions because the
> actual encoding is wrapped in an OCTET STRING. The actual extension
> could contain completely unstructured garbage and it would still
> reencode properly. 
> 
> Steve.
> -- 
> Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> Personal Email: [email-masked] 
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Business Email: [email-masked] PGP key: via homepage.
> 

Content-return: allowed
Date: Tue, 06 Mar 2001 15:21:43 -0800
From: Ambarish Malpani <[email-masked]>
Subject: Son-of-2459 - AIA with multiple AccessDescriptions with the same accessMethod
To: [email-masked]

Hi Guys,
    In the specification for AIA (section 4.2.2.1), there can
be multiple AccessDescriptions.

Can there be > 1 AccessDescription with the same accessMethod?
People have asked us a few times if this is legal or not. I think
this should be allowed and so specified in Son-of-2459. The
rationale for this, is people want fault tolerance, where they
want to specify the location of multiple OCSP responders, so that
if one is down, you can go to another.

Does this make sense?
Regards,
Ambarish

Date: Tue, 06 Mar 2001 23:11:27 +0000
From: Dr S N Henson <[email-masked]>
Organization: S N Henson
To: [email-masked]
Subject: Re: DER encoding of KeyUsage BIT STRING

Ambarish Malpani wrote:
> 
> SSLeay/OpenSSL does that. Seems to work pretty well with most
> things.
> 

The way OpenSSL handles BIT STRINGs goes something like this...

If the BIT STRING comes from an decoding a BIT STRING then the encoded
structure will precisely match the decoded one. This is primarily to
avoid breaking signatures.

If the BIT STRING is created internally then the number of unused bits
is set appropriately according to the number of trailing zeroes.

If the BIT STRING has certain flags set (which effectively mark it as
unnamed) then the number of bits is set to zero.

None of this however applies to certificate extensions because the
actual encoding is wrapped in an OCTET STRING. The actual extension
could contain completely unstructured garbage and it would still
reencode properly. 

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

Content-return: allowed
Date: Tue, 06 Mar 2001 14:37:45 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: DER encoding of KeyUsage BIT STRING
To: "'Peter Gutmann'" <[email-masked]>, [email-masked]

SSLeay/OpenSSL does that. Seems to work pretty well with most
things.

Regards,
Ambarish

> From: Peter Gutmann [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 11:52 AM
> To: [email-masked]
> Subject: Re: DER encoding of KeyUsage BIT STRING
> 
> 
> 
> 
> John Thielens <[email-masked]> writes:
> 
> >Ordinarily, I wouldn't even notice.  But in this case, the 
> certificate goes
> >through a toolkit that parses the certificate into an 
> internal canonical form
> >and then regenerates its own DER encoded certificate, 
> thereby changing the
> >second encoding into the first.
> 
> Is there really a toolkit out there which does that?  
> Wouldn't that break about
> 90% of the certificates in existence?
> 
> (I'm not just being facetious with that question, I can't 
> imagine how anyone
>  could field a toolkit which recodes certs into correct DER 
> without finding
>  that almost everything they try fails to work after the 
> recoding.  Which
>  toolkit is this?  I should probably put a warning about this 
> in the style
>  guide).
> 
> >1) the "unusual" CA is at fault for generating an improper 
> DER encoding with
> >trailing 0's explicit in a BIT STRING.
> 
> Yes, look up the rules for named bit strings in X.680/690 (I 
> don't have a copy
> handy at the moment so I can't quote chapter and verse).  
> OTOH the CA isn't
> that unusual, a lot of CAs and implementations do this (thus 
> my surprise that
> the toolkit managed to get past any field testing with that 
> behaviour).
> 
> Peter.
> 

Date: Tue, 06 Mar 2001 17:09:05 -0500
From: David Simonetti <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Steve,

Stephen Kent wrote:

>  I see there is considerable
> sentiment to allow for non-CA flagged entities to sign CRLs, but I'm
> not yet sure I understand why folks consider it important to not turn
> on the CA flag in certs for such entities. After all, since we have
> separate key usage bits for cert and CRL signing, we can construct a
> cert for an entity that signs CRLs and not grant that entity the
> ability to sign certs, if we so desire.
>

I don't think so.  From Section 4.2.1.10:

"If the cA bit is asserted, then the keyCertSign bit in the key usage extension
(see 4.2.1.3) MUST also be asserted."

--
David Simonetti
Securify (www.securify.com), 410-356-2260

Date: Tue, 6 Mar 2001 14:42:30 -0500
To: "David P. Kemp" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: [email-masked]

Dave,

>Steve,
>
>I think of a "CA" as some people in a room with a Safekeeper.
>If a CA wants to run its certificate signing functions on a machine
>with no network connections, and it's CRL signing functions on a
>network-connected machine, wouldn't that CA issue a certificate
>to its CRL-signing key signed by its certificate-signing key?

I agree that there is ambiguity in what we mean when we refer to a CA 
in such circumstances, but algorithmically I have always assumed that 
only CAs issued CRLs and we can tell whether the entity is a CA by 
the basic constraints extension. I see there is considerable 
sentiment to allow for non-CA flagged entities to sign CRLs, but I'm 
not yet sure I understand why folks consider it important to not turn 
on the CA flag in certs for such entities. After all, since we have 
separate key usage bits for cert and CRL signing, we can construct a 
cert for an entity that signs CRLs and not grant that entity the 
ability to sign certs, if we so desire.

As for your example, I would have expected the CA to accomplish the 
same effect by having a second cert, with the same name, but with a 
different key and with the key usage bits set to indicate CRL signing 
but not cert signing. In that case, I would have expected the cert 
for this second instance of the CA to have the CA flag set to true.

>If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
>isn't the subject of the certificate "a conforming CA"?

Not by my understanding.

>When X.509 says "keyCertSign: for verifying a CA's signature on
>certificates", doesn't "a CA" refer to the people with the signing
>machine, not a public key in a certificate with cA=true?

I have adopted a more restrictive interpretation, but I can be 
persuaded otherwise IF I get a good answer to the question I posed 
above.  Also, if we are to accommodate non-CA-flagged entities 
signing CRLs, we need to chnage the text in 2459bis in a lot of 
places and make this very clear up front.

Steve

Date: Tue, 6 Mar 2001 14:52:23 -0500
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: WG Last Call: Son-of-2459
Cc: <[email-masked]>

Trevor,

>Steve,
>I think your original idea is the right one. I am sure that products
>will appear which will support the features contained in son of RFC2459,
>so I think it premature to introduce another mechanism. I also agree
>with your premise that there will be a drive for the use of CAs who's
>job is the issuance of cross certificates to other CAs with a view to
>managing the trust relationships for a set of resources, and may never
>in their lifetime issue a certificate to a end user. I have seen this as
>an increasing trend with deployment planning due to the realisation of
>the complexity of the trust relationships required by organisations.

I appreciate the support, but I fear that we may be arguing for 
different models. I would want to see an organizational CA issue 
cross certs with name constraints, and that CA (or a subordinate of 
it) would certainly issue certs to end users. I am not fond of the 
"bridge CA" model that the U.S. federal PKI adopted, because none of 
its subscriber organizations can issue cross certs to the bridge 
containing other than simple, prohibited subtree name constraints. 
I'd be happier if the bridge CA subscriber organizations took the 
certs issued by the bridge CA and used them as a basis for issuing 
direct cross certs with name constraints. But I've been told that the 
complexity of doing that would be too great for the subscriber 
organizations, so ...

Anyway, since it is clear that not all folks will issue cross certs 
as I suggested, I have to admit to liking the fallback position of 
allowing specification of name constraints as part of the validation 
procedure, on a per trust anchor basis. The main argument I've seen 
is the one that questions whether this should be a user configurable 
parameter, or an administrative parameter, or whether this is a MAY 
(vs. SHOULD/MUST), which allows vendors to ignore the facility 
entirely.

Steve

From: "Michael Myers" <[email-masked]>
To: "David Kemp" <[email-masked]>, <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
Date: Tue, 6 Mar 2001 13:31:06 -0800
Importance: Normal

> From: David Kemp [[email-masked]]
> Sent: Tuesday, March 06, 2001 8:25 AM
> To: [email-masked]
> Subject: RE: Open Issue in Part1: path length constraints
>
> . . .
>
> P.S. There is a difference between OCSP and CRLs - OCSP responses
> can be signed by a "trusted" responder . . . . CRLs, on the other hand,
> are never valid unless signed by the CA or the CA's designee.
>
> . . .

Dave,

Does your observation of a "trusted" responder interpret case 1.b below or
were you intending to speak to some broader notion?

Section 4.2.2.2 of RFC 2560 asserts the following normative requirements:

   "Systems or applications that rely on OCSP responses . . . MUST reject
   the response if the certificate required to validate the signature on
   the response fails to meet at least one of the following criteria:

   "1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

The generality of case 1 allows for two sub-cases:

   1.a  An implicitly trusted but nonetheless CA-delegated trusted
   public key; and

   1.b  A key that is implicitly trusted by a relying party but is
   in no way related to the issuer of the certificate in question.

Mike

From: Sharon Boeyen <[email-masked]>
To: "'David Chadwick'" <[email-masked]>, "David A. Cooper" <[email-masked]>
Cc: "X.500 Directory Exploder List" <[email-masked]>, Tim Polk <[email-masked]>, PKIX <[email-masked]>
Subject: RE: X.509, PKIX, and pathLenConstraint
Date: Tue, 6 Mar 2001 15:35:48 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A67D.073A2DB0
Content-Type: text/plain

I can't help thinking this is getting much more complicated than it needs to
or that the discussion needs to be split into two threads, one on path
length constraints and the other on CRL-issuers.

First, there IS a definition of what a CA is (X.509 clause 3.3.16. It is "An
authority trusted by one or more users to create and assign public-key
certificates. Optionally the certification authority may create the users'
keys."

A CA also has responsibility for certificate revocation , but can delegate
that to another authority, or delegate the task of making revocation status
information available (e.g. an OCSP responder)as per the 509 quotes David C
passed along. That is the reason that the X.509 text now uses the term
CRL-issuer pretty much throughout when it talks about an entity that issues
a CRL. 

In the path validation process, from a path length constraints standpoint it
should make no difference what the final cert is used for, nor does it
matter what type of data was signed with the certified key. The constraint
on the path is still the same. The final cert and the one containing the
constraint do not count against the constraint. Is that point agreed? I want
to separate these so I'll know if the DR is ok to progress.

On the other issue of who issues CRLs, if the CA that issued the certificate
doesn't do it, then it is the responsibility of that CA to indicate the
responsible authority (as per the 509 quotes from David C), however an
entity that does not issue certificates is not a CA. Having said that, I'm
not convinced that at least for path validation reasons we need yet another
term.

Sharon

------_=_NextPart_001_01C0A67D.073A2DB0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: X.509, PKIX, and pathLenConstraint</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I can't help thinking this is getting much more =
complicated than it needs to or that the discussion needs to be split =
into two threads, one on path length constraints and the other on =
CRL-issuers.</FONT></P>

<P><FONT SIZE=3D2>First, there IS a definition of what a CA is (X.509 =
clause 3.3.16. It is &quot;An authority trusted by one or more users to =
create and assign public-key certificates. Optionally the certification =
authority may create the users' keys.&quot;</FONT></P>

<P><FONT SIZE=3D2>A CA also has responsibility for certificate =
revocation , but can delegate that to another authority, or delegate =
the task of making revocation status information available (e.g. an =
OCSP responder)as per the 509 quotes David C passed along. That is the =
reason that the X.509 text now uses the term CRL-issuer pretty much =
throughout when it talks about an entity that issues a CRL. </FONT></P>

<P><FONT SIZE=3D2>In the path validation process, from a path length =
constraints standpoint it should make no difference what the final cert =
is used for, nor does it matter what type of data was signed with the =
certified key. The constraint on the path is still the same. The final =
cert and the one containing the constraint do not count against the =
constraint. Is that point agreed? I want to separate these so I'll know =
if the DR is ok to progress.</FONT></P>

<P><FONT SIZE=3D2>On the other issue of who issues CRLs, if the CA that =
issued the certificate doesn't do it, then it is the responsibility of =
that CA to indicate the responsible authority (as per the 509 quotes =
from David C), however an entity that does not issue certificates is =
not a CA. Having said that, I'm not convinced that at least for path =
validation reasons we need yet another term.</FONT></P>

<P><FONT SIZE=3D2>Sharon</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A67D.073A2DB0--

To: [email-masked]
Subject: Re: DER encoding of KeyUsage BIT STRING
From: Peter Gutmann <[email-masked]>
Sender: Peter Gutmann <[email-masked]>
Date: Tue,  6 Mar 2001 14:51:57 -0500 (EST)

John Thielens <[email-masked]> writes:

>Ordinarily, I wouldn't even notice.  But in this case, the certificate goes
>through a toolkit that parses the certificate into an internal canonical form
>and then regenerates its own DER encoded certificate, thereby changing the
>second encoding into the first.

Is there really a toolkit out there which does that?  Wouldn't that break about
90% of the certificates in existence?

(I'm not just being facetious with that question, I can't imagine how anyone
 could field a toolkit which recodes certs into correct DER without finding
 that almost everything they try fails to work after the recoding.  Which
 toolkit is this?  I should probably put a warning about this in the style
 guide).

>1) the "unusual" CA is at fault for generating an improper DER encoding with
>trailing 0's explicit in a BIT STRING.

Yes, look up the rules for named bit strings in X.680/690 (I don't have a copy
handy at the moment so I can't quote chapter and verse).  OTOH the CA isn't
that unusual, a lot of CAs and implementations do this (thus my surprise that
the toolkit managed to get past any field testing with that behaviour).

Peter.

Date: Tue, 06 Mar 2001 14:23:54 -0500
From: John Thielens <[email-masked]>
Subject: DER encoding of KeyUsage BIT STRING
To: [email-masked]

I am encountering a problem with a CA that chooses to always encode the KeyUsage BIT STRING as a bit string of length 9, even if this length includes trailing 0's.  Every other CA I have encountered encodes KeyUsage as a minimum-length BIT STRING, stripping off any trailing 0's.

>From 2459:

KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1),
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

For example, a CA certificate with digitalSignature (0), nonRepudiation (1), keyCertSign (5), and cRLSign (6), mapped out as:
   BITS = 1100 0110 0
which would appear "normally" as:
  03 (BIT STRING) 02 (of length 2) 01 (with 1 pad bit) C6 (BITS as above)
in this "unusual" case appears as:
  03 (BIT STRING) 03 (of length 3) 07 (with 7 pad bits) C6 00 (BITS as above)

Ordinarily, I wouldn't even notice.  But in this case, the certificate goes through a toolkit that parses the certificate into an internal canonical form and then regenerates its own DER encoded certificate, thereby changing the second encoding into the first.  You can imagine the consequences when I calculate the hash on the tbsCertificate that results.

So which statement is true?

1) the "unusual" CA is at fault for generating an improper DER encoding with trailing 0's explicit in a BIT STRING.

2) the toolkit is at fault for not preserving the explicit trailing 0's in an alternate DER encoding of the KeyUsage BIT STRING with a semantic subtlety.

3) the "unusual" CA is using the technically most correct encoding, and the rest of the world shares a flaw where trailing 0's are truncated improperly.

Thanks for any insight from the DER experts!

John Thielens
ValiCert

From: Carlisle Adams <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
Date: Tue, 6 Mar 2001 14:18:33 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A672.3C8D4E30
Content-Type: text/plain

Hi Paul,

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
> Sent: 	Sunday, March 04, 2001 2:33 PM
> To: 	[email-masked]
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and
> rfc2511bis- 01.txt)
> 
> At 2:31 PM -0500 3/2/01, Carlisle Adams wrote:
> >If you (or anyone else reading this) would like to run the modules 
> >through a syntax checker and give me a list of the necessary 
> >changes, I'd be happy to incorporate them.  My sense, however, from 
> >what you've listed below, is that the changes required will be 
> >sufficiently minor that they can all be taken care of during the 
> >last "48 HOURS NOTICE" editing cleanup window from the RFC Editor. 
> >Therefore, I see no reason to hold up progression of either of these 
> >documents.
> 
> Carlisle: I take it from your comments that you don't think that any 
> of Phil's suggestions need to be implemented because no one tripped 
> over them. Is that correct? If so, it's fine that we don't make the 
> changes, but that is *quite* different than changing them after 
> everyone has used the current code for testing.
 
I guess I wasn't subtle enough...  :-)

Yes, that was essentially my underlying message.  I'm certainly happy to
make changes if they need to be made in order for the code to compile (and I
will humbly submit to your suggestion that this occur *before* submission to
the RFC Editor), but I do wonder how serious this can be if no one has ever
mentioned having a problem here before.

The PKIX meeting is in exactly 2 weeks.  How about if I report at that
meeting whether these drafts can be progressed as they are or whether
yet-another-revision is required?

> Phil: do you have evidence that any ASN.1 compiler other than the one 
> you listed has problems with the code as it stands now?
 
Unless I get concrete evidence that a "currently-employed" ASN.1 compiler
fails to compile this code, the drafts will remain unchanged.  (Phil may
provide evidence for a compiler of his choosing  if he wishes, but at least
one set of corrections must come from one of the implementors that have been
involved in the interop testing all this time.)  Does this seem fair enough?
After all, the implementors now have interoperable code; we shouldn't make
them re-tinker all the way back to the ASN.1 compilation stage unless there
is a good reason.

Carlisle.

------_=_NextPart_001_01C0A672.3C8D4E30
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis- 01.txt)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Paul,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Paul Hoffman / =
IMC[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sunday, March 04, 2001 2:33 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis- 01.txt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">At 2:31 PM -0500 3/2/01, Carlisle =
Adams wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;If you (or anyone else reading =
this) would like to run the modules </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;through a syntax checker and give =
me a list of the necessary </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;changes, I'd be happy to =
incorporate them.&nbsp; My sense, however, from </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;what you've listed below, is that =
the changes required will be </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;sufficiently minor that they can =
all be taken care of during the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;last &quot;48 HOURS NOTICE&quot; =
editing cleanup window from the RFC Editor. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;Therefore, I see no reason to =
hold up progression of either of these </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;documents.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carlisle: I take it from your comments =
that you don't think that any </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of Phil's suggestions need to be =
implemented because no one tripped </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">over them. Is that correct? If so, =
it's fine that we don't make the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">changes, but that is *quite* =
different than changing them after </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">everyone has used the current code =
for testing.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I guess I =
wasn't subtle enough...&nbsp; :-)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Yes, that =
was essentially my underlying message.&nbsp; I'm certainly happy to =
make changes if they need to be made in order for the code to compile =
(and I will humbly submit to your suggestion that this occur *before* =
submission to the RFC Editor), but I do wonder how serious this can be =
if no one has ever mentioned having a problem here before.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The PKIX =
meeting is in exactly 2 weeks.&nbsp; How about if I report at that =
meeting whether these drafts can be progressed as they are or whether =
yet-another-revision is required?</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Phil: do you have evidence that any =
ASN.1 compiler other than the one </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">you listed has problems with the code =
as it stands now?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Unless I =
get concrete evidence that a &quot;currently-employed&quot; ASN.1 =
compiler fails to compile this code, the drafts will remain =
unchanged.&nbsp; (Phil may provide evidence for a compiler of his =
choosing&nbsp; if he wishes, but at least one set of corrections must =
come from one of the implementors that have been involved in the =
interop testing all this time.)&nbsp; Does this seem fair enough?&nbsp; =
After all, the implementors now have interoperable code; we shouldn't =
make them re-tinker all the way back to the ASN.1 compilation stage =
unless there is a good reason.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A672.3C8D4E30--

Date: Tue, 06 Mar 2001 18:56:18 +0000
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: "David A. Cooper" <[email-masked]>
CC: "X.500 Directory Exploder List" <[email-masked]>, Tim Polk <[email-masked]>, PKIX <[email-masked]>
Subject: Re: X.509, PKIX, and pathLenConstraint

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

David

I think that the truth of the matter is that the scenario you present
below was never discussed or thought about at the X.509 meeting
(certainly not one that I can recall). It is one of those exceptional
cases that causes one to have to re-evaluate the wording in the
standard. But before we can get the wording correct, we first have to
decide what should be the desirable/correct outcome of such an unusual
scenario.

It seems to me that CA3 in your example is not a certification authority
in our usual meaning of the term (i.e. a certificate issuer), but is
rather a "revocation authority". If CA3 were a certification authority,
then any certificates it issued would not be trusted by the RPs of CA1.
However, neither is CA3 an end entity, since end entities are not
allowed to issue revocation lists (it must be an authority, see text
from 7.3 below). Thus one solution would be to update Basic Constraints
and to have 3 classes of entities in there, namely CAs, RevAs, and EEs.
At present we simply have a boolean, which indicates CA or not CA.

My hypothesis that we need to define a new type of authority is further
supported by the text in 8.4.2.1 which states

The cA component indicates if the certified public key may be used to
verify certificate signatures. 

This definition does not include any mention of verifying revocation
lists, therefore one could argue that if CA is false the subject could
be a RevA or an EE. Therefore Basic Constraints needs to differentiate
between a RevA and an EE. ONce this is done, the solution to the problem
is simple.

If CA3 is a CA, reject the CRL
If CA3 is an EE, reject the CRL
If CA3 is a RevA, accept the CRL

Here is the text that describes the certification authority in 7.3

The authority that issues certificates (public-key or attribute) also
has the responsibility to indicate the validity of certificates it
issues.  Generally, certificates are subject to possible subsequent
revocation. This revocation, and notification of the revocation may be
done directly by the same authority that issued the certificate, or
indirectly by another authority duly authorized by the authority that
issued the certificate. An authority that issues certificates is
required to state, possibly through a published statement of their
practices, through the certificates themselves, or through some other
identified means, whether:
- The certificates cannot be revoked; or
- The certificates may be revoked by the same certificate-issuing
authority directly; or
- The certificate-issuing authority authorizes a different authority to
perform revocation.

David (Chadwick)

"David A. Cooper" wrote:
> 
> For those of you who have not been following the PKIX mailing list,
> there has been a debate recently on the proper semantics for the
> pathLenConstraint field in the basicConstraints certificate extension.
> I believe the intention of pathLenConstraint was to limit the number
> of intermediate certificates in a path, but others disagree. I have
> been arguing my point on the PKIX list, but am afraid that I am losing
> the argument. In the end, I think that either interpretation of
> pathLenConstraint would be acceptable, but it is very important that
> X.509 and PKIX are consistent, and I believe that the solution PKIX is
> leaning towards is contrary to X.509 and is also inconsistent with the
> text of Defect Report 272
> (ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_272Rev1.pdf),
> which will be sent out for ballot in the near future.
> 
> From what I can tell, the decision in PKIX will not be made on the
> basis of which semantics are better, but on the general consensus as
> to which semantics were the "original" ones. So, if you have an
> opinion on this topic, please post a message on the topic to the PKIX
> list so that we can avoid a divergence in the standards.
> 
> The point of contention in this debate can be seen by looking at the
> sample certification paths below. In in diagram, CA1 has issued a
> cross-certificate to CA2 and has included a pathLenConstraint to
> ensure that its relying parties only validate end entity certificates
> issued by CA2. CA2 issues end entity certificates, but has also issued
> a cross-certificate to CA3 so that CA2's relying parties can accept
> certificates issued by CA3. In addition, CA2 includes in its  own end
> entity certificates a cRLDistributionPoint stating that revocation
> information for the certificates issued by CA2 should be obtained from
> CA3.
> 
> CA1
>   |   basicConstraints:
>   |           cA=TRUE
>   |           pathLenConstraint=0
>   |
>   |   keyUsage:
>   |           keyCertSign, cRLSign
>   |
>   |
>  \ /                                    keyUsage: digitalSignature
> CA2
> ------------------------------------------------------------------------->
> EE
>   |                                     cRLDistributionPoints:
>   |                                                  cRLIssuer: CA3
>   |
>   |   basicConstraints:
>   |           cA=TRUE
>   |
>   |   keyUsage:
>   |           keyCertSign, cRLSign
>   |
>  \ /
> CA3
> 
> Everyone is in agreement that CA1's relying parties should validate
> the certificate issued to EE. There is disagreement, however, over
> whether CA1's relying parties should validate CRLs issued by CA3
> (which is necessary to determine the status of the certificate issued
> to EE).
> 
> In order to validate CRLs issued by CA3, CA1's relying parties would
> first attempt to validate the certification path CA1--->CA2--->CA3.
> The problem is that X.509 states that
> 
>                 [pathLenConstraint] gives the maximum number of
> CA-certificates that may
>                 follow this certificate in a certification path. Value
> 0 indicates that the subject
>                 of this certificate may issue certificates only to
> end-entities and not to further CAs.
> 
> If the certificate issued by CA2 to CA3 did not include
> basicConstraints with cA=TRUE, then everyone would agree that that
> certificate was a end-entity certificate and that the path
> CA1-->CA2-->CA3 should validate. Some people argue, however, that
> since the certificate includes basicConstraints with cA=TRUE that the
> certificate is a CA-certificate and that since the inclusion of
> pathLenConstraint=0 in the preceding certificate means that CA2 may
> issue certificates only to end-entities, the certificate issued to CA3
> should be rejected. Unfortunately, this would mean that CA1's relying
> parties could not validate CRLs issued by CA3 and so could not
> determine the status of the certificate issued by CA2 to EE, even
> though they could validate the certificate itself.
> 
> While a careful reading of the quote from X.509 above would seem to
> suggest that the certification path CA1-->CA2-->CA3 should be
> rejected, I do not think this was the intended interpretation of
> pathLenConstraint. I you read Defect Report 272, for example, it
> states that "[t]he [path length] constraint controls the number of non
> self-issued CA certificates between the CA certificate containing the
> constraint and the end-entity certificate." This sentence suggests
> that the description of pathLenConstraint was written with the
> assumption that every certification path would end with an end-entity
> certificate and that the true goal of pathLenConstraint was to limit
> the number of non self-issued intermediate certificates in a
> certification path. In other words, the certification path
> CA1-->CA2-->CA3 should be validated since in this certification path
> CA3 is playing the role of an end-entity, not a CA, and so the
> certificate CA2-->CA3 should be treated as an end-entity certificate
> when validating this path.
> 
> I believe that this was not only the original intention when defining
> pathLenConstraint but also that it is the better interpretation as a
> result of potential scenarios such as the one shown above. As I
> mentioned before, however, it appears that PKIX is leaning towards
> adopting an interpretation of pathLenConstraint that would result in
> the reject of the path CA1-->CA2-->CA3. If you believe this is
> incorrect, please make your opinion known to the PKIX list. Otherwise,
> we will need to change X.509 and DR 272 in order to avoid a divergence
> between the standards.
> 
> Dave

-- 
*****************************************************************

David Chadwick, BSc PhD
Post: IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 161 745 8169
*NEW* Mobile: +44 77 96 44 7184 *NEW*
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------2FD6D6E58340BECF9E57DB54
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[email-masked]
x-mozilla-cpt:;11160
fn:David Chadwick
end:vcard

--------------2FD6D6E58340BECF9E57DB54--

Date: Tue, 06 Mar 2001 13:38:11 -0500
From: David Simonetti <[email-masked]>
To: David Kemp <[email-masked]>
CC: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Dave,

I agree with you on both points.

Dave S.

David Kemp wrote:

> Al,
>
> The question is what should be done about language such as RFC-2459
> section 5.1.2.5:  "This profile requires inclusion of <xxx> in all CRLs
> issued by conforming CAs."  In the case of CRLs signed by an end
> entity, I wouldn't want anyone to think that "This profile does not
> require inclusion of <xxx> in all CRLs issued by conforming end
> entities". :-)
>
> I'm quite happy with Warwick's "issued by conforming CRL Issuers".
> And I see you can accept that too.
>
> But to return to the original question: should path length constraints
> yield the identical results when the CRL Issuer is a CA and when the
> CRL Issuer is an end entity?   I say yes - a CRL should be accepted
> in one case iff it is accepted in the other case.
>
> Dave
>
> P.S. There is a difference between OCSP and CRLs - OCSP responses
> can be signed by a "trusted" responder (one which is not operated
> by the Certificate Management Authority, to use the DoD's term
> for the CA and it's authorized agents.)   CRLs, on the other hand,
> are never valid unless signed by the CA or the CA's designee.
> For that reason, I think it's reasonable to talk about CRLs being
> issued by the CA even when basicConstraints is absent in the CRL-signing
> cert.  But "CRL Issuer" says it all, so there is no reason pursue
> whether a CRL signed by the CA's agent is "issued" by the CA.
>
> > From: "Al Arsenault" <[email-masked]>
> >
> > I would support the former, or some variant of it.  Let's be clear about
> > our terminology.  We don't call an entity which signs OCSP responses but
> > doesn't sign certificates and has basicConstraints absent a "CA".  We
> > shouldn't call an entity which signs CRLs but doesn't sign certificates and
> > has basicConstraints absent a "CA", either.
> >
> > If we're sloppy with the terminology, somebody later on is going to fail to
> > grasp the subtlety of it and get this wrong.

--
David Simonetti
Securify (www.securify.com), 410-356-2260

From: Santoni Adriano <[email-masked]>
To: "[email-masked]'" <[email-masked]>, David Simonetti <[email-masked]>
Cc: Cameron Smith <[email-masked]>, [email-masked]
Subject: R: Registering a Certificate Policy OID
Date: Tue, 6 Mar 2001 18:39:35 +0100 

One last remark: do not expect people from national standardization bodies
to know what an OID is :-#

A

-----Messaggio originale-----
Da: Phillip H. Griffin [mailto:[email-masked]]
Inviato: giovedì 1 marzo 2001 0.27
A: David Simonetti
Cc: Cameron Smith; [email-masked]
Oggetto: Re: Registering a Certificate Policy OID

A couple of small points though. 

Semantics seem to matter to humans. I've helped 
set up OID registries for folks who felt that 
where they got their OID arc from had marketing
implications, even though the encoded OID value
is just an opaque string that has no semantics 
at all. 

So XYZ Consortium may wish to purchase an ISO
OID under "iso(1) identified-organization(3)"
or "joint-iso-itu-t(2) internationalRA(23)",
rather than use a free IANA OID, simply 
because they feel that this makes them a
recognized international organization.

Other folks may have OID size requirements that 
preclude using a free IANA OID for some purposes,
due to the length of these values when they are 
encoded. Instead an OID that encodes in less 
octets might be purchased so that object 
identifiers require less space or bandwidth 
in messages.

Phil

David Simonetti wrote:
> 
> Excellent summary, Russ!  I have found IANA to be the most convenient.
> 
> Dave S.
> 
> Russ Housley wrote:
> 
> > Cameron:
> >
> > It is absolutely critical that private OIDs are obtained from legitimate
> > authorities!  There are two basic strategies for obtaining legitimate
> > OIDs.  The first strategy is to register the objects with an
> > authority.  This strategy is very convenient if the PKI uses a small
number
> > of relatively stable OIDs to represent certificate policies.  The second
> > strategy is to obtain an arc from an authority and assign OIDs as
> > needed.  This strategy may be preferred if policies are less stable or
many
> > OIDs are needed.
> >
> > ANSI is the registration authority for the US for organization names
under
> > the global registration process established by ISO and ITU.  A fact
sheet
> > with links to an application form is located at the ANSI web site
> > (http://web.ansi.org/public/services/reg_org.html).  The ANSI OID arc
for
> > organizations is 2.16.840.1.  ANSI charges a fee for OID arc
> > assignments.  It takes approximately two weeks to receive the assigned
OID
> > arc from ANSI.  ANSI will assign a number (NEWNUM), creating a new OID
arc:
> > 2.16.840.1.NEWNUM.
> >
> > In most countries, the national standards association maintains an OID
> > registry.  As with the ANSI arc, these are generally arcs assigned under
> > the OID 2.16.  It may take some investigation to find the OID authority
for
> > a particular country.  The addresses for ISO national member bodies may
be
> > found at http://www.iso.ch/addresse/membodies.html.  The information
> > includes postal address and electronic mail.  In many cases, a web site
is
> > specified as well.
> >
> > Another possible starting point is the International Register of ISO DCC
> > NSAP schemes.  NSAP stands for Network Service Access Point, and is used
in
> > various international standards.  The registry for schemes may be
obtained
> > at http://www.fei.org.uk/fei/dcc-nsap.htm.  The web site currently lists
> > contact information for thirteen naming authorities, some of which will
> > also assign OIDs.
> >
> > The Internet Assigned Numbers Authority (IANA) assigns private
enterprise
> > numbers, which are OIDs, in the arc 1.3.6.1.4.1.  IANA has assigned arcs
to
> > over 7,500 companies to date.  The application page is located at
> > http://www.iana.org/forms.html, under Private Enterprise Numbers.  The
IANA
> > usually takes about one week.  An OID from IANA is free.  IANA will
assign
> > a number (NEWNUM) so that the new OID arc will be 1.3.6.1.4.1.NEWNUM.
> >
> > The U.S. Federal Government maintains the Computer Security Objects
> > Registry (CSOR).  The CSOR is the naming authority for the arc
> > 2.16.840.1.101.3, and is currently registering objects for security
labels,
> > cryptographic algorithms, and certificate policies.  The certificate
policy
> > OIDs are defined in the arc 2.16.840.1.101.3.2.1.  The CSOR provides
policy
> > OIDs to agencies of the U.S. Federal Government.  For more information
> > about the CSOR, see http://csrc.nist.gov/csor/.  For more information on
> > OIDs for certificate policies, see http://csrc.nist.gov/csor/pkireg.htm.
> >
> > Good luck,
> >     Russ
> >
> > At 04:20 PM 2/26/2001 -0800, Cameron Smith wrote:
> > >(Pardon my ignorant question and wide distribution, but I don't know
where
> > >else to turn.)
> > >
> > >How does one obtain/register a Certificate Policy OID for an
organization?
> > >
> > >Regards,
> > >
> > >Cameron
> > >
> > >--
> > >Cameron Smith
> > >PKI Security Analyst
> > >Symantec Corporation
> 
> --
> David Simonetti
> Securify (www.securify.com), 410-356-2260

*******************Internet Email Confidentiality Footer******************* 
Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi
allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto
erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne
comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso
e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente
messaggio nonche' nei suoi eventuali allegati devono essere attribuite
esclusivamente al mittente e non possono essere considerate come trasmesse o
autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA
S.p.A. nei confronti del destinatario o di terzi. 
SIA S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of SIA. Besides, The contents
of this message shall be understood as neither given nor endorsed by SIA
S.p.A.. 
SIA S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof. 

Date: Tue, 6 Mar 2001 11:25:07 -0500 (EST)
From: David Kemp <[email-masked]>
Reply-To: David Kemp <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
To: [email-masked]
Content-MD5: 3AeN6HDW/l7Iw74gTVuzQQ==

Al,

The question is what should be done about language such as RFC-2459
section 5.1.2.5:  "This profile requires inclusion of <xxx> in all CRLs
issued by conforming CAs."  In the case of CRLs signed by an end
entity, I wouldn't want anyone to think that "This profile does not
require inclusion of <xxx> in all CRLs issued by conforming end
entities". :-)

I'm quite happy with Warwick's "issued by conforming CRL Issuers".
And I see you can accept that too.

But to return to the original question: should path length constraints
yield the identical results when the CRL Issuer is a CA and when the
CRL Issuer is an end entity?   I say yes - a CRL should be accepted
in one case iff it is accepted in the other case.

Dave

P.S. There is a difference between OCSP and CRLs - OCSP responses
can be signed by a "trusted" responder (one which is not operated
by the Certificate Management Authority, to use the DoD's term
for the CA and it's authorized agents.)   CRLs, on the other hand,
are never valid unless signed by the CA or the CA's designee.
For that reason, I think it's reasonable to talk about CRLs being
issued by the CA even when basicConstraints is absent in the CRL-signing
cert.  But "CRL Issuer" says it all, so there is no reason pursue
whether a CRL signed by the CA's agent is "issued" by the CA.

> From: "Al Arsenault" <[email-masked]>
>
> I would support the former, or some variant of it.  Let's be clear about 
> our terminology.  We don't call an entity which signs OCSP responses but 
> doesn't sign certificates and has basicConstraints absent a "CA".  We 
> shouldn't call an entity which signs CRLs but doesn't sign certificates and 
> has basicConstraints absent a "CA", either.
> 
> If we're sloppy with the terminology, somebody later on is going to fail to 
> grasp the subtlety of it and get this wrong.

Date: Tue, 06 Mar 2001 10:43:20 -0500
From: "Lawrence Gross" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject:  Unsubscribe

Unsubscribe

>>> Sharon Boeyen <[email-masked]> 3/6/2001 10:34:42 AM >>>
>From an X.509 perspective I want to clarify what DR 272 is intended to do. 
With respect to the portion of the path that includes the cert containing
the 
extension and the cert that is the final one in the path, that portion of
the path can
exceed the constraint value by 2. Here is the relevant text from the DR:

". Therefore the total length of this segment of the path, excluding
self-issued certificates, may exceed the value of the constraint by as many
as two certificates. (This includes the certificates at the two endpoints of
the segment plus the CA certificates between the two endpoints that are
constrained by the value of this extension.)".

If the term "end-entity" in the DR resolution is what is causing the problem
in PKIX, 
then I'm sure we can replace that term with another one (e.g. the final cert
in the path). The 
509 DR is NOT trying to comment on what the final cert represents (with
respect to a CA, end user etc). The 
term end-entity is this context was meant to differentiate that final cert
from an intermediary cert. This is exactly the same as what is done with the
similar text for delegation paths for attribute certs. 

Would replacing "end-entity" in the DR eliminate the PKIX problem?

I realize that the discussion has moved beyond the pure DR into the area of
"who can issue CRLs", but that is a separate issue from the path length
constraint in which the value in that integer represents the maximum number
of intermediary non self-issued certs between the two endpoints (where one
endpoint is the cert containing the extension and the other end-point is the
final cert in the path, regarless of the entity type that is its subject).

Sharon

> From: David Kemp [mailto:[email-masked]] 
> Sent: Tuesday, March 06, 2001 9:18 AM
> To: [email-masked] 
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Dave,
> 
> Then is it your suggestion that all PKIX words regarding issuance of
> CRLs by "conforming CAs" be extended to "conforming CAs and 
> end entities",
> or is it your suggestion that CRLs MUST NOT be verified except by a
> public key which is also permitted to verify certificates?
> 
> I strongly disagree with the latter, of course.
> 
> I disagree with the former too, since it is my belief that a 
> "conforming
> CA" is the organization which signs the CRL, not the public key which
> signs the CRL.  But if PKIX chooses to regard some CRL signers as end
> entities, then it must have words which permit some end entities to
> sign CRLs.
> 
> Dave
> 
> 
> 
> > Date: Mon, 05 Mar 2001 16:30:10 -0500
> > From: David Simonetti <[email-masked]>
> >
> > Dave,
> > 
> > Responding to your question:
> > 
> > > If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> > > isn't the subject of the certificate "a conforming CA"?
> > 
> > No, it is an end entity.
> > --
> > David Simonetti
> > Securify (www.securify.com), 410-356-2260
> > 
> 

From: Sharon Boeyen <[email-masked]>
To: [email-masked]
Subject: RE: Open Issue in Part1: path length constraints
Date: Tue, 6 Mar 2001 10:34:42 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A652.F6ADFAA0
Content-Type: text/plain

>From an X.509 perspective I want to clarify what DR 272 is intended to do. 
With respect to the portion of the path that includes the cert containing
the 
extension and the cert that is the final one in the path, that portion of
the path can
exceed the constraint value by 2. Here is the relevant text from the DR:

". Therefore the total length of this segment of the path, excluding
self-issued certificates, may exceed the value of the constraint by as many
as two certificates. (This includes the certificates at the two endpoints of
the segment plus the CA certificates between the two endpoints that are
constrained by the value of this extension.)".

If the term "end-entity" in the DR resolution is what is causing the problem
in PKIX, 
then I'm sure we can replace that term with another one (e.g. the final cert
in the path). The 
509 DR is NOT trying to comment on what the final cert represents (with
respect to a CA, end user etc). The 
term end-entity is this context was meant to differentiate that final cert
from an intermediary cert. This is exactly the same as what is done with the
similar text for delegation paths for attribute certs. 

Would replacing "end-entity" in the DR eliminate the PKIX problem?

I realize that the discussion has moved beyond the pure DR into the area of
"who can issue CRLs", but that is a separate issue from the path length
constraint in which the value in that integer represents the maximum number
of intermediary non self-issued certs between the two endpoints (where one
endpoint is the cert containing the extension and the other end-point is the
final cert in the path, regarless of the entity type that is its subject).

Sharon

> From: David Kemp [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 9:18 AM
> To: [email-masked]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> 
> Dave,
> 
> Then is it your suggestion that all PKIX words regarding issuance of
> CRLs by "conforming CAs" be extended to "conforming CAs and 
> end entities",
> or is it your suggestion that CRLs MUST NOT be verified except by a
> public key which is also permitted to verify certificates?
> 
> I strongly disagree with the latter, of course.
> 
> I disagree with the former too, since it is my belief that a 
> "conforming
> CA" is the organization which signs the CRL, not the public key which
> signs the CRL.  But if PKIX chooses to regard some CRL signers as end
> entities, then it must have words which permit some end entities to
> sign CRLs.
> 
> Dave
> 
> 
> 
> > Date: Mon, 05 Mar 2001 16:30:10 -0500
> > From: David Simonetti <[email-masked]>
> >
> > Dave,
> > 
> > Responding to your question:
> > 
> > > If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> > > isn't the subject of the certificate "a conforming CA"?
> > 
> > No, it is an end entity.
> > --
> > David Simonetti
> > Securify (www.securify.com), 410-356-2260
> > 
> 

------_=_NextPart_001_01C0A652.F6ADFAA0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Open Issue in Part1: path length constraints</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>From an X.509 perspective I want to clarify what DR =
272 is intended to do. </FONT>
<BR><FONT SIZE=3D2>With respect to the portion of the path that =
includes the cert containing the </FONT>
<BR><FONT SIZE=3D2>extension and the cert that is the final one in the =
path, that portion of the path can</FONT>
<BR><FONT SIZE=3D2>exceed the constraint value by 2. Here is the =
relevant text from the DR:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;. Therefore the total length of this segment of =
the path, excluding self-issued certificates, may exceed the value of =
the constraint by as many as two certificates. (This includes the =
certificates at the two endpoints of the segment plus the CA =
certificates between the two endpoints that are constrained by the =
value of this extension.)&quot;.</FONT></P>

<P><FONT SIZE=3D2>If the term &quot;end-entity&quot; in the DR =
resolution is what is causing the problem in PKIX, </FONT>
<BR><FONT SIZE=3D2>then I'm sure we can replace that term with another =
one (e.g. the final cert in the path). The </FONT>
<BR><FONT SIZE=3D2>509 DR is NOT trying to comment on what the final =
cert represents (with respect to a CA, end user etc). The </FONT>
<BR><FONT SIZE=3D2>term end-entity is this context was meant to =
differentiate that final cert from an intermediary cert. This is =
exactly the same as what is done with the similar text for delegation =
paths for attribute certs. </FONT></P>

<P><FONT SIZE=3D2>Would replacing &quot;end-entity&quot; in the DR =
eliminate the PKIX problem?</FONT>
</P>

<P><FONT SIZE=3D2>I realize that the discussion has moved beyond the =
pure DR into the area of &quot;who can issue CRLs&quot;, but that is a =
separate issue from the path length constraint in which the value in =
that integer represents the maximum number of intermediary non =
self-issued certs between the two endpoints (where one endpoint is the =
cert containing the extension and the other end-point is the final cert =
in the path, regarless of the entity type that is its =
subject).</FONT></P>

<P><FONT SIZE=3D2>Sharon</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: David Kemp [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, March 06, 2001 9:18 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Open Issue in Part1: path length =
constraints</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Then is it your suggestion that all PKIX words =
regarding issuance of</FONT>
<BR><FONT SIZE=3D2>&gt; CRLs by &quot;conforming CAs&quot; be extended =
to &quot;conforming CAs and </FONT>
<BR><FONT SIZE=3D2>&gt; end entities&quot;,</FONT>
<BR><FONT SIZE=3D2>&gt; or is it your suggestion that CRLs MUST NOT be =
verified except by a</FONT>
<BR><FONT SIZE=3D2>&gt; public key which is also permitted to verify =
certificates?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I strongly disagree with the latter, of =
course.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I disagree with the former too, since it is my =
belief that a </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;conforming</FONT>
<BR><FONT SIZE=3D2>&gt; CA&quot; is the organization which signs the =
CRL, not the public key which</FONT>
<BR><FONT SIZE=3D2>&gt; signs the CRL.&nbsp; But if PKIX chooses to =
regard some CRL signers as end</FONT>
<BR><FONT SIZE=3D2>&gt; entities, then it must have words which permit =
some end entities to</FONT>
<BR><FONT SIZE=3D2>&gt; sign CRLs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Date: Mon, 05 Mar 2001 16:30:10 =
-0500</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: David Simonetti =
&lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Dave,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Responding to your question:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; If that certificate has cA=3Dfalse, =
and keyCertSign=3D0 and cRLSign=3D1,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; isn't the subject of the certificate =
&quot;a conforming CA&quot;?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; No, it is an end entity.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; David Simonetti</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Securify (www.securify.com), =
410-356-2260</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A652.F6ADFAA0--

Date: Tue, 06 Mar 2001 10:24:59 -0500
From: David Simonetti <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints

I agree with Al.

Dave S.

Al Arsenault wrote:

> Dave(s), et alia,
>
> >Then is it your suggestion that all PKIX words regarding issuance of
>
> >CRLs by "conforming CAs" be extended to "conforming CAs and end entities",
>
> >or is it your suggestion that CRLs MUST NOT be verified except by a
>
> >public key which is also permitted to verify certificates?
>
> >I strongly disagree with the latter, of course.
>
> >I disagree with the former too, since it is my belief that a "conforming
>
> >CA" is the organization which signs the CRL, not the public key which
>
> >signs the CRL.  But if PKIX chooses to regard some CRL signers as end
>
> >entities, then it must have words which permit some end entities to
>
> >sign CRLs.
>
> I would support the former, or some variant of it.  Let's be clear about
> our terminology.  We don't call an entity which signs OCSP responses but
> doesn't sign certificates and has basicConstraints absent a "CA".  We
> shouldn't call an entity which signs CRLs but doesn't sign certificates and
> has basicConstraints absent a "CA", either.
>
> If we're sloppy with the terminology, somebody later on is going to fail to
> grasp the subtlety of it and get this wrong.
>
>                 Al Arsenault
>                 Chief Security Architect
>                 Diversinet Corp.

--
David Simonetti
Securify (www.securify.com), 410-356-2260

Date: Tue, 06 Mar 2001 10:24:03 -0500
From: David Simonetti <[email-masked]>
To: David Kemp <[email-masked]>
CC: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

What is a CA?  Interestingly, in a cursory review of several of the PKIX
documents I couldn't find a definition.  I have always defined a CA as "the
trusted entity that binds a public key to a subject through the issuance of a
certificate."  I have *always*assumed* that "CA" and "issuance of certificates"
go hand-in-hand.  What do you call a CA that can't issue certificates?  I don't
know, but I wouldn't call it a CA.

Dave S.

David Kemp wrote:

> Dave,
>
> Then is it your suggestion that all PKIX words regarding issuance of
> CRLs by "conforming CAs" be extended to "conforming CAs and end entities",
> or is it your suggestion that CRLs MUST NOT be verified except by a
> public key which is also permitted to verify certificates?
>
> I strongly disagree with the latter, of course.
>
> I disagree with the former too, since it is my belief that a "conforming
> CA" is the organization which signs the CRL, not the public key which
> signs the CRL.  But if PKIX chooses to regard some CRL signers as end
> entities, then it must have words which permit some end entities to
> sign CRLs.
>
> Dave
>
> > Date: Mon, 05 Mar 2001 16:30:10 -0500
> > From: David Simonetti <[email-masked]>
> >
> > Dave,
> >
> > Responding to your question:
> >
> > > If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> > > isn't the subject of the certificate "a conforming CA"?
> >
> > No, it is an end entity.
> > --
> > David Simonetti
> > Securify (www.securify.com), 410-356-2260
> >

--
David Simonetti
Securify (www.securify.com), 410-356-2260

From: Al Arsenault <[email-masked]>
To: "'David Kemp'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
Date: Tue, 6 Mar 2001 09:55:13 -0500
Encoding: 38 TEXT

Dave(s), et alia,

>Then is it your suggestion that all PKIX words regarding issuance of

>CRLs by "conforming CAs" be extended to "conforming CAs and end entities",

>or is it your suggestion that CRLs MUST NOT be verified except by a

>public key which is also permitted to verify certificates?

>I strongly disagree with the latter, of course.

>I disagree with the former too, since it is my belief that a "conforming

>CA" is the organization which signs the CRL, not the public key which

>signs the CRL.  But if PKIX chooses to regard some CRL signers as end

>entities, then it must have words which permit some end entities to

>sign CRLs.

I would support the former, or some variant of it.  Let's be clear about 
our terminology.  We don't call an entity which signs OCSP responses but 
doesn't sign certificates and has basicConstraints absent a "CA".  We 
shouldn't call an entity which signs CRLs but doesn't sign certificates and 
has basicConstraints absent a "CA", either.

If we're sloppy with the terminology, somebody later on is going to fail to 
grasp the subtlety of it and get this wrong.

		Al Arsenault
		Chief Security Architect
		Diversinet Corp.

Date: Tue, 6 Mar 2001 09:18:06 -0500 (EST)
From: David Kemp <[email-masked]>
Reply-To: David Kemp <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints
To: [email-masked]
Content-MD5: r8+BTfNLJhRpce9aNgupEQ==

Dave,

Then is it your suggestion that all PKIX words regarding issuance of
CRLs by "conforming CAs" be extended to "conforming CAs and end entities",
or is it your suggestion that CRLs MUST NOT be verified except by a
public key which is also permitted to verify certificates?

I strongly disagree with the latter, of course.

I disagree with the former too, since it is my belief that a "conforming
CA" is the organization which signs the CRL, not the public key which
signs the CRL.  But if PKIX chooses to regard some CRL signers as end
entities, then it must have words which permit some end entities to
sign CRLs.

Dave

> Date: Mon, 05 Mar 2001 16:30:10 -0500
> From: David Simonetti <[email-masked]>
>
> Dave,
> 
> Responding to your question:
> 
> > If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> > isn't the subject of the certificate "a conforming CA"?
> 
> No, it is an end entity.
> --
> David Simonetti
> Securify (www.securify.com), 410-356-2260
> 

From: "Emi Tominaga" <[email-masked]>
To: <[email-masked]>
Subject: subscribe
Date: Tue, 6 Mar 2001 22:34:54 +0900

subscribe

From: [email-masked]
To: <[email-masked]>
Subject: Brand New E-Mail pager for FR-EE!
Date: Sat, 03 Mar 2001 18:46:51 -0600
Reply-To: [email-masked]

Brand New Pager for FR-EE!

   No long term contract
   No big prepayment of airtime
   No credit check

   Put Free pagers on your kids - Give one to your loved ones - For FR-EE

   Here at Paging America we are excited to be offering you this exclusive, top of the line, full featured pager in your choice
   of color for FR=EE. This side viewable display pager is one of the smallest and lightest pagers on the market today.

   Call 877-699-8546 to be Guaranteed Your FR-EE Pager Today

   Your pager will hold up to 20 numeric messages. It has 9 music alerts and silent vibration. New FLEX technology provides three
   times the battery life. Also, message time and date stamping and smart alarm so you can set a daily or weekly reminder.
   This pager comes in black, teal and blue.

   To receive your free pager all we ask is that you allow us to provide you with the monthly airtime cancelable at any time.
   There is no long term contract. Just call the toll free number and we'll ship your Fr-ee pager to you immediately in your choice of color
   already programmed with a local telephone number for your town.

   Make this easy phone call and we will deliver your pager immediately.

   Call 877-699-8546 to get in on this exciting offer today

Brand New Pager for FR-EE!

content-class: urn:content-classes:message
Subject: RE: WG Last Call: Son-of-2459: More about delta-CRLs
Date: Mon, 5 Mar 2001 14:47:55 -0800
From: "Trevor Freeman" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, "IETF-PXIX" <[email-masked]>

David,
You are pointing out a "delta" between X.509 and pkix. 
son of 2459 allows Freshest CRL extension in CRLs. (draft 4, para
5.2.6).
Trevor

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]]
Sent: Monday, March 05, 2001 1:43 PM
To: IETF-PXIX
Subject: RE: WG Last Call: Son-of-2459: More about delta-CRLs

Trevor,

According to X.509, the freshestCRL extension may only be used in
certificates:

                 The freshest CRL extension shall be used only as a
certificate extension
                 and may be used in certificates issued to authorities
as well as certificates
                 issued to users. This field identifies the CRL to which
a certificate user should
                 refer to obtain the freshest revocation information
(e.g.: latest dCRL).

X.509 defines a CRL extension, deltaInfo, that could be included in base
CRLs, but this extension has not been included in the PKIX profile. The
deltaInfo extension is described as follows:

                 This CRL extension is for use in CRLs that are not
dCRLs and is used to
                 indicate to relying parties that dCRLs are also
available for the CRL containing
                 this extension. The extension provides the location at
which the related dCRLs
                 can be found and optionally the time at which the next
dCRL is to be issued. 

Dave

At 01:06 PM 3/5/01 -0800, Trevor Freeman wrote:
>TF> given the range of possibilities introduced by having freshest CRL
>in either the certificate or CRL, I would prefer some recommendations
on
>what should be done. Having no guidance opens up a large number of
>permutations, and we want to progress this to draft standard, we need
to
>refine our scope to what is reasonable, not what is possible.
>
>TF> Having a freshest CRL extension in a CRL provides such an
indicator.

Date: Mon, 05 Mar 2001 16:42:33 -0500
To: "IETF-PXIX" <[email-masked]>
From: "David A. Cooper" <[email-masked]>
Subject: RE: WG Last Call: Son-of-2459: More about delta-CRLs

Trevor,

According to X.509, the freshestCRL extension may only be used in certificates:

                 The freshest CRL extension shall be used only as a certificate extension
                 and may be used in certificates issued to authorities as well as certificates
                 issued to users. This field identifies the CRL to which a certificate user should
                 refer to obtain the freshest revocation information (e.g.: latest dCRL).

X.509 defines a CRL extension, deltaInfo, that could be included in base CRLs, but this extension has not been included in the PKIX profile. The deltaInfo extension is described as follows:

                 This CRL extension is for use in CRLs that are not dCRLs and is used to
                 indicate to relying parties that dCRLs are also available for the CRL containing
                 this extension. The extension provides the location at which the related dCRLs
                 can be found and optionally the time at which the next dCRL is to be issued. 

Dave

At 01:06 PM 3/5/01 -0800, Trevor Freeman wrote:
>TF> given the range of possibilities introduced by having freshest CRL
>in either the certificate or CRL, I would prefer some recommendations on
>what should be done. Having no guidance opens up a large number of
>permutations, and we want to progress this to draft standard, we need to
>refine our scope to what is reasonable, not what is possible.
>
>TF> Having a freshest CRL extension in a CRL provides such an indicator.

Date: Mon, 05 Mar 2001 16:30:10 -0500
From: David Simonetti <[email-masked]>
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Dave,

Responding to your question:

> If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
> isn't the subject of the certificate "a conforming CA"?

No, it is an end entity.
--
David Simonetti
Securify (www.securify.com), 410-356-2260

Date: Mon, 05 Mar 2001 16:19:03 -0500
From: David Simonetti <[email-masked]>
To: "David A. Cooper" <[email-masked]>
CC: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
David,
<p>Ahh, thank you for the detailed response...and I think I see where our
differences arise.
<p>Referring back to the description that Tim gave us,
<p>"If that subject of the last certificate is not a CA, the path is clearly
acceptable.&nbsp; But what if the subject is a CA? Should the relying party
reject the path because the key is in a CA certificate *or* accept the
path because the subject is not being treated as a CA?"
<p>There is a more fundamental issue here.&nbsp; It appears that you are
proposing a certificate with a Key Usage extension, but without keyCertSign=1.&nbsp;
Is this a valid CA certificate?&nbsp; I assert that it is not.
<p>From the PKIX profile for basicConstraints:
<p>"This extension MUST appear as a critical extension in all CA certificates."
<p>Since the PKIX profile is silent on this next point, from the Minimum
Interoperability Specification for PKI Components (MISPC):
<p>"CA certificates shall contain a basicConstraints extension with the
cA component set to TRUE."
<p>Then, reusing you're own quote,
<p>"If the cA bit is asserted, then the keyCertSign bit in the key usage
extension MUST also be asserted."
<p>Summarizing, if we're referring to a CA certificate, then:
<p>1. It must include a basicConstraints extension;
<br>2. cA=TRUE (if not set to TRUE, then I assert that the subject is an
end entity regardless of the subject DN);
<br>3. It must include a basicConstraints extension
<br>4. keyCertSign=1
<p>Thus, all CA certificates will always have keyCertSign=1.&nbsp; Otherwise,
it is not a CA certificate, regardless of the subject DN.
<p>Furthermore, from the basicConstraints profile,
<p>"[pathLenConstraint] gives the maximum number of CA certificates that
may follow this certificate in a certification path."
<p>Thus, if pathLenConstraint=0, then no certificates with cA=TRUE may
follow; if pathLenConstrain=1, then at most one certificate with cA=TRUE
may follow, and so on.
<p>Then, I agree with Tim's proposal:
<p>"If the working group disagrees with this interpretation, the changes
to
<br>Part 1 are straightforward.&nbsp; First, modify the parenthetical in
4.2.1.10 to
<br>indicate that the end certificate in the path is considered a CA
<br>certificate if the basic constraints extension indicates
<br>cA=TRUE.&nbsp; Secondly, add one new step (h) to 6.1.5 and reject the
<br>certification path if (h) fails."
<p>I agree with these statements because, by definition, any entity which
is a CA can issue certificates.&nbsp; I also suggest adding the statement
as quoted above from the MISPC to Section 4.2.1.10.&nbsp; Otherwise you
end up with the scenario that started this whole discussion.
<p>Per the Microsoft implementation, have you confirmed that the path length
constraint variable is actually being processed?
<p>Dave S.
<p>"David A. Cooper" wrote:
<blockquote TYPE=CITE>&nbsp;At 03:44 PM 3/2/01 -0500, David Simonetti wrote:
<blockquote type=cite cite>David,
<p>You write, "With the other semantics, the certificate issued to the
CRL-issuer could include basicConstraints with cA=TRUE without causing
any problems."
<p>I think, more specifically, the certificate issued to the CRL-issuer
includes a basicConstraints ext with cA=True and pathLenContraint=0, and
a keyUsage extension with cRLSign=1.</blockquote>

<p><br>David,
<p>Consider the following scenarios:
<p>scenario 1:
<p><tt>CA1 ----------------------------> CA2 ---------------------------------->
CA3</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; basicConstraints:<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>keyUsage:</tt>
<br><x-tab></x-tab><x-tab></x-tab><tt>cA=TRUE<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>cRLSign</tt>
<br><x-tab></x-tab><x-tab></x-tab><tt>pathLenConstraint=0</tt><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>
<br><x-tab></x-tab><tt>keyUsage:<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab></tt><font face="Courier New, Courier">CRLDistributionPoints:</font>
<br><x-tab></x-tab><x-tab></x-tab><tt>keyCertSign, cRLSign<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab></tt><font face="Courier New, Courier">cRLIssuer:
CA3</font>
<p>scenario 2:
<p><tt>CA1 ----------------------------> CA2 ---------------------------------->
CA3</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; basicConstraints:<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>basicConstraints:</tt>
<br><x-tab></x-tab><x-tab></x-tab><tt>cA=TRUE<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>cA=TRUE</tt>
<br><x-tab></x-tab><x-tab></x-tab><tt>pathLenConstraint=0</tt><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>
<br><x-tab></x-tab><tt>keyUsage:<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>keyUsage:</tt>
<br><x-tab></x-tab><x-tab></x-tab><tt>keyCertSign, cRLSign<x-tab></x-tab><x-tab></x-tab><x-tab></x-tab>keyCertSign,
cRLSign</tt>
<p><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><font face="Courier New, Courier">CRLDistributionPoints:</font>
<br><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><x-tab></x-tab><font face="Courier New, Courier">cRLIssuer:
CA3</font>
<p>In both scenarios, CA1 wishes to allow its relying parties to validate
certificates issued by CA2. Also, in both scenarios, CA2 does not issue
its own CRLs, but instead relies CA3 to issue CRLs on its behalf. The only
difference is that in scenario 1 the certificate issued by CA2 to CA3 only
"authorizes" CA3 to sign CRLs, whereas in scenario 2 the certificate issued
by CA 2 to CA3 "authorizes" CA3 to sign both certificates and CRLs (perhaps
CA2 wishes to allow its own relying parties to accept certificates issued
by CA3).
<p>In scenario 1, since CA2 is not "authorizing" CA3 to sign certificates,
it does not include the basicConstraints extension in the certificate it
issues to CA3. In scenario 2, basicConstraints is included as required
since the intention is to "authorize" CA3 to sign certificates.
<p>No matter how pathLenConstraint is defined, CA1's relying parties will
be able to validate CRLs issued by CA3 in scenario 1. With scenario 2,
however, with one definition relying parties will be able to validate the
CRLs, but with the other they will not due to the presence of basicConstraints
in the certificate issued by CA2 to CA3.
<p>Note that what you suggest ("the certificate issued to the CRL-issuer
includes a basicConstraints ext with cA=True and pathLenContraint=0, and
a keyUsage extension with cRLSign=1") would not work. Using the definition
of pathLenConstraint that you support, such a certificate would be rejected
as a "CA-certificate" since it contains basicConstraints with cA=TRUE.
This is also contradictory to the PKIX profile:
<p><x-tab></x-tab><x-tab></x-tab>The cA bit indicates if the certified
public key may be used to
<br><x-tab></x-tab><x-tab></x-tab>verify signatures on other certificates.
If the cA bit is asserted,
<br><x-tab></x-tab><x-tab></x-tab>then the keyCertSign bit in the key usage
extension
<br><x-tab></x-tab><x-tab></x-tab>MUST also be asserted. If the cA bit
is not asserted, then the
<br><x-tab></x-tab><x-tab></x-tab>keyCertSign bit in the key usage extension
MUST NOT be asserted.
<br>&nbsp;
<blockquote type=cite cite>With the new semantics, if the keyUsage extension
is absent, is it then possible for the CRL-issuer, assuming it is a CA,
to also sign certificates?</blockquote>

<p><br>Two points:
<p>1) As noted in the quote above, if one does not wish to allow a certificate
subject's public key to be used to verify certificates, then one should
not include basicConstraints with cA=TRUE. If it is included then the issuing
CA intended to allow the subject to sign certificates. On the other hand,
it we are dealing with a scenario such as scenario 2 above, then it would
always be the case that CA1's relying parties would not accept certificates
signed by CA3 (even if they accept CRLs signed by CA3). If CA1's relying
parties tried to accept a certificate signed by CA3 then they would do
so by attempting to validate a path of the form CA1--->CA2--->CA3--->EE
and this path would fail as a result of the path length constraint.
<p>2) As I stated in my previous message, nobody is proposing new semantics.
We are merely trying to deal with the results of previously ambiguous text.
The semantics that I have been advocating have already in implemented in
products. For example, I used the NIST X.509 certification path test suite
to test the path validation code in Outlook Express on a Windows 98SE machine,
and for the path length tests, the results of validation were the same
whether the last certificate in the path included basicConstraints with
cA=TRUE or not. So it seems that Microsoft's path validation code currently
implements the semantics that I have been advocating. In addition, if you
look at DR 272, which is designed to clarify the meaning of path length
constraints in X.509, the text seems to suggest that it has always been
the ISO Directory group's intention that pathLenConstraint be interpreted
in this way.
<br>&nbsp;
<p>So, if we decide that pathLenConstraints should be calculated differently
when the last certificate in the path includes basicConstraints with cA=TRUE,
then we will be "breaking" real, deployed implementations. We would also
need to work to see that DR 272 is changed so that X.509 is consistent.
It may be the case that there are also deployed implementations that compute
pathLenConstraints differently when the end certificate included basicConstraints
with cA=TRUE that would be "broken" if we agree to go the other way. But
even if this is the case, we should not reject the idea of computing pathLenConstraint
the same way for all paths of equal length based on the argument that this
would be defining "new semantics". If there had been agreement in past
on what the "old semantics" were, then we wouldn't even be talking about
path length constraints now.
<p>Dave
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;</blockquote>
--
<br>David Simonetti
<br>Securify (www.securify.com), 410-356-2260
<br>&nbsp;</html>

content-class: urn:content-classes:message
Subject: RE: WG Last Call: Son-of-2459
Date: Mon, 5 Mar 2001 13:23:49 -0800
From: "Trevor Freeman" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>, "Steve Hanna" <[email-masked]>

Steve,
I think your original idea is the right one. I am sure that products
will appear which will support the features contained in son of RFC2459,
so I think it premature to introduce another mechanism. I also agree
with your premise that there will be a drive for the use of CAs who's
job is the issuance of cross certificates to other CAs with a view to
managing the trust relationships for a set of resources, and may never
in their lifetime issue a certificate to a end user. I have seen this as
an increasing trend with deployment planning due to the realisation of
the complexity of the trust relationships required by organisations.
Trevor

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, March 02, 2001 1:39 PM
To: Steve Hanna
Cc: [email-masked]
Subject: Re: WG Last Call: Son-of-2459

Steve,

I agree with most of the comments you have made re revisions to 2459, 
but I do disagree with the discussion if name constraints and its use 
in the validation algorithm.  I think that name constraints are 
critically important in PKIs that make extensive use of cross 
certification. Yet, as you note, they are no commonly used so far. I 
think that making provision to associate name constraints with trust 
anchors is a good way to let users (or administrators) locally manage 
the concerns that this extension addresses, without having to 
persuade CAs to issue cross certs with such constraints.  In fact, I 
was persuaded to drop my proposal for local issuance of such cross 
certs because of the inclusion of this facility as a control measure 
on the validation process.

This will become more than a local implementation issue, as we 
continue with the DPV/DPD work.  My current draft of the message 
syntax for requests calls for inclusion of name constraints as a 
validation control parameter, a protocol feature motivated by the 
notion that name constraints would become a standard part of the 
validation algorithm.

Steve

content-class: urn:content-classes:message
Subject: RE: WG Last Call: Son-of-2459: More about delta-CRLs
Date: Mon, 5 Mar 2001 13:06:38 -0800
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "IETF-PXIX" <[email-masked]>

Hi Dennis,

We already discussed on the mailing list the sentence contained in
section
5.2.4  Delta CRL Indicator:

" When a conforming CA issues a delta CRL, the CA MUST also issue a CRL
that
is complete for the given scope."

However I noticed that in the new text, MUST has not been changed into
SHOULD. There has been no definitive answer but many people were arguing
for
the SHOULD.

TF> I agree, we don't have a clause requiring the publication of a full
base when using OCSP. Non-delta aware client are not impacted since they
don't know about delta publication. It is therefore impossible to
achieve all clients having the same revocation information.

Indeed, this text always allows relying parties not supporting
delta-CRLs to
have access to the same freshness of the information. I would still
think
that this should be a recommendation and not be a mandatory requirement.

However, we did not discussed that much the implications of another
sentence: "A CRL user constructing a locally held CRL from delta-CRLs
...."
Notice the "s" at the end of delta-CRLs. 

TF> There are two cases to consider here. Where the freshest CRL
indicator is in the certificate or the CRL. In the former case, it may
be necessary to merge multiple delta CRLs since there is no guarantee of
a 1-2-1 relationship between base and delta. You could have delta CRLs
partitioned by reason coded, and a base CRL for all reasons. In the
later case where the freshet CRL indicator in in the CRL, there is an
implicit 1-2-1 relationship between base and delta. A delta aware client
in this case only has to search for the latest delta CRL. Each delta has
a this update time, so a client can establish which is the latest.
Merging the latest delta CRL with the appropriate base provided the
answer.

How is it possible to issue more than one delta-CRL referring to a given
basic CRL and know that it is the freshest ? The text does not say
anything.
Some guidance should be given. Is the following an adequate rough
explanation 

TF> given the range of possibilities introduced by having freshest CRL
in either the certificate or CRL, I would prefer some recommendations on
what should be done. Having no guidance opens up a large number of
permutations, and we want to progress this to draft standard, we need to
refine our scope to what is reasonable, not what is possible.

Every delta-CRL SHOULD indicate the next issuing date of the next
delta-CRL
[we have this feature]. If the next issuing date is missing, then it
means
that no further delta-CRL will be issued and that a new base CRL is now
also
available. The delta-CRL obtained is the freshest, when the date for
checking is between the issuing date and the next issuing date of that
delta-CRL. 

Ideally, but not necessarily, the base CRL SHOULD include an indicator
saying that a delta mechanism is supported [we do not have that
indicator].

TF> Having a freshest CRL extension in a CRL provides such an indicator.

Denis

Trevor

Date: Mon, 5 Mar 2001 16:06:22 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
To: [email-masked]
Content-MD5: mcusqIpGkd/UPXaokoQTBw==

Steve,

I think of a "CA" as some people in a room with a Safekeeper.
If a CA wants to run its certificate signing functions on a machine
with no network connections, and it's CRL signing functions on a
network-connected machine, wouldn't that CA issue a certificate
to its CRL-signing key signed by its certificate-signing key?

If that certificate has cA=false, and keyCertSign=0 and cRLSign=1,
isn't the subject of the certificate "a conforming CA"?

When X.509 says "keyCertSign: for verifying a CA's signature on
certificates", doesn't "a CA" refer to the people with the signing
machine, not a public key in a certificate with cA=true?  

Regards,
Dave

From: Stephen Kent <[email-masked]>
> 
> The text avoids referring to a CA as the indirect CRL issuer at first,
> but then refers to conforming CAs in the last paragraph. If something
> other than a CA issues an indirect CRL, or any kind of CRL, then the
> wording used throughout 2459 seems to not apply to such an entity,
> because we almost always seem to come back to phrases like "if used by a
> fonforming CA ..." The best rationale I've usually heard for indirect
> CRLs has been for one CA to issue a CRL for another, e.g., if the latter
> CA looses the ability to issue CRLs to to destruction of its private
> key.
> 
> Steve

Date: Mon, 05 Mar 2001 14:06:09 -0500
To: IETF-PXIX <[email-masked]>
From: "David A. Cooper" <[email-masked]>
Subject: Re: WG Last Call: Son-of-2459: More about delta-CRLs

At 06:12 PM 3/5/01 +0100, Denis Pinkas wrote:
>However, we did not discussed that much the implications of another
>sentence: "A CRL user constructing a locally held CRL from delta-CRLs ...."
>Notice the "s" at the end of delta-CRLs. 

I think the above sentence is correct. Imagine, for example, that a user has in his local cache CRL number 3. He downloads a delta-CRL with cRLNumber 7 and BaseCRLNumber 5. Perhaps the simplest solution at this point would be for the user to download a new full CRL with a cRLNumber of 5 or greater. However, the user could instead attempt to get a second delta-CRL that has a cRLNumber of 5 or greater and a BaseCRLNumber or 3 or less. The user would then apply the two delta-CRLs in sequence to the locally held CRL number 3 in order to locally construct the contents of CRL number 7.

>How is it possible to issue more than one delta-CRL referring to a given
>basic CRL and know that it is the freshest ? The text does not say anything.
>Some guidance should be given. Is the following an adequate rough
>explanation ?

How is this any different from full CRLs? One can always compare two CRLs using the cRLNumber and/or thisUpdate time to determine which is fresher, but even if CRLs include a nextUpdate time, there is no way to know for sure that no "emergency" CRLs have been issued.

>Every delta-CRL SHOULD indicate the next issuing date of the next delta-CRL
>[we have this feature]. If the next issuing date is missing, then it means
>that no further delta-CRL will be issued and that a new base CRL is now also
>available. The delta-CRL obtained is the freshest, when the date for
>checking is between the issuing date and the next issuing date of that
>delta-CRL. 

The profile already requires every CRL to include the nextUpdate field and states that "[t]he behavior of clients processing CRLs which omit nextUpdate is not specified by this profile". I see no reason to treat delta-CRLs differently from other types of CRLs in this respect and so I think it would be a bad idea to attach some special meaning to delta-CRLs that have no nextUpdate field.

Similarly, the profile states that the nextUpdate 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." There is no reason to apply different semantics to the nextUpdate field in delta-CRLs vs. non-deltas.

>Ideally, but not necessarily, the base CRL SHOULD include an indicator
>saying that a delta mechanism is supported [we do not have that indicator].

We already have the FreshestCRL certificate extension which "identifies how delta-CRL information is obtained". Is there some compelling reason to have a CRL extension as well?

Dave

Date: Mon, 5 Mar 2001 12:46:38 -0500 (EST)
From: Polar Humenn <[email-masked]>
To: Steve Hanna <[email-masked]>
cc: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: Son-of-2459

Below Steve Hanna writes about associating name constraints with "trust
anchors" as a bad idea, and that it should be done the "proper" way by
having your departmental CA producing cross certs. Wouldn't that require
every ordinary internet user with a browser to set up their own CA?

My next question is "what is a trust anchor?"

I thought we were talking about "validation". "Trust" is a COMPLETELY
different matter. I know it's pedantic, but should such a thing be called
a validation anchor, or validity anchor. I don't associate certificate
validation with trust. I validate first, then make a trust decision.

Many browsers come fully stocked with CA certs, which is a good thing,
because there is no general way to locate one if you needed to. My trust
policy is much different than my validation policy. Removing CA certs from
the "validators" may be a way to provide a trust decision, but it should
be construed to be the only way.

Cheers,
-Polar

On Fri, 2 Mar 2001, Steve Hanna wrote:

> Steve,
> 
> I certainly agree with you that name constraints (along with policy
> constraints) are critically important in PKIs that make extensive use of
> cross certification. The U.S. Government's Federal Bridge CA (currently
> in a pilot stage) includes name constraints in cross certificates that
> it issues and I expect that CAs will do this more frequently as cross
> certification increases.
> 
> However, I don't agree that it's important to let end-users associate
> name constraints with trust anchors. Few end-users even understand what
> a trust anchor is. The number of end-users that could properly assign
> name constraints to each trust anchor is much smaller, still. When I
> talk with browser vendors, they say that PKI must become simpler, not
> harder!
> 
> A better and more practical way to achieve the same end is for the
> end-user to have a single trust anchor (the corporate or departmental
> CA) and have that CA issue cross-certificates with name constraints.
> This allows the administrator to manage all the name constraints (as
> well as policy mappings and other policy constraints, which may be
> necessary in a cross-certification environment).
> 
> If the user is really paranoid, they can set up their own CA and use
> that as their trust anchor. Anyone sophisticated enough to configure
> name constraints is sophisticated enough to run their own CA. And there
> are plenty of free CA software packages out there that are perfectly
> adequate for issuing a few cross-certificates with name constraints.
> 
> I certainly don't mind if son-of-2459 says implementations MAY support
> name constraints on trust anchors. I just don't want to have it as a
> SHOULD or a MUST.
> 
> -Steve
> 
> Stephen Kent wrote:
> > 
> > Steve,
> > 
> > I agree with most of the comments you have made re revisions to 2459,
> > but I do disagree with the discussion if name constraints and its use
> > in the validation algorithm.  I think that name constraints are
> > critically important in PKIs that make extensive use of cross
> > certification. Yet, as you note, they are no commonly used so far. I
> > think that making provision to associate name constraints with trust
> > anchors is a good way to let users (or administrators) locally manage
> > the concerns that this extension addresses, without having to
> > persuade CAs to issue cross certs with such constraints.  In fact, I
> > was persuaded to drop my proposal for local issuance of such cross
> > certs because of the inclusion of this facility as a control measure
> > on the validation process.
> > 
> > This will become more than a local implementation issue, as we
> > continue with the DPV/DPD work.  My current draft of the message
> > syntax for requests calls for inclusion of name constraints as a
> > validation control parameter, a protocol feature motivated by the
> > notion that name constraints would become a standard part of the
> > validation algorithm.
> > 
> > Steve
> 

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com

Date: Mon, 05 Mar 2001 18:12:09 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: WG Last Call: Son-of-2459: More about delta-CRLs

We already discussed on the mailing list the sentence contained in section
5.2.4  Delta CRL Indicator:

" When a conforming CA issues a delta CRL, the CA MUST also issue a CRL that
is complete for the given scope."

However I noticed that in the new text, MUST has not been changed into
SHOULD. There has been no definitive answer but many people were arguing for
the SHOULD.

Indeed, this text always allows relying parties not supporting delta-CRLs to
have access to the same freshness of the information. I would still think
that this should be a recommendation and not be a mandatory requirement.

However, we did not discussed that much the implications of another
sentence: "A CRL user constructing a locally held CRL from delta-CRLs ...."
Notice the "s" at the end of delta-CRLs. 

How is it possible to issue more than one delta-CRL referring to a given
basic CRL and know that it is the freshest ? The text does not say anything.
Some guidance should be given. Is the following an adequate rough
explanation ?

Every delta-CRL SHOULD indicate the next issuing date of the next delta-CRL
[we have this feature]. If the next issuing date is missing, then it means
that no further delta-CRL will be issued and that a new base CRL is now also
available. The delta-CRL obtained is the freshest, when the date for
checking is between the issuing date and the next issuing date of that
delta-CRL. 

Ideally, but not necessarily, the base CRL SHOULD include an indicator
saying that a delta mechanism is supported [we do not have that indicator].

Denis

Date: Mon, 05 Mar 2001 18:04:31 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "David A. Cooper" <[email-masked]>, Steve Hanna <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: Son-of-2459

Steve (Hanna),

 ... using a response from David A. Cooper.

I think that we can all agree with the following (posted by David A.
Cooper):

>>I certainly don't mind if son-of-2459 says implementations MAY support
>>name constraints on trust anchors. I just don't want to have it as a
>>SHOULD or a MUST.
 
[David A. Coooper]

I would certainly agree with this. I like the idea of adding initial name
constraints values as input to the path validation algorithm, since
otherwise they would be the only state variables whose initial values can
not be set by the relying party. However, this should in no way be a SHOULD
or a MUST.
 
Section 6.1.1 specifies several inputs to the path validation algorithm and
then describes the results of path validation as a function of these inputs.
I don't think there is anything in section 6 that states that all of these
inputs must be user configurable. If the text does suggest otherwise, then
it should be changed.
 
For example, one of the inputs is "the time, T, for which the validity of
the path should be determined." I think it would be perfectly valid for an
implementation not accept this input, but instead to always determine the
validity of the path at the current time. Similarly, an implementation could
choose to "hard-code in" the values for initial-policy-mapping-inhibit,
initial-explicit-policy, and initial-any-policy-inhibit. So, even if
son-of-2459 adds the adds initial name constraints as an input, there would
be no requirement for implementations to allow for inputs other than "all
permitted, none excluded". Changing section 6.1.1 would only provide a new
option, not impose a new requirement.

[Denis]

In your first reply, you said:" Including name constraints in a self-issued
certificate is pretty unusual (and not likely to be very effective). "

I fully agree with you. Name constraints, when used, should be defined
outside the self-signed certificate. 

Then you add: " In general, I suggest finding a trusted CA (or a small
number) and having them issue cross certificates (with name constraints and
any other fancy stuff). This avoids the problem of having many trust anchors
with various name constraints, which must be replaced manually if the
constraints change (due to marketing, mergers, etc.)."

I am a little bit puzzled with your suggestion. Usually a given application
trusts an anchor to isssue names for some organizations. But another
application may chooose to apply different rules. So this is not a pure
decision from the CA, otherwise the application would have to evaluate these
name constraints before accepting them. 

So I have difficulties to see how the original name contraints could be
handled by using the cross certificates you mention. Whatever, this seems to
be only a suggestion. :-)

Denis
 
> Dave

From: "Anders Rundgren" <[email-masked]>
To: "PKIX-List" <[email-masked]>
Subject: CMS SignerInfo algorithm OIDs
Date: Mon, 5 Mar 2001 17:58:34 +0100

Hi
I just wonder if there is any one out there who can tell which 
CMS SignerInfo algorithm OIDs are valid and how they are to be formatted.
Some seem to have an additional parameter NULL that un practical implementations
often is not defined.

Any links or refs would be appreciated

Regards
Anders Rundgren

Date: Mon, 05 Mar 2001 11:06:02 -0500
To: [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints

--=====================_3814377==_.ALT
Content-Type: text/plain; charset="us-ascii"

Steve,

You are right that RFC 2459 seems to be somewhat careless in its use of the term CA. However, X.509 seems to be more clear:

(1) Certification Authority is defined as "An authority trusted by one or more users to create and assign public-key certificates."

(2) For the basicConstraints extension, it states: "The cA component indicates if the certified public key may be used to verify certificate signatures."

(3) For the cRLDistributionPoints extension, it states: "The cRLIssuer component identifies the authority that issues and signs the CRL."

So X.509, when defining CAs, doesn't seem to say anything about CRLs and also uses the term authority instead of certification authority to describe the entity that signs a CRL.

At 06:29 PM 3/2/01 -0500, Stephen Kent wrote:
>>X.509 states "[t]he cA component indicates if the certified public key may be used to verify certificate signatures". It says nothing about CRLs. Similarly, as you note, RFC 2459 ties keyCertSign to CA certificates but does do so with cRLSign. Are you arguing that we should change the standards to require basicConstraints with cA=TRUE in certificates that only authorize the use of the subject's public key to verify signatures on CRLs? Or are you suggesting that a certificate should be treated as a CA certificate if cRLSign is set in keyUsage even if basicConstraints is absent?
>
>I have always expected to see the CA flag set to true on a cert used to sign CRLs, but, as I noted in my message, a closer look at 2459 fails to require that. Still, throughout most of the document we see references to CAs, not to EEs, with regard to CRL signing. If there was an intent to allow non-CAs to sign CRLs, we certainly did not make it clear.
>
>Until we had the KeyUsage extension and the the certSign bit in v3 certs, there was no doubt that only a CA could sign a CRL. It was not clear to me that X.509, or 2459, made a point of advertising that a feature of this extension, and of indirect CRLs, was to promote the signing of CRLs by other than a CA. Rereading the 259 text, I still have to say that is not a message that comes through.
>
>>To be more specific, if we accept the idea that pathLenConstraint should be computed differently depending on what type of certificate the last one in the path is, should CA1's relying parties accept CRLs issued by CA3 in the certification path below?
>>
>>CA1 ----------------------------> CA2 ----------------------------------> CA3
>>         basicConstraints:                               keyUsage:
>>                 cA=TRUE                                 cRLSign
>>                 pathLenConstraint=0
>>
>>                 keyUsage:                               CRLDistributionPoints:
>>                         keyCertSign, cRLSign            cRLIssuer: CA3
>
>I would say no, if I understand your diagram. First, the cert from CA2 to CA3 does not say that CA3 is a CA! Also, if the distribution point extension is in the cert issued by CA2 to CA3, it is a statement about where to find the CA3 cert if it is ever revoked. If the distribution point were in certs issued by CA2 to EEs, then it would be saying that CA3 would be the issuer of these CRLs. But, look at the text below, from 2459

Yes, I should have CA issuing two certificates: one to an EE with the CRLDistributionPoints extension and the other issued to CA3 with the keyUsage extension.

>5.2.5  Issuing Distribution Point
>    The issuing distribution point is a critical CRL extension  identifies the CRL distribution point for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA  certificates only, or a limitied set of reason codes.  Although the extension is critical, conforming implementations are not required to support this extension.
>
>    The CRL is signed using the CA's private key.  CRL Distribution Points do not have their own key pairs.  If the CRL is stored in the X.500 Directory, it is stored in the Directory entry corresponding to the CRL distribution point, which may be different than the Directory entry of the CA.
>
>This explicitly refers to the CRL being signed with a CA private key, not an EE private key.

The quote from 2459 above seems to have been copied from the following statement from X.509. Notice that in X.509, however, it uses the term "CRL issuer" instead of CA.

                 The CRL is signed by the CRL issuer’s key  CRL distribution points do not have
                 their own key pairs. However, for a CRL distributed via the Directory, the CRL
                 is stored in the entry of the CRL distribution point, which may not be the directory
                 entry of the CRL issuer.

So, I would argue that any suggestion in 2459 that only CAs can sign CRLs was as a result of the authors not being sufficiently cautious in their use of terms. I see no reason to reject a CRL simply because the certificate issued to CRL's issuer does not contain basicConstraints with cA=TRUE.

Dave

--=====================_3814377==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Steve,<br>
<br>
You are right that RFC 2459 seems to be somewhat careless in its use of
the term CA. However, X.509 seems to be more clear:<br>
<br>
(1) Certification Authority is defined as &quot;An authority trusted by
one or more users to create and assign public-key
certificates.&quot;<br>
<br>
(2) For the basicConstraints extension, it states: &quot;The
<font size=2>cA</font> component indicates if the certified public key
may be used to verify certificate signatures.&quot;<br>
<br>
(3) For the cRLDistributionPoints extension, it states: &quot;The
<font size=2>cRLIssuer</font> component identifies the authority that
issues and signs the CRL.&quot;<br>
<br>
So X.509, when defining CAs, doesn't seem to say anything about CRLs and
also uses the term authority instead of certification authority to
describe the entity that signs a CRL.<br>
<br>
At 06:29 PM 3/2/01 -0500, Stephen Kent wrote:<br>
<blockquote type=cite cite><blockquote type=cite cite>X.509 states
&quot;[t]he<font size=2> cA</font> component indicates if the certified
public key may be used to verify certificate signatures&quot;. It says
nothing about CRLs. Similarly, as you note, RFC 2459 ties keyCertSign to
CA certificates but does do so with cRLSign. Are you arguing that we
should change the standards to require basicConstraints with cA=TRUE in
certificates that only authorize the use of the subject's public key to
verify signatures on CRLs? Or are you suggesting that a certificate
should be treated as a CA certificate if cRLSign is set in keyUsage even
if basicConstraints is absent?</blockquote><br>
I have always expected to see the CA flag set to true on a cert used to
sign CRLs, but, as I noted in my message, a closer look at 2459 fails to
require that. Still, throughout most of the document we see references to
CAs, not to EEs, with regard to CRL signing. If there was an intent to
allow non-CAs to sign CRLs, we certainly did not make it clear.<br>
<br>
Until we had the KeyUsage extension and the the certSign bit in v3 certs,
there was no doubt that only a CA could sign a CRL. It was not clear to
me that X.509, or 2459, made a point of advertising that a feature of
this extension, and of indirect CRLs, was to promote the signing of CRLs
by other than a CA. Rereading the 259 text, I still have to say that is
not a message that comes through.<br>
<br>
<blockquote type=cite cite>To be more specific, if we accept the idea
that pathLenConstraint should be computed differently depending on what
type of certificate the last one in the path is, should CA1's relying
parties accept CRLs issued by CA3 in the certification path below?<br>
<br>
<tt>CA1 ----------------------------&gt; CA2
----------------------------------&gt; CA3<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>basicConstraints:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cA=TRUE<x-tab>&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLSign<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>pathLenConstraint=0<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CRLDistributionPoints:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign,
cRLSign<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLIssuer:
CA3</tt></blockquote><br>
I would say no, if I understand your diagram. First, the cert from CA2 to
CA3 does not say that CA3 is a CA! Also, if the distribution point
extension is in the cert issued by CA2 to CA3, it is a statement about
where to find the CA3 cert if it is ever revoked. If the distribution
point were in certs issued by CA2 to EEs, then it would be saying that
CA3 would be the issuer of these CRLs. But, look at the text below, from
2459</tt></blockquote><br>
Yes, I should have CA issuing two certificates: one to an EE with the
<tt>CRLDistributionPoints extension and the other issued to CA3 with the
keyUsage extension.<br>
<br>
<br>
</tt><font face="Courier, Courier"><blockquote type=cite cite>5.2.5&nbsp;
Issuing Distribution Point</font><br>
&nbsp;&nbsp; The issuing distribution point is a critical CRL
extension&nbsp; identifies the CRL distribution point for a particular
CRL, and it indicates whether the CRL covers revocation for end entity
certificates only, CA&nbsp; certificates only, or a limitied set of
reason codes.&nbsp; Although the extension is critical, conforming
implementations are not required to support this extension.<br>
<br>
&nbsp;&nbsp; The CRL is signed using the CA's private key.&nbsp; CRL
Distribution Points do not have their own key pairs.&nbsp; If the CRL is
stored in the X.500 Directory, it is stored in the Directory entry
corresponding to the CRL distribution point, which may be different than
the Directory entry of the CA.<br>
<br>
This explicitly refers to the CRL being signed with a CA private key, not
an EE private key.</blockquote><br>
The quote from 2459 above seems to have been copied from the following
statement from X.509. Notice that in X.509, however, it uses the term
&quot;CRL issuer&quot; instead of CA.<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The
CRL is signed by the CRL issuer’s key&nbsp; CRL distribution points do
not have<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>their
own key pairs. However, for a CRL distributed via the Directory, the
CRL<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>is
stored in the entry of the CRL distribution point, which may not be the
directory<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>entry
of the CRL issuer.<br>
<br>
So, I would argue that any suggestion in 2459 that only CAs can sign CRLs
was as a result of the authors not being sufficiently cautious in their
use of terms. I see no reason to reject a CRL simply because the
certificate issued to CRL's issuer does not contain basicConstraints with
cA=TRUE.<br>
<br>
Dave<br>
</html>

--=====================_3814377==_.ALT--

Date: Sun, 4 Mar 2001 14:33:17 -0500
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)

At 2:31 PM -0500 3/2/01, Carlisle Adams wrote:
>If you (or anyone else reading this) would like to run the modules 
>through a syntax checker and give me a list of the necessary 
>changes, I'd be happy to incorporate them.  My sense, however, from 
>what you've listed below, is that the changes required will be 
>sufficiently minor that they can all be taken care of during the 
>last "48 HOURS NOTICE" editing cleanup window from the RFC Editor. 
>Therefore, I see no reason to hold up progression of either of these 
>documents.

Any change to any code in a document must be made before the document 
is sent to the RFC Editor. If any code is discovered to need changing 
after that time, the RFC Editor should kick it back to the IESG, who 
should ask the authors to fix it.

It is Very Bad to change anything other than minor editorial 
statements during the author review, or to even believe that all the 
authors will be around for the review.

Carlisle: I take it from your comments that you don't think that any 
of Phil's suggestions need to be implemented because no one tripped 
over them. Is that correct? If so, it's fine that we don't make the 
changes, but that is *quite* different than changing them after 
everyone has used the current code for testing.

Phil: do you have evidence that any ASN.1 compiler other than the one 
you listed has problems with the code as it stands now?

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Sex-Dialer Net" <[email-masked]>
Subject: ATTN ALL WEBMASTERS We're Now Paying Out $0.60 per Min, Cum Make $$$$ TODAY!!!
Date: Sun, 4 Mar 2001 05:19:24 -0800

We offer 4 Different Dialer Rates, We have THREE of the highest rates within the industry,
 
$0.60 for UK/USA/AUS mins!!!!
 
Check out our rates and compare them with ANY Dialer Program on the Net! We pay every 2 weeks !

Forgive me for contacting you without your permission.
I have just launched a new Dialer Program which has 3 of the highest $$$ per min, with the largest collection of marketing tools in the industry. Plus we offer 4 different dialers per webmaster. Plus we offer full support via email/ICQ.
If your interested check it out
www.sex-dialer.net
 
If you're not, I'm sorry to have bothered you, but thanks for taking the time to read this.
 
Happy Money-Making
 
Kind Regards
Sex-Dialer.Net

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Integration of OCPv2 , DPV & DPD
Date: Fri, 2 Mar 2001 18:07:09 -0800
Importance: Normal

Peter,

Standard gripe well noted but since we're at least (in my view) another IETF
or so away from this one going to last call there's ample opportunity to
correct it's more egregious abuses of ASN.1.  Thanks for the note.

Mike

> Sent: Saturday, March 03, 2001 2:01 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Integration of OCPv2 , DPV & DPD
>
>
> "Michael Myers" <[email-masked]> writes:
>
> >I've submitted a new OCSPv2 draft (-02) based on the WG's efforts in San
> >Diego.
>
> Shall we take my standard gripe about unnecessary tagging of
> elements as read?
> (2 in DPVOptions, 1 in PathParameters, 3 in DPDOptions, ie 50-75% of all
> context-specific tags used aren't actually needed).
>
> Peter.
>
>

Date: Fri, 02 Mar 2001 18:15:52 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: UIDs popping up in new-part1

Steve,

Mea culpa, mea culpa.

I read the message too hastily, and confused subject unique IDs with subject key IDs.  I apologize, and can well understand why my description of a potential use didn't make much sense.

Nonetheless, I agree with Ari Kermaier, that breaking backwards compatibility for purely esthetic reasons is a bad idea, unless we can be absolutely convinced that in fact no one uses them, and never will.

Sorry again of the confusion.

Bob

>>> Stephen Kent <[email-masked]> 03/02/01 10:45AM >>>
Bob,

>I strongly disagree that "nobody uses unique identifiers" or that
>"there's no good reason to retain support of them."  And I even
>more strongly reject the notion that just because it is alleged that no one
>uses them, applications SHOULD reject certificates which disprove
>the allegation!

RFC 2459 has deprecated the use of these fields for some time, so 
this is not a new matter. The current RFC states, in part,:

The subject and issuer unique identifiers are present in the 
certificate to handle the possibility of reuse of subject and/or
issuer names over time.  This profile recommends that names not be
reused for different entities and that Internet certificates not make 
use of unique identifiers.  CAs conforming to this profile SHOULD NOT 
generate certificates with unique identifiers.

  Also, your intentionally obfuscated description of how you might 
want to use them is not consistent with the semantics of the fields, 
as noted above, which were designed to allow disambiguation of certs 
when DNs were reused, NOT to locate certs in the way you allude to. 
As you may recall, the motivation for these fields was a directory 
access control problem caused by bad schema design. We came out 
strongly in the RFC against this hack as a way of fixing the problem.

Steve

content-class: urn:content-classes:message
Subject: Why is Inhibit Any Policy a mandatory extension to support for the client?
Date: Fri, 2 Mar 2001 17:03:26 -0800
From: "Trevor Freeman" <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0A37D.C095A20D
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Certificate policies is a mandatory to support extension for the client,
but policy mapping is optional, therefore the minimal conformant client
with son of 2459 can only support CA hierarchies with homogeneous
certificate issuance policies and practices. This client does not
support policy mapping therefore can only operate in a controlled
issuance policy environment. We are expecting the need to use the
inhibit any policy extension in such an environment?=20
This does not seem consistent.=20
If the CAs are operating to a homogeneous set of issuance policies, you
can legislate in said policies,  whether a CA can have the all policy
OID or not rather than require the client to support such an extension.=20
Why do we need to mandate support for this extension, in our profile for
such an environment?

Trevor Freeman
Program Manager
Phone: (425) 936-8477
Pager: 800-759-8352, id#1631457=20
Pager email: [email-masked]

------_=_NextPart_001_01C0A37D.C095A20D
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4658.0">
<TITLE>Why is Inhibit Any Policy a mandatory extension to support for =
the client?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Certificate policies is a mandatory to =
support extension for the client, but policy mapping is optional, =
therefore the minimal conformant client with son of 2459 can only =
support CA hierarchies with homogeneous certificate issuance policies =
and practices. This client does not support policy mapping therefore can =
only operate in a controlled issuance policy environment. We are =
expecting the need to use the inhibit any policy extension in such an =
environment? </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This does not seem consistent. </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">If the CAs are operating to a =
homogeneous set of issuance policies, you can legislate in said =
policies,&nbsp; whether a CA can have the all policy OID or not rather =
than require the client to support such an extension. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Why do we need to mandate support for =
this extension, in our profile for such an environment?</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Trevor Freeman</FONT></B>

<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Program Manager</FONT></B>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Phone: (425) 936-8477</FONT>

<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Pager: 800-759-8352, =
id#1631457 </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Pager email:<U> =
[email-masked]</U></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A37D.C095A20D--

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re:  Integration of OCPv2 , DPV & DPD
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sat, 3 Mar 2001 14:01:12 (NZDT)

"Michael Myers" <[email-masked]> writes:

>I've submitted a new OCSPv2 draft (-02) based on the WG's efforts in San
>Diego.

Shall we take my standard gripe about unnecessary tagging of elements as read?
(2 in DPVOptions, 1 in PathParameters, 3 in DPDOptions, ie 50-75% of all
context-specific tags used aren't actually needed).

Peter.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: Integration of OCPv2 , DPV & DPD
Date: Fri, 2 Mar 2001 16:43:20 -0800
Importance: Normal

All,

I've submitted a new OCSPv2 draft (-02) based on the WG's efforts in San
Diego.  This version incorporates the technical content of the OCSP-based
DPD and DPV I-Ds; those I-Ds will be allowed to expire in favor of this
unified specification.  Many thanks to all for your support in refining
those concepts.  A draft document defining the OCSP state machine was also
submitted.  If you wish to receive a copy of either prior to their eventual
appearance on the official IETF web site, please contact me offlist at
[email-masked].

Otherwise, here's a precis:

Pulled in core of the OCSP-based DPV and DPD I-Ds and moved around some
elements of the -01 text to more accurately reflect the
framework+service_type approach the prior three I-Ds and RFC2560 had already
defined.  I made what I hope are useful editorial (i.e. non-normative)
corrections along the way.  I also worked in the minor editorial corrections
we've made to RFC 2560 as it progresses along the standards track.

Accordingly, the Protocol Overview section is totally rewritten.  The only
potential surprise in this section is the abstract definition of Online
Revocation Status (ORS) service as a peer service to DPV and DPD.  ORS
service is simply what's currently in RFC 2560.  So basically we have ORS,
DPV and DPD as standardized OCSP services and a handful of potentially
useful but ancillary extensions (e.g. Archive Cutoff).

The technical definition of the DPV and DPD services were substantially
augmented to conform to the Dec 29 draft requirements definition as well as
the input received from the ad-hoc OCSPv2 working sessions conducted in San
Diego.  I wasn't able to work in all perspectives (some were mutually
exclusive of others) but at present the following is proposed in response to
those inputs:

DPVOptions  :: = SEQUENCE{
    pathParams              PathParameters             OPTIONAL,
    validAt           [2]   GeneralizedTime            OPTIONAL,
    revInfo           [3]   SEQUENCE OF RevocationInfo OPTIONAL,
    dPVFLags          [4]   DPVFlags                   OPTIONAL }

PathParameters ::= SEQUENCE {
    initialPolicySet  [0]   PolicyList                 OPTIONAL,
    trustPoints       [1]   SEQUENCE OF ReqCert        OPTIONAL }

DPVFlags ::= BIT STRING {
    returnpath        (0),
    returnrevinfo     (1),
    returntsp         (2),
    returnpolicy      (3) }

RevocationInfo ::= CHOICE {
    cRL               CertificateList,
    oCSP              OCSPResponse }

DPDOptions  :: = SEQUENCE{
    retryReference          OCTET STRING,
    initialPolicySet  [0]   EXPLICIT PolicyList OPTIONAL,
    trustPoints       [1]   SEQUENCE OF ReqCert OPTIONAL,
    validAt           [2]   GeneralizedTime     OPTIONAL,
    dDPFlags          [3]   DPDFlags            OPTIONAL}

DPDFlags ::=  BIT STRING {
    returnTSP          (0),
    returnpolicy       (1),
    crlonly            (2),
    ocsponly           (3),
    either             (4) }

SUBSTANTIAL context and additional technical content omitted for the sake of
brevity.  See the I-D for full details.  Specification subject to change.
Fasten seatbelts prior to takeoff.

Mike

Date: Fri, 2 Mar 2001 18:29:15 -0500
To: "David A. Cooper" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints
Cc: [email-masked]

--============_-1228546738==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

David,

>Steve,
>
>From a policy point of view, it may make sense to say that only CAs 
>should be issuing CRLs, but what does this mean from a certificate 
>path processing point of view?

I have to admit that I have not thought as much about the path 
processing aspect of the issue.

>
>X.509 states "[t]he cA component indicates if the certified public 
>key may be used to verify certificate signatures". It says nothing 
>about CRLs. Similarly, as you note, RFC 2459 ties keyCertSign to CA 
>certificates but does do so with cRLSign. Are you arguing that we 
>should change the standards to require basicConstraints with cA=TRUE 
>in certificates that only authorize the use of the subject's public 
>key to verify signatures on CRLs? Or are you suggesting that a 
>certificate should be treated as a CA certificate if cRLSign is set 
>in keyUsage even if basicConstraints is absent?

I have always expected to see the CA flag set to true on a cert used 
to sign CRLs, but, as I noted in my message, a closer look at 2459 
fails to require that. Still, throughout most of the document we see 
references to CAs, not to EEs, with regard to CRL signing. If there 
was an intent to allow non-CAs to sign CRLs, we certainly did not 
make it clear.

Until we had the KeyUsage extension and the the certSign bit in v3 
certs, there was no doubt that only a CA could sign a CRL. It was not 
clear to me that X.509, or 2459, made a point of advertising that a 
feature of this extension, and of indirect CRLs, was to promote the 
signing of CRLs by other than a CA. Rereading the 259 text, I still 
have to say that is not a message that comes through.

>To be more specific, if we accept the idea that pathLenConstraint 
>should be computed differently depending on what type of certificate 
>the last one in the path is, should CA1's relying parties accept 
>CRLs issued by CA3 in the certification path below?
>
>CA1 ----------------------------> CA2 ----------------------------------> CA3
>	basicConstraints:				keyUsage:
>		cA=TRUE					cRLSign
>		pathLenConstraint=0
>
>		keyUsage:				CRLDistributionPoints:
>			keyCertSign, cRLSign		cRLIssuer: CA3
>

I would say no, if I understand your diagram. First, the cert from 
CA2 to CA3 does not say that CA3 is a CA! Also, if the distribution 
point extension is in the cert issued by CA2 to CA3, it is a 
statement about where to find the CA3 cert if it is ever revoked. If 
the distribution point were in certs issued by CA2 to EEs, then it 
would be saying that CA3 would be the issuer of these CRLs. But, look 
at the text below, from 2459

5.2.5  Issuing Distribution Point

    The issuing distribution point is a critical CRL extension 
identifies the CRL distribution point for a particular CRL, and it 
indicates whether the CRL covers revocation for end entity
certificates only, CA  certificates only, or a limitied set of reason 
codes.  Although the extension is critical, conforming 
implementations are not required to support this extension.

    The CRL is signed using the CA's private key.  CRL Distribution
    Points do not have their own key pairs.  If the CRL is stored in 
the X.500 Directory, it is stored in the Directory entry 
corresponding to the CRL distribution point, which may be different 
than the Directory entry of the CA.

This explicitly refers to the CRL being signed with a CA private key, 
not an EE private key.

Steve
--============_-1228546738==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: Open Issue in Part1: path length
constraints</title></head><body>
<div>David,</div>
<div><br></div>
<blockquote type="cite" cite>Steve,<br>
</blockquote>
<blockquote type="cite" cite>From a policy point of view, it may make
sense to say that only CAs should be issuing CRLs, but what does this
mean from a certificate path processing point of view?</blockquote>
<div><br></div>
<div>I have to admit that I have not thought as much about the path
processing aspect of the issue.</div>
<div><br></div>
<blockquote type="cite" cite><br>
X.509 states &quot;[t]he<font size="-1"> cA</font> component indicates
if the certified public key may be used to verify certificate
signatures&quot;. It says nothing about CRLs. Similarly, as you note,
RFC 2459 ties keyCertSign to CA certificates but does do so with
cRLSign. Are you arguing that we should change the standards to
require basicConstraints with cA=TRUE in certificates that only
authorize the use of the subject's public key to verify signatures on
CRLs? Or are you suggesting that a certificate should be treated as a
CA certificate if cRLSign is set in keyUsage even if basicConstraints
is absent?</blockquote>
<div><br></div>
<div>I have always expected to see the CA flag set to true on a cert
used to sign CRLs, but, as I noted in my message, a closer look at
2459 fails to require that. Still, throughout most of the document we
see references to CAs, not to EEs, with regard to CRL signing. If
there was an intent to allow non-CAs to sign CRLs, we certainly did
not make it clear.</div>
<div><br></div>
<div>Until we had the KeyUsage extension and the the certSign bit in
v3 certs, there was no doubt that only a CA could sign a CRL. It was
not clear to me that X.509, or 2459, made a point of advertising that
a feature of this extension, and of indirect CRLs, was to promote the
signing of CRLs by other than a CA. Rereading the 259 text, I still
have to say that is not a message that comes through.</div>
<div><br></div>
<blockquote type="cite" cite>To be more specific, if we accept the
idea that pathLenConstraint should be computed differently depending
on what type of certificate the last one in the path is, should CA1's
relying parties accept CRLs issued by CA3 in the certification path
below?<br>
<br>
<tt>CA1 ----------------------------&gt; CA2
----------------------------------&gt; CA3<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>basicConstraints:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>keyUsage:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>cA=TRUE<x-tab>
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>cRLSign<br>
<x-tab> </x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>pathLenConstraint=0<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>keyUsage:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>CRLDistributionPoints:</tt></blockquote>
<blockquote type="cite"
cite><tt><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>keyCertSign, cRLSign<x-tab>&nbsp;&nbsp;&nbsp;
</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab>cRLIssuer: CA3</tt><br>
<tt></tt></blockquote>
<div><tt><br></tt></div>
<div><tt>I would say no, if I understand your diagram. First, the cert
from CA2 to CA3 does not say that CA3 is a CA! Also, if the
distribution point extension is in the cert issued by CA2 to CA3, it
is a statement about where to find the CA3 cert if it is ever revoked.
If the distribution point were in certs issued by CA2 to EEs, then it
would be saying that CA3 would be the issuer of these CRLs. But, look
at the text below, from 2459</tt></div>
<div><tt><br></tt></div>
<div><font face="Courier" size="+2" color="#000000">5.2.5&nbsp;
Issuing Distribution Point</font><br>
<font face="Courier" size="+2" color="#000000"></font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp; The
issuing distribution point is a critical CRL extension&nbsp;
identifies the CRL distribution point for a particular CRL, and it
indicates whether the CRL covers revocation for end
entity</font></div>
<div><font face="Courier" size="+2" color="#000000">certificates only,
CA&nbsp; certificates only, or a limitied set of reason codes.&nbsp;
Although the extension is critical, conforming implementations are not
required to support this extension.</font></div>
<div><font face="Courier" size="+2" color="#000000"><br>
&nbsp;&nbsp; The CRL is signed using the CA's private key.&nbsp; CRL
Distribution</font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp;
Points do not have their own key pairs.&nbsp; If the CRL is stored in
the X.500 Directory, it is stored in the Directory entry corresponding
to the CRL distribution point, which may be different than the
Directory entry of the CA.</font></div>
<div><tt><br></tt></div>
<div>This explicitly refers to the CRL being signed with a CA private
key, not an EE private key.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1228546738==_ma============--

Date: Fri, 02 Mar 2001 18:09:57 -0500
To: [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: Re: WG Last Call: Son-of-2459

At 05:34 PM 3/2/01 -0500, Steve Hanna wrote:
>I certainly don't mind if son-of-2459 says implementations MAY support
>name constraints on trust anchors. I just don't want to have it as a
>SHOULD or a MUST.

I would certainly agree with this. I like the idea of adding initial name constraints values as input to the path validation algorithm, since otherwise they would be the only state variables whose initial values can not be set by the relying party. However, this should in no way be a SHOULD or a MUST.

Section 6.1.1 specifies several inputs to the path validation algorithm and then describes the results of path validation as a function of these inputs. I don't think there is anything in section 6 that states that all of these inputs must be user configurable. If the text does suggest otherwise, then it should be changed.

For example, one of the inputs is "the time, T, for which the validity of the path should be determined." I think it would be perfectly valid for an implementation not accept this input, but instead to always determine the validity of the path at the current time. Similarly, an implementation could choose to "hard-code in" the values for initial-policy-mapping-inhibit, initial-explicit-policy, and initial-any-policy-inhibit. So, even if son-of-2459 adds the adds initial name constraints as an input, there would be no requirement for implementations to allow for inputs other than "all permitted, none excluded". Changing section 6.1.1 would only provide a new option, not impose a new requirement.

Dave

Date: Fri, 2 Mar 2001 18:04:15 -0500
To: Steve Hanna <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: WG Last Call: Son-of-2459
Cc: [email-masked]

Steve,

>Steve,
>
>I certainly agree with you that name constraints (along with policy
>constraints) are critically important in PKIs that make extensive use of
>cross certification. The U.S. Government's Federal Bridge CA (currently
>in a pilot stage) includes name constraints in cross certificates that
>it issues and I expect that CAs will do this more frequently as cross
>certification increases.
>
>However, I don't agree that it's important to let end-users associate
>name constraints with trust anchors. Few end-users even understand what
>a trust anchor is. The number of end-users that could properly assign
>name constraints to each trust anchor is much smaller, still. When I
>talk with browser vendors, they say that PKI must become simpler, not
>harder!

Bwoeser vendors have a very poor track record re offering appropriate 
controls for user management of certs, and the complete lack of 
management knobs for trust anchors is appalling. I understand the 
motivation here, I think that's one reason why we see such interest 
in DPV, but, as I note in the last paragraph, providing a control 
that's not invoked by most users need not make their lives more 
complex.  As a Mac user, I see a fair number of software modules that 
have novice user controls, but with (slightly hidden) advanced user 
controls as well.

>A better and more practical way to achieve the same end is for the
>end-user to have a single trust anchor (the corporate or departmental
>CA) and have that CA issue cross-certificates with name constraints.
>This allows the administrator to manage all the name constraints (as
>well as policy mappings and other policy constraints, which may be
>necessary in a cross-certification environment).

I like that approach too, and said as much a while ago, but was 
talked out of it.

>If the user is really paranoid, they can set up their own CA and use
>that as their trust anchor. Anyone sophisticated enough to configure
>name constraints is sophisticated enough to run their own CA. And there
>are plenty of free CA software packages out there that are perfectly
>adequate for issuing a few cross-certificates with name constraints.

It's a big step to go from managing name constraints for a few trust 
anchors to becoming one's own CA in order to manage these validation 
parameters, but I agree that in some cases one might do this.

>I certainly don't mind if son-of-2459 says implementations MAY support
>name constraints on trust anchors. I just don't want to have it as a
>SHOULD or a MUST.

If one mandates such support in products, but users choose not to 
make use of it, then their lives are unaffected. It's the vendors who 
have to do more work, but is that extra work significant relative to 
the rest of the cert processing implementation? I'm not convinced 
that it is.

Steve

Date: Fri, 02 Mar 2001 17:57:06 -0500
To: [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints

--=====================_33758381==_.ALT
Content-Type: text/plain; charset="us-ascii"

Steve,

 From a policy point of view, it may make sense to say that only CAs should be issuing CRLs, but what does this mean from a certificate path processing point of view?

X.509 states "[t]he cA component indicates if the certified public key may be used to verify certificate signatures". It says nothing about CRLs. Similarly, as you note, RFC 2459 ties keyCertSign to CA certificates but does do so with cRLSign. Are you arguing that we should change the standards to require basicConstraints with cA=TRUE in certificates that only authorize the use of the subject's public key to verify signatures on CRLs? Or are you suggesting that a certificate should be treated as a CA certificate if cRLSign is set in keyUsage even if basicConstraints is absent?

To be more specific, if we accept the idea that pathLenConstraint should be computed differently depending on what type of certificate the last one in the path is, should CA1's relying parties accept CRLs issued by CA3 in the certification path below?

CA1 ----------------------------> CA2 ----------------------------------> CA3
         basicConstraints:                               keyUsage:
                 cA=TRUE                                 cRLSign
                 pathLenConstraint=0 

                 keyUsage:                               CRLDistributionPoints:
                         keyCertSign, cRLSign            cRLIssuer: CA3

At 04:48 PM 3/2/01 -0500, Stephen Kent wrote:
>I am too bothered by the emergence of the notion that entities other than  CAs issues CRLs. I reread 2459 and it does not seem to make a case for this, although I did note that the CRLSign bit in key usage did not limit its use to CAs, even though the KeyCertSign bit is so restricted. But 5.2.5 (the CRL distribution point extension) does say: "The CRL is signed using the CA's private key" and that certainly argues for what I would consider the usual interpretation, i.e., only CAs sign CRLs.

--=====================_33758381==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Steve,<br>
<br>
 From a policy point of view, it may make sense to say that only CAs
should be issuing CRLs, but what does this mean from a certificate path
processing point of view?<br>
<br>
X.509 states &quot;[t]he <font size=2>cA</font> component indicates if
the certified public key may be used to verify certificate
signatures&quot;. It says nothing about CRLs. Similarly, as you note, RFC
2459 ties keyCertSign to CA certificates but does do so with cRLSign. Are
you arguing that we should change the standards to require
basicConstraints with cA=TRUE in certificates that only authorize the use
of the subject's public key to verify signatures on CRLs? Or are you
suggesting that a certificate should be treated as a CA certificate if
cRLSign is set in keyUsage even if basicConstraints is absent?<br>
<br>
To be more specific, if we accept the idea that pathLenConstraint should
be computed differently depending on what type of certificate the last
one in the path is, should CA1's relying parties accept CRLs issued by
CA3 in the certification path below?<br>
<br>
<tt>CA1 ----------------------------&gt; CA2
----------------------------------&gt; CA3<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>basicConstraints:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cA=TRUE<x-tab>&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLSign<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>pathLenConstraint=0
<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CRLDistributionPoints:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign,
cRLSign<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLIssuer:
CA3<br>
<br>
<br>
<br>
</tt>At 04:48 PM 3/2/01 -0500, Stephen Kent wrote:<br>
<blockquote type=cite cite>I am too bothered by the emergence of the
notion that entities other than&nbsp; CAs issues CRLs. I reread 2459 and
it does not seem to make a case for this, although I did note that the
CRLSign bit in key usage did not limit its use to CAs, even though the
KeyCertSign bit is so restricted. But 5.2.5 (the CRL distribution point
extension) does say: &quot;<font face="Courier, Courier" size=5>The CRL
is signed using the CA's private key&quot;</font> and that certainly
argues for what I would consider the usual interpretation, i.e., only CAs
sign CRLs.</blockquote><br>
</html>

--=====================_33758381==_.ALT--

Date: Fri, 2 Mar 2001 17:50:43 -0500
To: Ambarish Malpani <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
Cc: [email-masked]

--============_-1228548864==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ambarish,

>Hi Steve,
>     Is there anything that restricts indirect CRL issuance only
>to CAs? I think the concept of an entity other than the CA
>issuing CRLs is reasonably old.
>

Well, 5.3.4 (the indirect CRL section) of 2459 says:

    This CRL entry extension identifies the certificate issuer 
associated with an entry in an indirect CRL, i.e. a CRL that has the 
indirectCRL indicator set in its issuing distribution point 
extension. If this extension is not present on the first entry in an 
indirect CRL, the certificate issuer defaults to the CRL issuer. On 
subsequent entries in an indirect CRL, if this extension is not 
present, the certificate issuer for the entry is the same as that for 
the preceding entry.
    This field is defined as follows:

    id-ce-certificateIssuer   OBJECT IDENTIFIER ::= { id-ce 29 }

    certificateIssuer ::=     GeneralNames

    If used by conforming CAs that issue CRLs, this extension is 
always critical.  If an implementation ignored this extension it 
could not correctly attribute CRL entries to certificates.  This 
specification RECOMMENDS that implementations recognize this 
extension.

The text avoids referring to a CA as the indirect CRL issuer at 
first, but then refers to conforming CAs in the last paragraph. If 
something other than a CA issues an indirect CRL, or any kind of CRL, 
then the wording used throughout 2459 seems to not apply to such an 
entity, because we almost always seem to come back to phrases like 
"if used by a fonforming CA ..." The best rationale I've usually 
heard for indirect CRLs has been for one CA to issue a CRL for 
another, e.g., if the latter CA looses the ability to issue CRLs to 
to destruction of its private key.

Steve
--============_-1228548864==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>RE: Open Issue in Part1: path length
constraints</title></head><body>
<div>Ambarish,</div>
<div><br></div>
<blockquote type="cite" cite>Hi Steve,<br>
&nbsp;&nbsp;&nbsp; Is there anything that restricts indirect CRL
issuance only<br>
to CAs? I think the concept of an entity other than the
CA</blockquote>
<blockquote type="cite" cite>issuing CRLs is reasonably old.<br>
</blockquote>
<div><br></div>
<div>Well, 5.3.4 (the indirect CRL section) of 2459 says:</div>
<div><br></div>
<div><font face="Times New Roman" size="+1"
color="#000000"><br></font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp; This
CRL entry extension identifies the certificate issuer associated with
an entry in an indirect CRL, i.e. a CRL that has the indirectCRL
indicator set in its issuing distribution point extension. If this
extension is not present on the first entry in an indirect CRL, the
certificate issuer defaults to the CRL issuer. On subsequent entries
in an indirect CRL, if this extension is not present, the certificate
issuer for the entry is the same as that for the preceding
entry.</font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp; This
field is defined as follows:<br>
<br>
&nbsp;&nbsp; id-ce-certificateIssuer&nbsp;&nbsp; OBJECT IDENTIFIER ::=
{ id-ce 29 }<br>
<br>
&nbsp;&nbsp; certificateIssuer ::=&nbsp;&nbsp;&nbsp;&nbsp;
GeneralNames</font><br>
<font face="Courier" size="+2" color="#000000"></font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp; If
used by conforming CAs that issue CRLs, this extension is always
critical.&nbsp; If an implementation ignored this extension it could
not correctly attribute CRL entries to certificates.&nbsp; This
specification RECOMMENDS that implementations recognize this
extension.</font></div>
<div><font face="Courier" size="+2" color="#000000"><br></font></div>
<div>The text avoids referring to a CA as the indirect CRL issuer at
first, but then refers to conforming CAs in the last paragraph. If
something other than a CA issues an indirect CRL, or any kind of CRL,
then the wording used throughout 2459 seems to not apply to such an
entity, because we almost always seem to come back to phrases like
&quot;if used by a fonforming CA ...&quot; The best rationale I've
usually heard for indirect CRLs has been for one CA to issue a CRL for
another, e.g., if the latter CA looses the ability to issue CRLs to to
destruction of its private key.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1228548864==_ma============--

Date: Fri, 02 Mar 2001 17:34:54 -0500
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: Son-of-2459

Steve,

I certainly agree with you that name constraints (along with policy
constraints) are critically important in PKIs that make extensive use of
cross certification. The U.S. Government's Federal Bridge CA (currently
in a pilot stage) includes name constraints in cross certificates that
it issues and I expect that CAs will do this more frequently as cross
certification increases.

However, I don't agree that it's important to let end-users associate
name constraints with trust anchors. Few end-users even understand what
a trust anchor is. The number of end-users that could properly assign
name constraints to each trust anchor is much smaller, still. When I
talk with browser vendors, they say that PKI must become simpler, not
harder!

A better and more practical way to achieve the same end is for the
end-user to have a single trust anchor (the corporate or departmental
CA) and have that CA issue cross-certificates with name constraints.
This allows the administrator to manage all the name constraints (as
well as policy mappings and other policy constraints, which may be
necessary in a cross-certification environment).

If the user is really paranoid, they can set up their own CA and use
that as their trust anchor. Anyone sophisticated enough to configure
name constraints is sophisticated enough to run their own CA. And there
are plenty of free CA software packages out there that are perfectly
adequate for issuing a few cross-certificates with name constraints.

I certainly don't mind if son-of-2459 says implementations MAY support
name constraints on trust anchors. I just don't want to have it as a
SHOULD or a MUST.

-Steve

Stephen Kent wrote:
> 
> Steve,
> 
> I agree with most of the comments you have made re revisions to 2459,
> but I do disagree with the discussion if name constraints and its use
> in the validation algorithm.  I think that name constraints are
> critically important in PKIs that make extensive use of cross
> certification. Yet, as you note, they are no commonly used so far. I
> think that making provision to associate name constraints with trust
> anchors is a good way to let users (or administrators) locally manage
> the concerns that this extension addresses, without having to
> persuade CAs to issue cross certs with such constraints.  In fact, I
> was persuaded to drop my proposal for local issuance of such cross
> certs because of the inclusion of this facility as a control measure
> on the validation process.
> 
> This will become more than a local implementation issue, as we
> continue with the DPV/DPD work.  My current draft of the message
> syntax for requests calls for inclusion of name constraints as a
> validation control parameter, a protocol feature motivated by the
> notion that name constraints would become a standard part of the
> validation algorithm.
> 
> Steve

Content-return: allowed
Date: Fri, 02 Mar 2001 14:25:17 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Open Issue in Part1: path length constraints
To: [email-masked]

Hi Steve,
    Is there anything that restricts indirect CRL issuance only
to CAs? I think the concept of an entity other than the CA
issuing CRLs is reasonably old.

Regards,
Ambarish

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, March 02, 2001 1:49 PM
To: David Simonetti
Cc: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

<STUFF DELETED>

I am too bothered by the emergence of the notion that entities other than
CAs issues CRLs. I reread 2459 and it does not seem to make a case for this,
although I did note that the CRLSign bit in key usage did not limit its use
to CAs, even though the KeyCertSign bit is so restricted. But 5.2.5 (the CRL
distribution point extension) does say: "The CRL is signed using the CA's
private key" and that certainly argues for what I would consider the usual
interpretation, i.e., only CAs sign CRLs.

OCSP clearly introduced the notion of a non CA entity vouching for
certificate status. But we're talking about CRLs here and I still think they
should be issued only by CAs. I view the CRLSign bit to be a means by which
a CA can have different keys and certs for cert signing vs. CRL signing, and
appropriate split  that can enhance security in many instances.

Steve

Date: Fri, 02 Mar 2001 17:29:48 -0500
To: [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints

--=====================_32120252==_.ALT
Content-Type: text/plain; charset="us-ascii"

At 03:44 PM 3/2/01 -0500, David Simonetti wrote:
>David,
>
>You write, "With the other semantics, the certificate issued to the CRL-issuer could include basicConstraints with cA=TRUE without causing any problems."
>
>I think, more specifically, the certificate issued to the CRL-issuer includes a basicConstraints ext with cA=True and pathLenContraint=0, and a keyUsage extension with cRLSign=1.

David,

Consider the following scenarios:

scenario 1:

CA1 ----------------------------> CA2 ----------------------------------> CA3
      basicConstraints:                          keyUsage:
                 cA=TRUE                                 cRLSign
                 pathLenConstraint=0                     
         keyUsage:                                       CRLDistributionPoints:
                 keyCertSign, cRLSign                    cRLIssuer: CA3

scenario 2:

CA1 ----------------------------> CA2 ----------------------------------> CA3
      basicConstraints:                          basicConstraints:
                 cA=TRUE                                 cA=TRUE
                 pathLenConstraint=0                     
         keyUsage:                                       keyUsage:
                 keyCertSign, cRLSign                    keyCertSign, cRLSign

                                                         CRLDistributionPoints:
                                                                 cRLIssuer: CA3

In both scenarios, CA1 wishes to allow its relying parties to validate certificates issued by CA2. Also, in both scenarios, CA2 does not issue its own CRLs, but instead relies CA3 to issue CRLs on its behalf. The only difference is that in scenario 1 the certificate issued by CA2 to CA3 only "authorizes" CA3 to sign CRLs, whereas in scenario 2 the certificate issued by CA 2 to CA3 "authorizes" CA3 to sign both certificates and CRLs (perhaps CA2 wishes to allow its own relying parties to accept certificates issued by CA3).

In scenario 1, since CA2 is not "authorizing" CA3 to sign certificates, it does not include the basicConstraints extension in the certificate it issues to CA3. In scenario 2, basicConstraints is included as required since the intention is to "authorize" CA3 to sign certificates.

No matter how pathLenConstraint is defined, CA1's relying parties will be able to validate CRLs issued by CA3 in scenario 1. With scenario 2, however, with one definition relying parties will be able to validate the CRLs, but with the other they will not due to the presence of basicConstraints in the certificate issued by CA2 to CA3.

Note that what you suggest ("the certificate issued to the CRL-issuer includes a basicConstraints ext with cA=True and pathLenContraint=0, and a keyUsage extension with cRLSign=1") would not work. Using the definition of pathLenConstraint that you support, such a certificate would be rejected as a "CA-certificate" since it contains basicConstraints with cA=TRUE. This is also contradictory to the PKIX profile:

                 The cA bit indicates if the certified public key may be used to
                 verify signatures on other certificates. If the cA bit is asserted,
                 then the keyCertSign bit in the key usage extension
                 MUST also be asserted. If the cA bit is not asserted, then the
                 keyCertSign bit in the key usage extension MUST NOT be asserted.

>With the new semantics, if the keyUsage extension is absent, is it then possible for the CRL-issuer, assuming it is a CA, to also sign certificates?

Two points:

1) As noted in the quote above, if one does not wish to allow a certificate subject's public key to be used to verify certificates, then one should not include basicConstraints with cA=TRUE. If it is included then the issuing CA intended to allow the subject to sign certificates. On the other hand, it we are dealing with a scenario such as scenario 2 above, then it would always be the case that CA1's relying parties would not accept certificates signed by CA3 (even if they accept CRLs signed by CA3). If CA1's relying parties tried to accept a certificate signed by CA3 then they would do so by attempting to validate a path of the form CA1--->CA2--->CA3--->EE and this path would fail as a result of the path length constraint.

2) As I stated in my previous message, nobody is proposing new semantics. We are merely trying to deal with the results of previously ambiguous text. The semantics that I have been advocating have already in implemented in products. For example, I used the NIST X.509 certification path test suite to test the path validation code in Outlook Express on a Windows 98SE machine, and for the path length tests, the results of validation were the same whether the last certificate in the path included basicConstraints with cA=TRUE or not. So it seems that Microsoft's path validation code currently implements the semantics that I have been advocating. In addition, if you look at DR 272, which is designed to clarify the meaning of path length constraints in X.509, the text seems to suggest that it has always been the ISO Directory group's intention that pathLenConstraint be interpreted in this way.

So, if we decide that pathLenConstraints should be calculated differently when the last certificate in the path includes basicConstraints with cA=TRUE, then we will be "breaking" real, deployed implementations. We would also need to work to see that DR 272 is changed so that X.509 is consistent. It may be the case that there are also deployed implementations that compute pathLenConstraints differently when the end certificate included basicConstraints with cA=TRUE that would be "broken" if we agree to go the other way. But even if this is the case, we should not reject the idea of computing pathLenConstraint the same way for all paths of equal length based on the argument that this would be defining "new semantics". If there had been agreement in past on what the "old semantics" were, then we wouldn't even be talking about path length constraints now.

Dave

--=====================_32120252==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 03:44 PM 3/2/01 -0500, David Simonetti wrote:<br>
<blockquote type=cite cite>David,<br>
<br>
You write, &quot;With the other semantics, the certificate issued to the
CRL-issuer could include basicConstraints with cA=TRUE without causing
any problems.&quot;<br>
<br>
I think, more specifically, the certificate issued to the CRL-issuer
includes a basicConstraints ext with cA=True and pathLenContraint=0, and
a keyUsage extension with cRLSign=1.</blockquote><br>
David,<br>
<br>
Consider the following scenarios:<br>
<br>
scenario 1:<br>
<br>
<tt>CA1 ----------------------------&gt; CA2
----------------------------------&gt; CA3<br>
&nbsp;&nbsp;&nbsp;&nbsp;
basicConstraints:<x-tab>&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cA=TRUE<x-tab>&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cRLSign<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>pathLenConstraint=0<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></tt><font face="Courier New, Courier">CRLDistributionPoints:<br>
</font><tt><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign,
cRLSign<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></tt><font face="Courier New, Courier">cRLIssuer:
CA3<br>
<br>
</font>scenario 2:<br>
<br>
<tt>CA1 ----------------------------&gt; CA2
----------------------------------&gt; CA3<br>
&nbsp;&nbsp;&nbsp;&nbsp;
basicConstraints:<x-tab>&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>basicConstraints:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cA=TRUE<x-tab>&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>cA=TRUE<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>pathLenConstraint=0<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyUsage:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign,
cRLSign<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign,
cRLSign<br>
<br>
</tt><font face="Courier New, Courier"><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>CRLDistributionPoints:<br>
</font><tt><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></tt><font face="Courier New, Courier">cRLIssuer:
CA3<br>
<br>
</font>In both scenarios, CA1 wishes to allow its relying parties to
validate certificates issued by CA2. Also, in both scenarios, CA2 does
not issue its own CRLs, but instead relies CA3 to issue CRLs on its
behalf. The only difference is that in scenario 1 the certificate issued
by CA2 to CA3 only &quot;authorizes&quot; CA3 to sign CRLs, whereas in
scenario 2 the certificate issued by CA 2 to CA3 &quot;authorizes&quot;
CA3 to sign both certificates and CRLs (perhaps CA2 wishes to allow its
own relying parties to accept certificates issued by CA3).<br>
<br>
In scenario 1, since CA2 is not &quot;authorizing&quot; CA3 to sign
certificates, it does not include the basicConstraints extension in the
certificate it issues to CA3. In scenario 2, basicConstraints is included
as required since the intention is to &quot;authorize&quot; CA3 to sign
certificates.<br>
<br>
No matter how pathLenConstraint is defined, CA1's relying parties will be
able to validate CRLs issued by CA3 in scenario 1. With scenario 2,
however, with one definition relying parties will be able to validate the
CRLs, but with the other they will not due to the presence of
basicConstraints in the certificate issued by CA2 to CA3.<br>
<br>
Note that what you suggest (&quot;the certificate issued to the
CRL-issuer includes a basicConstraints ext with cA=True and
pathLenContraint=0, and a keyUsage extension with cRLSign=1&quot;) would
not work. Using the definition of pathLenConstraint that you support,
such a certificate would be rejected as a &quot;CA-certificate&quot;
since it contains basicConstraints with cA=TRUE. This is also
contradictory to the PKIX profile:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>The
cA bit indicates if the certified public key may be used to<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>verify
signatures on other certificates. If the cA bit is asserted,<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>then
the keyCertSign bit in the key usage extension<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>MUST
also be asserted. If the cA bit is not asserted, then the<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>keyCertSign
bit in the key usage extension MUST NOT be asserted.<br>
<br>
<blockquote type=cite cite>With the new semantics, if the keyUsage
extension is absent, is it then possible for the CRL-issuer, assuming it
is a CA, to also sign certificates?</blockquote><br>
Two points:<br>
<br>
1) As noted in the quote above, if one does not wish to allow a
certificate subject's public key to be used to verify certificates, then
one should not include basicConstraints with cA=TRUE. If it is included
then the issuing CA intended to allow the subject to sign certificates.
On the other hand, it we are dealing with a scenario such as scenario 2
above, then it would always be the case that CA1's relying parties would
not accept certificates signed by CA3 (even if they accept CRLs signed by
CA3). If CA1's relying parties tried to accept a certificate signed by
CA3 then they would do so by attempting to validate a path of the form
CA1---&gt;CA2---&gt;CA3---&gt;EE and this path would fail as a result of
the path length constraint.<br>
<br>
2) As I stated in my previous message, nobody is proposing new semantics.
We are merely trying to deal with the results of previously ambiguous
text. The semantics that I have been advocating have already in
implemented in products. For example, I used the NIST X.509 certification
path test suite to test the path validation code in Outlook Express on a
Windows 98SE machine, and for the path length tests, the results of
validation were the same whether the last certificate in the path
included basicConstraints with cA=TRUE or not. So it seems that
Microsoft's path validation code currently implements the semantics that
I have been advocating. In addition, if you look at DR 272, which is
designed to clarify the meaning of path length constraints in X.509, the
text seems to suggest that it has always been the ISO Directory group's
intention that pathLenConstraint be interpreted in this way.<br>
<br>
<br>
So, if we decide that pathLenConstraints should be calculated differently
when the last certificate in the path includes basicConstraints with
cA=TRUE, then we will be &quot;breaking&quot; real, deployed
implementations. We would also need to work to see that DR 272 is changed
so that X.509 is consistent. It may be the case that there are also
deployed implementations that compute pathLenConstraints differently when
the end certificate included basicConstraints with cA=TRUE that would be
&quot;broken&quot; if we agree to go the other way. But even if this is
the case, we should not reject the idea of computing pathLenConstraint
the same way for all paths of equal length based on the argument that
this would be defining &quot;new semantics&quot;. If there had been
agreement in past on what the &quot;old semantics&quot; were, then we
wouldn't even be talking about path length constraints now.<br>
<br>
Dave<br>
<br>
<br>
<br>
</html>

--=====================_32120252==_.ALT--

Date: Fri, 2 Mar 2001 16:48:40 -0500
To: David Simonetti <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints
Cc: [email-masked]

--============_-1228552433==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

David,

>Let's make this a fair fight and make it three on three.  This David 
>agrees with
>Steve and John.
>
>In Tim's original message:
>
>"CA "A" issues a CA certificate to CA "B".  "A" trusts end entity
>certificates issued by "B", but does not trust "B" to issue certificates to
>other CAs.  "A" includes basic constraints in the certificate it issues to
>"B" with cA = TRUE and pathLen = 0."
>
>""B" does not issue its own CRLs, but delegates this to CA "C".  "B" also
>trusts "C" to issue end entity certificates. So, "B" includes basic
>constraints in the certificate it issues to "B" with cA = TRUE."
>
>Let me begin by stating that I really dislike this scenario. 
>Theoretically this
>is possible, but why would anyone architect such a design?  If I really had to
>address this scenario, a design that fits within the current 
>semantics would be
>one that creates a distinct "personality" for issuing the CRLs which could be
>issued an end entity certificate with the cRLSign bit set.
>
>Stay with the current semantics and stop trying to break things that really
>aren't broken.

I am too bothered by the emergence of the notion that entities other 
than  CAs issues CRLs. I reread 2459 and it does not seem to make a 
case for this, although I did note that the CRLSign bit in key usage 
did not limit its use to CAs, even though the KeyCertSign bit is so 
restricted. But 5.2.5 (the CRL distribution point extension) does 
say: "The CRL is signed using the CA's private key" and that 
certainly argues for what I would consider the usual interpretation, 
i.e., only CAs sign CRLs.

OCSP clearly introduced the notion of a non CA entity vouching for 
certificate status. But we're talking about CRLs here and I still 
think they should be issued only by CAs. I view the CRLSign bit to be 
a means by which a CA can have different keys and certs for cert 
signing vs. CRL signing, and appropriate split  that can enhance 
security in many instances.

Steve
--============_-1228552433==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: Open Issue in Part1: path length
constraints</title></head><body>
<div>David,</div>
<div><br></div>
<blockquote type="cite" cite>Let's make this a fair fight and make it
three on three.&nbsp; This David agrees with<br>
Steve and John.<br>
<br>
In Tim's original message:<br>
<br>
&quot;CA &quot;A&quot; issues a CA certificate to CA &quot;B&quot;.&nbsp;
&quot;A&quot; trusts end entity<br>
certificates issued by &quot;B&quot;, but does not trust &quot;B&quot;
to issue certificates to<br>
other CAs.&nbsp; &quot;A&quot; includes basic constraints in the
certificate it issues to<br>
&quot;B&quot; with cA = TRUE and pathLen = 0.&quot;<br>
<br>
&quot;&quot;B&quot; does not issue its own CRLs, but delegates this to
CA &quot;C&quot;.&nbsp; &quot;B&quot; also<br>
trusts &quot;C&quot; to issue end entity certificates. So, &quot;B&quot;
includes basic<br>
constraints in the certificate it issues to &quot;B&quot; with cA =
TRUE.&quot;<br>
<br>
Let me begin by stating that I really dislike this scenario.&nbsp;
Theoretically this<br>
is possible, but why would anyone architect such a design?&nbsp; If I
really had to<br>
address this scenario, a design that fits within the current semantics
would be<br>
one that creates a distinct &quot;personality&quot; for issuing the
CRLs which could be<br>
issued an end entity certificate with the cRLSign bit set.<br>
<br>
Stay with the current semantics and stop trying to break things that
really</blockquote>
<blockquote type="cite" cite>aren't broken.</blockquote>
<div><br></div>
<div>I am too bothered by the emergence of the notion that entities
other than&nbsp; CAs issues CRLs. I reread 2459 and it does not seem
to make a case for this, although I did note that the CRLSign bit in
key usage did not limit its use to CAs, even though the KeyCertSign
bit is so restricted. But 5.2.5 (the CRL distribution point extension)
does say: &quot;<font face="Courier" size="+2" color="#000000">The CRL
is signed using the CA's private key&quot;</font><font
color="#000000"> and that certainly argues for</font> what I would
consider the usual interpretation, i.e., only CAs sign CRLs.</div>
<div><br></div>
<div>OCSP clearly introduced the notion of a non CA entity vouching
for certificate status. But we're talking about CRLs here and I still
think they should be issued only by CAs. I view the CRLSign bit to be
a means by which a CA can have different keys and certs for cert
signing vs. CRL signing, and appropriate split&nbsp; that can enhance
security in many instances.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1228552433==_ma============--

Date: Fri, 2 Mar 2001 16:39:26 -0500
To: Steve Hanna <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: WG Last Call: Son-of-2459
Cc: [email-masked]

Steve,

I agree with most of the comments you have made re revisions to 2459, 
but I do disagree with the discussion if name constraints and its use 
in the validation algorithm.  I think that name constraints are 
critically important in PKIs that make extensive use of cross 
certification. Yet, as you note, they are no commonly used so far. I 
think that making provision to associate name constraints with trust 
anchors is a good way to let users (or administrators) locally manage 
the concerns that this extension addresses, without having to 
persuade CAs to issue cross certs with such constraints.  In fact, I 
was persuaded to drop my proposal for local issuance of such cross 
certs because of the inclusion of this facility as a control measure 
on the validation process.

This will become more than a local implementation issue, as we 
continue with the DPV/DPD work.  My current draft of the message 
syntax for requests calls for inclusion of name constraints as a 
validation control parameter, a protocol feature motivated by the 
notion that name constraints would become a standard part of the 
validation algorithm.

Steve

Date: Fri, 02 Mar 2001 15:44:46 -0500
From: David Simonetti <[email-masked]>
To: "David A. Cooper" <[email-masked]>
CC: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

David,

You write, "With the other semantics, the certificate issued to the CRL-issuer could include basicConstraints with cA=TRUE without causing any problems."

I think, more specifically, the certificate issued to the CRL-issuer includes a basicConstraints ext with cA=True and pathLenContraint=0, and a keyUsage extension with cRLSign=1.  With the new semantics, if the keyUsage extension is absent, is it then possible for the CRL-issuer, assuming it is a CA, to also sign certificates?

Dave S.

"David A. Cooper" wrote:

> At 02:27 PM 3/1/01 -0500, [email-masked] wrote:
> >But why would you care about a CA's signature on an OCSP response or a CRL
> >if you don't trust the signature on the EE certificate you're inquiring
> >about?
>
> It will not always be the case that an CRL or OCSP response will be signed by the same entity (e.g, CA) that signed the EE certificate of interest. It may be that a certificate is issued with a cRLDistributionPoints extension specifying that corresponding CRLs will be issued by a different entity. The issuer of the CRLs does not have to be a CA (i.e., the certificate issued to this entity is not required to contain the basicConstraints extension). So, it is possible that a relying party will accept CRLs issued by some entity even though it would not accept certificates issued by this entity.
>
> Based on the semantics that Steve Hanna, et. al. support, a CA that relied on indirect CRLs (or OCSP responses signed by some other entity) to distribute revocation information would need to issue the CRL-issuing entity a certificate that either did not include basicConstraints or contained basicConstaints with cA=FALSE in order to avoid potential problems as a result of path length constraints.
>
> >I think that the alternative semantics under discussion can cause a real
> >difference in behavior only if the CA is using its certificate-signing key
> >for something that's not certificate-related at all - OCSP, CRL and CPS
> >signatures are all uninteresting except in the context of an
> >otherwise-trusted certificate signed by the CA.
>
> I disagree. The only disagreement we have occurs when a path length constraint has been imposed and the final certificate in the path includes a basicConstraints extension with cA=TRUE. According to PKIX, the cA component of basicConstraints is only used to specify whether the certificate subject is trusted to sign certificates. The value of basicConstraints says nothing about whether the certificate subject is trusted to issue CRLs, OCSP responses or anything else other than certificates.
>
> I would also like to note again that the current discussion is not about whether the interpretation of path length constraints should be changed. The text in RFC 2459 was not sufficiently clear and as a result there are currently some implementations that follow one set of semantics and other implementations that follow the other set.
>
> We need to make sure that new-part1 is clear about the semantics of path length constraint. However, given that both of the possible semantics have already been implemented, we can not really make a decision on the basis that one alternative describes the "current" semantics while the other represents a "change in the semantics".
>
> Dave

--
David Simonetti
Securify (www.securify.com), 410-356-2260

Date: Fri, 02 Mar 2001 14:58:21 -0500
From: "Lawrence Gross" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject:  Unsubscribe

Unsubscribe

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
Date: Fri, 2 Mar 2001 14:31:54 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A34F.6FF365A0
Content-Type: text/plain

Hi Phil,

Thanks for the feedback and the suggestion.

These specs have undergone interop testing among half a dozen or more
(perhaps 10) independent implementations for over a year and a half now.
Some of the implementors use available ASN.1 compilers; others, perhaps, are
using hand-coding.  But in any case, I've been assuming that if there were
problems with the syntax it would have been brought to my attention long
before now.  It looks like either no one has encountered any problems, or no
one has bothered mentioning it to me.

If you (or anyone else reading this) would like to run the modules through a
syntax checker and give me a list of the necessary changes, I'd be happy to
incorporate them.  My sense, however, from what you've listed below, is that
the changes required will be sufficiently minor that they can all be taken
care of during the last "48 HOURS NOTICE" editing cleanup window from the
RFC Editor.  Therefore, I see no reason to hold up progression of either of
these documents.

Carlisle.

> ----------
> From: 	Phillip H. Griffin[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Friday, March 02, 2001 12:51 PM
> To: 	Carlisle Adams
> Cc: 	[email-masked]; [email-masked]'
> Subject: 	Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and
> rfc2511bis-01.txt)
> 
> Petty perhaps, but it might be nice to review 
> this ASN.1 rigorously before any progression.
> 
> Just browsing through the -03 version I found 
> some busted notation. The named integer values
> "CMP1999(1), CMP2000(2)" should begin with lower
> case letters.
> 
> And "implicitConfirm ::= {id-it 13}" should be
> "implicitConfirm OBJECT IDNETIFIER ::= {id-it 13}"
> and "implicitConfirmValue ::= NULL" is invalid as
> well.
> 
> A good going over by an automated syntax checker 
> tool such as one of the freely available ones at 
> http://www.oss.com/products/syntax1.html or listed on
> http://asn1.elibel.tm.fr/en/links/index.htm#tools
> would probably find some things that I missed by eye.
> 

------_=_NextPart_001_01C0A34F.6FF365A0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis-01.txt)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Phil,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Thanks for =
the feedback and the suggestion.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">These =
specs have undergone interop testing among half a dozen or more =
(perhaps 10) independent implementations for over a year and a half =
now.&nbsp; Some of the implementors use available ASN.1 compilers; =
others, perhaps, are using hand-coding.&nbsp; But in any case, I've =
been assuming that if there were problems with the syntax it would have =
been brought to my attention long before now.&nbsp; It looks like =
either no one has encountered any problems, or no one has bothered =
mentioning it to me.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">If you (or =
anyone else reading this) would like to run the modules through a =
syntax checker and give me a list of the necessary changes, I'd be =
happy to incorporate them.&nbsp; My sense, however, from what you've =
listed below, is that the changes required will be sufficiently minor =
that they can all be taken care of during the last &quot;48 HOURS =
NOTICE&quot; editing cleanup window from the RFC Editor.&nbsp; =
Therefore, I see no reason to hold up progression of either of these =
documents.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Phillip H. =
Griffin[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Reply To:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Friday, March 02, 2001 12:51 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]; [email-masked]'</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis-01.txt)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Petty perhaps, but it might be nice to =
review </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this ASN.1 rigorously before any =
progression.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Just browsing through the -03 version =
I found </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">some busted notation. The named =
integer values</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;CMP1999(1), CMP2000(2)&quot; =
should begin with lower</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">case letters.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">And &quot;implicitConfirm ::=3D {id-it =
13}&quot; should be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;implicitConfirm OBJECT =
IDNETIFIER ::=3D {id-it 13}&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and &quot;implicitConfirmValue ::=3D =
NULL&quot; is invalid as</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">well.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A good going over by an automated =
syntax checker </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">tool such as one of the freely =
available ones at </FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.oss.com/products/syntax1.html" =
TARGET=3D"_blank">http://www.oss.com/products/syntax1.html</A></FONT></U=
><FONT SIZE=3D2 FACE=3D"Arial"> or listed on</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://asn1.elibel.tm.fr/en/links/index.htm#tools" =
TARGET=3D"_blank">http://asn1.elibel.tm.fr/en/links/index.htm#tools</A><=
/FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">would probably find some things that =
I missed by eye.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C0A34F.6FF365A0--

Date: Fri, 02 Mar 2001 19:19:44 +0000
From: Dr S N Henson <[email-masked]>
Organization: S N Henson
To: PKIX-List <[email-masked]>
Subject: Attribute certificate tagging discrepancy?

There appears to be a discrepancy between the tagging used for attribute
certificates in X509v3, X509 4th edition (draft 7) and the current PKIX
draft draft-ietf-pkix-ac509prof-06.txt.

The X509v3 attribute certficate ASN1 module does not change the default
tagging which is EXPLICIT.

The current PKIX draft has

     DEFINITIONS EXPLICIT TAGS ::=

in Appendix B.

However the X509 4th edition V7 draft,  Annex A seems to specify
IMPLICIT tagging as the module default.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: RE: Part1 last call comments
Date: Fri, 2 Mar 2001 10:46:15 -0800
Importance: Normal

> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, March 01, 2001 2:51 PM
> To: [email-masked]
> Subject: Re: Part1 last call comments
>
>
> All of these comments deal with the ASN.1 modules in
> draft-ietf-pkix-new-part1-04.txt and
> draft-ietf-pkix-ipki-pkalgs-01.txt.  Jim Schaad posted some comments
> earlier, but I do not completely agree with his resolutions.  I will
> address those second.  First, I want to raise a two things
> that were not
> raised in Jim's message.
>
>   1.  AuthorityKeyIdentifier is defined as:
>
>     AuthorityKeyIdentifier ::= SEQUENCE {
>        keyIdentifier             [0] KeyIdentifier           OPTIONAL,
>        authorityCertIssuer       [1] GeneralNames            OPTIONAL,
>        authorityCertSerialNumber [2] CertificateSerialNumber
> OPTIONAL  }
>
>     KeyIdentifier ::= OCTET STRING
>
> There is nothing wrong with this ASN.1; however, at least one
> compiler
> wants either "EXPLICIT" or "IMPLICIT" to be inserted before
> CertificateSerialNumber.  Obviously, only one of these is
> correct.  The
> problem in the compiler seems to come from the fact that
> CertificateSerialNumber is imported from the explicit module.
>
> The same compiler would like "EXPLICIT" or "IMPLICIT" to be
> inserted before
> uses of ORAddress, Name, DirectoryString, and
> RelativeDistinguishedName.
>
> A programmer must know a fair amount about ASN.1 to know the
> correct type
> of tagging in each case.  To avoid implementation errors from
> anyone that
> might use that tool, should we make the insertion?  My
> initial reaction is
> that anyone who uses a tool with such shortcomings must edit
> the module to
> overcome them.  I think that preserving alignment with X.509 is
> important.  However, I think we should make sure that the example
> certificate includes these cases to help implementors catch
> mistakes early
> in the development process.

I agree with Russ that the ASN.1 is correct and we should not "fix" it for a
broken tool.

> ...
> >7. Section A.1
> >                    id-domainComponent      AttributeType ::=
> > id-domainComponent
> >      replace with
> >                    id-domainComponent      AttributeType ::=
> > id-domainComponent }
>
> I do not think that this is the correct change.  The document says:
>
>          id-domainComponent     OBJECT IDENTIFIER  ::=
>                                              { 0 9 2342
> 19200300 100 1 25 }
>
>          id-domainComponent      AttributeType ::= id-domainComponent
>          domainComponent ::=     IA5String
>
> I think the middle statement should be deleted altogether.
> Also, the last
> line must begin with a capital letter ("domainComponent" becomes
> "DomainComponent").

Deleting the middle statement is acceptable to me.
> Russ

Jim

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Part1 last call comments
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sat, 3 Mar 2001 07:40:48 (NZDT)

Russ Housley <[email-masked]> writes:

>A programmer must know a fair amount about ASN.1 to know the correct type of
>tagging in each case.  To avoid implementation errors from anyone that might
>use that tool, should we make the insertion?

I would say, yes.  The ASN.1 rule you quote is a booby-trap which has caught a
number of implementors (I added it to the X.509 style guide a while back for
this reason, and you still occasionally see questions about it on various
lists, and I've had a few "Your dumpasn1 shows ... but RFC 2459 says ..." too),
it'd be worth making this explicit in the ASN.1.

Peter.

Date: Fri, 02 Mar 2001 13:44:59 -0500
To: [email-masked]
From: Ari Kermaier <[email-masked]>
Subject: Re: UIDs popping up in new-part1

The recommendation that Section 6.1.3 be amended to remove references to 
UIDs makes sense; CAs conforming to the current profile should not be 
required to support this mechanism for certificate chaining, nor should 
UIDs be allowed to needlessly complicate the revised validation algorithm.

However, requiring that UIDs be absent from a certificate would be a 
serious error, as would recommending that conforming CAs reject 
certificates containing UIDs. If the certificate in question contains the 
information required to perform chaining and validation as per the current 
profile, why should the CA not be free to ignore the presence of extraneous 
infomation? I think it would be a Very Bad Idea to break backwards 
compatibility for what is essentially nothing more than an aesthetic 
reason. A CA conforming to the current X.509 v3 profile should NOT reject a 
certificate that has a deprecated field from a X.509 v2 profile -- it 
should just ignore that field. Of course, eveyone "knows" that "nobody" 
uses UIDs, but that's not a good reason to break, even hypothetically, 
certificates that do use them unless there's a truly compelling positive or 
negative functional benefit.

Ari Kermaier
Phaos Technology

>Last fall, we agreed to remove issuer and subject unique identifier
>comparison from the validation algorithm. At least, I think we did. The
>argument was that nobody uses unique identifiers and there's no good
>reason to retain support for them.
>
>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
>they remain in step (a) (5) of section 6.1.3, which says:
>
>          (5) The certificate issuer unique identifier is the
>          working_issuer_UID, meaning:
>
>             (i) working_issuer_UID is non-null and matches the value in
>             the issuerUID field, or
>
>             (ii) working_issuer_UID is null and the issuerUID field is
>             not present.
>
>But working_issuer_UID is no longer set anywhere. We should either put
>back the text that initializes and updates this state variable or we
>should change this step so that it doesn't refer to this uninitialized
>varible. I suggest that we remove support for unique identifier chaining
>by changing this step to say:
>
>          (5) The issuerUniqueID and subjectUniqueID fields are not
>          present in the certificate.
>
>This will ensure that compliant implementations will not accidentally
>accept certificates that use these fields, since support for these
>fields is no longer required. I also suggest that we change the sentence
>in section 4.1.2.8 that reads "Applications conforming to this profile
>SHOULD be capable of parsing unique identifiers and making
>comparisons."  to read "Applications conforming to this profile SHOULD
>reject certificates that contain unique identifiers."
>
>-Steve

Date: Fri, 2 Mar 2001 12:45:34 -0500
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: UIDs popping up in new-part1
Cc: <[email-masked]>

--============_-1228566803==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Bob,

>I strongly disagree that "nobody uses unique identifiers" or that
>"there's no good reason to retain support of them."  And I even
>more strongly reject the notion that just because it is alleged that no one
>uses them, applications SHOULD reject certificates which disprove
>the allegation!

RFC 2459 has deprecated the use of these fields for some time, so 
this is not a new matter. The current RFC states, in part,:

The subject and issuer unique identifiers are present in the 
certificate to handle the possibility of reuse of subject and/or
issuer names over time.  This profile recommends that names not be
reused for different entities and that Internet certificates not make 
use of unique identifiers.  CAs conforming to this profile SHOULD NOT 
generate certificates with unique identifiers.

  Also, your intentionally obfuscated description of how you might 
want to use them is not consistent with the semantics of the fields, 
as noted above, which were designed to allow disambiguation of certs 
when DNs were reused, NOT to locate certs in the way you allude to. 
As you may recall, the motivation for these fields was a directory 
access control problem caused by bad schema design. We came out 
strongly in the RFC against this hack as a way of fixing the problem.

Steve
--============_-1228566803==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
 --></style><title>Re: UIDs popping up in
new-part1</title></head><body>
<div>Bob,</div>
<div><br></div>
<blockquote type="cite" cite>I strongly disagree that &quot;nobody
uses unique identifiers&quot; or that<br>
&quot;there's no good reason to retain support of them.&quot;&nbsp;
And I even<br>
more strongly reject the notion that just because it is alleged that
no one<br>
uses them, applications SHOULD reject certificates which
disprove</blockquote>
<blockquote type="cite" cite>the allegation!</blockquote>
<div><br></div>
<div>RFC 2459 has deprecated the use of these fields for some time, so
this is not a new matter. The current RFC states, in part,:</div>
<div><br></div>
<div><font face="Courier" size="+2" color="#000000">The subject and
issuer unique identifiers are present in the certificate to handle the
possibility of reuse of subject and/or</font></div>
<div><font face="Courier" size="+2" color="#000000">issuer names over
time.&nbsp; This profile recommends that names not be</font></div>
<div><font face="Courier" size="+2" color="#000000">reused for
different entities and that Internet certificates not make use of
unique identifiers.&nbsp; CAs conforming to this profile SHOULD NOT
generate certificates with unique identifiers.</font></div>
<div><font face="Courier" size="+2" color="#000000"><br></font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;</font>Also,
your intentionally obfuscated description of how you might want to use
them is not consistent with the semantics of the fields,&nbsp; as
noted above, which were designed to allow disambiguation of certs when
DNs were reused, NOT to locate certs in the way you allude to. As you
may recall, the motivation for these fields was a directory access
control problem caused by bad schema design. We came out strongly in
the RFC against this hack as a way of fixing the problem.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1228566803==_ma============--

Date: Fri, 02 Mar 2001 12:51:29 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting  
To: Carlisle Adams <[email-masked]>
CC: [email-masked], "[email-masked]'" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis-01.txt)

Petty perhaps, but it might be nice to review 
this ASN.1 rigorously before any progression.

Just browsing through the -03 version I found 
some busted notation. The named integer values
"CMP1999(1), CMP2000(2)" should begin with lower
case letters.

And "implicitConfirm ::= {id-it 13}" should be
"implicitConfirm OBJECT IDNETIFIER ::= {id-it 13}"
and "implicitConfirmValue ::= NULL" is invalid as
well.

A good going over by an automated syntax checker 
tool such as one of the freely available ones at 
http://www.oss.com/products/syntax1.html or listed on
http://asn1.elibel.tm.fr/en/links/index.htm#tools
would probably find some things that I missed by eye.

Phil
----
Phillip H. Griffin    Griffin Consulting
http://asn-1.com      Secure ASN.1 Design & Implementation
p:  +1-919-832-7008   1625 Glenwood Avenue
f:  +1-919-832-7390   Hayes Barton at Five Points
e:  [email-masked]    Raleigh, North Carolina 27608-2319 USA
------------------------------------------------------------

> Carlisle Adams wrote:
> 
> Hi,
> 
> For those of you that are curious, 2510bis-03 and 2511bis-01 are minor
> revisions to the previous drafts which, I believe, address all
> comments received (both privately and on the list) in the past 3
> months.  I feel that both documents are now ready to progress.
> 
> The documents can be found at the following locations:
> 
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-03.txt
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-01.txt
> 
> The changes between rfc2510bis-02 and rfc2510bis-03 are as follows:
> 
>           p.30:  added a comment on the "waiting" status regarding the
>           possible need for a polling mechanism in the transport layer
>           and allowing the possibility of polling PKIMessages in a
>           future version of this spec.  (You might recall Magnus
>           asking for this on the PKIX list....).
> 
>           p.33:  removed tag "[1]" from publicKeyMAC field (to align
>           with syntax in RFC 2511).
> 
>           p.39:  changed "OCTET STRING" to "string" in comment
>           regarding utf8Pairs ("OCTET STRING" was confusing to some
>           people).
> 
>           p.63:  added a comment regarding the way in which a
>           requester could indicate a preference for algorithm and
>           parameters with respect to centrally-generated key pairs
>           (Magnus also asked how this could be done and I should have
>           given him this answer, but didn't think of it at the
>           time...).
> 
>           p.67:  removed the position-dependence requirement for
>           requests in cr and kur (at least a couple of people have
>           asked for this on the list, including Magnus).
> 
>           p.75:  clarified what gets signed if the AltCertTemplate
>           control is used (someone asked for this on the list).
> 
>           p.80:  (see p.30 above).
> 
>           p.85:  (see p.39 above).
> 
>           p.86:  added the certReqId field to CertStatus (I had done
>           this in the body of the spec, but forgot to copy it to this
>           appendix!).
> 
> The changes between rfc2511bis-00 and rfc2511bis-01 are as follows:
> 
>           pp.1 and 13:  changed the work affiliation for Mike Myers.
> 
>           p.10:  added a missing parenthesis in the second line of the
>           comment under encValue.
> 
>           p.12:  added a reference to PKCS11.
> 
>           p.16:  changed "OCTET STRING" to "string" in comment
>           regarding utf8Pairs ("OCTET STRING" was confusing to some
>           people).
> 
> Carlisle.

From: "Pawling, John" <[email-masked]>
To: [email-masked]
Subject: RE: Part1 last call comments
Date: Fri, 2 Mar 2001 11:27:12 -0500 

All,

We compiled the PKIX1Explicit88 module in the
draft-ietf-pkix-new-part1-04.txt using the Enhanced SNACC ASN.1 compiler.
We found some of the same problems that Jim reported (X520SerialNumber
definition missing "::="; id-domainComponent defined twice).  We also found:

1) OLD: ub-serialNumber INTEGER ::= 64
   NEW: ub-serial-number INTEGER ::= 64

2) OLD: domainComponent ::= IA5String
   NEW: DomainComponent ::= IA5String

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

Content-return: allowed
Date: Fri, 02 Mar 2001 08:04:58 -0800
From: Frank Balluffi <[email-masked]>
Subject: RE: Part1 last call comments
To: "'Russ Housley'" <[email-masked]>, [email-masked]

Russ Housley said:

> The same compiler would like "EXPLICIT" or "IMPLICIT" to be 
> inserted before 
> uses of ORAddress, Name, DirectoryString, and 
> RelativeDistinguishedName.

Having been bitten by this in the past, I would recommend that PKIX at least
insert a comment into the ASN.1 source with the appropriate tag type.

Frank

> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, March 01, 2001 5:51 PM
> To: [email-masked]
> Subject: Re: Part1 last call comments
> 
> 
> All of these comments deal with the ASN.1 modules in 
> draft-ietf-pkix-new-part1-04.txt and 
> draft-ietf-pkix-ipki-pkalgs-01.txt.  Jim Schaad posted some comments 
> earlier, but I do not completely agree with his resolutions.  I will 
> address those second.  First, I want to raise a two things 
> that were not 
> raised in Jim's message.
> 
>   1.  AuthorityKeyIdentifier is defined as:
> 
>     AuthorityKeyIdentifier ::= SEQUENCE {
>        keyIdentifier             [0] KeyIdentifier           OPTIONAL,
>        authorityCertIssuer       [1] GeneralNames            OPTIONAL,
>        authorityCertSerialNumber [2] CertificateSerialNumber 
> OPTIONAL  }
> 
>     KeyIdentifier ::= OCTET STRING
> 
> There is nothing wrong with this ASN.1; however, at least one 
> compiler 
> wants either "EXPLICIT" or "IMPLICIT" to be inserted before 
> CertificateSerialNumber.  Obviously, only one of these is 
> correct.  The 
> problem in the compiler seems to come from the fact that 
> CertificateSerialNumber is imported from the explicit module.
> 
> The same compiler would like "EXPLICIT" or "IMPLICIT" to be 
> inserted before 
> uses of ORAddress, Name, DirectoryString, and 
> RelativeDistinguishedName.
> 
> A programmer must know a fair amount about ASN.1 to know the 
> correct type 
> of tagging in each case.  To avoid implementation errors from 
> anyone that 
> might use that tool, should we make the insertion?  My 
> initial reaction is 
> that anyone who uses a tool with such shortcomings must edit 
> the module to 
> overcome them.  I think that preserving alignment with X.509 is 
> important.  However, I think we should make sure that the example 
> certificate includes these cases to help implementors catch 
> mistakes early 
> in the development process.
> 
> 2.  The implicit module (section A.2) contains the following:
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     
> DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
>     IssuingDistributionPoint ::= SEQUENCE {
>       distributionPoint       [0] DistributionPointName OPTIONAL,
>       onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
>       onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
>       onlySomeReasons         [3] ReasonFlags OPTIONAL,
>       indirectCRL             [4] BOOLEAN DEFAULT FALSE }
> 
>     DistributionPointName ::= CHOICE {
>          fullName                [0]     GeneralNames,
>          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> 
> This matches the definitions from X.509 (4th Edition), but it 
> is still a 
> very strange use of CHOICE.  It relies on a little-known ASN.1 rule:
> 
>          The tagging construct specifies explicit tagging if 
> the "Tag Type"
>          alternative is used and the value of "TagDefault" 
> for the module is
>          "IMPLICIT TAGS", but the type defined by "Type" is a 
> choice type
>          or an any type.
> 
> The same compiler as discussed above, does not internally 
> implement this 
> rule.  The programmer must insert the "EXPLICIT."  Again, my 
> reaction is 
> that anyone who uses a tool with such shortcomings must edit 
> the module to 
> overcome them.  I think we should make sure that the example 
> certificate 
> includes these cases to help implementors catch mistakes early in the 
> development process.
> 
> I think that implementors would be well served if the specification 
> included the binary certificates were made available.  I do 
> not think that 
> we should make the document any bigger.  Perhaps we can 
> develop a companion 
> document that contains several sample certification paths 
> with CRLs to aid 
> developers.  Of course, we need to carefully consider the 
> validity periods 
> for the sample certificates to be useful to future 
> developers, but that is 
> a topic for another thread.
> 
> Now to Jim Schaad's message.
> 
> >3.  Section 4.2.2.2 - Recommend moving the defintion of 
> id-ad-caRepository
> >to implicit ASN.1 module since that is where accessLocation 
> is located.
> 
> Good idea.  I do not think that moving the OID definition will impact 
> anyone that already did an implementation.
> 
> >5.  ASN Module A.1:  Do not have a new module OID for this.
> 
> A new OID for the modules was assigned quite some time ago.  
> It should have 
> been included in this draft.
> 
>          id-mod-pkix1-explicit        OBJECT IDENTIFIER ::= { 
> id-mod 18 }
> 
> >6.  A.1:
> >                    X520SerialNumber        PrintableString (SIZE 
> > (1..ub-serial-number))
> >       replace with
> >                    X520SerialNumber        ::= 
> PrintableString (SIZE 
> > (1..ub-serial-number))
> 
> Agree; the assignment operator (::=) is missing.
> 
> >7. Section A.1
> >                    id-domainComponent      AttributeType ::= 
> > id-domainComponent
> >      replace with
> >                    id-domainComponent      AttributeType ::= 
> > id-domainComponent }
> 
> I do not think that this is the correct change.  The document says:
> 
>          id-domainComponent     OBJECT IDENTIFIER  ::=
>                                              { 0 9 2342 
> 19200300 100 1 25 }
> 
>          id-domainComponent      AttributeType ::= id-domainComponent
>          domainComponent ::=     IA5String
> 
> I think the middle statement should be deleted altogether.  
> Also, the last 
> line must begin with a capital letter ("domainComponent" becomes 
> "DomainComponent").
> 
> >8.  ASN Module A.2:  Do not have a new module OID for this.
> 
> A new OID for the modules was assigned quite some time ago.  
> It should have 
> been included in this draft.
> 
>          id-mod-pkix1-implicit        OBJECT IDENTIFIER ::= { 
> id-mod 19 }
> 
> >9.  Section A.2
> >                 anyPolicy OBJECT IDENTIFIER ::= 
> > {id-ce-certificate-policies 0}
> >       replace with
> >                 anyPolicy OBJECT IDENTIFIER ::= 
> {id-ce-certificatePolicies 0}
> >       (or fix the previous line)
> 
> Agree.  X.509 (the 4th Edition) uses 
> id-ce-certificatePolicies, and we 
> should too.
> 
> >----------------   Algorithm Draft
> >
> >ASN Module:
> >Fix:
> >    PKIX1Algorithms88 { tbd }
> 
> I assigned id-mod-pkix1-algorithms a long time ago.  It 
> should have been 
> put into this draft.
> 
>          id-mod-pkix1-algorithms      OBJECT IDENTIFIER ::= { 
> id-mod 17 }
> 
> >Replace
> >             cofactor  INTEGER  OPTIONAL,         -- The 
> integer h = #E(Fq)/n
> >With
> >             cofactor  INTEGER  OPTIONAL          -- The 
> integer h = #E(Fq)/n
> 
> My preference would be to replace the comma with "}" and 
> delete the next 
> line.  This is just taste.  The comma needs to go.
> 
> >------------------ Random
> >
> >part1-algs.asn(3) : warning XXXXX: Module PKIX1Algorithms88 
> does not have an
> >OID assigned to it
> >
> >  --- single name would be nice but not necessary.  In the 
> case of pkcs-9
> >however there should be a harmonization plan.
> >
> >rfc2630.asn(254) : warning XXXXX: Arc naming collision 
> between x9algorithm
> >and x9cm
> >         Conflicts with what's in Algorithms draft
> >rfc2630.asn(262) : warning XXXXX: Oid value assigned to 
> multiple symbols:
> >'dh-public-number' and 'dhpublicnumber'
> >         Conflicts with what's in Algorithms draft
> >rfc2634.asn(204) : warning XXXXX: Arc naming collision 
> between pkcs-9 and
> >pkcs9
> >         Conflicts with what's in Part1 A.1
> 
> I do not see a problem with adopting the names from RFC 2630 
> and RFC 2634.
> 
> Russ
> 
> 

Date: Thu, 01 Mar 2001 17:51:05 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Part1 last call comments

All of these comments deal with the ASN.1 modules in 
draft-ietf-pkix-new-part1-04.txt and 
draft-ietf-pkix-ipki-pkalgs-01.txt.  Jim Schaad posted some comments 
earlier, but I do not completely agree with his resolutions.  I will 
address those second.  First, I want to raise a two things that were not 
raised in Jim's message.

  1.  AuthorityKeyIdentifier is defined as:

    AuthorityKeyIdentifier ::= SEQUENCE {
       keyIdentifier             [0] KeyIdentifier           OPTIONAL,
       authorityCertIssuer       [1] GeneralNames            OPTIONAL,
       authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

    KeyIdentifier ::= OCTET STRING

There is nothing wrong with this ASN.1; however, at least one compiler 
wants either "EXPLICIT" or "IMPLICIT" to be inserted before 
CertificateSerialNumber.  Obviously, only one of these is correct.  The 
problem in the compiler seems to come from the fact that 
CertificateSerialNumber is imported from the explicit module.

The same compiler would like "EXPLICIT" or "IMPLICIT" to be inserted before 
uses of ORAddress, Name, DirectoryString, and RelativeDistinguishedName.

A programmer must know a fair amount about ASN.1 to know the correct type 
of tagging in each case.  To avoid implementation errors from anyone that 
might use that tool, should we make the insertion?  My initial reaction is 
that anyone who uses a tool with such shortcomings must edit the module to 
overcome them.  I think that preserving alignment with X.509 is 
important.  However, I think we should make sure that the example 
certificate includes these cases to help implementors catch mistakes early 
in the development process.

2.  The implicit module (section A.2) contains the following:

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

    IssuingDistributionPoint ::= SEQUENCE {
      distributionPoint       [0] DistributionPointName OPTIONAL,
      onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
      onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
      onlySomeReasons         [3] ReasonFlags OPTIONAL,
      indirectCRL             [4] BOOLEAN DEFAULT FALSE }

    DistributionPointName ::= CHOICE {
         fullName                [0]     GeneralNames,
         nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

This matches the definitions from X.509 (4th Edition), but it is still a 
very strange use of CHOICE.  It relies on a little-known ASN.1 rule:

         The tagging construct specifies explicit tagging if the "Tag Type"
         alternative is used and the value of "TagDefault" for the module is
         "IMPLICIT TAGS", but the type defined by "Type" is a choice type
         or an any type.

The same compiler as discussed above, does not internally implement this 
rule.  The programmer must insert the "EXPLICIT."  Again, my reaction is 
that anyone who uses a tool with such shortcomings must edit the module to 
overcome them.  I think we should make sure that the example certificate 
includes these cases to help implementors catch mistakes early in the 
development process.

I think that implementors would be well served if the specification 
included the binary certificates were made available.  I do not think that 
we should make the document any bigger.  Perhaps we can develop a companion 
document that contains several sample certification paths with CRLs to aid 
developers.  Of course, we need to carefully consider the validity periods 
for the sample certificates to be useful to future developers, but that is 
a topic for another thread.

Now to Jim Schaad's message.

>3.  Section 4.2.2.2 - Recommend moving the defintion of id-ad-caRepository
>to implicit ASN.1 module since that is where accessLocation is located.

Good idea.  I do not think that moving the OID definition will impact 
anyone that already did an implementation.

>5.  ASN Module A.1:  Do not have a new module OID for this.

A new OID for the modules was assigned quite some time ago.  It should have 
been included in this draft.

         id-mod-pkix1-explicit        OBJECT IDENTIFIER ::= { id-mod 18 }

>6.  A.1:
>                    X520SerialNumber        PrintableString (SIZE 
> (1..ub-serial-number))
>       replace with
>                    X520SerialNumber        ::= PrintableString (SIZE 
> (1..ub-serial-number))

Agree; the assignment operator (::=) is missing.

>7. Section A.1
>                    id-domainComponent      AttributeType ::= 
> id-domainComponent
>      replace with
>                    id-domainComponent      AttributeType ::= 
> id-domainComponent }

I do not think that this is the correct change.  The document says:

         id-domainComponent     OBJECT IDENTIFIER  ::=
                                             { 0 9 2342 19200300 100 1 25 }

         id-domainComponent      AttributeType ::= id-domainComponent
         domainComponent ::=     IA5String

I think the middle statement should be deleted altogether.  Also, the last 
line must begin with a capital letter ("domainComponent" becomes 
"DomainComponent").

>8.  ASN Module A.2:  Do not have a new module OID for this.

A new OID for the modules was assigned quite some time ago.  It should have 
been included in this draft.

         id-mod-pkix1-implicit        OBJECT IDENTIFIER ::= { id-mod 19 }

>9.  Section A.2
>                 anyPolicy OBJECT IDENTIFIER ::= 
> {id-ce-certificate-policies 0}
>       replace with
>                 anyPolicy OBJECT IDENTIFIER ::= {id-ce-certificatePolicies 0}
>       (or fix the previous line)

Agree.  X.509 (the 4th Edition) uses id-ce-certificatePolicies, and we 
should too.

>----------------   Algorithm Draft
>
>ASN Module:
>Fix:
>    PKIX1Algorithms88 { tbd }

I assigned id-mod-pkix1-algorithms a long time ago.  It should have been 
put into this draft.

         id-mod-pkix1-algorithms      OBJECT IDENTIFIER ::= { id-mod 17 }

>Replace
>             cofactor  INTEGER  OPTIONAL,         -- The integer h = #E(Fq)/n
>With
>             cofactor  INTEGER  OPTIONAL          -- The integer h = #E(Fq)/n

My preference would be to replace the comma with "}" and delete the next 
line.  This is just taste.  The comma needs to go.

>------------------ Random
>
>part1-algs.asn(3) : warning XXXXX: Module PKIX1Algorithms88 does not have an
>OID assigned to it
>
>  --- single name would be nice but not necessary.  In the case of pkcs-9
>however there should be a harmonization plan.
>
>rfc2630.asn(254) : warning XXXXX: Arc naming collision between x9algorithm
>and x9cm
>         Conflicts with what's in Algorithms draft
>rfc2630.asn(262) : warning XXXXX: Oid value assigned to multiple symbols:
>'dh-public-number' and 'dhpublicnumber'
>         Conflicts with what's in Algorithms draft
>rfc2634.asn(204) : warning XXXXX: Arc naming collision between pkcs-9 and
>pkcs9
>         Conflicts with what's in Part1 A.1

I do not see a problem with adopting the names from RFC 2630 and RFC 2634.

Russ

From: Carlisle Adams <[email-masked]>
To: [email-masked]
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)
Date: Fri, 2 Mar 2001 10:07:33 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A32A.82185300
Content-Type: text/plain

Hi,

For those of you that are curious, 2510bis-03 and 2511bis-01 are minor
revisions to the previous drafts which, I believe, address all comments
received (both privately and on the list) in the past 3 months.  I feel that
both documents are now ready to progress.

The documents can be found at the following locations:

   http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-03.txt
   http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-01.txt

The changes between rfc2510bis-02 and rfc2510bis-03 are as follows:

		p.30:  added a comment on the "waiting" status regarding the
possible need for a polling mechanism in the transport layer and allowing
the possibility of polling PKIMessages in a future version of this spec.
(You might recall Magnus asking for this on the PKIX list....).

		p.33:  removed tag "[1]" from publicKeyMAC field (to align
with syntax in RFC 2511).

		p.39:  changed "OCTET STRING" to "string" in comment
regarding utf8Pairs ("OCTET STRING" was confusing to some people).

		p.63:  added a comment regarding the way in which a
requester could indicate a preference for algorithm and parameters with
respect to centrally-generated key pairs (Magnus also asked how this could
be done and I should have given him this answer, but didn't think of it at
the time...).

		p.67:  removed the position-dependence requirement for
requests in cr and kur (at least a couple of people have asked for this on
the list, including Magnus).

		p.75:  clarified what gets signed if the AltCertTemplate
control is used (someone asked for this on the list).

		p.80:  (see p.30 above).

		p.85:  (see p.39 above).

		p.86:  added the certReqId field to CertStatus (I had done
this in the body of the spec, but forgot to copy it to this appendix!).

The changes between rfc2511bis-00 and rfc2511bis-01 are as follows:

		pp.1 and 13:  changed the work affiliation for Mike Myers.

		p.10:  added a missing parenthesis in the second line of the
comment under encValue.

		p.12:  added a reference to PKCS11.

		p.16:  changed "OCTET STRING" to "string" in comment
regarding utf8Pairs ("OCTET STRING" was confusing to some people).

Carlisle.

------_=_NextPart_001_01C0A32A.82185300
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and =
rfc2511bis-01.txt)</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">For those =
of you that are curious, 2510bis-03 and 2511bis-01 are minor revisions =
to the previous drafts which, I believe, address all comments received =
(both privately and on the list) in the past 3 months.&nbsp; I feel =
that both documents are now ready to progress.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The =
documents can be found at the following locations:</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp;</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-0=
3.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-pkix-rf=
c2510bis-03.txt</A></FONT></U>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp;</FONT><U> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-0=
1.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-pkix-rf=
c2511bis-01.txt</A></FONT></U>
</P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The =
changes between rfc2510bis-02 and rfc2510bis-03 are as follows:</FONT>
</P>
<UL><UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.30:&nbsp; added a comment on the &quot;waiting&quot; status =
regarding the possible need for a polling mechanism in the transport =
layer and allowing the possibility of polling PKIMessages in a future =
version of this spec.&nbsp; (You might recall Magnus asking for this on =
the PKIX list....).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.33:&nbsp; removed tag &quot;[1]&quot; from publicKeyMAC field =
(to align with syntax in RFC 2511).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.39:&nbsp; changed &quot;OCTET STRING&quot; to =
&quot;string&quot; in comment regarding utf8Pairs (&quot;OCTET =
STRING&quot; was confusing to some people).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.63:&nbsp; added a comment regarding the way in which a =
requester could indicate a preference for algorithm and parameters with =
respect to centrally-generated key pairs (Magnus also asked how this =
could be done and I should have given him this answer, but didn't think =
of it at the time...).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.67:&nbsp; removed the position-dependence requirement for =
requests in cr and kur (at least a couple of people have asked for this =
on the list, including Magnus).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.75:&nbsp; clarified what gets signed if the AltCertTemplate =
control is used (someone asked for this on the list).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.80:&nbsp; (see p.30 above).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.85:&nbsp; (see p.39 above).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.86:&nbsp; added the certReqId field to CertStatus (I had done =
this in the body of the spec, but forgot to copy it to this =
appendix!).</FONT></P>
</UL></UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The =
changes between rfc2511bis-00 and rfc2511bis-01 are as follows:</FONT>
</P>
<UL><UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">pp.1 and =
13:&nbsp; changed the work affiliation for Mike Myers.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.10:&nbsp; added a missing parenthesis in the second line of =
the comment under encValue.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.12:&nbsp; added a reference to PKCS11.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">p.16:&nbsp; changed &quot;OCTET STRING&quot; to =
&quot;string&quot; in comment regarding utf8Pairs (&quot;OCTET =
STRING&quot; was confusing to some people).</FONT>
</P>
<BR>
</UL></UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0A32A.82185300--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc2511bis-01.txt
Date: Fri, 02 Mar 2001 06:54:25 -0500
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 
                          Request Message Format (CRMF)
	Author(s)	: M. Myers, C. Adams, D. Solo, D. Kemp
	Filename	: draft-ietf-pkix-rfc2511bis-01.txt
	Pages		: 25
	Date		: 01-Mar-01
	
This document describes the Certificate Request Message Format
(CRMF).  This syntax is used to convey a request for a certificate to
a Certification Authority (CA) (possibly via a Registration Authority
(RA)) for the purposes of X.509 certificate production.  The request
will typically include a public key and associated registration
information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-01.txt

Internet-Drafts are also 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-rfc2511bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt
Date: Fri, 02 Mar 2001 06:54:20 -0500
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 
                          Management Protocols
	Author(s)	: C. Adams, S. Farrell
	Filename	: draft-ietf-pkix-rfc2510bis-03.txt
	Pages		: 89
	Date		: 01-Mar-01
	
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocols. Protocol messages are defined
for all relevant aspects of certificate creation and management.
Note that 'certificate' in this document refers to an X.509v3
Certificate as defined in [COR95, X509-AM].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-03.txt

Internet-Drafts are also 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-rfc2510bis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

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

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

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

--OtherAccess--

--NextPart--

Date: Thu, 01 Mar 2001 15:12:33 -0500
To: [email-masked]
From: "David A. Cooper" <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints

At 02:27 PM 3/1/01 -0500, [email-masked] wrote:
>But why would you care about a CA's signature on an OCSP response or a CRL
>if you don't trust the signature on the EE certificate you're inquiring
>about?

It will not always be the case that an CRL or OCSP response will be signed by the same entity (e.g, CA) that signed the EE certificate of interest. It may be that a certificate is issued with a cRLDistributionPoints extension specifying that corresponding CRLs will be issued by a different entity. The issuer of the CRLs does not have to be a CA (i.e., the certificate issued to this entity is not required to contain the basicConstraints extension). So, it is possible that a relying party will accept CRLs issued by some entity even though it would not accept certificates issued by this entity.

Based on the semantics that Steve Hanna, et. al. support, a CA that relied on indirect CRLs (or OCSP responses signed by some other entity) to distribute revocation information would need to issue the CRL-issuing entity a certificate that either did not include basicConstraints or contained basicConstaints with cA=FALSE in order to avoid potential problems as a result of path length constraints. With the other semantics, the certificate issued to the CRL-issuer could include basicConstraints with cA=TRUE without causing any problems.

>I think that the alternative semantics under discussion can cause a real
>difference in behavior only if the CA is using its certificate-signing key
>for something that's not certificate-related at all - OCSP, CRL and CPS
>signatures are all uninteresting except in the context of an
>otherwise-trusted certificate signed by the CA.

I disagree. The only disagreement we have occurs when a path length constraint has been imposed and the final certificate in the path includes a basicConstraints extension with cA=TRUE. According to PKIX, the cA component of basicConstraints is only used to specify whether the certificate subject is trusted to sign certificates. The value of basicConstraints says nothing about whether the certificate subject is trusted to issue CRLs, OCSP responses or anything else other than certificates.

I would also like to note again that the current discussion is not about whether the interpretation of path length constraints should be changed. The text in RFC 2459 was not sufficiently clear and as a result there are currently some implementations that follow one set of semantics and other implementations that follow the other set.

We need to make sure that new-part1 is clear about the semantics of path length constraint. However, given that both of the possible semantics have already been implemented, we can not really make a decision on the basis that one alternative describes the "current" semantics while the other represents a "change in the semantics".

Dave

From: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints
To: Marc Branchaud <[email-masked]>
Cc: [email-masked]
Date: Thu, 1 Mar 2001 14:27:03 -0500

But why would you care about a CA's signature on an OCSP response or a CRL
if you don't trust the signature on the EE certificate you're inquiring
about?

I think that the alternative semantics under discussion can cause a real
difference in behavior only if the CA is using its certificate-signing key
for something that's not certificate-related at all - OCSP, CRL and CPS
signatures are all uninteresting except in the context of an
otherwise-trusted certificate signed by the CA.

John

Marc Branchaud <[email-masked]>@home.x509.com on 03/01/2001 12:53:15 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: Open Issue in Part1: path length constraints

Bob Jueneman wrote:
>
> I would agree with David, that using the same key or certificate
> for both correspondence and certificate issuance would be
> extremely improbable.

How about a CA key signing OCSP responses?  Or CRLs, for that matter.
Either
are non-certificate "messages".

          Marc

Sender: [email-masked]
Date: Thu, 01 Mar 2001 09:53:15 -0800
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Re: Open Issue in Part1: path length constraints

Bob Jueneman wrote:
> 
> I would agree with David, that using the same key or certificate
> for both correspondence and certificate issuance would be
> extremely improbable.

How about a CA key signing OCSP responses?  Or CRLs, for that matter.  Either
are non-certificate "messages".

		Marc

Date: Thu, 01 Mar 2001 10:26:47 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints

I would agree with David, that using the same key or certificate
for both correspondence and certificate issuance would be
extremely improbable.

However, it is not nearly so clear that a CA might choose to use the 
same key for certificate signing and for signing its CPS, for
example, so it would appear that his scenario is worth considering.

Bob

>>> David Kemp <[email-masked]> 03/01/01 09:58AM >>>

> Date: Wed, 28 Feb 2001 13:28:46 -0500
> From: Steve Hanna <[email-masked]>
> X-Accept-Language: en
> To: "David P. Kemp" <[email-masked]>
> CC: [email-masked] 
> Subject: Re: Open Issue in Part1: path length constraints
> 
> "David P. Kemp" wrote:
> > > From: Steve Hanna <[email-masked]>
> > > I find it odd to say that a certificate with cA=TRUE is a CA certificate
> > > *unless* it is the last certificate in a path. I suppose this is only a
> > > wording problem, but I find this wording *less* clear than the old
> > > wording.
> > 
> > The oddness arises because you are applying the label "CA certificate"
> > to the certificate based on its contents instead of its usage.
> > 
> > If a certificate contains cA=TRUE and
> > keyCertSign=cRLSign=digitalSignature=1, then it can be used for more
> > than one purpose.  It is a CA certificate when validating the signature
> > of a certificate, and it is an EE certificate when validating the
> > signature of a CRL or a message.  (A CA should not use a cert-signing
> > private key to sign correspondence, but X.509 doesn't prohibit unhygenic
> > practices.)
> 
> So you're saying that a certificate with cA=TRUE is an end-entity
> certificate when it appears at the end of a certificate chain and a CA
> certificate otherwise? The same certificate is both a CA certificate and
> an end-entity certificate? This seems to be contrary to the way these
> terms have been used in the past and the way they are used in X.509, RFC
> 2459, new-part1, and throughout the industry.

Steve,

Yes, that's what I'm saying.  If "you" are a CA, and you use the same
private key to sign certificates and to sign email, and you are the
subject of a certificate which has both keyCertSign and digitalSignature
key usage bits, then what kind of certificate is it?

My answer is that it is both.  What is your answer?

Using the same cert for correspondence signatures and certificate
signatures is probably so risky that such certs are not routinely used.
But this discussion is about using the same cert for signing certificates
and for signing CRLs, which is probably standard industry practice.
When validating the signature on a CRL, is the CA's certificate a
CA certificate or an End-Entity certificate?

My answer is that it is the certificate of an entity which has signed
a CRL.  What is your answer?

> I suggest the following:
> 
>    In this case, it gives the maximum number of intermediate CA
>    certificates that may follow this certificate in a certification
>    path. (Note: One final certificate will follow the final intermediate
>    CA certificate in the path. This certificate may be either a CA
>    certificate or an end-entity certificate.) A pathLenConstraint of
>    zero indicates that no intermediate CA certificates may follow in the
>    path. Where it appears, the pathLenConstraint field MUST be greater
>    than or equal to zero. Where pathLenConstraint does not appear, there
>    is no limit to the allowed length of the certification path.

This doesn't answer the question of what to call the final certificate
in the path when that certificate has cA=TRUE and the signature being
verified is that of a CRL or a message.  Which is OK, since it doesn't
make a bit o' difference what you call it as long as it isn't counted in
pathLenConstraint.

The suggestion is OK with me, but it is no less plausible to
call (2) an "end-entity certificate" than it is to call (1) an
"intermediate CA certificate".  (1) is the last CA certificate
in the path, but if you want to call it an intermediate CA, fine.

     [anchor]  --> [CA-a]  --> [CA-b]  --> [Joe User] --> [message]
                                 (1)

     [anchor]  --> [CA-a]  --> [CA-b]  --> [message]
                                 (2)
                                 
Dave

Date: Thu, 01 Mar 2001 10:21:19 -0700
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: UIDs popping up in new-part1

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_4A11E303.8BEADE7E
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I strongly disagree that "nobody uses unique identifiers" or that
"there's no good reason to retain support of them."  And I even=20
more strongly reject the notion that just because it is alleged that no =
one=20
uses them, applications SHOULD reject certificates which disprove=20
the allegation!

I don't want to go into too much detail regarding a usage that would
be proprietary in any case, but we are considering the use of unique
IDs in order to facilitate finding and retrieving the appropriate keys =
in=20
a network-wide context, where the consuming application, the=20
encrypted data (if applicable), and the server on which the key
is stored (in encrypted form) may all be separate, and may tend to=20
migrate apart in a more or less unconstrained fashion.  We observe that
servers are often split due to increased workload, or perhaps merged=20
as servers are replaced with more powerful models, directory information,
including encrypted information is often replicated to other servers, =
but=20
not all servers may have access to the encryption keys (perhaps they=20
are stored on a smart card which is unique to only one server), and=20
 less-often accessed data is frequently migrated to archival media.

These can often be extremely complex issues, sometimes involving
terabytes of information.  The data may be essential to the operation,=20
or it may be important business records that must be preserved for legal
reasons, but are not all that often accessed.  Perhaps the data itself
is migrated to an off-site backup facility, but the key is retained in a =
smart
card.

In any case, the use of unique ID that may include some useful information
as to where the was generated or resides can be extremely helpful, and
yet can be dealt with using a standardized mechanisms that is quite =
compact.

Regards,

Bob

>
>>>> Steve Hanna <[email-masked]> 02/28/01 03:25PM >>>
>Last fall, we agreed to remove issuer and subject unique identifier
>comparison from the validation algorithm. At least, I think we did. The
>argument was that nobody uses unique identifiers and there's no good
>reason to retain support for them.
>
>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
>they remain in step (a) (5) of section 6.1.3, which says:
>
>         (5) The certificate issuer unique identifier is the
>         working_issuer_UID, meaning:
>
>            (i) working_issuer_UID is non-null and matches the value in
>            the issuerUID field, or
>
>            (ii) working_issuer_UID is null and the issuerUID field is
>            not present.
>
>But working_issuer_UID is no longer set anywhere. We should either put
>back the text that initializes and updates this state variable or we
>should change this step so that it doesn't refer to this uninitialized
>varible. I suggest that we remove support for unique identifier chaining
>by changing this step to say:
>
>         (5) The issuerUniqueID and subjectUniqueID fields are not
>         present in the certificate.
>
>This will ensure that compliant implementations will not accidentally
>accept certificates that use these fields, since support for these
>fields is no longer required. I also suggest that we change the sentence
>in section 4.1.2.8 that reads "Applications conforming to this profile
>SHOULD be capable of parsing unique identifiers and making
>comparisons."  to read "Applications conforming to this profile SHOULD
>reject certificates that contain unique identifiers."
>
>-Steve

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software

--=_4A11E303.8BEADE7E
Content-Type: text/x-vcard
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Bob Jueneman.vcf"

--=_4A11E303.8BEADE7E--

Date: Thu, 1 Mar 2001 11:58:00 -0500 (EST)
From: David Kemp <[email-masked]>
Reply-To: David Kemp <[email-masked]>
Subject: Re: Open Issue in Part1: path length constraints
To: [email-masked]
Content-MD5: /ystojI70rJUEsipyoz2LQ==

> Date: Wed, 28 Feb 2001 13:28:46 -0500
> From: Steve Hanna <[email-masked]>
> X-Accept-Language: en
> To: "David P. Kemp" <[email-masked]>
> CC: [email-masked]
> Subject: Re: Open Issue in Part1: path length constraints
> 
> "David P. Kemp" wrote:
> > > From: Steve Hanna <[email-masked]>
> > > I find it odd to say that a certificate with cA=TRUE is a CA certificate
> > > *unless* it is the last certificate in a path. I suppose this is only a
> > > wording problem, but I find this wording *less* clear than the old
> > > wording.
> > 
> > The oddness arises because you are applying the label "CA certificate"
> > to the certificate based on its contents instead of its usage.
> > 
> > If a certificate contains cA=TRUE and
> > keyCertSign=cRLSign=digitalSignature=1, then it can be used for more
> > than one purpose.  It is a CA certificate when validating the signature
> > of a certificate, and it is an EE certificate when validating the
> > signature of a CRL or a message.  (A CA should not use a cert-signing
> > private key to sign correspondence, but X.509 doesn't prohibit unhygenic
> > practices.)
> 
> So you're saying that a certificate with cA=TRUE is an end-entity
> certificate when it appears at the end of a certificate chain and a CA
> certificate otherwise? The same certificate is both a CA certificate and
> an end-entity certificate? This seems to be contrary to the way these
> terms have been used in the past and the way they are used in X.509, RFC
> 2459, new-part1, and throughout the industry.

Steve,

Yes, that's what I'm saying.  If "you" are a CA, and you use the same
private key to sign certificates and to sign email, and you are the
subject of a certificate which has both keyCertSign and digitalSignature
key usage bits, then what kind of certificate is it?

My answer is that it is both.  What is your answer?

Using the same cert for correspondence signatures and certificate
signatures is probably so risky that such certs are not routinely used.
But this discussion is about using the same cert for signing certificates
and for signing CRLs, which is probably standard industry practice.
When validating the signature on a CRL, is the CA's certificate a
CA certificate or an End-Entity certificate?

My answer is that it is the certificate of an entity which has signed
a CRL.  What is your answer?

> I suggest the following:
> 
>    In this case, it gives the maximum number of intermediate CA
>    certificates that may follow this certificate in a certification
>    path. (Note: One final certificate will follow the final intermediate
>    CA certificate in the path. This certificate may be either a CA
>    certificate or an end-entity certificate.) A pathLenConstraint of
>    zero indicates that no intermediate CA certificates may follow in the
>    path. Where it appears, the pathLenConstraint field MUST be greater
>    than or equal to zero. Where pathLenConstraint does not appear, there
>    is no limit to the allowed length of the certification path.

This doesn't answer the question of what to call the final certificate
in the path when that certificate has cA=TRUE and the signature being
verified is that of a CRL or a message.  Which is OK, since it doesn't
make a bit o' difference what you call it as long as it isn't counted in
pathLenConstraint.

The suggestion is OK with me, but it is no less plausible to
call (2) an "end-entity certificate" than it is to call (1) an
"intermediate CA certificate".  (1) is the last CA certificate
in the path, but if you want to call it an intermediate CA, fine.

     [anchor]  --> [CA-a]  --> [CA-b]  --> [Joe User] --> [message]
                                 (1)

     [anchor]  --> [CA-a]  --> [CA-b]  --> [message]
                                 (2)
                                 
Dave

Date: Thu, 1 Mar 2001 10:44:05 -0500 (EST)
From: David Kemp <[email-masked]>
Reply-To: David Kemp <[email-masked]>
Subject: RE: Part1 last call comments
To: [email-masked]
Content-MD5: kIvjC2059j24bj9lQaRcEw==

Hi Jim,

Thanks for pointing out that I misread your proposal, focusing on
the "expires" instead of the "all CRLs".

As long as there is a statement in 2459bis that CRL expiration is a
matter of local policy, and applications MUST make provision for the
fact that the next CRL will not be available precisely at nextUpdate,
then I don't have a problem with your original proposal "until all
existing CRLs expire."  A more precise wording might be "until the
application considers all existing CRLs to have expired", but that
would be redundant if 2459bis contains an unambiguous statement that
different applications *will* have different caching policies (different
definitions of "CRL expiration").

Section 3.3 says: "If a revocation is reported now, that revocation
will not be reliably notified to certificate-using systems until the
next periodic CRL is issued".  In the case where more than one CRL is
in scope for a particular certificate (for example a deltaCRL series
and a less-frequently-issued full CRL series, or overlapping partitions
with different dates), it is again a local application policy whether
to consider its local cache valid until the most fresh source has an
update, until the least fresh source has an update, or even beyond the
point where all sources have had an update (treat a CRL as valid for 24
hours even though a new one was issued after 12 hours).

So "until the next periodic CRL is issued" is correct for applications
which start trying to update their cache at nextUpdate of the freshest
in-scope CLR series.  "...until all currently issued CRLs pass their
next update" is correct for applications which start trying to update
their cache only when the last (least fresh) in-scope CRL passes
nextUpdate.  Note that neither of these statements is correct if CAs
populate nextUpdate with an inaccurate value.

If all applications were configured to require the absolute latest info
(i.e. no application used a CRL cache), then revocation will be
reliably notified even before the next periodic CRL (i.e. if you cache
CRLs exactly as you cache OCSP responses and the CA issues unscheduled
CRLs on revocation events, you will get revocation info from CRLs as
fresh as you would get it from OCSP).

And if some applications are configured to cache CRLs for 24 hours
and the CA issues them every 12 hours, then revocation won't be
reliably notified even after the next periodic CRL is issued.

So the statement in 3.3 doesn't mean much: certificate-using systems
will be reliably notified sooner than, exactly when, or later than
the next periodic in-scope CRL depending on the specific certificate-using
system's caching policy.  PKIX can't require all applications to use
the same caching policy; the freshness/bandwidth/response-time/availability
tradeoffs are different for different certificate-using applications.

In summary, I no longer disagree with what you originally proposed, but
I don't agree with it either, since neither the current wording nor the
proposed change is generally true but each is sometimes true.  Any
statement regarding "reliably notified" must be made within the context
of a specific CRL caching policy.  My goal is to nail down one piece of
jello in this revocation picture:  PKIX CAs MUST populate nextUpdate
with the true time of the next scheduled CRL, and applications have to
handle the propogation/caching/reliance issues.

Regards,
Dave

> > > 4. Section 3.3 - Minor point,  in paragraph 4 - This should be "until
> > > all existing CRLs expires" rather than "until the next periodic CRL
> > > update".  A CRL may be valid for more than one issue period (i.e. issue
> > > every 12 hours, expire after 24 hours).
> >
> > Jim,
> >
> > I disagree with this proposed change.  CRLs do not expire, they only
> > have a next scheduled update date.  As section 3.3 paragraph 3 says,
> > "the meaning of 'suitably-recent' may vary with local policy", and
> > if one local policy says that CRLs which are issued every 12 hours
> > don't expire until 24 hours after issue, fine.  A different local
> > policy, however, might say that the identical CRL expires 13 hours
> > after issue.
> >
> 
> Dave,
> 
> Would the text "until all currently issued CRLs pass their nextUpdate." be
> acceptable to you?  I merely want to reflect that there may be multiple
> valid CRLs in existence, and until all of them have passed their nextUpdate
> time a cached CRL can validly be expected to be used.
> 
> jim

From: "Martin Szotkowski" <[email-masked]>
To: <[email-masked]>
Subject: Problem with certificate validation with CRL?
Date: Thu, 1 Mar 2001 14:14:30 +0100
Organization: PVT, a.s.

Hi all,
we have two root CA keys:
1. CA1 with subject S1, issue certificates C1x and CRL1x from time T1 to T2
(validity of CA1 is from T1 to T3)
2. CA2 with subject S2 (issue C2x and CRL2x) from time T2 to T4 (validity of
CA2 is from T2 to T5)
T1 < T2 < T3 < T4 < T5
S1 != S2
T3 - T2 >= maximum validity of C1x (every issued C1x is always valid in all
validity time of CA1)

**** in time T1-T2 ****
C1x and CRL1x are issued (with CA1)
C1x have CRL Distribution Point CDP1
-- all is OK

**** in T2-T3 ****
C2x and CRL2x are issued (with CA2)
C2x have CDP2
CA1 doesn't issue CRL1x (see below idea 1.)
C2x is OK
-- *but* some C1x are still valid but CDP1 is pointing to *last* CRL1x !?

How can we resolve this problem?

My ideas are these, but I don't know which one is the best / conformable to
RFC

in time T2-T3
1. issue CRL1x with CA1 and CRL2x with CA2
 -- but for this I must issue two CRLs and must keep CA1 private key! - this
is for us unworkable
 -- In our policy is that private key is after T2 destroyed. New CA2 key is
on HW generated.
2. CDP1 == CDP2
  -- this we use, but when is checked validity C1x with CRL2x Internet
Explorer faild! (issuer for C1x and CRL2x is different!) I think, that IE is
right!
  - maybe we need put into C1x CDP1 cRLIssuer and into CRL2x too. But how do
it? (CDP1 must be then different to CDP2). Help this in IE? Is it
implemented in other applications?
3. don't put CDP into all certificates
 -- (:-<)
4. set S1 ==  S2
 -- Does this help us? Will this work; two CAcerts with same subject and
different keys in one CA?
5. some other way

thanks for all advices

Martin
(excuse my easy English)