Subject: Comments on the PKIX Roadmap

From: Denis Pinkas <[email-masked]>
Date: Fri, 29 Oct 1999 15:17:28 +0100

Comments on the PKIX Roadmap <draft-ietf-pkix-roadmap-04.txt>

Here are some comments and change text proposals followed by some
typos (not all !) to prove that I skimmed through the draft. The
problem was to get the time to read it and comment on it. :-)

I would like to mention upfront that the draft is very valuable in
general, in particular for the sections related to the historical
construction and the naming constraints. However, ...  :-)

Page 9:  The text says: 

   Of course, if
   a true non-repudation service is to be provided additional
services
   that prove the data was actually in the possesion of the subject
   requesting the time stamp. So, the [DVCS] draft was developed to
   provide two mechaisms to prove the subject actually possed the
data.
   In addition, [DVCS] provides two additional services: one to
verify
   all signatures attached to the signed document using all
appropriate
   status information and PKCs and one to verify and assert the
validity
   of one or more PKCs at the specified time. Thoughtfully, [DVCS]
   permits the [TSP] protocol to be used as one of the time stamp
   tokens. 

I would propose instead: 

[DVCS] allows to verify and assert the validity of all signatures
attached to the signed document using all appropriate status
information and PKCs or to verify and assert the validity of one or
more PKCs at the specified time. 

Page 9: The text says:"

   [ETNPT] was developed to use [DCVS] to maintain the trust in a
token
   issued by a non-repudiation Trusted Third Party (NR TTP) after
the
   key initially used to establish trust in the token expires.

I would propose instead: 

[ETNPT]was proposed to maintain the trust in a token  issued by a
non-repudiation Trusted Third Party (NR TTP) after the key initially
used to establish trust in the token expires. However, since TSP
provides that service, its goal needs to be clarified.

Page 28: Section 4.5. Change the title into: "Time Stamp Protocols"

Page 39: Section on POP. It should be noticed that POP is NOT always
needed. For some (old) "poorly designed" protocols, POP is needed
when the SAME key is being used for authentication purposes and non
repudiation purposes. Basically, if the protocol makes sure that the
identifier of the public key certificate is protected by the end
user signature, then POP does not need to be performed by the CA.
For the case of encryption, see the proposed text replacement. Here
is a full text replacement for that topic:

5.2 POP

Proof of Possession, or POP, or also CA POP, means that the CA is
adequately convinced that the entity requesting a PKC containing a
public key Y has access to the private key X corresponding to that
public key.

There has been some debate whether POP was or not needed. 

This question needs to be addressed separately considering the
context of use of the key, in particular whether a key is used for
an authentication or non repudiation service, or in a
confidentiality service. Note that this does not map to the key
usage bit directly, since it is possible to use a confidentiality
key to perform an authentication service, e.g. by asking to decrypt
an encrypted challenge.

5.2.1 POP for Signing Keys

Suppose Alice legitimately has private key X and its corresponding
public key Y. Alice has a PKC from Charlie, a CA, containing Y.
Alice uses X to sign a transaction T. Without POP, Mal could also
get a PKC from Charlie containing the same public key, Y. Now, there
are two possible threats: Mal could claim to have been the real
signer of T; or Alice can falsely deny signing T, claiming that it
was instead Mal. Since no one can reliably prove that Mal did or did
not ever possess X, neither of these claims can be refuted, and thus
the service provided by and the confidence in the PKI has been
defeated. (Of course, if Mal really did possess X, Alice's private
key, then no POP mechanism in the world will help, but that is a
different problem.)

Protection can be gained by having Alice, as the true signer of the
transaction, include in the signed information her PKC or an
identifier of her PKC (e.g., a hash of her PKC). This makes
impossible for Mal to claim authorship because he does not know the
private key from Alice and thus is unable to include his certificate
under the signature.

The adequate protection may be obtained in the general case, by
mandating the inclusion of a reference of the certificate every time
a signature (or non repudiation) key is being used in a protocol.

However, because all the protocols were not doing so, a conservative
measure has been taken by requesting POP to be performed by CAs. It
should thus be understood, that this measure is not strictly
necessary and is only a temporary measure to make old protocols
secure. New protocols or data formats are being developed. If the
key being used is always used in a context where the identifier of
the certificate is included in the protocol, then POP by the CA is
not necessary. The inclusion of the identifier of the certificate in
the protocol or data format may be understood as POP being performed
at the transaction time rather than by the CA, at the registration
time of the user in the PKI.

5.2.2 POP for Key Management Keys

Suppose that Al is a new instructor in the Computer Science
Department of a local University. Al has created a draft final exam
for the Introduction to Networking course he is teaching. He wants
to send a copy of the draft final to Dorothy, the Department Head,
for her review prior to giving the exam. This exam will of course be
encrypted, as several students have access to the computer system.
However, a quick search of the PKC repository (e.g., search the
repository for all records with subjectPublicKey=Dorothy's-value)
turns up the fact that several students have PKCs containing the
same public key management key as Dorothy. At this point, if no POP
has been done by the CA, Al has no way of knowing whether all of the
students have simply created these PKCs without knowing the
corresponding private key (and thus it is safe to send the encrypted
exam to Dorothy), or whether the students have somehow acquired
Dorothy's private key (and thus it is certainly not safe to send the
exam). 

The later case may seem unsafe. However, if the other students have
acquired the key, they do not even need to publish their
certificates and can simply decrypt in parallel.

The end story is that, if the key only known to Dorothy, there is no
problem. Thus POP by the CA is not needed. 

If the key, like a Diffie-Hellman key, is used for an authentication
service the answer depends from the protocol being used. In the
former example, the decryption was done locally and no data was sent
back on the wire. In an authentication protocol, the story is
different because either some encrypted or decrypted data is sent
back. If the data sent back contains the identifier of the
certificate in a way that it cannot be modified without that
modification being detected, then there is no need for POP. On the
contrary, POP by the CA is needed.

As a conservative measure, POP for encryption keys is recommended,
but it should be realized that it is not always needed.

In general it should be noticed that POP at the time of the
transaction is much superior than POP made by the CA, since it is
possible in real time to be sure that everything is correct, rather
than rely on that verification to be done at the time of
registration by the CA. Should the CA fail in that verification,
then there is a security breach. On the contrary, doing POP at the
time of the transaction, eliminates that problem.

CMP requires that POP be provided for all keys, either through on-
line or out-of-band means. There are any number of ways to provide
POP, and the choice of which to use is a local matter. Additionally,
a PKC requester can provide POP to either a CA or to an RA, if the
RA can adequately assure the CA that POP has been performed. Some of
the acceptable ways to provide POP include [the following text has
been kept unchanged]:

 - Out-of-band means:

 - For keys generated by the CA or an RA (e.g., on a token such as
   a smart card or PCMCIA card), possession of the token can
   provide adequate proof of possession of the private key.

 - For user-generated keys, another approach can be used in
   environments where "key recovery" requirements force the
   requester to provide a copy of the private key to the CA or an
   RA. In this case, the CA will not issue the requested PKC until
   such time as the requester has provided the private key. This
   approach is in general not recommended, as it is extremely
   risky (e.g., the system designers need to figure out a way to
   protect the private keys from compromise while they are being
   sent to the CA/RA/other authority, and how to protect them
   there), but it can be used.

 - On-line means:

 - For signature keys that are generated by an EE, the requester
   of a PKC can be required to sign some piece of data (typically,
   the PKC request itself) using the private key. The CA will then
   use the requested public key to verify the signature. If the
   signature verification works, the CA can safely conclude that
   the requester had access to the private key. If the signature
   verification process fails, the CA can conclude that the
   requester did not have access to the correct private key, and
   reject the request.

 - For key management keys that are generated by the requester,
   the CA can send the user the requested public key, along with
   the CA's own private key, to encrypt some piece of data, and
   send it to the requester to be decrypted. For example, the CA
   can generate some random challenge, and require some action to
   be taken after decryption (e.g., "decrypt this encrypted random
   number and send it back to me"). If the requester does not take
   the requested action, the CA concludes that the requester did
   not possess the private key, and the PKC is not issued.

Page 42: Section 5.3.1  on the key usage bits. The story about the
digital signature and NR bit is not correct. Setting the NR bit does
NOT means that the Signature bit must be present. [FORMAT] is clear
on that topic. 4 th line from first paragraph. Remove "and/or
nonRepudiation" then after make "bit" singular (i.e. remove the s).

Page 43. In the note in the middle of the page, delete the sentence:
"However, the nonRepudiation key usage bit is provided as an
indicator that such keys should not be used as a component of a
system providing a non-repudiation service."

Page 43. About the discussion, starting with "According to
[SIMONETTI], ..." I would propose a global replacement until the end
of that topic:

" The intent is that the digitalSignature bit should be set when
what is desired is the ability to sign ephemeral transactions; e.g.,
for a single session authentication. These transactions are
"ephemeral" in the sense that they are important only while they are
in existence; after the session is terminated, there is no long-term
record of the digital signature and its properties kept. 

When something is intended to be kept for some period of time for
non repudiation purposes, the nonRepudiation bit shall be set. This
implies that an application will digitally sign something that may
be used for non repudiation purposes; this bit must be turn on. 

A question came whether it was appropriate to turn on both the
signature bit and the NR bit. It is possible to use the same key for
two different purposes, but there is some danger to do so, if it may
exist cases where the protocol invoking the signature key is not
fully known. In such a case, it could happen, that instead of asking
the signature of a challenge, the protocol could ask a signature
over a hash that represents the hash of some transaction. A signer
could then agree on the terms of that transaction, instead of
opening a door which would be the case if the challenge is correctly
signed. In order to avoid this kind of problem, two different keys
are recommended. However, if, when using the same key for two
different purposes, it can be made sure that such misuse of the key
cannot happen, then this is not a problem. Since in many cases, it
is difficult to make the verification and thus get that assurance, a
good practice is to set only one bit at a time and thus use two
different keys."

Page 44. Section 5.4. Trust model. IMO, the approach that is
described is not appropriate. Trust is not related to an entity CA,
but to the trust placed by the EE in the context of an application.
Also there is not ONE trust point necessarily, but several. The
choice is NOT between a TOP CA (which does not necessarily exist)
and the local CA of the EE. The whole section should be changed to
reflect this.

Proposed change :

" An important design decision is which trust pointS for a
particular application should be used by a particular EE. This
decision depends from the context of use, i.e. from the kind of
application being used. For example, in a SET transaction, the bank
sets a single trust point and the end user has no choice about this.
In a different context the user (or a domain administrator) may
select which trust points to use. 

More text might be needed along these lines. 

A few typos (not all):

Page 5: Sercurity
Page 7: refrnce, posess, complimentary.
Page 8: devloped
Page 9: mecaisms , possesion, possed, repudation,  "can produced" to
be replaced by "can be produced"
Page 13: informtoin
Page 21: In the sentence "[TSP] also defines" replace "defines" by
"defined".
Page 25: "Diffie-Hellman a key" to be replaced by "a Diffie-Hellman
key"

---

From: Ed Gerck <[email-masked]>
Date: Sat, 30 Oct 1999 01:42:31 -0700

> Comments on the PKIX Roadmap <draft-ietf-pkix-roadmap-04.txt>

Dennis:

The PKIX roadmap is a very creative document. In fact, there is
little resemblance between its contents and the past
messages/consensus in this WG.

> record of the digital signature and its properties kept.

The ability to sign ephemeral transactions e.g., single session
authentication has to do with the *authenticated connection*
not with a *signed object* (the certificate) -- so, it is rather easy
to distinguish the DS bit in either case.  There is no need to
yet again redefine non-repudiation as a "non-ephemeral digital

>be used for non repudiation purposes; this bit must be turn on.

The new confusion introduced by your text (and the roadmap)  is
that non-repudiation has now nothing to do with "preventing the
denial of a previous act" (HAC, Menezes) or even with "protecting
against falsely denying an act" (RFC 2459) but with the *lifetime*
of a digital signature.  Hmmmm... this was never mentioned
in this WG and is clearly a redundant definition -- so, why
have it? To avoid the issue?

Or, perhaps there are those that now say the WG consensus on
NR was "wrong"?  Perhaps, but this should be decided in this list,
not in the roadmap text and not in a redundant definition of
lifetime.

I also note for the record that accepting this would mean to negate the
IETF decision process, which I think is even worse than confusing
"non-repudiation" with lifetime.  Thus, in the best spirit of the Internet
of routing around the damage, I ask for a recall of the roadmap as it is
and for a reinstatement of what was discussed and decided here.
Otherwise, in the future, someone will say "but, there is precedent for
this behavior" and we will have no more roads but just slippery
slopes to map, I am afraid.

Cheers,

Ed Gerck

---

From: Alfred Arsenault <[email-masked]>
Date: Sat, 30 Oct 1999 10:51:32 -0400

Ed,

	What was the "consensus" of this WG on the meaning of
"non-repudiation"?  I've looked back yet again at all of the messages,
and I can find no consensus.  I can find only several different groups
of people holding different ideas of what it means, or should mean, or
ought to mean but maybe doesn't, or...

	My interpretation of when the NR discussions stopped is that it wasn't
because the WG reached consensus, it was because a number of the
participants just stopped trying to make the same point/argue against
the same point over and over and over ... 

	I'll ask the working group chairs to bring this up in Washington.  The
Roadmap (and other WG documents, but especially the Roadmap, because of
its purpose) should reflect the consensus of the WG on its major
issues.  It should not be "creative" nor contradictory, nor should it
reflect the views of just its authors unless those are explicitly
identified as such.  

	(Please note:  I'm leaving for the airport in about 30 minutes; I'll
most likely be away from e-mail access for the next nine days.  Please
don't interpret my silence/non-participation in discussions of this
between now and then as agreeing to or disagreeing with any stated
position.)

			Al Arsenault

--- This posting represents the opinions of the author only, and may or
may not reflect the views of his employer or of any other organization
with which he may have a relationship.

---

From: Ed Gerck <[email-masked]>
Date: Sun, 31 Oct 1999 00:59:24 -0700

Alfred Arsenault wrote:

> "non-repudiation"?

Wading through the messages in the archives it is possible to see that this
WG reached clear consensus on several NR items. For example, that NR is
not simply the setting of a bit -- in fact, this WG's  *unanimity* (!!) on NR was
that setting the NR-bit is neither necessary nor sufficient to define the
provision of NR services.

Based on this 100% consensual understanding,  this WG considered various
possibilities for defining the provision of NR services in a technical protocol,
and several clearly distinct modes of NR emerged -- I counted four main modes
(see archives).  Some of these NR modes were detailed in an effort by Tom Gindin
....that  is not even  *cited* in the roadmap .... with a proposed RFC... but which
was nonetheless extensively discussed in this WG and is archived at the IETF.
Can we NR that RFC? ;-))

Thus, reading the roadmap I felt a warp effect --  how could the roadmap ignore
these points of consensus and actions including a proposed RFC and, instead,
come up with an equivalence between NR and lifetime which was not discussed
at all? And, which is 100% redundant with the notion of lifetime itself -- after all,
if we want to signal a short lifetime there is a very well defined field for this in
PKIX that has nothing to do with NR.  Besides, the roadmap confused
"authenticated connection" (which authentication is ephemeral by definition and
lasts as long as the connection itself) with "signed object" (a certificate) which
can last much longer than even its signature lifetime (when providing support
for signature verification as in... NR ).

There are other problems with the new roadmap (see my previous msgs) and problems
which I did not address either --- and which IMO seriously undermine its usefulness
to reflect what this WG discussed and what the protocols are for.  Two of its key
purposes -- and that is why I suggested it should be recalled and redone.  It may be
that the new PKIX roadmap  "captured the WG's feelings from around mid '98
timeframe" as Sean Turner has mentioned today in this list -- but, aren't we
around end '99 timeframe?

Cheers,

Ed Gerck

Date: Sun, 31 Oct 1999 00:59:24 -0700
From: Ed Gerck <[email-masked]>
To: Alfred Arsenault <[email-masked]>
CC: IETF-PXIX <[email-masked]>, Sean Turner <[email-masked]>
Subject: Re: lifetime versus NR, Re: Comments on the PKIX Roadmap

Alfred Arsenault wrote:

> "non-repudiation"?

Wading through the messages in the archives it is possible to see that this
WG reached clear consensus on several NR items. For example, that NR is
not simply the setting of a bit -- in fact, this WG's  *unanimity* (!!) on NR was
that setting the NR-bit is neither necessary nor sufficient to define the
provision of NR services.

Based on this 100% consensual understanding,  this WG considered various
possibilities for defining the provision of NR services in a technical protocol,
and several clearly distinct modes of NR emerged -- I counted four main modes
(see archives).  Some of these NR modes were detailed in an effort by Tom Gindin
....that  is not even  *cited* in the roadmap .... with a proposed RFC... but which
was nonetheless extensively discussed in this WG and is archived at the IETF.
Can we NR that RFC? ;-))

Thus, reading the roadmap I felt a warp effect --  how could the roadmap ignore
these points of consensus and actions including a proposed RFC and, instead,
come up with an equivalence between NR and lifetime which was not discussed
at all? And, which is 100% redundant with the notion of lifetime itself -- after all,
if we want to signal a short lifetime there is a very well defined field for this in
PKIX that has nothing to do with NR.  Besides, the roadmap confused
"authenticated connection" (which authentication is ephemeral by definition and
lasts as long as the connection itself) with "signed object" (a certificate) which
can last much longer than even its signature lifetime (when providing support
for signature verification as in... NR ).

There are other problems with the new roadmap (see my previous msgs) and problems
which I did not address either --- and which IMO seriously undermine its usefulness
to reflect what this WG discussed and what the protocols are for.  Two of its key
purposes -- and that is why I suggested it should be recalled and redone.  It may be
that the new PKIX roadmap  "captured the WG's feelings from around mid '98
timeframe" as Sean Turner has mentioned today in this list -- but, aren't we
around end '99 timeframe?

Cheers,

Ed Gerck

Date: Sat, 30 Oct 1999 15:00:52 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: "Stephen Farrell (Baltimore)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: LAAP performance issues

The model in the draft doesn't explicitly restrict the model to be for
the
"never revoke" method in draft-ietf-pkix-ac509prof-01.txt.  Should we
add a new
request and response to support revocation or was it intended to use
OCSP to get
revocation information?

Cheers,

spt

Andy Dowling wrote:

> Hi Stephen, David
>
> some suggestions on LAAP performance:
>
> 1. Batch LAAP requests. Perhaps the LAAPRequestMessage could be replaced
> with
>     a SEQUENCE of LAAPRequestMessage, so that a LRQ could request multiple
> ACs
>     with a single LAAP request? (The LRP would evaluate each
> LAAPRequestMessage
>     in the SEQUENCE individually). This could result in a saving of network
> bandwidth in
>     cases where a large volume of ACs is to be pulled over LAAP.
>
> 2.  Support for a "keep-alive" TCP connection between LRQ and LRP.
>      One problem with this is that, at the socket layer, some LRP
> implementations may
>      timeout the socket after a couple of minutes of inactivity. Perhaps the
> use of a "null"
>      LAAP request could be used in order for the LRQ to force the connection
> to stay
>      alive at the socket layer. This seems like a strange idea, 'cos if the
> LRP supports
>      keep-alives then the LRP will set the to infinite lifetime anyway.
> Nonetheless, comments
>      on this would be appreciated....
>
> Thanks,
>
> Andy
>
> -----
> Andy Dowling
> SSE (A Siemens Company)
> Fitzwilliam Court, Leeson Close,
> Dublin 2, Ireland
>
> E-Mail:  [email-masked]
> Web: http://www.sse.ie
> Phone: +353 1 216 2021
> Fax:   +353 1 216 2082

Date: Sat, 30 Oct 1999 16:17:11 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: PKIX <[email-masked]>
Subject: Comments on draft-ietf-pkix-ac509prof-01.txt

Just a few comments/questions:

1. Can we add the text AA CA to the terminology section?  It is used in
section 5 and I think is pretty import.  Some suggested text (feel free
to modify it as you see fit): "AA CA  A CA that issues a PKC to an AA
indicating that it is allowed to issue ACs."

2. Clause 4.3.8 (issuerUniqueId) says: "This field MUST NOT be used."
shouldn't it be changed to say: "This field MUST be populated if the
AA's PKC includes the issuerUniqueId field.  Otherwise, this field MUST
NOT be used."  RFC2459 recommends that they not be included, but it
doesn't prohibit them.  In the case issuerUniqueIdentifier is present in
the AA's PKC, AC validation should check that they are present and both
match.

3. I think the first bullet in 5 (Attribute Certificate Validation)
should be changed to say: "The AC signature must be cryptographically
correct and the AC issuer's entire certification path (including the AC
issuer's PKC) MUST be verified in accordance with [RFC2459]."  On first
reading I wasn't sure that you only had to check the signature on the
issuer's PKC or the entire certificate path.  I think it's better to be
explicit.

4. Should we add a new "MUST satisfy" bullet in 5 that says: "The AC
issuer's distinguished name in issuerName.GeneralNames must match the
name in the AC issuer's PKC issuer field."  Or do you implicitly get
that check from checking the signature on the AC?

5. Right be the additional certification path checks in clause 5 there's
a parenthetical that should refer to (3) vice (2).

6.  Where is the format for the AC revocation list?  Are the revoked ACs
going to be put on the CRL or in some AC specific revocation list?

Thanks,

spt

Date: Sat, 30 Oct 1999 14:51:32 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: PKIX <[email-masked]>
Subject: Comments on draft-ietf-pkix-ldap-v3-01.txt

After thinking about the draft a bit I'd like to suggest a few
modifications (mostly organizational).

The draft includes both the protocol and schema issues to deal with
LDAPv3 servers.  I think we should split the two topics as the draft is
called "operational protocols".  I think the draft should just talk
about the protocol issues and not the schema.  My suggestion is to
update RFC 2587 (Internet X.509 Public Key Infrastructure LDAPv2 Schema)
to include the attribute and object classes required to support
attribute certificate users.  Then the LDAPv2 schema could support
storing the attribute certificate related information.  Another draft
should be spawned to include specific LDAPv3 schema issues such support
for matching rules, etc.

There is support for the pmiUser but where are the attribute authority's
certificates stored?  Should we define an pmiAA (name to be determined)
object class to support storing of the attribute certificate for the AA?

Also, which revocation list includes the revoked attribute
certificates?  I assumed it would be stored in a separate attribute
certificate revocation list, but the draft is silent on the issue (so is
draft-ietf-pkix-ac509prof-01.txt).

Thanks,

spt

Date: Sat, 30 Oct 1999 14:02:39 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: GMT <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: TYPO in Roadmap-04 re BERT

Todd,

I'm working on another version.  I will wait to send in the next version of the
roadmap after you've submitted the new bert draft so I can get it right.  Sorry
for the confusion.

spt

GMT wrote:

> FYI  All - BERT is not dead. The concluding statement in the PKI Roadmap is
> incorrect here.
>
> The BERT Token Specification is undergoing a redesign to allow it to support
> virtually any kind of event representation. It also will have a predefined
> set of event types including a Notarial Subtoken complete with a
> ceremony-service marker. The token structure will represent a digital
> harness with an encoded and protected manifest. This will allow the modular
> plugging in of a number of optional token components to create an
> interoperable policy centric token. - the ultimate timestamp so to speak -
>
> Anyway, the new token structure will also have an applications and Network
> transparent API to address the marking, validating, and verifying of
> virtually all events in time and space. We feel this is the start of "agency
> control" and conveyance models and that they will operate  by demonstrating
> the intent of the user. These token data structures and the API for managing
> them are very important to eCommerce and will be of more important to PKIX
> as the evolution of the Internet and Global ECommerce continues.
>
> The currently underway draft will not make this meeting but will be filed
> shortly afterward and will be available for comment as such prior to the
> next meeting.
>
> If I can answer any questions in the mean time please feel free to contact
> me or Michael directly
>
> [email-masked]
> [email-masked]
>
> Todd Glassey
>
> > Todd:
> >
> > Here's the BERT excerpt from the roadmap, published Oct 22...note the
> > status at the end.
> >
> >    DOCUMENT TITLE: Basic Event Representation Token <draft-ietf-pkix-
> >    bert1-01.txt>
> >
> >    DESCRIPTION: This document defines a finite method of representing a
> >    discrete instant in time as a referable event. The Basic Event
> >    Representation Token (BERT) is a light-weight binary token designed
> >    for use in large numbers over short periods of time. The tokens
> >    contain only a single instance of an event stamp and the trust
> >    process is referenced against an external reference.
> >
> >    STATUS: Work has been discontinued.
> >
> >

Date: Sat, 30 Oct 1999 14:02:39 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: GMT <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: TYPO in Roadmap-04 re BERT

Todd,

I'm working on another version.  I will wait to send in the next version of the
roadmap after you've submitted the new bert draft so I can get it right.  Sorry
for the confusion.

spt

GMT wrote:

> FYI  All - BERT is not dead. The concluding statement in the PKI Roadmap is
> incorrect here.
>
> The BERT Token Specification is undergoing a redesign to allow it to support
> virtually any kind of event representation. It also will have a predefined
> set of event types including a Notarial Subtoken complete with a
> ceremony-service marker. The token structure will represent a digital
> harness with an encoded and protected manifest. This will allow the modular
> plugging in of a number of optional token components to create an
> interoperable policy centric token. - the ultimate timestamp so to speak -
>
> Anyway, the new token structure will also have an applications and Network
> transparent API to address the marking, validating, and verifying of
> virtually all events in time and space. We feel this is the start of "agency
> control" and conveyance models and that they will operate  by demonstrating
> the intent of the user. These token data structures and the API for managing
> them are very important to eCommerce and will be of more important to PKIX
> as the evolution of the Internet and Global ECommerce continues.
>
> The currently underway draft will not make this meeting but will be filed
> shortly afterward and will be available for comment as such prior to the
> next meeting.
>
> If I can answer any questions in the mean time please feel free to contact
> me or Michael directly
>
> [email-masked]
> [email-masked]
>
> Todd Glassey
>
> > Todd:
> >
> > Here's the BERT excerpt from the roadmap, published Oct 22...note the
> > status at the end.
> >
> >    DOCUMENT TITLE: Basic Event Representation Token <draft-ietf-pkix-
> >    bert1-01.txt>
> >
> >    DESCRIPTION: This document defines a finite method of representing a
> >    discrete instant in time as a referable event. The Basic Event
> >    Representation Token (BERT) is a light-weight binary token designed
> >    for use in large numbers over short periods of time. The tokens
> >    contain only a single instance of an event stamp and the trust
> >    process is referenced against an external reference.
> >
> >    STATUS: Work has been discontinued.
> >
> >

Date: Sat, 30 Oct 1999 13:53:14 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: Ed Gerck <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-roadmap-04.txt

Ed,

Thanks for taking the time to review the document and sorry it took me so long to get to this
message.  That section hasn't changed since the first draft (draft-ietf-pkix-roadmap-01.txt).
Clearly there's been more discussion on the list and it needs to be updated.  But, I think it
captured the WG's feelings from around mid '98 timeframe.

spt

Ed Gerck wrote:

> [email-masked] wrote:
>
> > 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 PKIX Roadmap
> >         Author(s)       : A. Arsenault, S. Turner
> >         Filename        : draft-ietf-pkix-roadmap-04.txt
> >         Pages           : 40
> >         Date            : 22-Oct-99
>
> >From the above draft:
>
>    According to [SIMONETTI], the intent is that the digitalSignature bit
>    should be set when what is desired is the ability to sign ephemeral
>    transactions; e.g., for a single session authentication. These
>    transactions are "ephemeral" in the sense that they are important
>    only while they are in existence; after the session is terminated,
>    there is no long-term record of the digital signature and its
>    properties kept. When something is intended to be kept for some
>    period of time, the nonRepudiation bit should be set.
>
> The last phrase finds no support on what was discussed in this WG,
> non-repudiation is not a non-ephemeral digital signature.
>
> There are also other instances where the draft finds no support in
> the WG discussions, even when it says it has:
>
>     The discussion on the PKIX mailing list has centered on the
>    digitalSignature bit and the nonRepudiation bit. The question has
>    come down to something like: When support for the service of non-
>    repudiation is desired, should both the digitalSignature and
>    nonRepudiation bits be set, or just the nonRepudiation bit?
>
> because this question was neither substantive nor representative
> of the discussions -- unless "has come down to" means something
> else.
>
> Cheers,
>
> Ed Gerck

Date: Sat, 30 Oct 1999 10:51:32 -0400
From: Alfred Arsenault <[email-masked]>
Organization: @Home Network
To: Ed Gerck <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: Re: lifetime versus NR, Re: Comments on the PKIX Roadmap

Ed,

			Al Arsenault

> slopes to map, I am afraid.

From: "Anders Rundgren" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>, "'SEIS-List'" <[email-masked]>
Cc: "Magnus (RSA)" <[email-masked]>
Subject: QC comparisons are DEADLY serious!
Date: Sat, 30 Oct 1999 15:20:01 +0100

Stefan, 

I strongly disagree on your conclusions regarding certificate comparisons. 
Rather, I consider the possibility to compare certificates from a certain issuer and CPS 
to be a major "quality" property that deserves a section of its own. 

To give an example. If you have a QC issued by a TTP (ID-certificates that 
will only be used within the issuer's own domain are pretty uninteresting) and 
your bank accepts that certificate in conjunction with its Internet-bank it 
is VERY interesting for BOTH the bank (RP) and for the customer (Subscriber) 
to know what will happen the day you log in with a renewed certificate. 
IN ADVANCE. 

So what you describe as a "minor issue" is for some people a FUNDAMENTAL 
ISSUE that the QC draft IMLHO must address in much more serious way than in V02. 

Anders

-----Original Message-----
From: Stefan Santesson <[email-masked]>
To: Anders Rundgren <[email-masked]>; 'SEIS-List' <[email-masked]>; [email-masked] <[email-masked]>
Date: Friday, October 29, 1999 23:09
Subject: SEIS: Re: QC certificates MAY CERTAINLY be compared!

>--- Message on the SEIS mailing list ([email-masked])
>
>Anders,
>
>Thank you, I have noticed your comment.
>
>The security considerations section contains CONSIDERATIONS for the general
>case and I still believe in the intent behind this sentence, as a good
>general guidance to implementations. 
>
>Setting up implementations with the intent to compare two qualified
>certificates to see if they represent the same person IS generally a bad
>service that shouldn't be performed. Since in the general case, you will
>have clear risk of misleading results.
>
>Well, if you leave the general case and go into speciffic cases such as
>comparing SEIS certificates within a local region (such as Sweden), then
>there will allways be cases where some security considerations does not
>apply (such as this particular one).
>
>I think this is a minor issue within the security consideration section
>which does not affect the implementation of the profile. Shure there are an
>even better way of expressing the original intent behind that sentence. But
>on the other hand,  there will allways be a better way of everything.
>
>I think the present description is good enough. Can you live with it ?
>
>/Stefan
>
>At 17:55 1999-10-25 +0100, Anders Rundgren wrote:
>>Stefan,
>>I have said it before and I say it again.  The following QC-statement is 
>>higly doubtful:
>>
>>"Comparing two qualified certificates to determine if they represent
>> the same physical entity may provide misleading results and should
>> not be performed"
>>
>>As you know our famous (?) SEIS-card does indeed allow certificates to
>>be compared for subject identity.   That is IMO the whole (and only) point 
>>with *real* ID-cards!
>>
>>So this is a statement of the CPS.  Not of the draft.
>>
>>
>>
>>BTW, why no explicit support for "container ID" (card serial) as most QCs 
>>will be
>>put in smart cards?  It was in SEIS already.
>>
>>
>>Anders
>>
>>
>>-----Original Message-----
>>From: Stefan Santesson <[email-masked]>
>>To: [email-masked] <[email-masked]>
>>Date: Monday, October 25, 1999 14:14
>>Subject: New submitted draft for Qualified Certificates
>>
>>
>>>All,
>>>
>>>A new draft for a Qualified Certificates Profile was submitted friday 22.
>>>
>>>The new draft can be obtained from:
>>>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>>>
>>>The QC website has been udated accrodingly:
>>>http://www.accurata.se/QC/
>>>
>>>See also under settled topics to obtain information about major
>>>considerations since the last draft.
>>>
>>>/Stefan
>>>-------------------------------------------------------------------
>>>Stefan Santesson                <[email-masked]>
>>>Accurata AB                     http://www.accurata.se
>>>Slagthuset                      Tel. +46-40 108588              
>>>211 20  Malmö                   Fax. +46-40 150790              
>>>Sweden                        Mobile +46-70 5247799
>>>
>>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>>-------------------------------------------------------------------
>>> 
>
>
>----------------- SEIS mailing list ([email-masked])
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: [email-masked]
>
>

Date: Sat, 30 Oct 1999 01:42:31 -0700
From: Ed Gerck <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: lifetime versus NR, Re: Comments on the PKIX Roadmap

Dennis:

Cheers,

Ed Gerck

Date: Fri, 29 Oct 1999 16:41:23 -0700
To: Tony Bartoletti <[email-masked]>, [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Y2K, RFC 2459, . . .

Um, why is any of this relevant in the PKIX WG? I don't see any PKI issues 
here...

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 29 Oct 1999 16:31:32 -0700
To: [email-masked], [email-masked]
From: Tony Bartoletti <[email-masked]>
Subject: Re: Y2K, RFC 2459, . . .

I believe the rules for "leap year" adjustments are as follows:

  A leap-day is added every year divisible by 4,
    EXCEPT if year is divisible by 100 (no leap-day added)
	UNLESS year is divisible by 400 (ordinary leap-day added).

So, the year 2000 is an ordinary leap year, being divisible by 400.

___tony___

At 06:06 PM 10/29/99 EDT, [email-masked] wrote:
>Reading, w/out having kept up to date w/ISO issues . . . 
>I've have been watching for, and not seeing comments addressing the 
>requirement of our calendar to add an extra Leap Day after the year 2000.
>
>As I recall, the calendar we have was designed to best keep accurate with the 
>sun, and requires a leap day every 4 yrs.  This schedule, also, calls for and 
>additional day every 1000 years.  The intent was to add it after the 
>millennium.  As the calendar truly recognizes the year 2000 as the last year 
>in this millennium, it seems that we were to add an additional day during the 
>1st year of the next millennium, 2001.
>
>Where is this issue being addressed?  Or, has this path been abandoned by all 
>parties concerned.  (Initially, the entire Christian world . . . perhaps only 
>the Catholic churches.)
>
>

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

From: [email-masked]
Date: Fri, 29 Oct 1999 18:06:43 EDT
Subject: Y2K, RFC 2459, . . .
To: [email-masked]

Reading, w/out having kept up to date w/ISO issues . . . 
I've have been watching for, and not seeing comments addressing the 
requirement of our calendar to add an extra Leap Day after the year 2000.

As I recall, the calendar we have was designed to best keep accurate with the 
sun, and requires a leap day every 4 yrs.  This schedule, also, calls for and 
additional day every 1000 years.  The intent was to add it after the 
millennium.  As the calendar truly recognizes the year 2000 as the last year 
in this millennium, it seems that we were to add an additional day during the 
1st year of the next millennium, 2001.

Where is this issue being addressed?  Or, has this path been abandoned by all 
parties concerned.  (Initially, the entire Christian world . . . perhaps only 
the Catholic churches.)

Date: Sat, 30 Oct 1999 00:01:27 +0200
To: "Anders Rundgren" <[email-masked]>, "'SEIS-List'" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: QC certificates MAY CERTAINLY be compared!

Anders,

Thank you, I have noticed your comment.

The security considerations section contains CONSIDERATIONS for the general
case and I still believe in the intent behind this sentence, as a good
general guidance to implementations. 

Setting up implementations with the intent to compare two qualified
certificates to see if they represent the same person IS generally a bad
service that shouldn't be performed. Since in the general case, you will
have clear risk of misleading results.

Well, if you leave the general case and go into speciffic cases such as
comparing SEIS certificates within a local region (such as Sweden), then
there will allways be cases where some security considerations does not
apply (such as this particular one).

I think this is a minor issue within the security consideration section
which does not affect the implementation of the profile. Shure there are an
even better way of expressing the original intent behind that sentence. But
on the other hand,  there will allways be a better way of everything.

I think the present description is good enough. Can you live with it ?

/Stefan

At 17:55 1999-10-25 +0100, Anders Rundgren wrote:
>Stefan,
>I have said it before and I say it again.  The following QC-statement is 
>higly doubtful:
>
>"Comparing two qualified certificates to determine if they represent
> the same physical entity may provide misleading results and should
> not be performed"
>
>As you know our famous (?) SEIS-card does indeed allow certificates to
>be compared for subject identity.   That is IMO the whole (and only) point 
>with *real* ID-cards!
>
>So this is a statement of the CPS.  Not of the draft.
>
>
>
>BTW, why no explicit support for "container ID" (card serial) as most QCs 
>will be
>put in smart cards?  It was in SEIS already.
>
>
>Anders
>
>
>-----Original Message-----
>From: Stefan Santesson <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Monday, October 25, 1999 14:14
>Subject: New submitted draft for Qualified Certificates
>
>
>>All,
>>
>>A new draft for a Qualified Certificates Profile was submitted friday 22.
>>
>>The new draft can be obtained from:
>>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>>
>>The QC website has been udated accrodingly:
>>http://www.accurata.se/QC/
>>
>>See also under settled topics to obtain information about major
>>considerations since the last draft.
>>
>>/Stefan
>>-------------------------------------------------------------------
>>Stefan Santesson                <[email-masked]>
>>Accurata AB                     http://www.accurata.se
>>Slagthuset                      Tel. +46-40 108588              
>>211 20  Malmö                   Fax. +46-40 150790              
>>Sweden                        Mobile +46-70 5247799
>>
>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>-------------------------------------------------------------------
>> 

Date: Fri, 29 Oct 1999 23:20:25 +0200
To: Russ Housley <[email-masked]>, [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: Re: QC certificates and Nationality
Cc: "'SEIS-List'" <[email-masked]>

You can store as many citizenship countries as you like (in the personal data
field).

3.2.1 states:

   The countryOfCitizenship attribute SHALL, when present, contain the
   identifier of at least one of the subject's claimed country of
   citizenship at the time that the certificate was issued. If the
   subject is a citizen of more than one country, more than one country
   MAY be present. Determination of citizenship is a matter of law and
   is outside the scope of this document.

At 16:40 1999-10-27 -0500, you wrote:
>What goes into the QC when a person is a citizen of more than one country?
>
>Russ

Date: Fri, 29 Oct 1999 15:39:29 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: draft-ietf-pkix-ipki-ecdsa-02.txt
Cc: [email-masked]

In addition, since the support for ECC based key agreement and key
transport are being profiled under the S/MIME Mail Security Working Group,
should not the specification for these keys also be folded into the updated
RFC 2459?

François 

At 11:44 AM 27/10/99 -0500, you wrote:
>Given that RFC 2459 must be updated, I suggest that these specification be 
>folded into the updated RFC 2459. I do not think that a separate document 
>adds value.
>
>Russ
>
[snip]

Date: Fri, 29 Oct 1999 15:17:28 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Comments on the PKIX Roadmap

Page 9:  The text says: 

   Of course, if

I would propose instead: 

Page 9: The text says:"

I would propose instead: 

5.2 POP

 - Out-of-band means:

 - On-line means:

Proposed change :

A few typos (not all):

Page 5: Sercurity

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-qc-02.txt
Date: Fri, 29 Oct 1999 07:43:02 -0400
Sender: [email-masked]

--NextPart

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

	Title           : Internet X.509 Public Key Infrastructure
			  Qualified Certificates
	Author(s)	: S. Santesson, W. Polk, P. Barzin, M. Nystrom
	Filename	: draft-ietf-pkix-qc-02.txt
	Pages		: 35
	Date		: 27-Oct-99
	
This document forms a certificate profile for Qualified Certificates,
based on RFC 2459, for use in the Internet. The term Qualified
Certificate is used to describe a certificate with a certain
qualified status within applicable governing law. Further, Qualified
Certificates are issued exclusively to physical persons represented
by a registered unmistakable identity.

The goal of this document is to define a general syntax independent
of local legal requirements. The profile is however designed to allow
further profiling in order to meet specific local needs.

It is important to note that the profile does not define any legal
requirements for Qualified Certificates.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-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-qc-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-qc-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-qc-02.txt

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

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

--OtherAccess--

--NextPart--

From: "Andy Dowling" <[email-masked]>
To: "Stephen Farrell (Baltimore)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: LAAP performance issues
Date: Fri, 29 Oct 1999 09:16:59 +0100

Hi Stephen, David

some suggestions on LAAP performance:

1. Batch LAAP requests. Perhaps the LAAPRequestMessage could be replaced
with
    a SEQUENCE of LAAPRequestMessage, so that a LRQ could request multiple
ACs
    with a single LAAP request? (The LRP would evaluate each
LAAPRequestMessage
    in the SEQUENCE individually). This could result in a saving of network
bandwidth in
    cases where a large volume of ACs is to be pulled over LAAP.

2.  Support for a "keep-alive" TCP connection between LRQ and LRP.
     One problem with this is that, at the socket layer, some LRP
implementations may
     timeout the socket after a couple of minutes of inactivity. Perhaps the
use of a "null"
     LAAP request could be used in order for the LRQ to force the connection
to stay
     alive at the socket layer. This seems like a strange idea, 'cos if the
LRP supports
     keep-alives then the LRP will set the to infinite lifetime anyway.
Nonetheless, comments
     on this would be appreciated....

Thanks,

Andy

-----
Andy Dowling
SSE (A Siemens Company)
Fitzwilliam Court, Leeson Close,
Dublin 2, Ireland

E-Mail:  [email-masked]
Web: http://www.sse.ie
Phone: +353 1 216 2021
Fax:   +353 1 216 2082

From: Alex Deacon <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: DisplayText for Verisign Certificate
Date: Thu, 28 Oct 1999 18:06:18 -0700

FYI,

It looks like the proposed son-of-rfc2459 draft
(draft-ietf-pkix-new-part1-00.txt) has addressed this issue by adding
IA5String as an additional CHOICE for DisplayText.

Alex

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, October 16, 1999 1:29 AM
> To: [email-masked]
> Subject: Re: DisplayText for Verisign Certificate
> 
> 
> "Amit Kapoor" <[email-masked]> writes:
> 
> >While working with Bob Jueneman on some S/MIME certificate 
> issues we ran 
> >into the following with a Verisign issued certificate:
> >
> >The portion of ASN.1 dump showing the problem:
> >
> >Verisign is encoding the DisplayText as IA5 whereas 
> according to 2459 it can 
> >be one of Visible, BMP or UTF8 string.
> >
> >Should we add IA5String to the choice list of DisplayText or 
> treat this as a 
> >error and not support the Verisign certificates?
> 
> This was quietly changed between the final draft and the RFC, 
> as a result of 
> this some implementations expect one and some expect the other.  The 
> workaround I've got in my code is:
> 
> /* All draft versions of the PKIX profile had the organization as an
>    IA5String, but the final RFC changed it to a 
> VisibleString, in order
>    to kludge around this for the certs which use an IA5String 
> (which in
>    practice means only Verisign, since noone else uses seems 
> to use policy
>    qualifiers), we allow both types but put the VisibleString option
>    first which means it'll get used preferentially when encoding */
> 
> The code comment explains why it appears to be a Verisign bug 
> (but isn't), 
> noone else seems to use qualifiers so you won't see it 
> anywhere else, and 
> what Verisign were doing was correct at the time they did it. 
>  I should 
> really put this in the style guide.
> 
> Peter.
> 

From: Michael Myers <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, [email-masked]
Subject: RE: New draft - NULL Public Key Signatures
Date: Thu, 28 Oct 1999 14:08:57 -0700

Ambarish,

That's what I'd concluded from reading the draft, but I wanted to ask to be
certain.

Mike

> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Thursday, October 28, 1999 11:19 AM
> To: Michael Myers; Ambarish Malpani; [email-masked]
> Subject: RE: New draft - NULL Public Key Signatures
> 
> 
> 
> Hi Mike,
>     Good question.
> 
> Actually, if you read the draft, you actually might be able to
> figure out that it is independent of X.509 or other certificates.
> Just as RSA can work fine with any format of certification.
> 
> But still, a very good question.
> 
> Regards,
> Ambarish
> 
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 
> > -----Original Message-----
> > From: Michael Myers [mailto:[email-masked]]
> > Sent: Thursday, October 28, 1999 9:08 AM
> > To: Ambarish Malpani; [email-masked]
> > Subject: RE: New draft - NULL Public Key Signatures
> > 
> > 
> > Ambarish,
> > 
> > Does this proposal require X.509 certificates?  Or is it the 
> > case that the
> > draft, when finalized, will propose a non-X.509 approach to 
> public key
> > management?
> > 
> > Mike
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Ambarish Malpani [mailto:[email-masked]]
> > > Sent: Tuesday, October 19, 1999 4:16 PM
> > > To: [email-masked]
> > > Subject: New draft - NULL Public Key Signatures
> > > 
> > > 
> > > 
> > > Hi Guys,
> > >     Given the traffic on this list, it sounds like this IETF is
> > > going to be a pretty boring one. :-)
> > > 
> > > I have just submitted an individual draft about NULL Public Key
> > > Signatures, which I hope will be part of this working group soon
> > > (make things at the PKIX meeting more interesting).
> > > 
> > > The main (serious) reason for this draft, is to allow people to
> > > describe data items that may be signed or unsigned more easily
> > > in ASN.1.
> > > 
> > > Also, having a NULL algorithm is asthetically pleasing.
> > > 
> > > So here it is.
> > > 
> > > Please send all your flames/comments to this list.
> > > 
> > > Thanks,
> > > Ambarish
> > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > Ambarish Malpani
> > > Architect                                                
> > 650.567.5457
> > > ValiCert, Inc.                                  
> > [email-masked]
> > > 1215 Terra Bella Ave.                         
> http://www.valicert.com
> > Mountain View, CA 94043-1833
> > 
> > 
> 

From: Ambarish Malpani <[email-masked]>
To: Michael Myers <[email-masked]>, Ambarish Malpani <[email-masked]>, [email-masked]
Subject: RE: New draft - NULL Public Key Signatures
Date: Thu, 28 Oct 1999 11:19:14 -0700

Hi Mike,
    Good question.

Actually, if you read the draft, you actually might be able to
figure out that it is independent of X.509 or other certificates.
Just as RSA can work fine with any format of certification.

But still, a very good question.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Thursday, October 28, 1999 9:08 AM
> To: Ambarish Malpani; [email-masked]
> Subject: RE: New draft - NULL Public Key Signatures
> 
> 
> Ambarish,
> 
> Does this proposal require X.509 certificates?  Or is it the 
> case that the
> draft, when finalized, will propose a non-X.509 approach to public key
> management?
> 
> Mike
> 
> 
> 
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[email-masked]]
> > Sent: Tuesday, October 19, 1999 4:16 PM
> > To: [email-masked]
> > Subject: New draft - NULL Public Key Signatures
> > 
> > 
> > 
> > Hi Guys,
> >     Given the traffic on this list, it sounds like this IETF is
> > going to be a pretty boring one. :-)
> > 
> > I have just submitted an individual draft about NULL Public Key
> > Signatures, which I hope will be part of this working group soon
> > (make things at the PKIX meeting more interesting).
> > 
> > The main (serious) reason for this draft, is to allow people to
> > describe data items that may be signed or unsigned more easily
> > in ASN.1.
> > 
> > Also, having a NULL algorithm is asthetically pleasing.
> > 
> > So here it is.
> > 
> > Please send all your flames/comments to this list.
> > 
> > Thanks,
> > Ambarish
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [email-masked]
> > 1215 Terra Bella Ave.                         
http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 

From: "Todd Glassey @ GMT" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Another DoS attack. - potantial CMS additon
Date: Thu, 28 Oct 1999 09:28:33 -0700

Hi all,  the forwarded letter is regarding a denial of service attack mode
in IPsec negotiations. We also have similar issues in commercial transaction
processing with the same attack vector.

----- Original Message -----
From: Tamir Zegman <[email-masked]>
To: ipsec <[email-masked]>; ipsra <[email-masked]>
Sent: Thursday, October 28, 1999 01:40 AM
Subject: Another DoS attack.

> I'm posting this message to both mailing lists as this issue concerns
> them both.
>
> An attacker using either aggressive, main or base mode can send a
> certificate whose RSA public key consists of a long modulus (16384) and
> a non trivial exponent.

This is an interesting reazilzation that I believe may have real-world
consequences in the sucessfull operation of commercial PKI systems. The
issue is Denial of Service by flooding the exponetiation engine's input
queue with massive key structures and thus overloading the local processor.

> The responder will be left to do the exponentiation till hell freezes
> unless of course his implementation limits the length of public key
> signatures it is willing to verify.

In a number of the protocols we are working I would suggest that we should
also on address this by allowing a policy control of the maximum size of
expected key structures... this may be something to add to CMS before it
goes final. Also the TS protocol will need some sort of control to prevent
this abuse model.

> A similar attack can be mounted using DSA.
> This attack can be extended to other online protocols that use
> certificates in which the responder is asked to verify a public key
> signature.

anyone else see the light in this tunnel?

Todd

From: Michael Myers <[email-masked]>
To: Ambarish Malpani <[email-masked]>, [email-masked]
Subject: RE: New draft - NULL Public Key Signatures
Date: Thu, 28 Oct 1999 09:07:36 -0700

Ambarish,

Does this proposal require X.509 certificates?  Or is it the case that the
draft, when finalized, will propose a non-X.509 approach to public key
management?

Mike

> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Tuesday, October 19, 1999 4:16 PM
> To: [email-masked]
> Subject: New draft - NULL Public Key Signatures
> 
> 
> 
> Hi Guys,
>     Given the traffic on this list, it sounds like this IETF is
> going to be a pretty boring one. :-)
> 
> I have just submitted an individual draft about NULL Public Key
> Signatures, which I hope will be part of this working group soon
> (make things at the PKIX meeting more interesting).
> 
> The main (serious) reason for this draft, is to allow people to
> describe data items that may be signed or unsigned more easily
> in ASN.1.
> 
> Also, having a NULL algorithm is asthetically pleasing.
> 
> So here it is.
> 
> Please send all your flames/comments to this list.
> 
> Thanks,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 

Date: Wed, 27 Oct 1999 16:40:55 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: QC certificates and Nationality
Cc: "'SEIS-List'" <[email-masked]>

What goes into the QC when a person is a citizen of more than one country?

Russ

Date: Wed, 27 Oct 1999 11:44:24 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: draft-ietf-pkix-ipki-ecdsa-02.txt

Given that RFC 2459 must be updated, I suggest that these specification be 
folded into the updated RFC 2459. I do not think that a separate document 
adds value.

Russ

==========

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

	Title		: Internet X.509 Public Key Infrastructure
                           Representation of Elliptic Curve Digital 
Signature
                           Algorithm (ECDSA) Keys and Signatures in 
Internet
                           X.509 Public Key Infrastructure Certificates
	Author(s)	: L. Bassham, D. Johnson, W. Polk
	Filename	: draft-ietf-pkix-ipki-ecdsa-02.txt
	Pages		: 15
	Date		: 22-Oct-99
	
This is the third draft of a profile for specification of Elliptic
Curve Digital Signature Algorithm (ECDSA) keys and signatures in
Internet Public Key Infrastructure X.509 certificates and certificate
revocation lists. This specification is an addendum to RFC 2459;
implementations must also conform to RFC 2459.  In addition, this
document references ANSI X9.62 for the specification of the ECDSA
algorithm.  This specification only addresses the format of ECDSA
keys and signatures.  Please send comments on this document to the
[email-masked] mail list.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-qc-02.txt
Date: Thu, 28 Oct 1999 07:29:42 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Qualified Certificates
	Author(s)	: S. Santesson, T. Polk, P. Barzin,  M. Nystrom
	Filename	: draft-ietf-pkix-qc-02.txt
	Pages		: 35
	Date		: 27-Oct-99
	
This document forms a certificate profile for Qualified Certificates,
based on RFC 2459, for use in the Internet. The term Qualified
Certificate is used to describe a certificate with a certain
qualified status within applicable governing law. Further, Qualified
Certificates are issued exclusively to physical persons represented
by a registered unmistakable identity.

The goal of this document is to define a general syntax independent
of local legal requirements. The profile is however designed to allow
further profiling in order to meet specific local needs.

It is important to note that the profile does not define any legal
requirements for Qualified Certificates.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-qc-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-qc-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-qc-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-qc-02.txt

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

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

--OtherAccess--

--NextPart--

Received: from Server (dialup-209.245.71.89.LosAngeles1.Level3.net [209.245.71.89]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA24386; Wed, 27 Oct 1999 20:17:37 -0700 (PDT)
From: [email-masked]
Subject: The best long distance International rates
Date: Wed, 27 Oct 1999 16:45:04
Message-Id: <261.280024.57549@Server>

Hi, 

  10-10-629 is your NUMBER to MAKE MONEY while SAVING MONEY!
Just dial 10-10-629 + 1 + Tel. No + Code(212570),
Code on your First Call Only!

  I have exciting new for you! I am an IndependentRepresentative 
for WorldxChange Communications, one of the world's leaders in 
discounted long distance service.  My friends and family are 
enjoying the benefits of WxC's service and I wanted to pass them 
along to you.  How does 5 cents a minute sound?  We also have the 
best International rates.

More information see our website:
                      http://www.worldxchange.com/agent/212570

Please contact me at:[email-masked] as soon as possible so 
you can start taking advantage of these low rates on your next 
call.  There is no set-up fee and no contracts to sign.  Just 
dial the number and use my agent activation number (212570) on 
your first call.  Or, you can pre-subscribe for additional 
options. It's that easy.

Thank for your help, and I look forward to contact you.

Sincerely,

   Ben

Independent Representative
Worldxchange Communications

 

 

From: Santosh Chokhani <[email-masked]>
To: "'Peter Williams'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: CRL Distribution Points
Date: Wed, 27 Oct 1999 17:16:00 -0400

I interpret RFC 2459, Section 5  to mean that the relying parties may
encounter ARL, DP CRL, and delta CRL.  Given that, the entire text of Annex
is pertinent to 2459, not just the check for indirect CRL issuer.  This can
be done either by reference or by inclusion.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Wednesday, October 27, 1999 3:23 PM
To: Santosh Chokhani; 'Russ Housley'; [email-masked]
Subject: RE: CRL Distribution Points

ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc

At your suggestion I have reviewed the above-identified
amendment text.

For those who only want the bottom line of this mail, here it is:

	I suggest that a simple statement is added to that which 
	Russ has already 	drafted: it should state that 
	"X.509 processing of the crlIssuer field is REQUIRED, if
	present".

Annex M review, for the purpose or understanding Russ' request
for comment in light of Annex M:

I note, that wherever CA was formally, used,
the more general term "authority" is now substituted.
Authority is defined as CA or AA.

I note that the concepts of CrlDistribution Point
have not changed by amendment from the 
X.509 version used by 2459.

I do note that the whole concept of DPs has
been extended to the PMI, which is not part
of 2459 work. I ignored everything in 13.14
as out of review scope, for now.

Annex M1.1 states the CRL types, and helps
out the new scope idea, which is not part
of this review.

Annex M.2 specifies a logical procedure for
selecting CRL processing, based on CRL reliance
policy, defined in the CP.

Annex M.3 states the rules for selecting a CRL
from the various flavors available, according to 
various  requirements. The annex makes it
clear that 1 or more of the several DPs provided can 
be used when DP processing is appropriate.

The concept of dominance and freshness, nicely allows
the IBM override of VeriSign that I described,
whether or not cRLIssuer processing is used.

M.5.1.4 addresses one interaction of cert-based DP
signals and CRL-hosted DP signals. 

The first bullet points out a alternative matching rule 
covering DPName, or the optional CrlIssuer name. Either match is acceptable.

The last bullet states the crlIssuer rule I stated originally.

Annex M is very nice piece of work, which makes it easier
to do what the market requires.

Annex M is completely consistent with my argument, and
does not change the way X.509 has handled cRLIssuer
and indirect CRL signals.

Russ should ensure that his overloading of semantics
on the cRLissuer field continue require that the
base X.509 rules are followed, as stated in X.509
and even more forcefully stated in Annex M.5.1.4
of the FPDAM.
 
Is that a fair review and conclusion, tuned to the question 
posed?

The review only reinforced my original conclusion. Let
me know if I have made an error in my reasoning, or 
if there are other factors in play.  I just do
not want PKIX to be non-conforming with X.509.

I suggest that a simple statement is added to that which 
Russ has already 	drafted: it should state that 
"X.509 processing of the crlIssuer field is REQUIRED, if
present".

Thanks for insisting we all review Annex M. Persistence
in leadership does pay dividends.

Peter.

that indirect issuance is the same as used in the 

> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Wednesday, October 27, 1999 11:18 AM
> To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> Peter:
> 
> You really need to carefully review the Annex M in the draft. 
>  That should
> explain it all.  If you find incompleteness, errors or 
> inconsistencies in
> that Annex, please let me know.  We would be interested in 
> making that Annex
> as complete and accurate as possible.
> 
> 
> -----Original Message-----
> From: Peter Williams [mailto:[email-masked]]
> Sent: Wednesday, October 27, 1999 2:16 PM
> To: Santosh Chokhani; 'Russ Housley'; [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> 
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Wednesday, October 27, 1999 8:16 AM
> > To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> > [email-masked]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Peter:
> > 
> > My interpretation of the statement is that the issuer name in the
> > certificate should match the issuer name in the CRL.
> 
> This interpretation interferes with the X.509 specification which
> enables use of ANY independently-named (validation) authority.  The 
> CrIssuer field signals the identity  and intended use of a given 
> authority  to relying parties, when optionally present. If the
> cRLIssuer value is not present, the default rule you mention 
> above controls. Otherwise "the issuer name in the
> **cRLIssuer** value should match the issuer name in the CRL."
> 
> Let us also note that the name of the CRLDP, when the
> RDN flavour is used, is subordinate to the **CRL issuer**,
> as identififed using the CrlIssuer Rule, if one
> is performing conforming processing. The cRLIssuer
> is identified using the processing summarized above.
> 
> Why cannot we do the simple thing, and just implement
> what X.509 specifies? Its hardly contentious, its
> not hard,  and has already been ratified by the ISO voting 
> process, which included a PKIX voice.
> 
> Lets now advocate the case, with famous-name examples to
> make the case easier to follow:
> 
> Case
> ----
> 
> Folk have quite widely adopted the separation of power idea
> between CAs and VAs (or those who indirectly
> issug CRLs). Enterprises WANT to be able to
> issue a local/extranet CRL, that controls whether a VeriSign
> public certificate is flagged suspended in that
> relying-party domain.
> 
> Taking IBM as the example enterprise customer that chooses
> to quite normally outsource its ceritifcate manufacturing to
> VeriSign, IBM may well wish to have VeriSign indicate
> the users of IBM certificates should use a given , non-VeriSign
> CRL issuer, identified in the CrlIssuer name using
> an DN selected in the IBM corporate DN-name space. 
> 
> Policies for issuing IBM's indirect CRL would meet IBM 
> guidelines, which may be more stringent than the those used by
> VeriSign. Furthermore, for IBM is likely to have 
> a significantly more realtime data at its RAs concerning
> revocation/suspension data than VeriSign has, or has yet 
> accepted for processing under its own CPS rules.  
> 
> Whether IBM or an outsource VA operate the IBM
> CrlIssuer is an operational choice, much like
> any decision to deploy a product server on
> the IBM LAN, or use a service provider.
> 
> 
> Conclusion, to date:
> -------------------
> 
> The model argued above is what the cRLIssuer field
> was designed for; processing must comply for a
> user cert validation result to be conforming with X.509,
> and for the allied process of confirming a certificate chain
> to be similarly conforming.
> 
> I have no particular objection, if it is
> technically appropriate, for PKIX to overload the CrlIssuer
> signal with Russ' meanings
> 
> But one cannot simple replace
> the original processing requirements with an
> interpretative wave of the PKIX magic wand, and 
> still be able to interwork securely with 
> correctly-implemented X.509 certificate-using 
> systems now widespread.
> 
> Peter.
> 
> > 
> > -----Original Message-----
> > From: Peter Williams [mailto:[email-masked]]
> > Sent: Tuesday, October 26, 1999 8:35 PM
> > To: Santosh Chokhani; Peter Williams; 'Russ Housley'; 
> > [email-masked]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > 
> >  
> > > Peter:
> > > 
> > > The issuer of the CRL should be identified from issuer name 
> > > field in the CRL
> > > and not based on what directory entry or what attribute you 
> > > queried.  The
> > > directory is not trusted, the network is not trusted, and 
> > > there is no strong
> > > binding between the attribute value and the object/attribute.
> > 
> > But, from the standard(12.6.2	Certificate extension fields)
> > at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc
> > 
> > "The cRLIssuer component identifies the authority that issues 
> > and signs the
> > CRL. If this component is absent, the CRL issuer name 
> defaults to the
> > certificate issuer name."
> > 
> > I assume we are going to comply with X.509 concerning
> > the rules for identifying the issuer of a CRL, as given
> > above.  If not, the security section of son-of-2459 should
> > identify that PKIX validation processing is non-conforming with
> > the ISO standard.  
> >  
> > Peter.
> > 
> > 
> > > -----Original Message-----
> > > From: Peter Williams [mailto:[email-masked]]
> > > Sent: Tuesday, October 26, 1999 8:02 PM
> > > To: Santosh Chokhani; 'Russ Housley'; [email-masked]
> > > Subject: RE: CRL Distribution Points
> > > 
> > > 
> > > Russ,
> > > 
> > > You need to ensure that an indirect issuer of the
> > > CRL fragment can be identified, so that the signature
> > > can be appropriately verified, as per the X.509 model.
> > > 
> > > How would we do that with your standard today? - whilst
> > > also pointing to the location of the value in 
> > > a directory/uri-resolver?
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > Sent: Tuesday, October 26, 1999 4:39 PM
> > > > To: 'Russ Housley'; [email-masked]
> > > > Subject: RE: CRL Distribution Points
> > > > 
> > > > 
> > > > Russ:
> > > > 
> > > > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > > > idea to include
> > > > Annex M, point to it or borrow the applicable sections in the 
> > > > PKIX RFC.
> > > > 
> > > > -----Original Message-----
> > > > From: Russ Housley [mailto:[email-masked]]
> > > > Sent: Tuesday, October 26, 1999 12:58 PM
> > > > To: [email-masked]
> > > > Subject: CRL Distribution Points
> > > > 
> > > > 
> > > > In reviewing the document that Tim recently posted, I 
> > > > realized that we were 
> > > > not really clear about the semantics of a DistributionPoint 
> > > > with an absent 
> > > > distributionPoint, a present reasons, and a present 
> > > > cRLIssuer.  The ASN.1 
> > > > is repeated below for those who have not memorized it.
> > > > 
> > > > If the cRLDistributionPoints extension does not contain a 
> > > > DistributionPointName, but does contain a cRLIssuer, then 
> > following 
> > > > semantics MUST be assumed:
> > > > 
> > > > 1) If the cRLIssuer is of type directoryName, then the 
> > > > certificateRevocationList attribute in the Directory entry of 
> > > > the cRLIssuer 
> > > > contains the current CRL for the associated reasons.
> > > > 
> > > > 2) If the cRLIssuer is of type URI, then the URI is a 
> > > pointer to the 
> > > > current CRL for the associated reasons.  The expected values 
> > > > for the URI 
> > > > are those defined in 4.2.1.7.
> > > > 
> > > > 3) Processing rules for other values are not defined by this 
> > > > specification.
> > > > 
> > > > Does this seem right?
> > > > 
> > > > Russ
> > > > 
> > > > = = = = = = = = = =
> > > > 
> > > >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > > > DistributionPoint
> > > > 
> > > >     DistributionPoint ::= SEQUENCE {
> > > >          distributionPoint       [0]     
> > > > DistributionPointName OPTIONAL,
> > > >          reasons                 [1]     ReasonFlags OPTIONAL,
> > > >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > > > 
> > > >     DistributionPointName ::= CHOICE {
> > > >          fullName                [0]     GeneralNames,
> > > >          nameRelativeToCRLIssuer [1]     
> > RelativeDistinguishedName }
> > > > 
> > > >     ReasonFlags ::= BIT STRING {
> > > >          unused                  (0),
> > > >          keyCompromise           (1),
> > > >          cACompromise            (2),
> > > >          affiliationChanged      (3),
> > > >          superseded              (4),
> > > >          cessationOfOperation    (5),
> > > >          certificateHold         (6) }
> > > > 
> > > 
> > 
> 

From: Peter Williams <[email-masked]>
To: Santosh Chokhani <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: CRL Distribution Points
Date: Wed, 27 Oct 1999 12:22:48 -0700

ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc

At your suggestion I have reviewed the above-identified
amendment text.

For those who only want the bottom line of this mail, here it is:

	I suggest that a simple statement is added to that which 
	Russ has already 	drafted: it should state that 
	"X.509 processing of the crlIssuer field is REQUIRED, if
	present".

Annex M review, for the purpose or understanding Russ' request
for comment in light of Annex M:

I note, that wherever CA was formally, used,
the more general term "authority" is now substituted.
Authority is defined as CA or AA.

I note that the concepts of CrlDistribution Point
have not changed by amendment from the 
X.509 version used by 2459.

I do note that the whole concept of DPs has
been extended to the PMI, which is not part
of 2459 work. I ignored everything in 13.14
as out of review scope, for now.

Annex M1.1 states the CRL types, and helps
out the new scope idea, which is not part
of this review.

Annex M.2 specifies a logical procedure for
selecting CRL processing, based on CRL reliance
policy, defined in the CP.

Annex M.3 states the rules for selecting a CRL
from the various flavors available, according to 
various  requirements. The annex makes it
clear that 1 or more of the several DPs provided can 
be used when DP processing is appropriate.

The concept of dominance and freshness, nicely allows
the IBM override of VeriSign that I described,
whether or not cRLIssuer processing is used.

M.5.1.4 addresses one interaction of cert-based DP
signals and CRL-hosted DP signals. 

The first bullet points out a alternative matching rule 
covering DPName, or the optional CrlIssuer name. Either match is acceptable.

The last bullet states the crlIssuer rule I stated originally.

Annex M is very nice piece of work, which makes it easier
to do what the market requires.

Annex M is completely consistent with my argument, and
does not change the way X.509 has handled cRLIssuer
and indirect CRL signals.

Russ should ensure that his overloading of semantics
on the cRLissuer field continue require that the
base X.509 rules are followed, as stated in X.509
and even more forcefully stated in Annex M.5.1.4
of the FPDAM.
 
Is that a fair review and conclusion, tuned to the question 
posed?

The review only reinforced my original conclusion. Let
me know if I have made an error in my reasoning, or 
if there are other factors in play.  I just do
not want PKIX to be non-conforming with X.509.

I suggest that a simple statement is added to that which 
Russ has already 	drafted: it should state that 
"X.509 processing of the crlIssuer field is REQUIRED, if
present".

Thanks for insisting we all review Annex M. Persistence
in leadership does pay dividends.

Peter.

that indirect issuance is the same as used in the 

> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Wednesday, October 27, 1999 11:18 AM
> To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> Peter:
> 
> You really need to carefully review the Annex M in the draft. 
>  That should
> explain it all.  If you find incompleteness, errors or 
> inconsistencies in
> that Annex, please let me know.  We would be interested in 
> making that Annex
> as complete and accurate as possible.
> 
> 
> -----Original Message-----
> From: Peter Williams [mailto:[email-masked]]
> Sent: Wednesday, October 27, 1999 2:16 PM
> To: Santosh Chokhani; 'Russ Housley'; [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> 
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Wednesday, October 27, 1999 8:16 AM
> > To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> > [email-masked]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Peter:
> > 
> > My interpretation of the statement is that the issuer name in the
> > certificate should match the issuer name in the CRL.
> 
> This interpretation interferes with the X.509 specification which
> enables use of ANY independently-named (validation) authority.  The 
> CrIssuer field signals the identity  and intended use of a given 
> authority  to relying parties, when optionally present. If the
> cRLIssuer value is not present, the default rule you mention 
> above controls. Otherwise "the issuer name in the
> **cRLIssuer** value should match the issuer name in the CRL."
> 
> Let us also note that the name of the CRLDP, when the
> RDN flavour is used, is subordinate to the **CRL issuer**,
> as identififed using the CrlIssuer Rule, if one
> is performing conforming processing. The cRLIssuer
> is identified using the processing summarized above.
> 
> Why cannot we do the simple thing, and just implement
> what X.509 specifies? Its hardly contentious, its
> not hard,  and has already been ratified by the ISO voting 
> process, which included a PKIX voice.
> 
> Lets now advocate the case, with famous-name examples to
> make the case easier to follow:
> 
> Case
> ----
> 
> Folk have quite widely adopted the separation of power idea
> between CAs and VAs (or those who indirectly
> issug CRLs). Enterprises WANT to be able to
> issue a local/extranet CRL, that controls whether a VeriSign
> public certificate is flagged suspended in that
> relying-party domain.
> 
> Taking IBM as the example enterprise customer that chooses
> to quite normally outsource its ceritifcate manufacturing to
> VeriSign, IBM may well wish to have VeriSign indicate
> the users of IBM certificates should use a given , non-VeriSign
> CRL issuer, identified in the CrlIssuer name using
> an DN selected in the IBM corporate DN-name space. 
> 
> Policies for issuing IBM's indirect CRL would meet IBM 
> guidelines, which may be more stringent than the those used by
> VeriSign. Furthermore, for IBM is likely to have 
> a significantly more realtime data at its RAs concerning
> revocation/suspension data than VeriSign has, or has yet 
> accepted for processing under its own CPS rules.  
> 
> Whether IBM or an outsource VA operate the IBM
> CrlIssuer is an operational choice, much like
> any decision to deploy a product server on
> the IBM LAN, or use a service provider.
> 
> 
> Conclusion, to date:
> -------------------
> 
> The model argued above is what the cRLIssuer field
> was designed for; processing must comply for a
> user cert validation result to be conforming with X.509,
> and for the allied process of confirming a certificate chain
> to be similarly conforming.
> 
> I have no particular objection, if it is
> technically appropriate, for PKIX to overload the CrlIssuer
> signal with Russ' meanings
> 
> But one cannot simple replace
> the original processing requirements with an
> interpretative wave of the PKIX magic wand, and 
> still be able to interwork securely with 
> correctly-implemented X.509 certificate-using 
> systems now widespread.
> 
> Peter.
> 
> > 
> > -----Original Message-----
> > From: Peter Williams [mailto:[email-masked]]
> > Sent: Tuesday, October 26, 1999 8:35 PM
> > To: Santosh Chokhani; Peter Williams; 'Russ Housley'; 
> > [email-masked]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > 
> >  
> > > Peter:
> > > 
> > > The issuer of the CRL should be identified from issuer name 
> > > field in the CRL
> > > and not based on what directory entry or what attribute you 
> > > queried.  The
> > > directory is not trusted, the network is not trusted, and 
> > > there is no strong
> > > binding between the attribute value and the object/attribute.
> > 
> > But, from the standard(12.6.2	Certificate extension fields)
> > at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc
> > 
> > "The cRLIssuer component identifies the authority that issues 
> > and signs the
> > CRL. If this component is absent, the CRL issuer name 
> defaults to the
> > certificate issuer name."
> > 
> > I assume we are going to comply with X.509 concerning
> > the rules for identifying the issuer of a CRL, as given
> > above.  If not, the security section of son-of-2459 should
> > identify that PKIX validation processing is non-conforming with
> > the ISO standard.  
> >  
> > Peter.
> > 
> > 
> > > -----Original Message-----
> > > From: Peter Williams [mailto:[email-masked]]
> > > Sent: Tuesday, October 26, 1999 8:02 PM
> > > To: Santosh Chokhani; 'Russ Housley'; [email-masked]
> > > Subject: RE: CRL Distribution Points
> > > 
> > > 
> > > Russ,
> > > 
> > > You need to ensure that an indirect issuer of the
> > > CRL fragment can be identified, so that the signature
> > > can be appropriately verified, as per the X.509 model.
> > > 
> > > How would we do that with your standard today? - whilst
> > > also pointing to the location of the value in 
> > > a directory/uri-resolver?
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > Sent: Tuesday, October 26, 1999 4:39 PM
> > > > To: 'Russ Housley'; [email-masked]
> > > > Subject: RE: CRL Distribution Points
> > > > 
> > > > 
> > > > Russ:
> > > > 
> > > > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > > > idea to include
> > > > Annex M, point to it or borrow the applicable sections in the 
> > > > PKIX RFC.
> > > > 
> > > > -----Original Message-----
> > > > From: Russ Housley [mailto:[email-masked]]
> > > > Sent: Tuesday, October 26, 1999 12:58 PM
> > > > To: [email-masked]
> > > > Subject: CRL Distribution Points
> > > > 
> > > > 
> > > > In reviewing the document that Tim recently posted, I 
> > > > realized that we were 
> > > > not really clear about the semantics of a DistributionPoint 
> > > > with an absent 
> > > > distributionPoint, a present reasons, and a present 
> > > > cRLIssuer.  The ASN.1 
> > > > is repeated below for those who have not memorized it.
> > > > 
> > > > If the cRLDistributionPoints extension does not contain a 
> > > > DistributionPointName, but does contain a cRLIssuer, then 
> > following 
> > > > semantics MUST be assumed:
> > > > 
> > > > 1) If the cRLIssuer is of type directoryName, then the 
> > > > certificateRevocationList attribute in the Directory entry of 
> > > > the cRLIssuer 
> > > > contains the current CRL for the associated reasons.
> > > > 
> > > > 2) If the cRLIssuer is of type URI, then the URI is a 
> > > pointer to the 
> > > > current CRL for the associated reasons.  The expected values 
> > > > for the URI 
> > > > are those defined in 4.2.1.7.
> > > > 
> > > > 3) Processing rules for other values are not defined by this 
> > > > specification.
> > > > 
> > > > Does this seem right?
> > > > 
> > > > Russ
> > > > 
> > > > = = = = = = = = = =
> > > > 
> > > >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > > > DistributionPoint
> > > > 
> > > >     DistributionPoint ::= SEQUENCE {
> > > >          distributionPoint       [0]     
> > > > DistributionPointName OPTIONAL,
> > > >          reasons                 [1]     ReasonFlags OPTIONAL,
> > > >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > > > 
> > > >     DistributionPointName ::= CHOICE {
> > > >          fullName                [0]     GeneralNames,
> > > >          nameRelativeToCRLIssuer [1]     
> > RelativeDistinguishedName }
> > > > 
> > > >     ReasonFlags ::= BIT STRING {
> > > >          unused                  (0),
> > > >          keyCompromise           (1),
> > > >          cACompromise            (2),
> > > >          affiliationChanged      (3),
> > > >          superseded              (4),
> > > >          cessationOfOperation    (5),
> > > >          certificateHold         (6) }
> > > > 
> > > 
> > 
> 

Date: Wed, 27 Oct 1999 14:22:25 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: New draft - NULL Public Key Signatures

>>>>> "Ambarish" == Ambarish Malpani <[email-masked]> writes:

 Ambarish> Hi Paul, The reason is to allow a way to indicate that
 Ambarish> something is not signed even when the formal syntax
 Ambarish> requires it to be signed.

Yes, I realize that; the draft makes that clear.

My point is that this is a rather obscure way of providing this
capability.  If it's desirable to allow things to be unsigned, let the 
syntax do so.  Using the syntax for "signed data" where the signature
is actually meaningless is, at best, a weird encoding hack and, at
worst, higly misleading and confusing.

 Ambarish> One example as Marc B. pointed out was unsigned OCSP
 Ambarish> responses.  Another potential example is to actually issue
 Ambarish> self-signed certs with this kind of a signature - to
 Ambarish> clearly indicate that the signature on the cert doesn't
 Ambarish> really mean much.

Why is it useful to be able to issue self-not-signed certs?  The fact
that this proposal allows such things to be done doesn't mean it is
something that *should* be done.  (Dan Harkins, are you there?  :-) )

 Ambarish> Another reason was to allow protocols to actually require
 Ambarish> signatures everywhere, an support this algorithm if the
 Ambarish> signature was optional - for example, in the OCSP protocol,
 Ambarish> we have an optional signature section on the request -
 Ambarish> makes the syntax quite a bit uglier than just requiring a
 Ambarish> signature and allowing for NULL signatures.

But declaring the signature to be optional is far clearer.  And why
does that make the syntax ugly?  I thought one of the benefits of
ASN.1 is that it's trivial to describe optional components.

	paul

From: Santosh Chokhani <[email-masked]>
To: "'Peter Williams'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: CRL Distribution Points
Date: Wed, 27 Oct 1999 14:18:03 -0400

Peter:

You really need to carefully review the Annex M in the draft.  That should
explain it all.  If you find incompleteness, errors or inconsistencies in
that Annex, please let me know.  We would be interested in making that Annex
as complete and accurate as possible.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Wednesday, October 27, 1999 2:16 PM
To: Santosh Chokhani; 'Russ Housley'; [email-masked]
Subject: RE: CRL Distribution Points

> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Wednesday, October 27, 1999 8:16 AM
> To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> Peter:
> 
> My interpretation of the statement is that the issuer name in the
> certificate should match the issuer name in the CRL.

This interpretation interferes with the X.509 specification which
enables use of ANY independently-named (validation) authority.  The 
CrIssuer field signals the identity  and intended use of a given 
authority  to relying parties, when optionally present. If the
cRLIssuer value is not present, the default rule you mention 
above controls. Otherwise "the issuer name in the
**cRLIssuer** value should match the issuer name in the CRL."

Let us also note that the name of the CRLDP, when the
RDN flavour is used, is subordinate to the **CRL issuer**,
as identififed using the CrlIssuer Rule, if one
is performing conforming processing. The cRLIssuer
is identified using the processing summarized above.

Why cannot we do the simple thing, and just implement
what X.509 specifies? Its hardly contentious, its
not hard,  and has already been ratified by the ISO voting 
process, which included a PKIX voice.

Lets now advocate the case, with famous-name examples to
make the case easier to follow:

Case
----

Folk have quite widely adopted the separation of power idea
between CAs and VAs (or those who indirectly
issug CRLs). Enterprises WANT to be able to
issue a local/extranet CRL, that controls whether a VeriSign
public certificate is flagged suspended in that
relying-party domain.

Taking IBM as the example enterprise customer that chooses
to quite normally outsource its ceritifcate manufacturing to
VeriSign, IBM may well wish to have VeriSign indicate
the users of IBM certificates should use a given , non-VeriSign
CRL issuer, identified in the CrlIssuer name using
an DN selected in the IBM corporate DN-name space. 

Policies for issuing IBM's indirect CRL would meet IBM 
guidelines, which may be more stringent than the those used by
VeriSign. Furthermore, for IBM is likely to have 
a significantly more realtime data at its RAs concerning
revocation/suspension data than VeriSign has, or has yet 
accepted for processing under its own CPS rules.  

Whether IBM or an outsource VA operate the IBM
CrlIssuer is an operational choice, much like
any decision to deploy a product server on
the IBM LAN, or use a service provider.

Conclusion, to date:
-------------------

The model argued above is what the cRLIssuer field
was designed for; processing must comply for a
user cert validation result to be conforming with X.509,
and for the allied process of confirming a certificate chain
to be similarly conforming.

I have no particular objection, if it is
technically appropriate, for PKIX to overload the CrlIssuer
signal with Russ' meanings

But one cannot simple replace
the original processing requirements with an
interpretative wave of the PKIX magic wand, and 
still be able to interwork securely with 
correctly-implemented X.509 certificate-using 
systems now widespread.

Peter.

> 
> -----Original Message-----
> From: Peter Williams [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 8:35 PM
> To: Santosh Chokhani; Peter Williams; 'Russ Housley'; 
> [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> 
>  
> > Peter:
> > 
> > The issuer of the CRL should be identified from issuer name 
> > field in the CRL
> > and not based on what directory entry or what attribute you 
> > queried.  The
> > directory is not trusted, the network is not trusted, and 
> > there is no strong
> > binding between the attribute value and the object/attribute.
> 
> But, from the standard(12.6.2	Certificate extension fields)
> at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc
> 
> "The cRLIssuer component identifies the authority that issues 
> and signs the
> CRL. If this component is absent, the CRL issuer name defaults to the
> certificate issuer name."
> 
> I assume we are going to comply with X.509 concerning
> the rules for identifying the issuer of a CRL, as given
> above.  If not, the security section of son-of-2459 should
> identify that PKIX validation processing is non-conforming with
> the ISO standard.  
>  
> Peter.
> 
> 
> > -----Original Message-----
> > From: Peter Williams [mailto:[email-masked]]
> > Sent: Tuesday, October 26, 1999 8:02 PM
> > To: Santosh Chokhani; 'Russ Housley'; [email-masked]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Russ,
> > 
> > You need to ensure that an indirect issuer of the
> > CRL fragment can be identified, so that the signature
> > can be appropriately verified, as per the X.509 model.
> > 
> > How would we do that with your standard today? - whilst
> > also pointing to the location of the value in 
> > a directory/uri-resolver?
> >  
> > 
> > > -----Original Message-----
> > > From: Santosh Chokhani [mailto:[email-masked]]
> > > Sent: Tuesday, October 26, 1999 4:39 PM
> > > To: 'Russ Housley'; [email-masked]
> > > Subject: RE: CRL Distribution Points
> > > 
> > > 
> > > Russ:
> > > 
> > > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > > idea to include
> > > Annex M, point to it or borrow the applicable sections in the 
> > > PKIX RFC.
> > > 
> > > -----Original Message-----
> > > From: Russ Housley [mailto:[email-masked]]
> > > Sent: Tuesday, October 26, 1999 12:58 PM
> > > To: [email-masked]
> > > Subject: CRL Distribution Points
> > > 
> > > 
> > > In reviewing the document that Tim recently posted, I 
> > > realized that we were 
> > > not really clear about the semantics of a DistributionPoint 
> > > with an absent 
> > > distributionPoint, a present reasons, and a present 
> > > cRLIssuer.  The ASN.1 
> > > is repeated below for those who have not memorized it.
> > > 
> > > If the cRLDistributionPoints extension does not contain a 
> > > DistributionPointName, but does contain a cRLIssuer, then 
> following 
> > > semantics MUST be assumed:
> > > 
> > > 1) If the cRLIssuer is of type directoryName, then the 
> > > certificateRevocationList attribute in the Directory entry of 
> > > the cRLIssuer 
> > > contains the current CRL for the associated reasons.
> > > 
> > > 2) If the cRLIssuer is of type URI, then the URI is a 
> > pointer to the 
> > > current CRL for the associated reasons.  The expected values 
> > > for the URI 
> > > are those defined in 4.2.1.7.
> > > 
> > > 3) Processing rules for other values are not defined by this 
> > > specification.
> > > 
> > > Does this seem right?
> > > 
> > > Russ
> > > 
> > > = = = = = = = = = =
> > > 
> > >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > > DistributionPoint
> > > 
> > >     DistributionPoint ::= SEQUENCE {
> > >          distributionPoint       [0]     
> > > DistributionPointName OPTIONAL,
> > >          reasons                 [1]     ReasonFlags OPTIONAL,
> > >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > > 
> > >     DistributionPointName ::= CHOICE {
> > >          fullName                [0]     GeneralNames,
> > >          nameRelativeToCRLIssuer [1]     
> RelativeDistinguishedName }
> > > 
> > >     ReasonFlags ::= BIT STRING {
> > >          unused                  (0),
> > >          keyCompromise           (1),
> > >          cACompromise            (2),
> > >          affiliationChanged      (3),
> > >          superseded              (4),
> > >          cessationOfOperation    (5),
> > >          certificateHold         (6) }
> > > 
> > 
> 

From: Peter Williams <[email-masked]>
To: Santosh Chokhani <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: CRL Distribution Points
Date: Wed, 27 Oct 1999 11:15:33 -0700

> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Wednesday, October 27, 1999 8:16 AM
> To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> Peter:
> 
> My interpretation of the statement is that the issuer name in the
> certificate should match the issuer name in the CRL.

This interpretation interferes with the X.509 specification which
enables use of ANY independently-named (validation) authority.  The 
CrIssuer field signals the identity  and intended use of a given 
authority  to relying parties, when optionally present. If the
cRLIssuer value is not present, the default rule you mention 
above controls. Otherwise "the issuer name in the
**cRLIssuer** value should match the issuer name in the CRL."

Let us also note that the name of the CRLDP, when the
RDN flavour is used, is subordinate to the **CRL issuer**,
as identififed using the CrlIssuer Rule, if one
is performing conforming processing. The cRLIssuer
is identified using the processing summarized above.

Why cannot we do the simple thing, and just implement
what X.509 specifies? Its hardly contentious, its
not hard,  and has already been ratified by the ISO voting 
process, which included a PKIX voice.

Lets now advocate the case, with famous-name examples to
make the case easier to follow:

Case
----

Folk have quite widely adopted the separation of power idea
between CAs and VAs (or those who indirectly
issug CRLs). Enterprises WANT to be able to
issue a local/extranet CRL, that controls whether a VeriSign
public certificate is flagged suspended in that
relying-party domain.

Taking IBM as the example enterprise customer that chooses
to quite normally outsource its ceritifcate manufacturing to
VeriSign, IBM may well wish to have VeriSign indicate
the users of IBM certificates should use a given , non-VeriSign
CRL issuer, identified in the CrlIssuer name using
an DN selected in the IBM corporate DN-name space. 

Policies for issuing IBM's indirect CRL would meet IBM 
guidelines, which may be more stringent than the those used by
VeriSign. Furthermore, for IBM is likely to have 
a significantly more realtime data at its RAs concerning
revocation/suspension data than VeriSign has, or has yet 
accepted for processing under its own CPS rules.  

Whether IBM or an outsource VA operate the IBM
CrlIssuer is an operational choice, much like
any decision to deploy a product server on
the IBM LAN, or use a service provider.

Conclusion, to date:
-------------------

The model argued above is what the cRLIssuer field
was designed for; processing must comply for a
user cert validation result to be conforming with X.509,
and for the allied process of confirming a certificate chain
to be similarly conforming.

I have no particular objection, if it is
technically appropriate, for PKIX to overload the CrlIssuer
signal with Russ' meanings

But one cannot simple replace
the original processing requirements with an
interpretative wave of the PKIX magic wand, and 
still be able to interwork securely with 
correctly-implemented X.509 certificate-using 
systems now widespread.

Peter.

> 
> -----Original Message-----
> From: Peter Williams [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 8:35 PM
> To: Santosh Chokhani; Peter Williams; 'Russ Housley'; 
> [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> 
>  
> > Peter:
> > 
> > The issuer of the CRL should be identified from issuer name 
> > field in the CRL
> > and not based on what directory entry or what attribute you 
> > queried.  The
> > directory is not trusted, the network is not trusted, and 
> > there is no strong
> > binding between the attribute value and the object/attribute.
> 
> But, from the standard(12.6.2	Certificate extension fields)
> at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc
> 
> "The cRLIssuer component identifies the authority that issues 
> and signs the
> CRL. If this component is absent, the CRL issuer name defaults to the
> certificate issuer name."
> 
> I assume we are going to comply with X.509 concerning
> the rules for identifying the issuer of a CRL, as given
> above.  If not, the security section of son-of-2459 should
> identify that PKIX validation processing is non-conforming with
> the ISO standard.  
>  
> Peter.
> 
> 
> > -----Original Message-----
> > From: Peter Williams [mailto:[email-masked]]
> > Sent: Tuesday, October 26, 1999 8:02 PM
> > To: Santosh Chokhani; 'Russ Housley'; [email-masked]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Russ,
> > 
> > You need to ensure that an indirect issuer of the
> > CRL fragment can be identified, so that the signature
> > can be appropriately verified, as per the X.509 model.
> > 
> > How would we do that with your standard today? - whilst
> > also pointing to the location of the value in 
> > a directory/uri-resolver?
> >  
> > 
> > > -----Original Message-----
> > > From: Santosh Chokhani [mailto:[email-masked]]
> > > Sent: Tuesday, October 26, 1999 4:39 PM
> > > To: 'Russ Housley'; [email-masked]
> > > Subject: RE: CRL Distribution Points
> > > 
> > > 
> > > Russ:
> > > 
> > > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > > idea to include
> > > Annex M, point to it or borrow the applicable sections in the 
> > > PKIX RFC.
> > > 
> > > -----Original Message-----
> > > From: Russ Housley [mailto:[email-masked]]
> > > Sent: Tuesday, October 26, 1999 12:58 PM
> > > To: [email-masked]
> > > Subject: CRL Distribution Points
> > > 
> > > 
> > > In reviewing the document that Tim recently posted, I 
> > > realized that we were 
> > > not really clear about the semantics of a DistributionPoint 
> > > with an absent 
> > > distributionPoint, a present reasons, and a present 
> > > cRLIssuer.  The ASN.1 
> > > is repeated below for those who have not memorized it.
> > > 
> > > If the cRLDistributionPoints extension does not contain a 
> > > DistributionPointName, but does contain a cRLIssuer, then 
> following 
> > > semantics MUST be assumed:
> > > 
> > > 1) If the cRLIssuer is of type directoryName, then the 
> > > certificateRevocationList attribute in the Directory entry of 
> > > the cRLIssuer 
> > > contains the current CRL for the associated reasons.
> > > 
> > > 2) If the cRLIssuer is of type URI, then the URI is a 
> > pointer to the 
> > > current CRL for the associated reasons.  The expected values 
> > > for the URI 
> > > are those defined in 4.2.1.7.
> > > 
> > > 3) Processing rules for other values are not defined by this 
> > > specification.
> > > 
> > > Does this seem right?
> > > 
> > > Russ
> > > 
> > > = = = = = = = = = =
> > > 
> > >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > > DistributionPoint
> > > 
> > >     DistributionPoint ::= SEQUENCE {
> > >          distributionPoint       [0]     
> > > DistributionPointName OPTIONAL,
> > >          reasons                 [1]     ReasonFlags OPTIONAL,
> > >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > > 
> > >     DistributionPointName ::= CHOICE {
> > >          fullName                [0]     GeneralNames,
> > >          nameRelativeToCRLIssuer [1]     
> RelativeDistinguishedName }
> > > 
> > >     ReasonFlags ::= BIT STRING {
> > >          unused                  (0),
> > >          keyCompromise           (1),
> > >          cACompromise            (2),
> > >          affiliationChanged      (3),
> > >          superseded              (4),
> > >          cessationOfOperation    (5),
> > >          certificateHold         (6) }
> > > 
> > 
> 

From: Ambarish Malpani <[email-masked]>
To: Paul Koning <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: New draft - NULL Public Key Signatures
Date: Wed, 27 Oct 1999 11:14:06 -0700

Hi Paul,
    The reason is to allow a way to indicate that something is
not signed even when the formal syntax requires it to be signed.

One example as Marc B. pointed out was unsigned OCSP responses.
Another potential example is to actually issue self-signed certs
with this kind of a signature - to clearly indicate that the
signature on the cert doesn't really mean much.

Another reason was to allow protocols to actually require signatures
everywhere, an support this algorithm if the signature was
optional - for example, in the OCSP protocol, we have an optional
signature section on the request - makes the syntax quite a bit
uglier than just requiring a signature and allowing for NULL
signatures.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 8:09 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: New draft - NULL Public Key Signatures
> 
> 
> I'm not having much success seeing the analogy between Null ESP and
> null signature, nor a reason why the latter is useful and should be
> standardized. 
> 
> Null ESP serves a specific purpose, which is well documented: to
> provide data integrity without simultaneously providing
> confidentiality.  While that's not often desirable, there are
> certainly cases where it is a useful service.
> 
> But I don't see that the analogy carries over to null 
> signatures.  The 
> political/legal issues that stand in the way of universal
> confidentiality don't apply.  As far as I can tell from the RFC, the
> purpose is really just an encoding hack: a way of specifying that
> signatures are omitted without saying it explictly.
> 
> So what good is that?
> 
> 	paul
> 

From: "Salz, Rich" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Interaction of extendedKeyUsage and keyUsage
Date: Wed, 27 Oct 1999 11:43:39 -0400

Hypotheses:
    1 if no KU extension is present, the cert can be used for "anything"
    2 if KU is present, the cert can only be used as specified by the bits
    3 if a particular OID appears in the EKU, the cert can be used as
      specified by that OID.
    4 if the OID does not appear -- or if the EKU is empty -- the cert
      cannot be used
Are those correct?
If so, what happens when #3 meets #1.  E.g., suppose a certificate has
id-kp-OCSPSigning in its EKU as specified by RFC2560. Must it have KU with
digitalSignature, as indicated by RFC2459?

From: Santosh Chokhani <[email-masked]>
To: "'Peter Williams'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: CRL Distribution Points
Date: Wed, 27 Oct 1999 11:15:58 -0400

Peter:

My interpretation of the statement is that the issuer name in the
certificate should match the issuer name in the CRL.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Tuesday, October 26, 1999 8:35 PM
To: Santosh Chokhani; Peter Williams; 'Russ Housley'; [email-masked]
Subject: RE: CRL Distribution Points

> Peter:
> 
> The issuer of the CRL should be identified from issuer name 
> field in the CRL
> and not based on what directory entry or what attribute you 
> queried.  The
> directory is not trusted, the network is not trusted, and 
> there is no strong
> binding between the attribute value and the object/attribute.

But, from the standard(12.6.2	Certificate extension fields)
at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc

"The cRLIssuer component identifies the authority that issues and signs the
CRL. If this component is absent, the CRL issuer name defaults to the
certificate issuer name."

I assume we are going to comply with X.509 concerning
the rules for identifying the issuer of a CRL, as given
above.  If not, the security section of son-of-2459 should
identify that PKIX validation processing is non-conforming with
the ISO standard.  
 
Peter.

> -----Original Message-----
> From: Peter Williams [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 8:02 PM
> To: Santosh Chokhani; 'Russ Housley'; [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> Russ,
> 
> You need to ensure that an indirect issuer of the
> CRL fragment can be identified, so that the signature
> can be appropriately verified, as per the X.509 model.
> 
> How would we do that with your standard today? - whilst
> also pointing to the location of the value in 
> a directory/uri-resolver?
>  
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Tuesday, October 26, 1999 4:39 PM
> > To: 'Russ Housley'; [email-masked]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Russ:
> > 
> > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > idea to include
> > Annex M, point to it or borrow the applicable sections in the 
> > PKIX RFC.
> > 
> > -----Original Message-----
> > From: Russ Housley [mailto:[email-masked]]
> > Sent: Tuesday, October 26, 1999 12:58 PM
> > To: [email-masked]
> > Subject: CRL Distribution Points
> > 
> > 
> > In reviewing the document that Tim recently posted, I 
> > realized that we were 
> > not really clear about the semantics of a DistributionPoint 
> > with an absent 
> > distributionPoint, a present reasons, and a present 
> > cRLIssuer.  The ASN.1 
> > is repeated below for those who have not memorized it.
> > 
> > If the cRLDistributionPoints extension does not contain a 
> > DistributionPointName, but does contain a cRLIssuer, then following 
> > semantics MUST be assumed:
> > 
> > 1) If the cRLIssuer is of type directoryName, then the 
> > certificateRevocationList attribute in the Directory entry of 
> > the cRLIssuer 
> > contains the current CRL for the associated reasons.
> > 
> > 2) If the cRLIssuer is of type URI, then the URI is a 
> pointer to the 
> > current CRL for the associated reasons.  The expected values 
> > for the URI 
> > are those defined in 4.2.1.7.
> > 
> > 3) Processing rules for other values are not defined by this 
> > specification.
> > 
> > Does this seem right?
> > 
> > Russ
> > 
> > = = = = = = = = = =
> > 
> >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > DistributionPoint
> > 
> >     DistributionPoint ::= SEQUENCE {
> >          distributionPoint       [0]     
> > DistributionPointName OPTIONAL,
> >          reasons                 [1]     ReasonFlags OPTIONAL,
> >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > 
> >     DistributionPointName ::= CHOICE {
> >          fullName                [0]     GeneralNames,
> >          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> > 
> >     ReasonFlags ::= BIT STRING {
> >          unused                  (0),
> >          keyCompromise           (1),
> >          cACompromise            (2),
> >          affiliationChanged      (3),
> >          superseded              (4),
> >          cessationOfOperation    (5),
> >          certificateHold         (6) }
> > 
> 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-00.txt
Date: Wed, 27 Oct 1999 08:48:26 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Certificate and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-00.txt
	Pages		: 143
	Date		: 26-Oct-99
	
This is the first draft of a specification based upon RFC 2459.  When
complete, this specification will obsolete RFC 2459.  This
specification includes numerous 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.  However,
parameter inheritance was omitted from the path validation algorithm in RFC 2459.  In this draft, the path validation algorithm has a
comprehensive and extremely detailed description.  Details such as
parameter inheritance are covered thoroughly.  In addition, this
draft anticipates certain corrections proposed in the X.509 standard
for the policy processing aspects of path validation.
A new section 6.3, CRL validation, has been added as well.  This
section provides a supplement to the path validation algorithm that
determines if a particular CRL may be used to verify the status of a
particular certificate.  (The basic path validation algorithm is, by
design, independent of the type and format of status information.)
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet.  An overview of the approach and model are provided
as an introduction.  The X.509 v3 certificate format is described in
detail, with additional information regarding the format and
semantics of Internet name forms (e.g., IP addresses).  Standard
certificate extensions are described and one new Internet-specific
extension is defined.  A required set of certificate extensions is
specified.  The X.509 v2 CRL format is described and a required
extension set is defined as well.  An algorithm for X.509 certificate
path validation is described. Supplemental infor

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-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-new-part1-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-new-part1-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-new-part1-00.txt

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

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

--OtherAccess--

--NextPart--

Reply-To: "eZDesk.com" <[email-masked]>
From: "eZDesk.com" <[email-masked]>
To: <[email-masked]>
Subject: New Loan Product Release
Date: Wed, 27 Oct 1999 06:39:10 -0500
Organization: EFS, Inc. d/b/a eZDesk.com

Using your EXISTING Loan System (windows), you can send
loan documents directly to anyone with just a click !

Click2Doc(TM) makes it easy.  Think!  FREE same day delivery of loan
docs, disclosures, applications, approvals, conditions, etc. to anyone by
email.  Recipient needs NO software.  NO plugins.  NO downloads.  They can
save, view, print.  Documents Set can be password protected.

www.Click2Doc.com

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Certificate Management Messages over CMS to Proposed Standard
Reply-to: [email-masked]
Date: Wed, 27 Oct 1999 07:29:41 -0400
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Certificate Management Messages over
CMS <draft-ietf-pkix-cmc-05.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by November 16, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-05.txt

From: "GMT" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: TYPO in Roadmap-04 re BERT 
Date: Tue, 26 Oct 1999 19:38:56 -0700

FYI  All - BERT is not dead. The concluding statement in the PKI Roadmap is
incorrect here.

The BERT Token Specification is undergoing a redesign to allow it to support
virtually any kind of event representation. It also will have a predefined
set of event types including a Notarial Subtoken complete with a
ceremony-service marker. The token structure will represent a digital
harness with an encoded and protected manifest. This will allow the modular
plugging in of a number of optional token components to create an
interoperable policy centric token. - the ultimate timestamp so to speak -

Anyway, the new token structure will also have an applications and Network
transparent API to address the marking, validating, and verifying of
virtually all events in time and space. We feel this is the start of "agency
control" and conveyance models and that they will operate  by demonstrating
the intent of the user. These token data structures and the API for managing
them are very important to eCommerce and will be of more important to PKIX
as the evolution of the Internet and Global ECommerce continues.

The currently underway draft will not make this meeting but will be filed
shortly afterward and will be available for comment as such prior to the
next meeting.

If I can answer any questions in the mean time please feel free to contact
me or Michael directly

[email-masked]
[email-masked]

Todd Glassey

> Todd:
>
> Here's the BERT excerpt from the roadmap, published Oct 22...note the
> status at the end.
>
>    DOCUMENT TITLE: Basic Event Representation Token <draft-ietf-pkix-
>    bert1-01.txt>
>
>    DESCRIPTION: This document defines a finite method of representing a
>    discrete instant in time as a referable event. The Basic Event
>    Representation Token (BERT) is a light-weight binary token designed
>    for use in large numbers over short periods of time. The tokens
>    contain only a single instance of an event stamp and the trust
>    process is referenced against an external reference.
>
>    STATUS: Work has been discontinued.
>
>

From: Peter Williams <[email-masked]>
To: Santosh Chokhani <[email-masked]>, Peter Williams <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: CRL Distribution Points
Date: Tue, 26 Oct 1999 17:35:25 -0700

> Peter:
> 
> The issuer of the CRL should be identified from issuer name 
> field in the CRL
> and not based on what directory entry or what attribute you 
> queried.  The
> directory is not trusted, the network is not trusted, and 
> there is no strong
> binding between the attribute value and the object/attribute.

But, from the standard(12.6.2	Certificate extension fields)
at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc

"The cRLIssuer component identifies the authority that issues and signs the
CRL. If this component is absent, the CRL issuer name defaults to the
certificate issuer name."

I assume we are going to comply with X.509 concerning
the rules for identifying the issuer of a CRL, as given
above.  If not, the security section of son-of-2459 should
identify that PKIX validation processing is non-conforming with
the ISO standard.  
 
Peter.

> -----Original Message-----
> From: Peter Williams [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 8:02 PM
> To: Santosh Chokhani; 'Russ Housley'; [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> Russ,
> 
> You need to ensure that an indirect issuer of the
> CRL fragment can be identified, so that the signature
> can be appropriately verified, as per the X.509 model.
> 
> How would we do that with your standard today? - whilst
> also pointing to the location of the value in 
> a directory/uri-resolver?
>  
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Tuesday, October 26, 1999 4:39 PM
> > To: 'Russ Housley'; [email-masked]
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Russ:
> > 
> > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > idea to include
> > Annex M, point to it or borrow the applicable sections in the 
> > PKIX RFC.
> > 
> > -----Original Message-----
> > From: Russ Housley [mailto:[email-masked]]
> > Sent: Tuesday, October 26, 1999 12:58 PM
> > To: [email-masked]
> > Subject: CRL Distribution Points
> > 
> > 
> > In reviewing the document that Tim recently posted, I 
> > realized that we were 
> > not really clear about the semantics of a DistributionPoint 
> > with an absent 
> > distributionPoint, a present reasons, and a present 
> > cRLIssuer.  The ASN.1 
> > is repeated below for those who have not memorized it.
> > 
> > If the cRLDistributionPoints extension does not contain a 
> > DistributionPointName, but does contain a cRLIssuer, then following 
> > semantics MUST be assumed:
> > 
> > 1) If the cRLIssuer is of type directoryName, then the 
> > certificateRevocationList attribute in the Directory entry of 
> > the cRLIssuer 
> > contains the current CRL for the associated reasons.
> > 
> > 2) If the cRLIssuer is of type URI, then the URI is a 
> pointer to the 
> > current CRL for the associated reasons.  The expected values 
> > for the URI 
> > are those defined in 4.2.1.7.
> > 
> > 3) Processing rules for other values are not defined by this 
> > specification.
> > 
> > Does this seem right?
> > 
> > Russ
> > 
> > = = = = = = = = = =
> > 
> >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > DistributionPoint
> > 
> >     DistributionPoint ::= SEQUENCE {
> >          distributionPoint       [0]     
> > DistributionPointName OPTIONAL,
> >          reasons                 [1]     ReasonFlags OPTIONAL,
> >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > 
> >     DistributionPointName ::= CHOICE {
> >          fullName                [0]     GeneralNames,
> >          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> > 
> >     ReasonFlags ::= BIT STRING {
> >          unused                  (0),
> >          keyCompromise           (1),
> >          cACompromise            (2),
> >          affiliationChanged      (3),
> >          superseded              (4),
> >          cessationOfOperation    (5),
> >          certificateHold         (6) }
> > 
> 

From: Santosh Chokhani <[email-masked]>
To: "'Peter Williams'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: CRL Distribution Points
Date: Tue, 26 Oct 1999 20:11:47 -0400

Peter:

The issuer of the CRL should be identified from issuer name field in the CRL
and not based on what directory entry or what attribute you queried.  The
directory is not trusted, the network is not trusted, and there is no strong
binding between the attribute value and the object/attribute.

-----Original Message-----
From: Peter Williams [mailto:[email-masked]]
Sent: Tuesday, October 26, 1999 8:02 PM
To: Santosh Chokhani; 'Russ Housley'; [email-masked]
Subject: RE: CRL Distribution Points

Russ,

You need to ensure that an indirect issuer of the
CRL fragment can be identified, so that the signature
can be appropriately verified, as per the X.509 model.

How would we do that with your standard today? - whilst
also pointing to the location of the value in 
a directory/uri-resolver?

> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 4:39 PM
> To: 'Russ Housley'; [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> Russ:
> 
> Please Annex M on X.509 Draft Amendment.  It will be a good 
> idea to include
> Annex M, point to it or borrow the applicable sections in the 
> PKIX RFC.
> 
> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 12:58 PM
> To: [email-masked]
> Subject: CRL Distribution Points
> 
> 
> In reviewing the document that Tim recently posted, I 
> realized that we were 
> not really clear about the semantics of a DistributionPoint 
> with an absent 
> distributionPoint, a present reasons, and a present 
> cRLIssuer.  The ASN.1 
> is repeated below for those who have not memorized it.
> 
> If the cRLDistributionPoints extension does not contain a 
> DistributionPointName, but does contain a cRLIssuer, then following 
> semantics MUST be assumed:
> 
> 1) If the cRLIssuer is of type directoryName, then the 
> certificateRevocationList attribute in the Directory entry of 
> the cRLIssuer 
> contains the current CRL for the associated reasons.
> 
> 2) If the cRLIssuer is of type URI, then the URI is a pointer to the 
> current CRL for the associated reasons.  The expected values 
> for the URI 
> are those defined in 4.2.1.7.
> 
> 3) Processing rules for other values are not defined by this 
> specification.
> 
> Does this seem right?
> 
> Russ
> 
> = = = = = = = = = =
> 
>     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> DistributionPoint
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     
> DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
>     DistributionPointName ::= CHOICE {
>          fullName                [0]     GeneralNames,
>          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> 
>     ReasonFlags ::= BIT STRING {
>          unused                  (0),
>          keyCompromise           (1),
>          cACompromise            (2),
>          affiliationChanged      (3),
>          superseded              (4),
>          cessationOfOperation    (5),
>          certificateHold         (6) }
> 

From: Peter Williams <[email-masked]>
To: Santosh Chokhani <[email-masked]>, "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: CRL Distribution Points
Date: Tue, 26 Oct 1999 17:01:44 -0700

Russ,

You need to ensure that an indirect issuer of the
CRL fragment can be identified, so that the signature
can be appropriately verified, as per the X.509 model.

How would we do that with your standard today? - whilst
also pointing to the location of the value in 
a directory/uri-resolver?

> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 4:39 PM
> To: 'Russ Housley'; [email-masked]
> Subject: RE: CRL Distribution Points
> 
> 
> Russ:
> 
> Please Annex M on X.509 Draft Amendment.  It will be a good 
> idea to include
> Annex M, point to it or borrow the applicable sections in the 
> PKIX RFC.
> 
> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Tuesday, October 26, 1999 12:58 PM
> To: [email-masked]
> Subject: CRL Distribution Points
> 
> 
> In reviewing the document that Tim recently posted, I 
> realized that we were 
> not really clear about the semantics of a DistributionPoint 
> with an absent 
> distributionPoint, a present reasons, and a present 
> cRLIssuer.  The ASN.1 
> is repeated below for those who have not memorized it.
> 
> If the cRLDistributionPoints extension does not contain a 
> DistributionPointName, but does contain a cRLIssuer, then following 
> semantics MUST be assumed:
> 
> 1) If the cRLIssuer is of type directoryName, then the 
> certificateRevocationList attribute in the Directory entry of 
> the cRLIssuer 
> contains the current CRL for the associated reasons.
> 
> 2) If the cRLIssuer is of type URI, then the URI is a pointer to the 
> current CRL for the associated reasons.  The expected values 
> for the URI 
> are those defined in 4.2.1.7.
> 
> 3) Processing rules for other values are not defined by this 
> specification.
> 
> Does this seem right?
> 
> Russ
> 
> = = = = = = = = = =
> 
>     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> DistributionPoint
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     
> DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
>     DistributionPointName ::= CHOICE {
>          fullName                [0]     GeneralNames,
>          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> 
>     ReasonFlags ::= BIT STRING {
>          unused                  (0),
>          keyCompromise           (1),
>          cACompromise            (2),
>          affiliationChanged      (3),
>          superseded              (4),
>          cessationOfOperation    (5),
>          certificateHold         (6) }
> 

From: Santosh Chokhani <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: CRL Distribution Points
Date: Tue, 26 Oct 1999 19:39:00 -0400

Russ:

Please Annex M on X.509 Draft Amendment.  It will be a good idea to include
Annex M, point to it or borrow the applicable sections in the PKIX RFC.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Tuesday, October 26, 1999 12:58 PM
To: [email-masked]
Subject: CRL Distribution Points

In reviewing the document that Tim recently posted, I realized that we were 
not really clear about the semantics of a DistributionPoint with an absent 
distributionPoint, a present reasons, and a present cRLIssuer.  The ASN.1 
is repeated below for those who have not memorized it.

If the cRLDistributionPoints extension does not contain a 
DistributionPointName, but does contain a cRLIssuer, then following 
semantics MUST be assumed:

1) If the cRLIssuer is of type directoryName, then the 
certificateRevocationList attribute in the Directory entry of the cRLIssuer 
contains the current CRL for the associated reasons.

2) If the cRLIssuer is of type URI, then the URI is a pointer to the 
current CRL for the associated reasons.  The expected values for the URI 
are those defined in 4.2.1.7.

3) Processing rules for other values are not defined by this specification.

Does this seem right?

Russ

= = = = = = = = = =

    CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

    DistributionPointName ::= CHOICE {
         fullName                [0]     GeneralNames,
         nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

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

Date: Tue, 26 Oct 1999 19:30:17 -0500
To: Warwick Ford <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: FW: ISC Meeting Notice - Nov. 8-11, Washington, DC
Cc: "[email-masked]'" <[email-masked]>, [email-masked]

Here is what the IETF has planned for Thursday morning.  Several of the 
people that are active in PKIX are also active in S/MIME.  This scheduling 
conflict is quite unfortunate.

Russ

THURSDAY, November 11, 1999
0800-1700  IETF Registration - West Conference Center
0800-0900  Continental Breakfast -
0900-1130  Morning Sessions
         APP  fax        Internet Fax WG
         APP  mmms       Mobile Multimedia Messaging Service BOF
         OPS  tewg       Internet Traffic Engineering WG
         RTG  mobileip   IP Routing for Wireless/Mobile Hosts WG
         SEC  smime      S/MIME Mail Security WG
         TSV  avt        Audio/Video Transport WG *

At 08:36 AM 10/18/99 -0700, Warwick Ford wrote:
>FYI, attached is the meeting notice for the next American Bar Association
>Information Security Committee meeting, which is scheduled for Washington DC
>the same week as the IETF.  To take advantage of this co-location, the ABA
>group has requested a meeting with PKIX experts to discuss various topics of
>mutual interest.  Accordingly, an unofficial joint meeting has been
>scheduled for the Thursday morning 11/11.  This meeting has no official
>status in the IETF and anyone is welcome to attend.  We don't have a venue
>yet, so any offers to host that meeting will be appreciated.  (Maybe 30-40
>people(?), preferably close to the Omni Shoreham.)
>
>Warwick
>

Date: Tue, 26 Oct 1999 19:25:15 -0500
To: "Xiong Shao Jun" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: directory entry with NULL DN
Cc: [email-masked]

NULL DNs are intended for use in environments where the subject does not 
have a DN.  If your subject has an LDAP entry, it has a DN, so you should 
populate it.

Russ

At 04:08 PM 10/24/99 +0800, Xiong Shao Jun wrote:
>Hi, there. I posted a mail a few days ago, but received no reply.
>I have some questions about rfc2587. If a PKI subject has null
>DN in certificate, how can it have an entry in LDAP?
>
>Thanx in advance.
>
>Xiong Shaojun
>China Merchants Bank

Date: Tue, 26 Oct 1999 11:57:54 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: CRL Distribution Points

In reviewing the document that Tim recently posted, I realized that we were 
not really clear about the semantics of a DistributionPoint with an absent 
distributionPoint, a present reasons, and a present cRLIssuer.  The ASN.1 
is repeated below for those who have not memorized it.

If the cRLDistributionPoints extension does not contain a 
DistributionPointName, but does contain a cRLIssuer, then following 
semantics MUST be assumed:

1) If the cRLIssuer is of type directoryName, then the 
certificateRevocationList attribute in the Directory entry of the cRLIssuer 
contains the current CRL for the associated reasons.

2) If the cRLIssuer is of type URI, then the URI is a pointer to the 
current CRL for the associated reasons.  The expected values for the URI 
are those defined in 4.2.1.7.

3) Processing rules for other values are not defined by this specification.

Does this seem right?

Russ

= = = = = = = = = =

    CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

    DistributionPointName ::= CHOICE {
         fullName                [0]     GeneralNames,
         nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

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

Date: Tue, 26 Oct 1999 15:47:04 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: New version of PKIX - IPsec draft

draft-ietf-ipsec-pki-req-03.txt is out and being discussed in the IPsec WG. 
Information on that WG can be found at <http://www.vpnc.org/ietf-ipsec/>.

--Paul Hoffman, Director
--VPN Consortium

Date: Tue, 26 Oct 1999 15:38:45 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: New version of PKIX - IPsec draft

draft-ietf-ipsec-pki-req-03.txt is out and being discussed in the IPsec WG. 
Information on that WG can be found at <http://www.vpnc.org/ietf-ipsec/>.

--Paul Hoffman, Director
--VPN Consortium

Organization: ESAT, K.U.Leuven, Belgium
Date: Tue, 26 Oct 1999 22:17:59 +0200 (CEST)
From: Eurocrypt 2000 <[email-masked]>
To: [email-masked]
Subject: Eurocrypt 2000 submission deadline: November 3, 1999

-------------------------------------------------------------
                  E U R O C R Y P T    2 0 0 0
                         May 14-18, 2000
                    Bruges (Brugge), Belgium

     http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/
-------------------------------------------------------------

This is a reminder that the submission deadline for 
Eurocrypt 2000 is November 3, 1999. 

Visit http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/ 
for more information.

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

Sender: [email-masked]
Date: Tue, 26 Oct 1999 11:17:51 -0700
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Re: New draft - NULL Public Key Signatures

Phillip M Hallam-Baker wrote:
> 
> Steve,
> 
>         Yes, I agree that the joke is pretty funny. I don't think turning
> it into an RFC would improve the joke, and we may well find that the
> joke ends up being on us.
> 
>         Given the ability of companies to mess up big time I can well imagine
> some company selling a product claiming to be PKIX compliant, offering only
> the NULL signature, export rules, licensing restrictions already mean that
> many products ship requiring a crypto engine to be obtained elsewhere.
> 

The absence of a NPKA RFC doesn't prevent that.  Nothing in PKIX says that
you MUST (or even SHOULD) support any particular crypto algorithm, or even a
particular OID for a particular algorithm.

>         If the product runs without security it is inevitable that someone will
> use it without. I remember a while back when I persuaded a company that they
> had a problem with a crypto implementation, sent them extensive
> documentation
> on the changes needed. A year later the product was broken with great media
> fanfare. Turns out my memo had made it to the documentation but not the
> code.
> 

I, for one, am not advocating that anything be able to run without security. 
I don't see what the big deal is about standardizing this.  Like everything
else, those of us who know what we're doing won't hang ourselves with this
rope.  Sure, some idiot might misuse the standard, but the IETF can't prevent
that from happening.  The proper forum to address those kinds of concerns is
something like a PKI accreditation body, that certifies a given level of
conformance.

>         Or it may just be that I am in a particularly humourless mood given
> that there are a couple of nuclear plants in the vicinity and I have been
> assured via the television that the events which occurred in Japan could
> not occur in the US by 'experts' who clearly lack the level of knowledge of
> nuclear processes taught at UK high schools.
> 
>         This thing we are building has to be usable by folk who _have_ a
> degree in Nuclear Physics :-)
> 
>         Folk who need a NULL signature for Test purposes will probably find
> that SHA-1 or MD5 can be used to the same effect, with the significant
> advantage that integrity problems are revealled. I have a serious concern
> that applying NULL in the context envisaged by Marc may remove an integrity
> check which in the pure SSL context is not significant but which becomes
> significant in a hybrid SSL/message passing system.
> 

Which kind of hybrid contexts are you referring to?  Actually, the answer
isn't that important -- there'll always be some way to abuse the system.  The
existence of such possibilities shouldn't stop us from agreeing on a
technical standard.

>         The overhead of SHA-1 is low, we already have the OID. Ergo no need
> for a NULL draft to confuse the befuddled holders of doctorates in nuclear
> physics.
> 

The availability of SHA-1 isn't the point.  In fact, using a raw digest
algorithm instead of an "officially" NULL signature is really just muddying
the waters without adding any kind of security benefit.  So there's a digest
of the pack/blob/message?  It doesn't achieve anything.  Much better to
explicitly say "I'm not including any integrity/authentication here, where
you might expect to see it.  You should derive integrity and/or
authentication some other way."

		Marc

p.s. - As to the humour in the draft, let me proclaim my support for as much
humour as possible in these documents.  The stuff's hard enough to read as it
is.  But, if humour upsets people, then I can live (well, exist, really)
without it.

Date: Tue, 26 Oct 1999 11:09:13 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: New draft - NULL Public Key Signatures

I'm not having much success seeing the analogy between Null ESP and
null signature, nor a reason why the latter is useful and should be
standardized. 

Null ESP serves a specific purpose, which is well documented: to
provide data integrity without simultaneously providing
confidentiality.  While that's not often desirable, there are
certainly cases where it is a useful service.

But I don't see that the analogy carries over to null signatures.  The 
political/legal issues that stand in the way of universal
confidentiality don't apply.  As far as I can tell from the RFC, the
purpose is really just an encoding hack: a way of specifying that
signatures are omitted without saying it explictly.

So what good is that?

	paul

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: New draft - NULL Public Key Signatures
Date: Tue, 26 Oct 1999 10:52:14 -0400
Importance: Normal

Steve,

	Yes, I agree that the joke is pretty funny. I don't think turning
it into an RFC would improve the joke, and we may well find that the
joke ends up being on us.

	Given the ability of companies to mess up big time I can well imagine
some company selling a product claiming to be PKIX compliant, offering only
the NULL signature, export rules, licensing restrictions already mean that
many products ship requiring a crypto engine to be obtained elsewhere.

	If the product runs without security it is inevitable that someone will
use it without. I remember a while back when I persuaded a company that they
had a problem with a crypto implementation, sent them extensive
documentation
on the changes needed. A year later the product was broken with great media
fanfare. Turns out my memo had made it to the documentation but not the
code.

	Or it may just be that I am in a particularly humourless mood given
that there are a couple of nuclear plants in the vicinity and I have been
assured via the television that the events which occurred in Japan could
not occur in the US by 'experts' who clearly lack the level of knowledge of
nuclear processes taught at UK high schools.

	This thing we are building has to be usable by folk who _have_ a
degree in Nuclear Physics :-)

	Folk who need a NULL signature for Test purposes will probably find
that SHA-1 or MD5 can be used to the same effect, with the significant
advantage that integrity problems are revealled. I have a serious concern
that applying NULL in the context envisaged by Marc may remove an integrity
check which in the pure SSL context is not significant but which becomes
significant in a hybrid SSL/message passing system.

	The overhead of SHA-1 is low, we already have the OID. Ergo no need
for a NULL draft to confuse the befuddled holders of doctorates in nuclear
physics.

		Phill

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Monday, October 25, 1999 10:15 PM
> To: Phillip M Hallam-Baker
> Cc: [email-masked]
> Subject: RE: New draft - NULL Public Key Signatures
>
>
> Phill & Marc,
>
> This draft, which Ambarish and I discussed months ago, is written in the
> same spirit as RFC 2410, the NULL encryption algorithm and its use in ESP.
> Maybe we can clue in the otherwise clusless in the security considerations
> section, but we have precedent for this style of RFC. I didn't think of it
> as anything but a fun document which serves a very minimal (technical)
> purpose, but maybe my co-conspirator had more ambitious plans.
>
> Steve
>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-roadmap-04.txt
Date: Tue, 26 Oct 1999 07:25:06 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure PKIX Roadmap
	Author(s)	: A. Arsenault, S. Turner
	Filename	: draft-ietf-pkix-roadmap-04.txt
	Pages		: 40
	Date		: 22-Oct-99
	
This document provides an overview or 'roadmap' of the work done by
the IETF PKIX working group. It describes some of the terminology
used in the working group's documents, and the theory behind an
X.509-based Public Key Infrastructure and Privilege Management
Infrastructure (PMI). It identifies each document developed by the
PKIX working group, and describes the relationships among the various
documents. It also provides advice to would-be PKIX implementors
about some of the issues discussed at length during PKIX development,
in hopes of making it easier to build implementations that will
actually interoperate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-04.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-roadmap-04.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-roadmap-04.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-roadmap-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-roadmap-04.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-ecdsa-02.txt
Date: Tue, 26 Oct 1999 07:25:00 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure  
                          Representation of Elliptic Curve Digital Signature    
                          Algorithm (ECDSA) Keys and Signatures in Internet     
                          X.509 Public Key Infrastructure Certificates
	Author(s)	: L. Bassham, D. Johnson, W. Polk
	Filename	: draft-ietf-pkix-ipki-ecdsa-02.txt
	Pages		: 15
	Date		: 22-Oct-99
	
This is the third draft of a profile for specification of Elliptic
Curve Digital Signature Algorithm (ECDSA) keys and signatures in
Internet Public Key Infrastructure X.509 certificates and certificate
revocation lists. This specification is an addendum to RFC 2459;
implementations must also conform to RFC 2459.  In addition, this
document references ANSI X9.62 for the specification of the ECDSA
algorithm.  This specification only addresses the format of ECDSA
keys and signatures.  Please send comments on this document to the
[email-masked] mail list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-ecdsa-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-ecdsa-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-ecdsa-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-ecdsa-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 26 Oct 1999 12:35:25 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Comments on dhpop-02

Comments on draft-ietf-pkix-dhpop-02

The following comments are mainly presentation and vocabulary
oriented.

For the presentation, I read the document twice but could not have a
clear view of the description being made. I would guess that I would
need much more time to understand it, which I don't have.

This means that the document should be improved to ease the reading.
In particular the document refers upfront to two algorithms which
are not clearly referenced afterwards. The relationship between
sections 3,4 and 5 is not crystal clear.

My main concerns are vocabulary related. The document makes use of
the word "signature" whereas no signature is ever involved. 

I understand a signature as being verifiable by anyone. If it is
only verifiable (and thus forgeable) by one verifier, then it is
only an integrity check value.

The use of the word "signature" should be avoided and several
replacements are proposed. 

The current abstract is:

This document describes two methods for producing a signature from a
Diffie-Hellman key pair.  This behavior is needed for such
operations as creating a signature of a PKCS #10 certification
request.  These algorithms are designed to provide a proof-of-
possession rather than general purpose signing.

I would propose the following:

This document describes two methods for producing an integrity check
value from a Diffie-Hellman key pair.  This behavior is needed for
such operations as creating an integrity check value of a PKCS #10
certification request.  These algorithms are designed to provide a
proof-of- possession rather than general purpose signing.

Then, in the introduction, I would propose:

This document describes two new data origin authentication
algorithms using the Diffie- Hellman key agreement process to
provide a shared secret as the basis for the construction of an
integrity check value. With the first algorithm, the integrity check
value is constructed for a specific recipient/verifier by using a
D-H public key of that verifier.  With the second algorithm, the
integrity check value is constructed for arbitrary verifiers.  This
is done by creating an appropriate D-H key pair and using it for the
creation of the integrity check value.

The title of section 2 should be " Using DH Ephemeral keys for the
authentication process" and the next sentence: 

   The steps for creating a DH-based integrity check value are:

This does not provide all the changes required in the document but
gives the general direction for the replacements.

And additional unrelated topic. LeadingInfo and TrailingInfo are
introduced in section 3, page 3, item c) but only explained on the
next page in section 4. It would be good to move the explanations in
section 3. 

Denis

Date: Mon, 25 Oct 1999 19:59:58 -0700
From: Ed Gerck <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Phillip M Hallam-Baker <[email-masked]>, [email-masked]
Subject: Re: New draft - NULL Public Key Signatures

Stephen Kent wrote:

> Phill & Marc,
>
> This draft, which Ambarish and I discussed months ago, is written in the
> same spirit as RFC 2410, the NULL encryption algorithm and its use in ESP.
> Maybe we can clue in the otherwise clusless in the security considerations
> section, but we have precedent for this style of RFC.

If you mean the section:

   NULL is a block cipher the origins of which appear to be lost in
   antiquity.  Despite rumors that the National Security Agency
   suppressed publication of this algorithm, there is no evidence of
   such action on their part. Rather, recent archaeological evidence
   suggests that the NULL algorithm was developed in Roman times, as an
   exportable alternative to Ceaser ciphers. However, because Roman
   numerals lack a symbol for zero, written records of the algorithm's
   development were lost to historians for over two millennia.

then out of place humor has just been redefined. Maybe it is indeed
time to consider technical writing rules when submitting RFCs, which
do not have to include references to "Ceaser" [SIC] in order to be
interesting.

Cheers,

Ed Gerck

From: "Anders Rundgren" <[email-masked]>
To: "'SEIS-List'" <[email-masked]>, <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: "Magnus (RSA)" <[email-masked]>
Subject: Re: QC certificates MAY CERTAINLY be compared!
Date: Tue, 26 Oct 1999 04:31:14 +0100

Stefan,

1. The QC statemnent in question does not mention *different* issuers

2. The statement is still incorrect when applied to SEIS-cards from different
issuers as unique identity in those is "person-number" and nothing else.  Name is volatile.
I.e. SEIS-certs may very well be compared but you must restrict the comparision to
the attributes that form the STATIC and unique identity.  Regardless if the certs
are issued from the same or different issuers.

3.  No comments to the Container-ID stuff?

/Anders

-----Original Message-----
From: Stefan Santesson <[email-masked]>
To: Anders Rundgren <[email-masked]>; 'SEIS-List' <[email-masked]>; [email-masked] <[email-masked]>
Cc: Magnus (RSA) <[email-masked]>
Date: Monday, October 25, 1999 22:56
Subject: Re: QC certificates MAY CERTAINLY be compared!

Anders,

This is a consequence of the profile, not an opinion of utilization.

If you have two certificates issued by different issuers, and you compare
these certificates and find differences in the subject names, then you may
not be able to tell if these certificates are issued to the same individual
or not. At least not on the basis of what is defined in the QC profile.

This does not mean that you can not do name comparison in a "controlled
environment" based on some other knowledge.

/Stefan

At 17:55 1999-10-25 +0100, Anders Rundgren wrote:
>Stefan,
>I have said it before and I say it again.  The following QC-statement is 
>higly doubtful:
>
>"Comparing two qualified certificates to determine if they represent
> the same physical entity may provide misleading results and should
> not be performed"
>
>As you know our famous (?) SEIS-card does indeed allow certificates to
>be compared for subject identity.   That is IMO the whole (and only) point 
>with *real* ID-cards!
>
>So this is a statement of the CPS.  Not of the draft.
>
>
>
>BTW, why no explicit support for "container ID" (card serial) as most QCs 
>will be
>put in smart cards?  It was in SEIS already.
>
>
>Anders
>
>
>-----Original Message-----
>From: Stefan Santesson <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Monday, October 25, 1999 14:14
>Subject: New submitted draft for Qualified Certificates
>
>
>>All,
>>
>>A new draft for a Qualified Certificates Profile was submitted friday 22.
>>
>>The new draft can be obtained from:
>>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>>
>>The QC website has been udated accrodingly:
>>http://www.accurata.se/QC/
>>
>>See also under settled topics to obtain information about major
>>considerations since the last draft.
>>
>>/Stefan
>>-------------------------------------------------------------------
>>Stefan Santesson                <[email-masked]>
>>Accurata AB                     http://www.accurata.se
>>Slagthuset                      Tel. +46-40 108588              
>>211 20  Malmö                   Fax. +46-40 150790              
>>Sweden                        Mobile +46-70 5247799
>>
>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>-------------------------------------------------------------------
>>

Date: Mon, 25 Oct 1999 22:14:39 -0400
To: "Phillip M Hallam-Baker" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: New draft - NULL Public Key Signatures
Cc: <[email-masked]>

Phill & Marc,

This draft, which Ambarish and I discussed months ago, is written in the
same spirit as RFC 2410, the NULL encryption algorithm and its use in ESP.
Maybe we can clue in the otherwise clusless in the security considerations
section, but we have precedent for this style of RFC. I didn't think of it
as anything but a fun document which serves a very minimal (technical)
purpose, but maybe my co-conspirator had more ambitious plans.

Steve

Date: Mon, 25 Oct 1999 19:12:26 -0700
From: Ed Gerck <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-roadmap-04.txt

[email-masked] wrote:

> 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 PKIX Roadmap
>         Author(s)       : A. Arsenault, S. Turner
>         Filename        : draft-ietf-pkix-roadmap-04.txt
>         Pages           : 40
>         Date            : 22-Oct-99

>From the above draft:

   According to [SIMONETTI], the intent is that the digitalSignature bit
   should be set when what is desired is the ability to sign ephemeral
   transactions; e.g., for a single session authentication. These
   transactions are "ephemeral" in the sense that they are important
   only while they are in existence; after the session is terminated,
   there is no long-term record of the digital signature and its
   properties kept. When something is intended to be kept for some
   period of time, the nonRepudiation bit should be set.

The last phrase finds no support on what was discussed in this WG,
non-repudiation is not a non-ephemeral digital signature.

There are also other instances where the draft finds no support in
the WG discussions, even when it says it has:

    The discussion on the PKIX mailing list has centered on the
   digitalSignature bit and the nonRepudiation bit. The question has
   come down to something like: When support for the service of non-
   repudiation is desired, should both the digitalSignature and
   nonRepudiation bits be set, or just the nonRepudiation bit?

because this question was neither substantive nor representative
of the discussions -- unless "has come down to" means something
else.

Cheers,

Ed Gerck

Date: Tue, 26 Oct 1999 00:01:12 +0200
To: "Anders Rundgren" <[email-masked]>, "'SEIS-List'" <[email-masked]>, <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: QC certificates MAY CERTAINLY be compared!
Cc: "Magnus (RSA)" <[email-masked]>

Anders,

This is a consequence of the profile, not an opinion of utilization.

If you have two certificates issued by different issuers, and you compare
these certificates and find differences in the subject names, then you may
not be able to tell if these certificates are issued to the same individual
or not. At least not on the basis of what is defined in the QC profile.

This does not mean that you can not do name comparison in a "controlled
environment" based on some other knowledge.

/Stefan

At 17:55 1999-10-25 +0100, Anders Rundgren wrote:
>Stefan,
>I have said it before and I say it again.  The following QC-statement is 
>higly doubtful:
>
>"Comparing two qualified certificates to determine if they represent
> the same physical entity may provide misleading results and should
> not be performed"
>
>As you know our famous (?) SEIS-card does indeed allow certificates to
>be compared for subject identity.   That is IMO the whole (and only) point 
>with *real* ID-cards!
>
>So this is a statement of the CPS.  Not of the draft.
>
>
>
>BTW, why no explicit support for "container ID" (card serial) as most QCs 
>will be
>put in smart cards?  It was in SEIS already.
>
>
>Anders
>
>
>-----Original Message-----
>From: Stefan Santesson <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Monday, October 25, 1999 14:14
>Subject: New submitted draft for Qualified Certificates
>
>
>>All,
>>
>>A new draft for a Qualified Certificates Profile was submitted friday 22.
>>
>>The new draft can be obtained from:
>>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>>
>>The QC website has been udated accrodingly:
>>http://www.accurata.se/QC/
>>
>>See also under settled topics to obtain information about major
>>considerations since the last draft.
>>
>>/Stefan
>>-------------------------------------------------------------------
>>Stefan Santesson                <[email-masked]>
>>Accurata AB                     http://www.accurata.se
>>Slagthuset                      Tel. +46-40 108588              
>>211 20  Malmö                   Fax. +46-40 150790              
>>Sweden                        Mobile +46-70 5247799
>>
>>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>>-------------------------------------------------------------------
>>

Sender: [email-masked]
Date: Mon, 25 Oct 1999 14:37:22 -0700
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Re: New draft - NULL Public Key Signatures

Phillip M Hallam-Baker wrote:
> 
> At the very least I would want to see a very clear message stating
> that this mechanism offers no security and is for test purposes only.
> 
> Unfortunately the text is written with the assumption that the reader
> understands the purpose.

I disagree about it being only useful for test purposes.  For the same
reason, given below, I disagree when you say:

> 
> I don't think that the same case can be made for the need for a NULL
> integrity algorithm as for a NULL confidentiality algorithm. The need
> for the NULL IPSEC method arose because it is very hard to debug
> a system when you can't read any messages
> 

A NULL signture algorithm is just what the doctor ordered for getting rid of
signature baggage when authentication and integrity are provided by other
means.

I'll grant that the need for this only arises in very specific circumstances,
but to relegate it to just testing is going too far.  The particular
circumstance I have in mind, BTW, is when you're doing something like OCSP
over SSL, _and_ you don't care about future non-repudiation.  In that
specific case, the SSL protection and the OCSP signature are redundant.  It
would be nice to finesse away the OCSP signature.  This would allow
optimizations like reusing the SSL session key, to avoid costly PK
operations.

As to the draft's humour, perhaps it is a bit misplaced.  It would be better
not to undermine the serious applications of the algorithm.

		Marc

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Ambarish Malpani" <[email-masked]>, <[email-masked]>
Subject: RE: New draft - NULL Public Key Signatures
Date: Mon, 25 Oct 1999 16:07:51 -0400
Importance: Normal

I just got round to reading the draft. I find the levity unnecessary
and somewhat disturbing.

>1.  Introduction
>
>   This memo defines the NULL public key algorithm. It explains how NPKA
>   NULL algorithm should be used both for digital signatures and
>   encryption/key exchange.

>   Despite the fact that we are not lawyers, we are relatively confident
>   that it is quite safe to use this algorithm for export for any key
>   length size. It is also quite impossible for people to discover your
>   private key via timing, power analysis or other cryptographic
>   methods, as long as you are only using this algorithm.

At the very least I would want to see a very clear message stating
that this mechanism offers no security and is for test purposes only.

Unfortunately the text is written with the assumption that the reader
understands the purpose.

I don't think that the same case can be made for the need for a NULL
integrity algorithm as for a NULL confidentiality algorithm. The need
for the NULL IPSEC method arose because it is very hard to debug 
a system when you can't read any messages

The humourous references to the attacks the scheme is proof against
are I suspect likely to fall flat when some knuckle-brain implements
this and uses it for a real purpose. 

If workers at a nuclear fuel reprocessing plant can be ill trained 
enough to willingly carry buckets of enriched uranium about the place
by hand methinks we should not underestimate the risk of overestimating
the general level of competence.

		Phill

> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Tuesday, October 19, 1999 7:16 PM
> To: [email-masked]
> Subject: New draft - NULL Public Key Signatures
> 
> 
> 
> Hi Guys,
>     Given the traffic on this list, it sounds like this IETF is
> going to be a pretty boring one. :-)
> 
> I have just submitted an individual draft about NULL Public Key
> Signatures, which I hope will be part of this working group soon
> (make things at the PKIX meeting more interesting).
> 
> The main (serious) reason for this draft, is to allow people to
> describe data items that may be signed or unsigned more easily
> in ASN.1.
> 
> Also, having a NULL algorithm is asthetically pleasing.
> 
> So here it is.
> 
> Please send all your flames/comments to this list.
> 
> Thanks,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 
> 

From: "Anders Rundgren" <[email-masked]>
To: "'SEIS-List'" <[email-masked]>, "Stefan Santesson" <[email-masked]>, <[email-masked]>
Cc: "Magnus (RSA)" <[email-masked]>
Subject: QC certificates MAY CERTAINLY be compared!
Date: Mon, 25 Oct 1999 17:55:47 +0100

Stefan,
I have said it before and I say it again.  The following QC-statement is higly doubtful:

"Comparing two qualified certificates to determine if they represent
 the same physical entity may provide misleading results and should
 not be performed"

As you know our famous (?) SEIS-card does indeed allow certificates to
be compared for subject identity.   That is IMO the whole (and only) point with *real* ID-cards!

So this is a statement of the CPS.  Not of the draft.

BTW, why no explicit support for "container ID" (card serial) as most QCs will be
put in smart cards?  It was in SEIS already.

Anders

-----Original Message-----
From: Stefan Santesson <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, October 25, 1999 14:14
Subject: New submitted draft for Qualified Certificates

>All,
>
>A new draft for a Qualified Certificates Profile was submitted friday 22.
>
>The new draft can be obtained from:
>http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt
>
>The QC website has been udated accrodingly:
>http://www.accurata.se/QC/
>
>See also under settled topics to obtain information about major
>considerations since the last draft.
>
>/Stefan
>-------------------------------------------------------------------
>Stefan Santesson                <[email-masked]>
>Accurata AB                     http://www.accurata.se
>Slagthuset                      Tel. +46-40 108588              
>211 20  Malmö                   Fax. +46-40 150790              
>Sweden                        Mobile +46-70 5247799
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>

Date: Mon, 25 Oct 1999 17:57:42 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Tim Polk <[email-masked]>
CC: [email-masked]
Subject: Re: updated path validation text

Tim,

Thanks for sending the section in advance, since we have not yet
since the draft, that was (?) posted by 5PM on October 22.  :-)

> Folks,
> 
> We are currently editing "son-of-RFC 2459" which should - no, *will* - be
> posted by 5PM on October 22 (that is, before the Washington meeting
> cut-off).  In general, that should be plenty of time to review and discuss
> before the meeting.  Most of it is minor stuff, and pretty straightforward.

(text deleted)

> Please take a long, hard look at this text!  Your comments are appreciated!

Since you asked, here is some feedback.

In RFC 2459, we had five state variables, now we have twelve !
Verifying the accuracy of the whole description can only be done
while implementing the specification. However, besides the
complexity, I would like to point to some concerns.

I tried to read the text as a new reader and found that the text on
contrained subtrees works fine when subject (DN) names are used, but
it is not clear to understand the description when subjectAltNames
are used in leaf certificates.

Another concern is the following : the whole approach is implictly
making the assumption that all the information for path validation
is within the certificates themselves. This is one approach. Another
approach, which can be used in combination, is to allow some of the
information normally carried out in certificates (e.g. the
equivalent of the contrained subtrees) to be defined in a local
policy. The text should allow for that alternative.

Denis
 
> Thanks,
> Tim Polk

Date: Mon, 25 Oct 1999 17:12:46 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Comments on ac509prof-01

First of all, thanks for Stephen and Russ, for providing the
document in time. It has a much better shape and content when
compared to the previous version. I have however several comments:

The document is far too authorization oriented (as the current PDAM
from ISO). While the basic content of the document is in the right
direction, the abstract is not appropriate. The reader does not care
too much about the possible uses of the attribute certificates, but
care about what they are.

The current abstract is:

 Authorization services are required for numerous Internet
protocols,
 including TLS, IPSec, and S/MIME. The X.509 Attribute Certificate
 provides a structure that can form the basis for such services
 [X.509]. This specification defines a profile for the use of X.509
 Attribute Certificates to provide authorization services for
 Internet protocols. Some optional features are also specified which
 are not required for conformance to the base profile.

The document contents however (misplaced in section 4) a very good
abstract that should be reused to replace the current abstract. Here
is a proposal:

   This specification defines a profile for the use of X.509
   Attribute Certificates. Attribute certificates may be used in 
   a wide range of applications and environments covering a broad 
   spectrum of interoperability goals and a broader spectrum of 
   operational and assurance requirements. The goal of this document
   is to establish a common baseline for generic applications 
   requiring broad interoperability and limited special purpose 
   requirements.  In particular, the emphasis will be on supporting 
   the use of attribute certificates for informal Internet
electronic
   mail, IPSec, and WWW applications.

The section 4.2 about Object Identifiers is misplaced, since it is a
recap of what is supported but no explanations are provided at this
time about their rational.

AAControls are introduced in section 4.6.1 where it is said: "

   The AAControls PKC extension, intended to be used in CA 
   and AC Issuer PKCs, *MAY* be used to help answer the question.

However in section 5 on Attribute Certificate Validation we have the
following text:

 2. All PKC's on the path from the AA CA down to and including the
    AC issuer's PKC *MUST* contain an aaControls extension as
defined
    below (the PKC with the AA CA's as subject need not contain
    this extension).
 3. Only those attributes in the AC which are allowed according to
    all of the aaControls extension values in all of the PKCs from
    the AA CA to the AC issuer, may be used for authorization
    decisions, all other attributes MUST be ignored ...

This is contradictory. There are basically at least two environments
where AC can be used: an on-line authorization scheme and a
store-and-forward environment manipulating signed messages linked to
ACs. Only one environment is really addressed here and there is no
reason to impose the use of AAControls to both environments.
Furthermore when using ACs in an on-line access control scheme the
use of AA controls is not a must. If the access enforcement function
uses an authorization scheme using both the name of the Attribute
Authority and the value of the attribute, there is no need to make
sure that the AC is trusted to issue any attribute value. For these
reasons, the use of AAControls is not needed at all. There are two
options: suppress them or make them truly optional.

Other detailed comments

On page 4, we have the following paragraph:

   In other cases, it is more suitable for a client simply to
   authenticate to the server and for the server to request ("pull")
   the client's AC from an AC issuer or a repository. A major
benefit
   of the "pull" model is that it can be implemented without changes
to
   the client or client-server protocol. It is also more suitable
for
   some inter-domain cases where the client's rights should be
assigned
   within the server's domain, rather than within the client's
"home"
   domain.

It would be nice to warn the user about the disadvantages of the
pull model. It is thus proposed to add the following after the
second sentence.

A major disadvantage of the "pull" model is that without any change
a receiving entity does not know which attribute certificate to use
and thus the principle of least privilege cannot be supported. In
addition, all attributes certificates are not necessarily public and
thus instead of providing a complex access control scheme to
restrict the access to those attribute certificates, the scheme is
better suited to public attributes or to attributes used in a closed
domain.

At the top of page 10. The first sentence reads: 
   For any protocol where the AC is passed in an authenticated
message ...

It should be noticed that attribute certificates are not necessarily
used in a protocol, but also in data structures (e.g. a signed
message). The sentence should be changed to:

   For any environment where the AC is passed in an authenticated
message ...

Side comments

Section 4.5.1 is for legacy systems and it is questionable if the
complexity involved by the encipherment does not negate its
practical use. 

In section 4.5.2 (Access Identity), the syntax encourages for a
multiplicity of names, one for each service, whereas the PKI
encourages for the reverse. In fact, in that case attribute
certificates are not more used to carry attributes like roles, but
names instead.

Denis

Date: Mon, 25 Oct 1999 15:15:58 +0200
To: [email-masked]
From: Stefan Santesson <[email-masked]>
Subject: New submitted draft for Qualified Certificates

All,

A new draft for a Qualified Certificates Profile was submitted friday 22.

The new draft can be obtained from:
http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-02.txt

The QC website has been udated accrodingly:
http://www.accurata.se/QC/

See also under settled topics to obtain information about major
considerations since the last draft.

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-roadmap-04.txt
Date: Mon, 25 Oct 1999 07:01:27 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure PKIX Roadmap
	Author(s)	: A. Arsenault, S. Turner
	Filename	: draft-ietf-pkix-roadmap-04.txt
	Pages		: 40
	Date		: 22-Oct-99
	
This document provides an overview or 'roadmap' of the work done by
the IETF PKIX working group. It describes some of the terminology
used in the working group's documents, and the theory behind an
X.509-based Public Key Infrastructure and Privilege Management
Infrastructure (PMI). It identifies each document developed by the
PKIX working group, and describes the relationships among the various
documents. It also provides advice to would-be PKIX implementors
about some of the issues discussed at length during PKIX development,
in hopes of making it easier to build implementations that will
actually interoperate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-04.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-roadmap-04.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-roadmap-04.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-roadmap-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-roadmap-04.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-ecdsa-02.txt
Date: Mon, 25 Oct 1999 07:01:21 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure  
                          Representation of Elliptic Curve Digital Signature    
                          Algorithm (ECDSA) Keys and Signatures in Internet     
                          X.509 Public Key Infrastructure Certificates
	Author(s)	: L. Bassham, D. Johnson, W. Polk
	Filename	: draft-ietf-pkix-ipki-ecdsa-02.txt
	Pages		: 15
	Date		: 22-Oct-99
	
This is the third draft of a profile for specification of Elliptic
Curve Digital Signature Algorithm (ECDSA) keys and signatures in
Internet Public Key Infrastructure X.509 certificates and certificate
revocation lists. This specification is an addendum to RFC 2459;
implementations must also conform to RFC 2459.  In addition, this
document references ANSI X9.62 for the specification of the ECDSA
algorithm.  This specification only addresses the format of ECDSA
keys and signatures.  Please send comments on this document to the
[email-masked] mail list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-ecdsa-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-ecdsa-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-ecdsa-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-ecdsa-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Sun, 24 Oct 1999 16:08:53 +0800
From: "Xiong Shao Jun" <[email-masked]>
Organization: China Merchants Bank
To: [email-masked]
Subject: directory entry with NULL DN

Hi, there. I posted a mail a few days ago, but received no reply.
I have some questions about rfc2587. If a PKI subject has null
DN in certificate, how can it have an entry in LDAP?

Thanx in advance.

Xiong Shaojun
China Merchants Bank

Date: Fri, 22 Oct 1999 15:45:26 -0700
To: Paul Koning <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: Semantics
Cc: [email-masked]

At 06:09 PM 10/22/99 -0400, you wrote:
>>>>>> "Tony" == Tony Bartoletti <[email-masked]> writes:
>
> Tony> At 04:46 PM 10/22/99 -0400, Michael Duren wrote:
>
> Mike> Denis,
>  
> Mike> In looking at the TSP specification, I have one observation.
>  
> Mike> In section 2.1 of the document, it is stated that the serial
> Mike> number shall be "a monotonically incrementing integer for each
> Mike> newly generated time stamp token".  However, in section 2.4.2
> Mike> when the meaning and the usage of the serial number is
> Mike> discussed, it is referred to as "a strictly monotonically
> Mike> increasing integer."
>  
> Mike> My understanding is that "monotonically increasing" values can
> Mike> be equal (i.e. the time value is monotonically increasing) and
> Mike> "strictly increasing" values cannot have equal values.  I am
> Mike> not sure what "strictly monotonically increasing" implies.
> Mike> Seems to me that the serial number should be referred to as
> Mike> "strictly increasing" or "unique and monotonically increasing"
> Mike> in both places.
>  
> Mike> Any comments?
>  
> Mike> Mike Duren
>
> Tony> "Strictly" speaking, you are correct.
>
> Tony> The sequence <2,5,7,7,7,9> is monotonically increasing because
> Tony> it never decreases.
>
> Tony> Uniqueness (1-to-1 mapping) requires a "strictly increasing"
> Tony> (or decreasing) seq.
>
>That doesn't match the terminology I'm familiar with.
>
>2,5,7,7,7... is "monotonically non-decreasing" but it is not
>"monotonically increasing".

I believe the term "monotonic sequence" is intended to imply that
the sign (+/-) of the differences never changes.  It is either
always "+" or always "-", which allows "+0" or "-0".  Since this
leads to 4 possibilities, some schools take "strictly" as a
refinement of monotonic, and I suppose some instead take "increasing"
as a refinement of "non-decreasing".

Come to think of it, with "increasing, decreasing, non-increasing,
and non-decreasing" understood, the term "monotonic" becomes redundant. 

I agree, as you state below, that we should avoid terms that
may be misinterpreted, and try to use "plain english" where possible.

>But given that there appear to be differing interpretations of the
>terminology, it would be best not to use these ambiguous technical
>terms but rather describe in plain english what the required property
>is (i.e., "each value must be > than its predecessor" or "each value
>must be >= its predecessor" depending on which is wanted).
>
>	paul
>
>

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

Date: Fri, 22 Oct 1999 18:09:47 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Semantics

>>>>> "Tony" == Tony Bartoletti <[email-masked]> writes:

 Tony> At 04:46 PM 10/22/99 -0400, Michael Duren wrote:

 Mike> Denis,
  
 Mike> In looking at the TSP specification, I have one observation.
  
 Mike> In section 2.1 of the document, it is stated that the serial
 Mike> number shall be "a monotonically incrementing integer for each
 Mike> newly generated time stamp token".  However, in section 2.4.2
 Mike> when the meaning and the usage of the serial number is
 Mike> discussed, it is referred to as "a strictly monotonically
 Mike> increasing integer."
  
 Mike> My understanding is that "monotonically increasing" values can
 Mike> be equal (i.e. the time value is monotonically increasing) and
 Mike> "strictly increasing" values cannot have equal values.  I am
 Mike> not sure what "strictly monotonically increasing" implies.
 Mike> Seems to me that the serial number should be referred to as
 Mike> "strictly increasing" or "unique and monotonically increasing"
 Mike> in both places.
  
 Mike> Any comments?
  
 Mike> Mike Duren

 Tony> "Strictly" speaking, you are correct.

 Tony> The sequence <2,5,7,7,7,9> is monotonically increasing because
 Tony> it never decreases.

 Tony> Uniqueness (1-to-1 mapping) requires a "strictly increasing"
 Tony> (or decreasing) seq.

That doesn't match the terminology I'm familiar with.

2,5,7,7,7... is "monotonically non-decreasing" but it is not
"monotonically increasing".

But given that there appear to be differing interpretations of the
terminology, it would be best not to use these ambiguous technical
terms but rather describe in plain english what the required property
is (i.e., "each value must be > than its predecessor" or "each value
must be >= its predecessor" depending on which is wanted).

	paul

Date: Fri, 22 Oct 1999 14:55:30 -0700
To: "Michael Duren" <[email-masked]>, "Denis Pinkas" <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: Re: Semantics
Cc: <[email-masked]>

At 04:46 PM 10/22/99 -0400, Michael Duren wrote: 

<excerpt><smaller>Denis,

</smaller>  

<smaller>In looking at the TSP specification, I have one observation.

</smaller>  

<smaller>In section 2.1 of the document, it is stated that the serial
number shall be "a monotonically incrementing integer for each newly
generated time stamp token".  However, in section 2.4.2 when the meaning
and the usage of the serial number is discussed, it is referred to as "a
strictly monotonically increasing integer."

</smaller>  

<smaller>My understanding is that "monotonically increasing" values can
be equal (i.e. the time value is monotonically increasing) and "strictly
increasing" values cannot have equal values.  I am not sure what
"strictly monotonically increasing" implies.  Seems to me that the serial
number should be referred to as "strictly increasing" or "unique and
monotonically increasing" in both places.

</smaller>  

<smaller>Any comments?

</smaller>  

<smaller>Mike Duren

</smaller>  

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

"Strictly" speaking, you are correct.

The sequence <<2,5,7,7,7,9> is monotonically increasing because it never
decreases.

Uniqueness (1-to-1 mapping) requires a "strictly increasing" (or
decreasing) seq.

___tony___ (Hey, that MS in math finally paid off!)

Tony Bartoletti                                             LL

IOWA Center                                              LL LL

Lawrence Livermore National Laboratory                LL LL LL

PO Box 808, L - 089                                   LL LL LL

Livermore, CA 94551-9900                              LL LL LLLLLLLL

phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL

email: [email-masked]                                   LLLLLLLL

Reply-To: "Michael Duren" <[email-masked]>
From: "Michael Duren" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: Semantics
Date: Fri, 22 Oct 1999 16:46:34 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01BF1CAD.00235A20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Denis,
=20
In looking at the TSP specification, I have one observation.
=20
In section 2.1 of the document, it is stated that the serial number =
shall be "a monotonically incrementing integer for each newly generated =
time stamp token".  However, in section 2.4.2 when the meaning and the =
usage of the serial number is discussed, it is referred to as "a =
strictly monotonically increasing integer."
=20
My understanding is that "monotonically increasing" values can be equal =
(i.e. the time value is monotonically increasing) and "strictly =
increasing" values cannot have equal values.  I am not sure what =
"strictly monotonically increasing" implies.  Seems to me that the =
serial number should be referred to as "strictly increasing" or "unique =
and monotonically increasing" in both places.
=20
Any comments?

Mike Duren
=20

------=_NextPart_000_001B_01BF1CAD.00235A20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Denis,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>In looking at the TSP specification, =
I have one=20
observation.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>In section 2.1 of the document, it is stated that =
the serial=20
number shall be &quot;a monotonically incrementing integer for each =
newly=20
generated time stamp token&quot;.&nbsp; However, in section 2.4.2 when =
the=20
meaning and the usage of the serial number is discussed, it is referred =
to as=20
&quot;a strictly monotonically increasing integer.&quot;</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>My understanding is that &quot;monotonically =
increasing&quot;=20
values can be equal (i.e. the time value is monotonically increasing) =
and=20
&quot;strictly increasing&quot; values cannot have equal values.&nbsp; I =
am not=20
sure what &quot;strictly monotonically increasing&quot; implies.&nbsp;=20
</FONT><FONT size=3D2>Seems to me that the serial number should be =
referred to as=20
&quot;strictly increasing&quot; or &quot;unique and monotonically=20
increasing&quot; in both places.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Any comments?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Mike Duren</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_001B_01BF1CAD.00235A20--

Date: Fri, 22 Oct 1999 13:23:42 -0400
To: Francois Rousseau <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-ac509prof-01.txt
Cc: [email-masked]

Francois:

This is a topic for the IETF meeting.  There is also an issue of 
compatibility with RFC 2530.

Russ

At 04:34 PM 10/19/99 -0400, Francois Rousseau wrote:
>Russ and/or Steve,
>
>The syntax of the issuer field in version 2 ACs was modified in the X.509
>FPDAM such there would not be a need for the authorityKeyIdentifier
>extension in an AC to assist the AC verifier in checking the signature of
>the AC. By instead filling the optional baseCertificateId component of the
>issuer field, the intend was that you would achieve the same result without
>using any extensions, which is also the approach recommended in the X.509
>FPDAM. The only reason the issuerName component of the issuer field was
>left was for backward compatibility with version 1 ACs as defined in
>X.509(97).
>
>In addition, I do not see the argument at paragraph 4.3.3 when you say
>using the baseCertificateId field to reference the AC issuer would mean
>that the AC verifier would be dependent on the AC issuer's public key
>infrastructure.
>
>François

From: Peter Williams <[email-masked]>
To: Zahid Ahmed <[email-masked]>, "Luo, Feng (Exchange)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: certificate chain
Date: Fri, 22 Oct 1999 13:24:03 -0700

> -----Original Message-----
> From: Zahid Ahmed [mailto:[email-masked]]
> Sent: Friday, October 22, 1999 11:44 AM
> To: Peter Williams; Luo, Feng (Exchange); [email-masked]'
> Subject: RE: certificate chain
> 
> 
> I think validating the server cert is necessary but
> not sufficient. Validating that the CA root public
> cert is a trusted CA would also be required in many
> clients. However, it seems that many SSL clients do
> not do this (including browsers?). So, I think, in
> practice we do have different levels of cert-based
> authe going on.

Each vendor does their own validation procedures on
the certiifcate processes of SSL; this is correct,
as SSL does not standardize those processes. It
is also consistent with the design of a "socket"
protocol.  

> 
> In the case of anonymously-originated messages, the
> (web) servers still need to be validated; the clients,
> i.e., the senders, could be anonymous. 

This is one option.  SSL also enables the server
to be anonymous ; that is,  it does not cite a certificate.

This means that a vendor client UA must have other
means to authenticate the server's handshake msgs; this may
mean that the server cert is locally supplied by the client
based on the src-address of the socket, or non-certificate 
based techniques are used.

This design ensure that SSL sockets can address multiuple
applications, without being tied to any given application; it 
allows for either server or client side path formation
according to the needs of the sockct application, for
either party. Furthermore, neither side is required
to use the certs which are delivered in the SSL stream,
it can always use an alternative chain, or no
chain at all.

Peter.

These features are important elements of SSL design. They
limit the power of CAs, or one of the parties, to control
communications. SSL does enable the parties to leverage
third-parties to remove the element of mutual suspicion.
Any further role of third-parties in an SSL design is
upto the vendors application; https is one such
semi-standardized concept linking SSL to UA-web-centered
http.
> 
> 
> 
> 
> > -----Original Message-----
> > From: Peter Williams [mailto:[email-masked]]
> > Sent: Thursday, October 21, 1999 5:34 PM
> > To: Luo, Feng (Exchange); [email-masked]'
> > Subject: RE: certificate chain
> > 
> > 
> > 
> > SSL does not specify the rules for certificate chain
> > validation. Also remember, that an SSL handshake
> > can use anonymously-originated messages in either 
> > direction.
> > 
> > TLS systems have to offer the backwards compatible
> > with SSL v3, which means that TLS systems
> > must process v1 certs.
> > 
> > 
> > > -----Original Message-----
> > > From: Luo, Feng (Exchange) [mailto:[email-masked]]
> > > Sent: Thursday, October 21, 1999 5:29 PM
> > > To: [email-masked]'
> > > Subject: certificate chain
> > > 
> > > 
> > > In the SSL handshake, what's the standard that the 
> > SSL-enabled client
> > > authenticates the SSL-enabled sever in the certificate chain 
> > > of the web
> > > server. It seems like that the Netscape browser and IE only 
> > > look at the
> > > server certificate sent by the web server, but the Marimba 
> > > tuner is looking
> > > at not only the server certificate but also the CA 
> > > certificate which issued
> > > that server certificate.
> > > Can some one tell me which method is the RFC standard? Where 
> > > can I have the
> > > documentation on this?
> > > 
> > > Thanks
> > > Feng
> > > 
> > > 
> > > **************************************************************
> > > *********
> > > Bear Stearns is not responsible for any recommendation, 
> > solicitation, 
> > > offer or agreement or any information about any 
> > transaction, customer 
> > > account or account activity contained in this communication.
> > > **************************************************************
> > > *********
> > > 
> > 
> 

From: Zahid Ahmed <[email-masked]>
To: Peter Williams <[email-masked]>, "Luo, Feng (Exchange)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: certificate chain
Date: Fri, 22 Oct 1999 11:44:24 -0700

I think validating the server cert is necessary but
not sufficient. Validating that the CA root public
cert is a trusted CA would also be required in many
clients. However, it seems that many SSL clients do
not do this (including browsers?). So, I think, in
practice we do have different levels of cert-based
authe going on.

In the case of anonymously-originated messages, the
(web) servers still need to be validated; the clients,
i.e., the senders, could be anonymous. 

> -----Original Message-----
> From: Peter Williams [mailto:[email-masked]]
> Sent: Thursday, October 21, 1999 5:34 PM
> To: Luo, Feng (Exchange); [email-masked]'
> Subject: RE: certificate chain
> 
> 
> 
> SSL does not specify the rules for certificate chain
> validation. Also remember, that an SSL handshake
> can use anonymously-originated messages in either 
> direction.
> 
> TLS systems have to offer the backwards compatible
> with SSL v3, which means that TLS systems
> must process v1 certs.
> 
> 
> > -----Original Message-----
> > From: Luo, Feng (Exchange) [mailto:[email-masked]]
> > Sent: Thursday, October 21, 1999 5:29 PM
> > To: [email-masked]'
> > Subject: certificate chain
> > 
> > 
> > In the SSL handshake, what's the standard that the 
> SSL-enabled client
> > authenticates the SSL-enabled sever in the certificate chain 
> > of the web
> > server. It seems like that the Netscape browser and IE only 
> > look at the
> > server certificate sent by the web server, but the Marimba 
> > tuner is looking
> > at not only the server certificate but also the CA 
> > certificate which issued
> > that server certificate.
> > Can some one tell me which method is the RFC standard? Where 
> > can I have the
> > documentation on this?
> > 
> > Thanks
> > Feng
> > 
> > 
> > **************************************************************
> > *********
> > Bear Stearns is not responsible for any recommendation, 
> solicitation, 
> > offer or agreement or any information about any 
> transaction, customer 
> > account or account activity contained in this communication.
> > **************************************************************
> > *********
> > 
> 

From: Brian Korver <[email-masked]>
Subject: Re: CRACK
To: [email-masked] (Ari Huttunen)
Date: Fri, 22 Oct 1999 09:31:41 -0700 (PDT)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

Ari Huttunen writes:
> There's another architectural thing you should consider. What about modifying
> the protocol so that when the server starts believing in the authenticity of the
> client, the server issues the client's public key a certificate? This certificate
> would have a very limited life-time, just enough for the purpose at hand.
> It would be transported to the client in the 'last' message, whatever that is.
> 
> Although this creates more public key operations, the legacy authentication
> functionality could be located on a different physical box than the actual
> security gateway.. This achieves a very similar function to the Kerberos ticket
> granting server, and the certificate is similar to Kerberos tickets. You'd of
> course have to set up the trust relations appropriately.
> 
> There could also exist "one time certificates" that can be used only once
> during their life-time to gain access, similar to one time passwords. Some
> way or another they would be revoked the moment they are used.
> 
> (CPU is basically very cheap. If not this year, then perhaps next..)

We thought about that, but there are already perfectly good protocols
for obtaining certificates (CEP, PKIX, whatever) and these certificates
could be short-lived for exactly this purpose.  On the other hand,
as you point out, this is a more heavyweight mechanism.  Hence
the draft.

brian
[email-masked]

Date: Fri, 22 Oct 1999 18:14:01 +0300
From: Ari Huttunen <[email-masked]>
Organization: Data Fellows Oyj
To: Brian Korver <[email-masked]>
CC: "Waters, Stephen" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: CRACK

(PKIX: CRACK refers to draft-harkins-ipsec-ike-crack-00.txt.)

Brian Korver wrote:

> Waters, Stephen writes:
> > Hi Dan,
> >
> > Looks good.
> >
> > Where did CRACK come from? A dubious name in a security protocol.

A very catching marketing trick, I presume. ;-)

>
> >
> > Can the client's private/public key be unique for each connection?
>
> Sure.  But that would require an implementation+policy that would generate
> a separate IKE SA for each connection.  If you connect frequently, I'm not
> sure you would want that.
>

There's another architectural thing you should consider. What about modifying
the protocol so that when the server starts believing in the authenticity of the
client, the server issues the client's public key a certificate? This certificate
would have a very limited life-time, just enough for the purpose at hand.
It would be transported to the client in the 'last' message, whatever that is.

Although this creates more public key operations, the legacy authentication
functionality could be located on a different physical box than the actual
security gateway.. This achieves a very similar function to the Kerberos ticket
granting server, and the certificate is similar to Kerberos tickets. You'd of
course have to set up the trust relations appropriately.

There could also exist "one time certificates" that can be used only once
during their life-time to gain access, similar to one time passwords. Some
way or another they would be revoked the moment they are used.

(CPU is basically very cheap. If not this year, then perhaps next..)

>
> >
> >
> > Steve.
>
> brian
> [email-masked]

--
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

Data Fellows Corporation       http://www.DataFellows.com

F-Secure products: Integrated Solutions for Enterprise Security

From: [email-masked]
To: <[email-masked]>
Subject: Keep in touch.
Date: Fri, 22 Oct 1999 02:55:05 -0700

Want to keep in touch with old friends from school?
The Gradfinder website is the perfect place to do just that.

On Gradfinder you can search for friends, add your
current contact info, a current photo, and details
about what you are up to these days. You can update
your info at any time after that. All changes happen
immediately. There are also message boards you can use
to help organize reunions. You can use our photo album
wizard to create online albums to share with friends
and family.

There are currently over 100,000 schools listed from
grade 1 to university from 60 countries around the world.

This service is free so check it out!

This site can be found at:

http://www.gradfinder.com

From: Peter Williams <[email-masked]>
To: "Luo, Feng (Exchange)" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: certificate chain
Date: Thu, 21 Oct 1999 17:34:17 -0700

SSL does not specify the rules for certificate chain
validation. Also remember, that an SSL handshake
can use anonymously-originated messages in either 
direction.

TLS systems have to offer the backwards compatible
with SSL v3, which means that TLS systems
must process v1 certs.

> -----Original Message-----
> From: Luo, Feng (Exchange) [mailto:[email-masked]]
> Sent: Thursday, October 21, 1999 5:29 PM
> To: [email-masked]'
> Subject: certificate chain
> 
> 
> In the SSL handshake, what's the standard that the SSL-enabled client
> authenticates the SSL-enabled sever in the certificate chain 
> of the web
> server. It seems like that the Netscape browser and IE only 
> look at the
> server certificate sent by the web server, but the Marimba 
> tuner is looking
> at not only the server certificate but also the CA 
> certificate which issued
> that server certificate.
> Can some one tell me which method is the RFC standard? Where 
> can I have the
> documentation on this?
> 
> Thanks
> Feng
> 
> 
> **************************************************************
> *********
> Bear Stearns is not responsible for any recommendation, solicitation, 
> offer or agreement or any information about any transaction, customer 
> account or account activity contained in this communication.
> **************************************************************
> *********
> 

From: "Luo, Feng (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: certificate chain
Date: Thu, 21 Oct 1999 20:28:54 -0400

In the SSL handshake, what's the standard that the SSL-enabled client
authenticates the SSL-enabled sever in the certificate chain of the web
server. It seems like that the Netscape browser and IE only look at the
server certificate sent by the web server, but the Marimba tuner is looking
at not only the server certificate but also the CA certificate which issued
that server certificate.
Can some one tell me which method is the RFC standard? Where can I have the
documentation on this?

Thanks
Feng

***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***********************************************************************

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-04.txt
Date: Thu, 21 Oct 1999 06:52:57 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Time Stamp 
                          Protocols
	Author(s)	: C. Adams,  P. Cain, D. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-04.txt
	Pages		: 18
	Date		: 20-Oct-99
	
A time stamping service allows to prove that a datum existed before
a particular time and can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]). This document describes the format of a request sent to a
Time Stamping Authority (TSA) and of the response that is returned.
An example on how to prove that a digital signature was generated
during the validity period of the corresponding public key
certificate is given in an annex.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-04.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-time-stamp-04.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-time-stamp-04.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-time-stamp-04.txt

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

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

--OtherAccess--

--NextPart--

From: "Toni Price" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Fw: PKI Opportunities
Date: Wed, 20 Oct 1999 15:42:17 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01BF1B11.B046FEE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

IETF Member:

My name is Toni Price and I have been retained to do a search for two =
"PKI" professionals with a leading provider of encryption-based network =
security solutions in Silicon Valley.  I am looking for a PKI Standards =
Engineer and a PKI Systems Engineer.  If you know of anyone looking for =
this kind of opportunity I would appreciate a referral. =20

Please give them my telephone number and e-mail information.

Thank you,

Toni Price
Price-Serrano People Services, Inc.
510-436-0858/office
510-436-0859/fax
[email-masked]

------=_NextPart_000_0036_01BF1B11.B046FEE0
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.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>IETF Member:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My name is Toni Price and I have been =
retained to=20
do a search for two "PKI" professionals&nbsp;with a leading provider of=20
encryption-based network security solutions in Silicon Valley.&nbsp; I =
am=20
looking for a PKI Standards Engineer and a PKI Systems Engineer.&nbsp; =
If you=20
know of anyone looking for this kind of opportunity I would appreciate a =

referral.&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Please give them my telephone number =
and e-mail=20
information.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT face=3DArial><FONT face=3D"Lucida =
Handwriting">Toni=20
Price<BR></FONT>Price-Serrano People Services,=20
Inc.<BR>510-436-0858/office<BR>510-436-0859/fax<BR><A=20
href=3D"mailto:[email-masked]">[email-masked]</A></FONT><=
/FONT></DIV></BODY></HTML>

------=_NextPart_000_0036_01BF1B11.B046FEE0--

From: "Peter Williams" <[email-masked]>
To: <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Wed, 20 Oct 1999 10:51:19 -0700
Importance: Normal

> 
> OTOH, I do see a use for such a service for
> Denis' purpose, which, I guess, is to figure out 
> whether a certificate was valid at some time
> in the past as part of evaluating the evidence
> for NR purposes. That's not what I read SCVP or
> OCSP-X as trying to address though.
> 
> Stephen. 

I believe OCSP-X is trying, amongst other things, to address the 
functions laid out in Section 8.1 of the VeriSign CPS, and 
similar requirements set out in more modern security
practice designs.
https://www.verisign.com/repository/CPS1.2/CPSCH8.HTM

The idea of authorization in VeriSign CPS 8.1 contrasts 
with technical authorization:

As Phill said, there is an "integrated" element of authorization,
but not the sense of X.509 AC's authorization
model, I suggest. The VeriSign CPS was designed to control the
behaviour of humans by tying them to intent so they
can be criminally prosecuted by govts or held in breach,
or liable for a tort, etc. ACs were designed
to instrument technical security systems, not
faciliate a legal protocol, per se.

In conclusion:

(1) I believe OCSP-X may co-locate "AC-type authorization
and access control" with signature verification functions. 
I disagree with Phill's apparent assertion that it is natural
for the VA deploymen to inherently colocate technical authentication 
and access  control decision making, and/or enforcement. 

(2) I also believe It IS appropriate in TTP-grade VAs (like VeriSign
and ValiCert) for there to be integrated, "natural" legal
authorization processing during signature verification,
as controlled by a C/VPS legal protocol.  OCSP-X seems to 
intend to enable this function to be partially performed 
by an entity distinct from the relying-party. The practice
statement of the VA responder (ValiCert's, AT&T's...)
then control the precise legal semantics, once the
OCSP-X packets have performed the raw signalling
and communication.

Sender: [email-masked]
Date: Tue, 19 Oct 1999 17:38:11 -0700
From: Marc Branchaud <[email-masked]>
Organization: Xcert International Inc.
To: [email-masked]
Subject: Re: New draft - NULL Public Key Signatures

Actually, I think defining a NULL signature algorithm would be pretty useful.

One thing I was looking for in the draft was a defintion of the ASN.1 SIGNED
macro with a NPKA signature, e.g. that the signatureValue shall consist of a
0-length BIT STRING.  I guess this might show up in section 2.5...

Also, in the interest of interoperability I think only one OID should be
defined. (One of the good properties to put in section 6 is that NPKA
produces the same signature results regardless of what hash algorithm is
used.)

Other comments:

2.1.1 - Shouldn't

   S{C, V} => C
   G{E, B} => E

be

   S{C, V} => E
   G{E, B} => C

?  Similarly for 2.1.2...

2.2 - RC5 is a symmetric cipher.  Better to use RSA to avoid confusion.

6 - Another good property: Useful for protocols that were so short-sighted as
to require a signature in the ASN.1 without any regard to other possible
authentication methods.  The NPKA can be used to avoid redundant
authentication.

		Marc

Ambarish Malpani wrote:
> 
> Hi Guys,
>     Given the traffic on this list, it sounds like this IETF is
> going to be a pretty boring one. :-)
> 
> I have just submitted an individual draft about NULL Public Key
> Signatures, which I hope will be part of this working group soon
> (make things at the PKIX meeting more interesting).
> 
> The main (serious) reason for this draft, is to allow people to
> describe data items that may be signed or unsigned more easily
> in ASN.1.
> 
> Also, having a NULL algorithm is asthetically pleasing.
> 
> So here it is.
> 
> Please send all your flames/comments to this list.
> 
> Thanks,
> Ambarish
>

From: Ambarish Malpani <[email-masked]>
To: [email-masked]
Subject: New draft - NULL Public Key Signatures
Date: Tue, 19 Oct 1999 16:16:03 -0700

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_01BF1A87.EA04BF30
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Guys,
    Given the traffic on this list, it sounds like this IETF is
going to be a pretty boring one. :-)

I have just submitted an individual draft about NULL Public Key
Signatures, which I hope will be part of this working group soon
(make things at the PKIX meeting more interesting).

The main (serious) reason for this draft, is to allow people to
describe data items that may be signed or unsigned more easily
in ASN.1.

Also, having a NULL algorithm is asthetically pleasing.

So here it is.

Please send all your flames/comments to this list.

Thanks,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833

------_=_NextPart_000_01BF1A87.EA04BF30
Content-Type: text/plain;
	name="nullSignatures-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="nullSignatures-00.txt"

Network Working Group                             A. Malpani (ValiCert)
Category: Internet-Draft                                   October 1999
Expires in six months

		 The NULL Public Key Algorithm (NPKA)
		     <draft-malpani-npka-00.txt>

Status of this Memo

   This document is an Internet-Draft.  Internet Drafts are working =
doc-
   uments of the Internet Engineering Task Force (IETF), its Areas, and
   its Working Groups.  Note that other groups may also distribute =
work-
   ing documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other =
documents
   at any time.  It is not appropriate to use Internet Drafts as refer-
   ence material, or to cite them other than as a ``working draft'' or
   ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the internet-drafts =
Shadow
   Directories on:

      ftp.is.co.za (Africa)
      nic.nordu.net (Europe)
      ds.internic.net (US East Coast)
      ftp.isi.edu (US West Coast)
      munnari.oz.au (Pacific Rim)

   Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This memo defines the NULL public key algorithm. The original goal
   of this effort was to be able to allow people to optionally sign
   data, without needing the make the signature optional in the ASN.1.
   While we were at it, we decided to, for completeness, also specify
   the method for NULL public key encryption.

1.  Introduction

   This memo defines the NULL public key algorithm. It explains how =
NPKA
   NULL algorithm should be used both for digital signatures and
   encryption/key exchange.

   Despite the fact that we are not lawyers, we are relatively =
confident
   that it is quite safe to use this algorithm for export for any key
   length size. It is also quite impossible for people to discover your
   private key via timing, power analysis or other cryptographic
   methods, as long as you are only using this algorithm.

2. Algorithm Details

2.1 Algorithm Definition

   In this section, we will show how NPKA can be used for both digital
   signatures and key exchange. We use the following notation:

    B represents the puBlic key
    V represents the priVate key
    C is the Clear text message
    E is the Encrypted message
    S is the Signing algorithm
    G is the siGnature verification algorithm
    Y is the key/data encrYption algorithm
    D is the key/data decryption algorithm
    F{x, y} is the function F on data elements x and y

2.1.1 Digital Signatures

   This section shows how a private key is used to create a digital
   signature and a public key used to verify the digital signature.

   For signatures, the holder of the private key uses the message and
   the private key to produce a digital signature, which can be =
verified
   by anyone with the holder's public key.

   S{C, V} =3D> C
   G{E, B} =3D> E

   Note: This satisfies the property required by all public key
   signature algorithms - G{S{C, V}, B} =3D> C

2.1.2 Encryption/Key Exchange

   This section shows how a public key is used to encrypt data/keys
   and a public key used to decrypt the data.

   Y{C, B} =3D> C
   D{E, V} =3D> E

   Note: This satisfies the property required by all public key
   encryption algorithms - D{Y{C, B}, V} =3D> C

2.2 Keying Material

   Like other modern ciphers, e.g., RC5 [RFC-2040], NPKA
   can make use of keys of varying lengths.  However, no
   measurable increase in security is afforded by the use of longer key
   lengths.

2.3 Padding

   NULL has a block size of 1 byte, thus padding is not necessary.

2.4. Performance

   The NULL encryption algorithm is significantly faster than other
   commonly used symmetric encryption algorithms and implementations of
   the base algorithm are available for all commonly used hardware and
   OS platforms.

2.5 Test Vectors

   [TBD]
   We should also show what a cert with an NPKA signature looks like

3. Object Identifiers

   [TBD]
   We need to create the OIDs for sha1withNPKA, md4withNPKA, ...

4. Operational Requirements

   [TBD]

5. Security Considerations

   If you do implement this algorithm, please make sure that signatures
   using that algorithm are only accepted in places where you do not =
need
   signatures. Similarly, encryption with this algorithm is only =
performed
   where you do not want encryption.

6. Algorithm properties

   In this section, we try to outline the main properties of NPKA.

   - Very, very high performance for both encryption and decryption,
   for key exchange and signing.
   - No export restrictions (for any key length).
   - No risk of exposing your private key to any potential attacks.
   - Short key sizes are as strong as keys twice as long.
   - Small algorithm footprint - excellent for smart card support or =
other
   low memory devices.
   - Support for any sized key.
   - Can easily be used in both a block or streaming mode.
   - Great synchronization properties - loss of a single bit in =
transmission
   results in only a single bit loss at the receiver (?)

7. Intellectual Property Rights

   [TBD]

8. Acknowledgments

   Spiritual and textual guidance for this document we provided by
   [RFC2410].

9.  References

   [RFC-2410]   Glenn R., and Kent, S., "The NULL Encryption Algorithm =
and
		Its Use With IPsec", RFC 2410, November 1998.

10.  Editors' Addresses

   Ambarish Malpani
   ValiCert, Inc.
   1215 Terra Bella,
   Mountain View, CA 94043

   EMail: [email-masked]
   Phone: 650.567.5457

11.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph =
are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

------_=_NextPart_000_01BF1A87.EA04BF30--

Date: Tue, 19 Oct 1999 23:33:45 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Francois Rousseau <[email-masked]>
CC: [email-masked], xme <[email-masked]>, RussHousley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-ac509prof-01.txt

Hi Francois,

> The syntax of the issuer field in version 2 ACs was modified in the X.509
> FPDAM such there would not be a need for the authorityKeyIdentifier
> extension in an AC to assist the AC verifier in checking the signature of
> the AC. By instead filling the optional baseCertificateId component of the
> issuer field, the intend was that you would achieve the same result without
> using any extensions, which is also the approach recommended in the X.509
> FPDAM. The only reason the issuerName component of the issuer field was
> left was for backward compatibility with version 1 ACs as defined in
> X.509(97).

Fair enough, we can add text to say that AKID is not needed if
baseCerificateId is used.

> In addition, I do not see the argument at paragraph 4.3.3 when you say
> using the baseCertificateId field to reference the AC issuer would mean
> that the AC verifier would be dependent on the AC issuer's public key
> infrastructure.

I guess we meant that use of baseCertificateId means that the 
AC relying party is also a relying party for whoever the AA
puts in as its PKC issuer. I can envisage some interdomain
cases where the AA is within one PKI (say certfied by CA-1)
but the AC relying party doesn't trust CA-1. If some CA the
relying party does trust (CA-2), issues another PKC for the AA,
then the relying party can use the AC is the AC has the
AA's name in the issuer field. Not sure if this'll be a 
real case, but I think its useful to allow such a split.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Date: Tue, 19 Oct 1999 16:34:24 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-ac509prof-01.txt

Russ and/or Steve,

The syntax of the issuer field in version 2 ACs was modified in the X.509
FPDAM such there would not be a need for the authorityKeyIdentifier
extension in an AC to assist the AC verifier in checking the signature of
the AC. By instead filling the optional baseCertificateId component of the
issuer field, the intend was that you would achieve the same result without
using any extensions, which is also the approach recommended in the X.509
FPDAM. The only reason the issuerName component of the issuer field was
left was for backward compatibility with version 1 ACs as defined in
X.509(97).

In addition, I do not see the argument at paragraph 4.3.3 when you say
using the baseCertificateId field to reference the AC issuer would mean
that the AC verifier would be dependent on the AC issuer's public key
infrastructure.

François

Date: Tue, 19 Oct 1999 14:00:59 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: PKIX <[email-masked]>
Subject: OID Typo in RFC2560?

All,

Forgive me if this has been caught earlier.  In clause 4.2.2.2 of RFC
2560 it says: "OCSP signing delegation SHALL be designated by the
inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
extension included in the OCSP response signer's certificate."  And
later it provides an oid reference of: id-kp-OCSPSigning OBJECT
IDENTIFIER ::= {id-kp 9}.  After that though, it refers to the
"id-ad-ocspSigning value as described above." I assume this is just a
typo and "id-ad-ocspSigning" should be replaced with
"id-kp-OCSPSigning"?  Or did I miss something?

spt

From: Warwick Ford <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: ISC Meeting Notice - Nov. 8-11, Washington, DC
Date: Mon, 18 Oct 1999 08:36:14 -0700

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_01BF197E.83B898C0
Content-Type: text/plain;
	charset="iso-8859-1"

FYI, attached is the meeting notice for the next American Bar Association
Information Security Committee meeting, which is scheduled for Washington DC
the same week as the IETF.  To take advantage of this co-location, the ABA
group has requested a meeting with PKIX experts to discuss various topics of
mutual interest.  Accordingly, an unofficial joint meeting has been
scheduled for the Thursday morning 11/11.  This meeting has no official
status in the IETF and anyone is welcome to attend.  We don't have a venue
yet, so any offers to host that meeting will be appreciated.  (Maybe 30-40
people(?), preferably close to the Omni Shoreham.)

Warwick

------_=_NextPart_000_01BF197E.83B898C0
Content-Type: application/msword;
	name="MeetingNotice11-99 dc v5.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="MeetingNotice11-99 dc v5.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAYwAAAAAAAAAA
EAAAZQAAAAEAAAD+////AAAAAGIAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------_=_NextPart_000_01BF197E.83B898C0--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dcs-03.txt
Date: Mon, 18 Oct 1999 06:53:09 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Data  
                          Validation and Certification Server Protocols
	Author(s)	: C. Adams, P. Sylvester,  M. Zolotarev, R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-03.txt
	Pages		: 26
	Date		: 15-Oct-99
	
This document describes a general data validation and certification
service and the protocols to be used when communicating with it.  The
Data Validation and Certification Server is a Trusted Third Party
(TTP) that can be used as one component in building reliable non-
repudiation services (see [ISONR]).
Useful Data Validation and Certification Server responsibilities in a
PKI are to validate signed documents and to assert the validity of
public key certificates at a given time.
We give examples of how to use the Data Certification Server to
extend the lifetime of a signature beyond key expiry or revocation
and to query the Data Certification Server regarding the status of a
public key certificate.
<draft>Note: The initial drafts of this protocol used the
abbreviation DCS instead of DVCS.</draft>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-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-dcs-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-dcs-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-dcs-03.txt

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

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

--OtherAccess--

--NextPart--

From: "Suzanne" <[email-masked]>
To: [email-masked]
Date: Mon, 18 Oct 1999 11:28:08 +0000
Subject: remove
Reply-to: [email-masked]
Priority: normal

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suzanne Carr
Tel: 01665 603 862
Email: [email-masked]
Email: [email-masked]
WWW:   http://www.oubliette.zetnet.co.uk

From: [email-masked]
To: [email-masked]
Subject: remove
Date: Mon, 18 Oct 1999 09:17:07 +0200

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: DisplayText for Verisign Certificate
Sender: [email-masked]
Reply-To: [email-masked]
Date: Sat, 16 Oct 1999 08:28:58 (NZDT)

"Amit Kapoor" <[email-masked]> writes:

>While working with Bob Jueneman on some S/MIME certificate issues we ran 
>into the following with a Verisign issued certificate:
>
>The portion of ASN.1 dump showing the problem:
>
>Verisign is encoding the DisplayText as IA5 whereas according to 2459 it can 
>be one of Visible, BMP or UTF8 string.
>
>Should we add IA5String to the choice list of DisplayText or treat this as a 
>error and not support the Verisign certificates?

This was quietly changed between the final draft and the RFC, as a result of 
this some implementations expect one and some expect the other.  The 
workaround I've got in my code is:

/* All draft versions of the PKIX profile had the organization as an
   IA5String, but the final RFC changed it to a VisibleString, in order
   to kludge around this for the certs which use an IA5String (which in
   practice means only Verisign, since noone else uses seems to use policy
   qualifiers), we allow both types but put the VisibleString option
   first which means it'll get used preferentially when encoding */

The code comment explains why it appears to be a Verisign bug (but isn't), 
noone else seems to use qualifiers so you won't see it anywhere else, and 
what Verisign were doing was correct at the time they did it.  I should 
really put this in the style guide.

Peter.

From: "Amit Kapoor" <[email-masked]>
To: "PKIX" <[email-masked]>
Cc: <[email-masked]>
Subject: DisplayText for Verisign Certificate
Date: Fri, 15 Oct 1999 12:04:36 -0700
Importance: Normal

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01BF1705.72CDD2B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

	While working with Bob Jueneman on some S/MIME
	certificate issues we ran into the following with
	a Verisign issued certificate:

	The portion of ASN.1 dump showing the problem:

     766 06   11:                   OBJECT IDENTIFIER
		:                     Verisign certificatePolicy (2 16 840 1 113733 1 7
1 1)
     779 30  142:                   SEQUENCE {
     782 30   40:                     SEQUENCE {
     784 06    8:                       OBJECT IDENTIFIER cps (1 3 6 1 5 5
7 2 1)
     794 16   28:                       IA5String
'https://www.verisign.com/CPS'
		:                       }
     824 30   98:                     SEQUENCE {
     826 06    8:                       OBJECT IDENTIFIER
		:                         unotice (1 3 6 1 5 5 7 2 2)
     836 30   86:                       SEQUENCE {
     838 30   21:                         SEQUENCE {
     840 16   14:                           IA5String 'VeriSign, Inc.'
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^
     856 30    3:                           SEQUENCE {
     858 02    1:                             INTEGER 1
		:                             }
		:                           }
     861 1A   61:                         VisibleString
		:                   'VeriSign's CPS incorp. by reference liab. ltd. ('
		:                   'c)97 VeriSign'
		:                         }
		:                       }
		:                     }

	Verisign is encoding the DisplayText as IA5 whereas according to
	2459 it can be one of Visible, BMP or UTF8 string.

	Should we add IA5String to the choice list of DisplayText or treat
	this as a error and not support the Verisign certificates?

	regards

Amit

------------------------------------------------------
Certificate Authority: http://www.smeme.com
CA root : http://www.smeme.com/faq_operational.html#16
------------------------------------------------------

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

------=_NextPart_000_000F_01BF1705.72CDD2B0--

From: [email-masked]
To: [email-masked], Sean Mullan <[email-masked]>
Date: Fri, 15 Oct 1999 20:16:43 +0400
Subject: Re: Processing CRLs without Issuing Distribution Points
Reply-to: [email-masked]
Priority: normal

<color><param>0100,0100,0100</param>On 15 Oct 99, at 11:21, Sean Mullan wrote:

<color><param>7F00,0000,0000</param>> 

> RFC 2459 does not require that CRLs contain an Issuing

> Distribution Point extension.

> Does this mean that a CA may issue *partial* CRLs without

> including an Issuing Distribution Point Extension?

</color>How I understand, if CRL doesn't contain IDP, that means the CRL

is complete.

X.509 (08/97):

"<color><param>0100,0100,0100</param><FontFamily><param>Times New Roman</param>The particular CA responsible for each entry is as indicated by the certificate 

issuer CRL entry extension in that entry or in accordance with the defaulting

rules described in 12.6.3.2. In such a CRL, it is the responsibility of the CRL 

issuer to ensure that the CRL is complete in that it contains all revocation entries, 

consistent with <bold><smaller>onlyContainsUserCerts</bold><bigger>, <bold><smaller>onlyContainsCACerts</bold><bigger>, and <bold><smaller>onlySomeReasons</bold><bigger> 

indicators, from all CAs that identify this CRL issuer in their certificates."

<smaller>So, the content of CRL is on CRL issuer responsibility.</color><FontFamily><param>Arial CYR</param><bigger>

<color><param>7F00,0000,0000</param>> 

> If the answer is yes, it is not possible for a relying party to 

> safely determine if a certificate has not been revoked by inspecting

> a CRL without an Issuing Distribution Point extension. It cannot

> assume that a single CRL is an exhaustive list and it also cannot

> assume a sequence of CRLs when taken as one is an exhaustive list.

> Therefore a relying party cannot safely determine that the certificate in 

> question has not been revoked.

> RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial 

> CRLs containing revoked CA certs only in the authorityRevocationList 

> attribute, but makes no mention as to whether or not those CRLs should 

> contain an Issuing Distribution Point extension. We claim they must in 

> order for a relying party to be sure that the CRL is a partial CRL 

> containing an exhaustive list of revoked CA certs only.

> Have there been any partial CRLs deployed w/o Issuing Distribution

> Point extensions?

> We think that RFC 2459 should be changed (or made more clear) to make 

> the Issuing Distribution Point extension mandatory for CAs which split CRLs

> according to reason codes or user/CA type, and that relying parties

> should treat CRLs without an Issuing Distribution Point

> extension as complete (exhaustive) CRLs.

</color>I think, you don't have another choices in the case, when you have

CRL with full reasons ( or without IDP at all ).

<color><param>7F00,0000,0000</param>> 

> -- 

> Sean Mullan			Email: [email-masked]

> Sun Microsystems Laboratories	Tel:   (781) 442-0926	

> One Network Drive		Fax:   (781) 442-1692

> Burlington, MA 01803-0902

<nofill>
____________
Pavel Krylov

Sender: [email-masked]
Date: Fri, 15 Oct 1999 11:21:01 -0400
From: Sean Mullan <[email-masked]>
Organization: Sun Microsystems
To: [email-masked]
Subject: Processing CRLs without Issuing Distribution Points

RFC 2459 does not require that CRLs contain an Issuing
Distribution Point extension.

Does this mean that a CA may issue *partial* CRLs without
including an Issuing Distribution Point Extension?

If the answer is yes, it is not possible for a relying party to 
safely determine if a certificate has not been revoked by inspecting
a CRL without an Issuing Distribution Point extension. It cannot
assume that a single CRL is an exhaustive list and it also cannot
assume a sequence of CRLs when taken as one is an exhaustive list.
Therefore a relying party cannot safely determine that the certificate in 
question has not been revoked.

RFC 2587 (LDAP v2 schema) states that CAs may choose to store partial 
CRLs containing revoked CA certs only in the authorityRevocationList 
attribute, but makes no mention as to whether or not those CRLs should 
contain an Issuing Distribution Point extension. We claim they must in 
order for a relying party to be sure that the CRL is a partial CRL 
containing an exhaustive list of revoked CA certs only.

Have there been any partial CRLs deployed w/o Issuing Distribution
Point extensions?

We think that RFC 2459 should be changed (or made more clear) to make 
the Issuing Distribution Point extension mandatory for CAs which split CRLs
according to reason codes or user/CA type, and that relying parties
should treat CRLs without an Issuing Distribution Point
extension as complete (exhaustive) CRLs.

-- 
Sean Mullan			Email: [email-masked]
Sun Microsystems Laboratories	Tel:   (781) 442-0926	
One Network Drive		Fax:   (781) 442-1692
Burlington, MA 01803-0902

Date: Thu, 14 Oct 1999 14:31:07 -0700
To: Robert Moskowitz <[email-masked]>, Tim Polk <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: updated path validation text

At 05:02 PM 10/14/99 -0400, Robert Moskowitz wrote:
>here is it mostly cleaned up..

That is *not* clean, *nor* is it complete. The beginning of the file you 
sent reads:

                Upon completion of all steps, path processing has
                succeeded if the value of explicit_policy variable is
                greater than zero, or the valid_policy_tree is not NULL.

             6
              .1

                .
                 6
                   O

                    ut
                      p
                       u
                        t

                         s

Could people who have alternative formats for documents pass those files to 
the document authors and let those authors turn them in? If you want to 
help Tim, send the file to Tim, not the whole list. He can decide whether 
or not to make this a list thing.

Also, as the maintainer of the web site, I'm happy to take a file from you 
and put it on the web site so you can just send a pointer. That way, the 
subset of the 1170 people on this mailing list who can't read your format 
don't have to waste their time with downloading a file they can't read.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 14 Oct 1999 17:02:16 -0400
To: Tim Polk <[email-masked]>, [email-masked]
From: Robert Moskowitz <[email-masked]>
Subject: Re: updated path validation text

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

At 05:36 PM 10/13/1999 -0400, Tim Polk wrote:

>P.S.  Sorry about the Word attachment.  The straightforward conversion to
>text lost all the formatting/indenting , and I think that really helps the
>readers' comprehension.  If anyone asks, I will convert it to a nice UNIX
>text file and repost.  Otherwise, it will get fixed when I convert to
>nroff...

here is it mostly cleaned up..

--=====================_64037881==_
Content-Type: text/plain; name="2459-61.txt";
 x-mac-type="42494E41"; x-mac-creator="74747874"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="2459-61.txt"

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

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]
--=====================_64037881==_--

Date: Thu, 14 Oct 1999 16:08:13 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Y2K and Digital Certificates Article
Cc: [email-masked], [email-masked]

Bob:

Here is the first paragraph from an article you wrote:

You'd think that a new Internet standard would be free of Y2K problems. But 
if it has a legacy component, think again. Digital certificates have been 
around for a dozen years and in that time they've gone through three 
versions. We finally have an Internet Standard Profile (RFC 2459, Internet 
X.509 PKI Certificate, and Certificate Revocation List, collectively known 
as PKIX). But this new standard has a Y2K bomb that could go off 40 years 
from now--when it is well entrenched in our businesses.

I do not consider this a Y2K-like situation.  RFC 2459 clearly tells 
developers how to handle UTCTime and GeneralizedTime.  There is no ambiguity.

Russ

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Scope of OCSP
Date: Thu, 14 Oct 1999 14:41:39 -0400
Importance: Normal

All,

	To give some explanation for the proposed scope of OCSPX.
As I see it there are two potential models for deployment of
PKI functionality.

1)	Fat PKIX aware Client supported by minimal server
		bringing together a data set.

2)	Thin client, PK aware but not PKI aware, supported by
		PKIX aware server.

	As members of the group are probably aware, my personal
prejudice is for approach (1). This is however a prejudice and
not an argument. There are many applications in which the
second approcah is more appropriate. These include wireless
applications and interactions with legacy mainframes.

	[I find the references to "Mobile IP" and such irrelevant.
It is taken as a given that in any situation in which a client
is relying on a server for trust decisions that an appropriately
secure protocol will be employed and that the client will ensure
that the data supplied is authentic, this requires only mutual
authentication however and not a PK INFRASTRUCTURE. I will make 
this more explicit in the security issues section of next draft.]

	I believe there are applications which will mandate 
particular approaches. My hypothesis is that there is _NO_ middle
ground. Whenever there is a need for a thin authentication client
a fat authorization client will be unacceptable.

	As I specifically state in the draft, there is a security
risk in delegation of trust path dicovery to a remote server. There
is an additional risk in delegation of trust path validation. There
is however no ADDITIONAL risk in then adding the authorization since
an attacker who can spoof authentication can spoof authorization by
simply spoofing the identity of a sufficiently priviledged individual.

	[Equally the 'risk' introduced by delegating trust path 
discovery is not that great since regardless of where the data is 
analyzed it must come from an outside source.]

	Issues of timing and venue are important, so much so that
I would hope to see a little more explanation of opinions than
"I don't believe the time is right". The time is never right in 
the IETF, there is always another group. 

	I don't think that the IETF process progresses at such a 
reckless pace that we need be affraid of putting out proposals
for fear that it is 'too soon'. I have customers who have expressed
a clear demand for the functionality described. If the problem
is complex and needs time to be worked on then the time to start 
is now. The only reason to wait would be if there was insufficient
experience of PKI deployment to understand the problems at this
point. This is certainly not the case where I sit.

	That said, if there is a clear consensus that there is
a clear need etc. for one subset of the OCSP-X functionality and
no consensus for the remainder it may be appropriate to write
two drafts, one on the proposed standard track and another on the
experimental. I would like to see reasons other than "thats not
the way I want to do it" and I would like to see specific references
to the draft before taking this approach however.

		Phill

Date: Thu, 14 Oct 1999 10:24:01 -0700
From: Ed Gerck <[email-masked]>
To: Phillip M Hallam-Baker <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: Sentient applications, was Re: FW: OCSP-X  Internet Draft:  Extensions to OCSP

Phillip M Hallam-Baker wrote:

> Ed,
>
>         The ability to use knowledge is not generally considered a
> sufficient requirement for sentience. Knowledge is simply information
> that can be used.

Not knowledge, but reasoning without data.

>         The language used would be appropriate if a human were
> performing the task, it is therefore appropriate if a machine replaces
> the human.

If what you say is true, then I move for us to apply it immediately to all
laws and get rid of all lawyers, now substituted by computers.

So, since that is not possible (yet?) your document would be better
appreciated, IMO, if it would allow the reader to use today's tools --
where one needs to replace vague human-based reasonings such as

 "For an application to make an informed decision as to whether it trusts a
  digital certificate"

with programmable assertions such as

 "For an application to decide whether a digital certificate is trusted, the
 application must be programmed with a trust metric, defined here to
  include, exclusively,"

which MUST include the trust metrics used for the decision, not only the
trust-points (certificate, signing key, etc.).  To do otherwise is to require
reasoning without data.

Also, I don't find it useful to remind us of the Church-Turing hypothesis as
explicit in your second paragraph, unless you also note that time and
memory space were not factors in that hypothesis.

Thus, exactly because I valued your text, I would suggest it should not require
infinite time and memory in order to be implemented.

Cheers,

Ed Gerck

Date: Thu, 14 Oct 1999 13:14:43 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: updated path validation text
To: [email-masked], [email-masked]

--Singular_of_Boars_835_000
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 94DPisCJhRl2F2K7b/xgiw==

Tim,

  Posting PDF is, I believe, a lesser sin than posting native Word  :-).
Attached is a portable version of the document.

> P.S.  Sorry about the Word attachment.  The straightforward conversion to
> text lost all the formatting/indenting , and I think that really helps the
> readers' comprehension.  If anyone asks, I will convert it to a nice UNIX
> text file and repost.  Otherwise, it will get fixed when I convert to
> nroff...

--Singular_of_Boars_835_000
Content-Type: APPLICATION/pdf; name="RevisedPathproc6c.pdf"; x-unix-mode=0644
Content-Transfer-Encoding: BASE64
Content-Description: RevisedPathproc6c.pdf
Content-MD5: BgSt2spDGrumJ85EMQG94g==

--Singular_of_Boars_835_000--

From: [email-masked]
To: [email-masked]
Subject: unsubscribe
Date: Thu, 14 Oct 1999 18:03:54 +0200

From: "Steve Sodt" <[email-masked]>
To: "Phillip M Hallam-Baker" <[email-masked]>, "Ed Gerck" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Sentient applications, was Re: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Thu, 14 Oct 1999 11:58:17 -0400
Importance: Normal
Disposition-Notification-To: "Steve Sodt" <[email-masked]>

Just an aside, I've also heard it argued that - paraphrased - knowledge
enables the use of information, implying that it is a prerequisite to the
effective use of information.  In this sense knowledge is independent, and
information dependent.  Sorry to interject any unwelcome simplemindedness.

-----Original Message-----
From: Phillip M Hallam-Baker [mailto:[email-masked]]
Sent: Thursday, October 14, 1999 11:36 AM
To: Ed Gerck
Cc: [email-masked]'
Subject: RE: Sentient applications, was Re: FW: OCSP-X Internet Draft:
Extensions to OCSP

Ed,

	The ability to use knowledge is not generally considered a
sufficient requirement for sentience. Knowledge is simply information
that can be used.

	The language used would be appropriate if a human were
performing the task, it is therefore appropriate if a machine replaces
the human.

	I don't find it usefull to revisit Searle's Chineese room on
an IETF mailing list. The only reason that Searle's argument is
so much discussed is that it is so bad that everyone has their own
favourite means of arguing against it.

		Phill

Date: Thu, 14 Oct 1999 16:58:36 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: "Linn, John" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, xme <[email-masked]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP

John,

> I don't think that the viability or utility of offloaded validation is
> something which would vary as a function of the application protocol(s) with
> which the validated certificates are being used.  It's a design tradeoff
> (probably more visible within PKI provider layers than in their consumer
> applications) which incurs additional reliance on a central server but
> reduces the amount of data which must be propagated to the clients in order
> for validation to be performed.

Well, some of the arguments in SCVP and OCSP-X relate to
"footprint", "device complexity" etc. One of the questions
I'd want answered is how these arguments stand up in
real cases - if such protocols don't actually reduce
the footprint etc. when used in real applications
then the arguments fall.

There are also issues to do with mapping from 
application specific naming to certificates. E.g.
if I want to encrypt a mail for someone, do I
first get their cert, then check with the server
for a valid path, or do I send up the email
address? The answers to such questions may well
mean that the claimed centralisation of policy
isn't really there (in addition to also affecting
the footprint stuff again).

Another reason for wanting to see the effect
of this is that it changes the trust model
of any PKI consuming application, and given
the ways things are implemented, potentially
without the application being modified. I'm
concerned that replacing a current PKI library 
(which has path validation) with one with 
only remote path validaiton may open up 
new vulnerabilities. Maybe I'm just stupid, 
but I want to see what the consequences would 
be before recommending this.

Basically, in the absence of worked cases, we're
assuming a lot in saying that such protocols 
should be on the standards track.

> If I understood earlier discussion on this thread correctly, Stephen had
> already agreed about the merits of support for server-based path
> construction.  If a client depends on its server for path construction
> purposes, it's already accepted the dependency on server availability; given
> this acceptance, I don't see a strong availability-oriented argument against
> broader scope for the server-side functions.  By extending OCSP (already
> accepted as an on-line service trusted for validation support purposes), the
> proposal isn't adding an additional attack target, though it arguably makes
> the existing target more attractive by broadening the impact of a successful
> compromise.

Not quite. Paths can be cached and re-used. A clever client
(of a path constructing server) could even relate them to 
build a "picture" of the PKI which is relevant for it.
The protocol I'd like to see would also have a "didn't
like that path, can you find another?" option for the
client to use. This means that the server doesn't have to
be trusted for much, nor need it be as "available" as
a putative SCVP/OCSP-X server.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: "Linn, John" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: "Linn, John" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Thu, 14 Oct 1999 11:44:06 -0400

Stephen wrote:

> > I fully agree with the additional explanations you have provided.
> 
> 'Fraid I don't, not "fully" anyway. Like I said in 
> my previous mail, I'd still love to see a worked case 
> showing why its a good thing to use a server to 
> construct *and* validate *all* certificate paths
> that a client will *ever* use. Even for one 
> application, (e.g. TLS or S/MIME), I'm far from
> convinced that this is a good approach. Until
> I do see such an example, I'll be very sceptical.

I don't think that the viability or utility of offloaded validation is
something which would vary as a function of the application protocol(s) with
which the validated certificates are being used.  It's a design tradeoff
(probably more visible within PKI provider layers than in their consumer
applications) which incurs additional reliance on a central server but
reduces the amount of data which must be propagated to the clients in order
for validation to be performed.  

> 
> (Don't forget, this isn't free, we'd be creating
> a new highly attractive target for attacks, that
> also has to be highly available and widely
> contactable! Just imagine using this if you had
> a mobile IP connection. Yuk!)

If I understood earlier discussion on this thread correctly, Stephen had
already agreed about the merits of support for server-based path
construction.  If a client depends on its server for path construction
purposes, it's already accepted the dependency on server availability; given
this acceptance, I don't see a strong availability-oriented argument against
broader scope for the server-side functions.  By extending OCSP (already
accepted as an on-line service trusted for validation support purposes), the
proposal isn't adding an additional attack target, though it arguably makes
the existing target more attractive by broadening the impact of a successful
compromise.     

--jl

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Ed Gerck" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Sentient applications, was Re: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Thu, 14 Oct 1999 11:35:39 -0400
Importance: Normal

Ed,

	The ability to use knowledge is not generally considered a
sufficient requirement for sentience. Knowledge is simply information
that can be used.

	The language used would be appropriate if a human were 
performing the task, it is therefore appropriate if a machine replaces
the human.

	I don't find it usefull to revisit Searle's Chineese room on
an IETF mailing list. The only reason that Searle's argument is
so much discussed is that it is so bad that everyone has their own
favourite means of arguing against it.

		Phill

Date: Thu, 14 Oct 1999 15:22:34 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
CC: "[email-masked]'" <[email-masked]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP

Stephen,

You made a good guess !

So at least you got one example, but you might be right to say
that's not what you read SCVP or OCSP-X are trying to address
though.

Denis

> John, Denis,
> 
> Denis Pinkas wrote:
> >
> > John,
> >
> > I fully agree with the additional explanations you have provided.
> 
> 'Fraid I don't, not "fully" anyway. Like I said in
> my previous mail, I'd still love to see a worked case
> showing why its a good thing to use a server to
> construct *and* validate *all* certificate paths
> that a client will *ever* use. Even for one
> application, (e.g. TLS or S/MIME), I'm far from
> convinced that this is a good approach. Until
> I do see such an example, I'll be very sceptical.
> 
> (Don't forget, this isn't free, we'd be creating
> a new highly attractive target for attacks, that
> also has to be highly available and widely
> contactable! Just imagine using this if you had
> a mobile IP connection. Yuk!)
> 
> OTOH, I do see a use for such a service for
> Denis' purpose, which, I guess, is to figure out
> whether a certificate was valid at some time
> in the past as part of evaluating the evidence
> for NR purposes. That's not what I read SCVP or
> OCSP-X as trying to address though.
> 
> Stephen.
> 
> >
> > Denis
> >
> > > Denis proposed the following as a candidate functional scope for an OCSP-X:
> > >
> > > >
> > > > 1) validating a certificate * for a given time * against some rules
> > > > which would desribe an acceptable certification *forest* to be used
> > > > (a forest has several trees and thus several roots to be fully
> > > > explicit).
> > > >
> > > > 2) giving back to the user the certification path (i.e. the
> > > > certificate identifiers - not necessarilly the certificates
> > > > themselves) that have been used * for that given time * for the
> > > > validation, including the relevant revocation (i.e. CRLs) or status
> > > > (i.e. OSCP responses) information.
> > > >
> > > > This would be quite sufficient at the time being.
> > > >
> > >
> > > I agree that this would be a useful core set.  Further, return of (2) could
> > > be optional.  It would be useful to those clients which wish to retrace the
> > > path validation performed by the server, to display the path if needed, or
> > > to record information for audit purposes.  If none of these cases hold,
> > > return of the data collected by the server during the validation process
> > > seems redundant.
> > >
> > > --jl
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 647 7406
> 61 Fitzwilliam Lane,                    fax: +353 1 647 7499
> Dublin 2.                mailto:[email-masked]
> Ireland                             http://www.baltimore.com

From: Peter Sylvester <[email-masked]>
Date: Thu, 14 Oct 1999 15:20:08 +0200 (MET DST)
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dcs-02.txt

Please ignore the following draft. 

A new version will be send today or tomorrow. 

	Title		: Internet X.509 Public Key Infrastructure Data   
                          Validation and Certification Server Protocols
	Author(s)	: C. Adams, P. Sylvester, M. Zolotarev,  R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-02.txt
	Pages		: 26
	Date		: 13-Oct-99

Date: Thu, 14 Oct 1999 14:17:55 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Denis Pinkas <[email-masked]>
CC: "Linn, John" <[email-masked]>, "[email-masked]'" <[email-masked]>, xme <[email-masked]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP

John, Denis,

Denis Pinkas wrote:
> 
> John,
> 
> I fully agree with the additional explanations you have provided.

'Fraid I don't, not "fully" anyway. Like I said in 
my previous mail, I'd still love to see a worked case 
showing why its a good thing to use a server to 
construct *and* validate *all* certificate paths
that a client will *ever* use. Even for one 
application, (e.g. TLS or S/MIME), I'm far from
convinced that this is a good approach. Until
I do see such an example, I'll be very sceptical.

(Don't forget, this isn't free, we'd be creating
a new highly attractive target for attacks, that
also has to be highly available and widely
contactable! Just imagine using this if you had
a mobile IP connection. Yuk!)

OTOH, I do see a use for such a service for
Denis' purpose, which, I guess, is to figure out 
whether a certificate was valid at some time
in the past as part of evaluating the evidence
for NR purposes. That's not what I read SCVP or
OCSP-X as trying to address though.

Stephen.

> 
> Denis
> 
> > Denis proposed the following as a candidate functional scope for an OCSP-X:
> >
> > >
> > > 1) validating a certificate * for a given time * against some rules
> > > which would desribe an acceptable certification *forest* to be used
> > > (a forest has several trees and thus several roots to be fully
> > > explicit).
> > >
> > > 2) giving back to the user the certification path (i.e. the
> > > certificate identifiers - not necessarilly the certificates
> > > themselves) that have been used * for that given time * for the
> > > validation, including the relevant revocation (i.e. CRLs) or status
> > > (i.e. OSCP responses) information.
> > >
> > > This would be quite sufficient at the time being.
> > >
> >
> > I agree that this would be a useful core set.  Further, return of (2) could
> > be optional.  It would be useful to those clients which wish to retrace the
> > path validation performed by the server, to display the path if needed, or
> > to record information for audit purposes.  If none of these cases hold,
> > return of the data collected by the server during the validation process
> > seems redundant.
> >
> > --jl

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Date: Thu, 14 Oct 1999 14:39:29 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "Linn, John" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP

John,

I fully agree with the additional explanations you have provided.

Denis

> Denis proposed the following as a candidate functional scope for an OCSP-X:
> 
> >
> > 1) validating a certificate * for a given time * against some rules
> > which would desribe an acceptable certification *forest* to be used
> > (a forest has several trees and thus several roots to be fully
> > explicit).
> >
> > 2) giving back to the user the certification path (i.e. the
> > certificate identifiers - not necessarilly the certificates
> > themselves) that have been used * for that given time * for the
> > validation, including the relevant revocation (i.e. CRLs) or status
> > (i.e. OSCP responses) information.
> >
> > This would be quite sufficient at the time being.
> >
> 
> I agree that this would be a useful core set.  Further, return of (2) could
> be optional.  It would be useful to those clients which wish to retrace the
> path validation performed by the server, to display the path if needed, or
> to record information for audit purposes.  If none of these cases hold,
> return of the data collected by the server during the validation process
> seems redundant.
> 
> --jl

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ocspx-00.txt
Date: Thu, 14 Oct 1999 06:52:34 -0400
Sender: [email-masked]

--NextPart

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

	Title		: OCSP Extensions
	Author(s)	: P. Hallam-Baker
	Filename	: draft-ietf-pkix-ocspx-00.txt
	Pages		: 16
	Date		: 13-Oct-99
	
The OCSP protocol [RFC2560] enables online validation of the reliability of a digital certificate. RFC2560  defines a mandatory-to-implement mechanism supporting the revocation status of the certificate and defines and optional extension mechanism to support a richer set of semantics (e.g. full path validation by the OCSP server).

This document defines Internet-standard  extensions to OCSP that enable a client to delegate processing of certificate acceptance functions to a 
trusted server. The client may control the degree to which delegation takes place. In addition limited support is provided for delegating authorization decisions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ocspx-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-ocspx-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-ocspx-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-ocspx-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-ocspx-00.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-dcs-02.txt
Date: Thu, 14 Oct 1999 06:52:26 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Data   
                          Validation and Certification Server Protocols
	Author(s)	: C. Adams, P. Sylvester, M. Zolotarev,  R. Zuccherato
	Filename	: draft-ietf-pkix-dcs-02.txt
	Pages		: 26
	Date		: 13-Oct-99
	
This document describes a general data validation and certification
service and the protocols to be used when communicating with it.  The
Data Validation and Certification Server is a Trusted Third Party
(TTP) that can be used as one component in building reliable non-
repudiation services (see [ISONR]).
Useful Data Validation and Certification Server responsibilities in a
PKI are to validate signed documents and to assert the validity of
public key certificates at a given time.
We give examples of how to use the Data Certification Server to
extend the lifetime of a signature beyond key expiry or revocation
and to query the Data Certification Server regarding the status of a
public key certificate.
<draft>Note: The initial drafts of this protocol used the
abbreviation DCS instead of DVCS.</draft>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-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-dcs-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-dcs-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-dcs-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 13 Oct 1999 17:36:39 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: updated path validation text

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

Folks,

We are currently editing "son-of-RFC 2459" which should - no, *will* - be
posted by 5PM on October 22 (that is, before the Washington meeting
cut-off).  In general, that should be plenty of time to review and discuss
before the meeting.  Most of it is minor stuff, and pretty straightforward.

However, the current draft of section 6.1 (the path validation algorithm)
is significantly more detailed than the section 6.1 in RFC 2459.  It
probably bears additional review, so I wanted to circulate it ahead of the
rest of the I-D.  There are two basic changes:

#1 The old text left out details that appeared elsewhere in the
specification.  The new text is more comprehensive, addressing every field
or extension that affects whether a certification path is valid.

For example, the algorithm in section 6.1 assumed that unique identifiers
did not appear.  However, section 4.1.2.8 and 6.1 of RFC 2459 require that
UIDs be processed if they appear in a certificate, and this clearly affects
path validation.  The reader needed to augment the algorithm in 6.1 with
information from other sections of the document.  The new text explicitly
addresses the processing rules when UIDs apper in subject or issuer names.
This increases the bulk of the document, but should make it significantly
easier to use.

#2 ISO will be meeting Oct. 28 to consider some bug fixes that affect
processing of the certificate policies extensions and related constraints.
The bugs were important, causing unexpected acceptance of certain
certification paths!  Our goal is to incorporate the bug fixes into
"son-of-RFC 2459" so that policy and path processing in the ISO and IETF
specifications are equivalent. This text incorporates what we *expect* to
be the ouput of the Oct. 28 ISO meeting.  At least, it matches several
countries ballot comments...

Anyway, I have attached my current draft of section 6.1.  I believe this
text to be comprehensive, and I think it is in line with the changes ISO
will *probably* make regarding the defect report.

Please take a long, hard look at this text!  Your comments are appreciated!

Thanks,

Tim Polk

P.S.  Sorry about the Word attachment.  The straightforward conversion to
text lost all the formatting/indenting , and I think that really helps the
readers' comprehension.  If anyone asks, I will convert it to a nice UNIX
text file and repost.  Otherwise, it will get fixed when I convert to
nroff...
--=====================_939864999==_
Content-Type: application/octet-stream; name="RevisedPathproc6c.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="RevisedPathproc6c.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAUQAAAAAAAAAA
EAAAUgAAAAEAAAD+////AAAAAFAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///+////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
--=====================_939864999==_--

From: "Linn, John" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "Salz, Rich" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Wed, 13 Oct 1999 16:19:48 -0400

Denis proposed the following as a candidate functional scope for an OCSP-X:

> 
> 1) validating a certificate * for a given time * against some rules
> which would desribe an acceptable certification *forest* to be used
> (a forest has several trees and thus several roots to be fully
> explicit).
> 
> 2) giving back to the user the certification path (i.e. the
> certificate identifiers - not necessarilly the certificates
> themselves) that have been used * for that given time * for the
> validation, including the relevant revocation (i.e. CRLs) or status
> (i.e. OSCP responses) information.
> 
> This would be quite sufficient at the time being.
> 

I agree that this would be a useful core set.  Further, return of (2) could
be optional.  It would be useful to those clients which wish to retrace the
path validation performed by the server, to display the path if needed, or
to record information for audit purposes.  If none of these cases hold,
return of the data collected by the server during the validation process
seems redundant. 

--jl

Date: Wed, 13 Oct 1999 09:14:27 -0700
From: Ed Gerck <[email-masked]>
To: Denis Pinkas <[email-masked]>
CC: "Salz, Rich" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP

Denis Pinkas wrote:

> >
> > I share Stephen's concerns about PKIX getting involved in authorization; I
> > think it's way too premature.

I agree, except if the implict assumptions in the RFC (see my last msg) are
made explict.  Then, the RFC could specify authorization but with clear
trust metrics to be applied, not just trust points as it does today.  In
practice, though, this would not be very much different than what you
suggest below, which also IMO deals with authorization. For example,
you define one such trust metric below, authorizing a certificate to be
used if it meets the criteria trusted beforehand ("some rules",
"acceptable") for its validity:

> 1) validating a certificate * for a given time * against some rules
> which would desribe an acceptable certification *forest* to be used
> (a forest has several trees and thus several roots to be fully
> explicit).

Yes. However, for the sake of terminology (and, saving trees), the
data model you mention is not called forest but "network" -- in contrast
to a "hierarchical tree".  To summarize the difference, the network data
model can be regarded as an extended form of the hierarchic
data model – the principal distinction between the two being that
in a hierarchic structure, a child record has exactly one parent
whereas in a network structure, a child record can have any
number of parents (possibly even zero).

The other data model which could also be applied  is the relational
data model, which then would describe an acceptable *view* to
be used when authorizing a certificate within a trust metric.

Cheers,

Ed Gerck

Date: Wed, 13 Oct 1999 16:42:45 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "Salz, Rich" <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP

> 
> I share Stephen's concerns about PKIX getting involved in authorization; I
> think it's way too premature.

I share the same concern too. We should not address authorization.
The document is in fact adsressing too many aspects. From the list
of functionality only two items should be covered/supported: 

1) validating a certificate * for a given time * against some rules
which would desribe an acceptable certification *forest* to be used
(a forest has several trees and thus several roots to be fully
explicit).

2) giving back to the user the certification path (i.e. the
certificate identifiers - not necessarilly the certificates
themselves) that have been used * for that given time * for the
validation, including the relevant revocation (i.e. CRLs) or status
(i.e. OSCP responses) information.

This would be quite sufficient at the time being.

Denis

> There are many places where cross-certification is "outlawed" and path
> discovery is pretty darn simple.  I think that's justification enough
> to start work here.
>         /r$

From: "Salz, Rich" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Wed, 13 Oct 1999 10:18:28 -0400

I share Stephen's concerns about PKIX getting involved in authorization; I
think it's way too premature.

There are many places where cross-certification is "outlawed" and path
discovery is pretty darn simple.  I think that's justification enough
to start work here.
	/r$

Date: Wed, 13 Oct 1999 10:04:52 -0400
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: End-Entity Certificate Policies

>>>>> "Andrew" == Andrew Probert <[email-masked]> writes:

 Andrew> CAs would never use the *same* policy OID as they surely they
 Andrew> would be issuing policies prefixed by their own unique
 Andrew> company's / CAs OID!

Not necessarily.  What if a CA adopted the Standard Terms and
Conditions created by the European Professional Association of CAs?
There are plenty of examples like that in current business practice. 

	paul

Date: Wed, 13 Oct 1999 15:31:01 +0100
From: Detlef =?iso-8859-1?Q?H=FChnlein?= <[email-masked]>
Organization: Secunet AG - The Trust Company
To: [email-masked]
Subject: CQRE'99 - Call for Participation

Dear Listmembers! 

Sorry for crossposting. The Call for Participation below
might be of interest for you. To register, please visit
http://www.cqre.net . You might want to note that the 
early bird registration period already expires on Oct. 22, 
which is less than two weeks from now. 

I would be looking forward to seeing you at CQRE. 

Best regards

	Detlef Huehnlein

***************************************************************
                  Call for Participation 
            CQRE [Secure] Congress & Exhibition
        Duesseldorf, Germany, Nov. 30 - Dec. 2 1999
---------------------------------------------------------------
provides a new international forum covering most aspects of
information security with a special focus to the role of
information security in the context of rapidly evolving 
economic processes.
---------------------------------------------------------------
Part I covers stratecial issues of IT-Security while Part II
will discuss more technical issues, like 

- SmartCard Technology / Security
- Public Key Infrastructures
- Network Security
- Mobile Security
- Intrusion Detection
- Enterprise Security
- Security Design
- Electronic Payment
- Electronic Commerce
- Cryptography
- Espionage
- Interoperability
- Biometrics 
- Risk Management
- Signature Laws 
- Training / Awareness

for example.
----------------------------------------------------------------
                       CQRE-PROGRAM:
----------------------------------------------------------------
Part I - Strategical Aspects
Tuesday, November 30, 1999
----------------------------------------------------------------
09.30 Opening: Chairman Paul Arlman, Federation of European 
Stock Exchange 
09.45 Keynote Dr.Hagen Hultzsch, Deutsche Telekom AG
"A corporate group in transition - how Deutsche Telekom is 
preparing for the digital economy."
10.15 Keynote Jean-Paul Figer, Cap Gemini S.A
"Brave Digital World? The balance between chances and 
risks for the information society."
10:45 Coffee
11:15 Five parallel Workshops:
Workshop 1 - "Values & standards"   (Prof.Dr. Gertrud Höhler)
Workshop 2 - "Law & regulation"     (Klaus-Dieter Scheurle)  
Workshop 3 - "Strategy & success" 
Workshop 4 - "Role of technology"   (Karl-Heinz Streibich)
Workshop 5 - "Monitoring & control" (Piet van Reenen)
12.45 Lunch
14.15 Keynote Dr.Ulrich Schumacher, CEO Infineon
"Network Citizen - what does the networked citizen and 
consumer stand to gain and lose?"
15.15 Workshop results (Moderator Paul Arlman) 
15.45 Coffee
16.00 Summary / 10-point-programme 
17.00 Happy Hour
18.00 Platform debate (Moderator Klaus-Peter Siegloch, ZDF)
----------------------------------------------------------------
Part II - Technical Aspects:
Wednesday, December 1, 1999
----------------------------------------------------------------
09.00 R.Baumgart: Welcome 
09.15 B.Schneier: "Attack trees - a novel methodology 
        for risk management."
10.00 Refreshments 
10.15 Four parallel tracks:
I. Risk Management:
      D.Povey: "Developing Electronic Trust Policies 
        Using a Risk Management Model"
      J.Hopkinson: "Guidelines for the Management
        of IT-Security"
II. Security Design:
      L.Romano, A.Mazzeo and N.Mazzocca: "SECURE:
        a simulation tool for PKI design"
      D.Basin: "Lazy Infinite State Analysis 
        of Security Protocols"
III. Enterprise Security:
      P.Kunz: "The case for IT-Security"
      W.Wedl: "Integrated Enterprise Security - Examples 
        conducted in large European Enterprises"
      B.Esslinger: "The PKI development of Deutsche Bank"
IV. Tutorial:
      H.Handschuh: "Cryptographic SmartCards"
11.45 Lunch
13.15 S.Senda: "Electronic Cash in Japan"
14.00 M.Yung, Y.Tsiounis, M.Jakobsson, D.MRhaihi:
      "Panel: Electronic payments where do we go 
      from here?"
15.00 Four parallel tracks:
I. SmartCard Issues
      R.Kehr, J.Possega, H.Vogt: "PCA: Jini-based 
        Personal Card Assistant"
      M.Nyström, J.Brainard: "An X.509-Compatible 
        Syntax for Compact Certificates"
II. Applications
      D.Hühnlein, J.Merkle: "Secure and cost efficent
        electronic stamps"
      K.Sako: "Implementation of a Digital 
        Lottery Server on WWW"
III. PKI-experiences
      J.Lopez, A.Mana, J.J.Ortega: "CerteM: 
        Certification System Based on Electronic 
      Mail Service Structure"
        K.Schmeh: "A method for developing PKI models"
      J.Hughes: "The Realities of PKI Inter-Operability
IV. Tutorial
      S.Kent: "How many Certification Authorities 
        are Enough?"
16.45 J.J.Quisquater: "Attacks on SmartCards 
        and Countermeasures"
17.00 M.Kuhn: "How tamper-resistant are 
        todays SmartCards?"
18.15 L. Martini,M. Kuhn, J.J.Quisquater, Hamann: 
        "Secure SmartCards - Fact or Fiction"
19.00 Get-together with music (4 to the bar)
        and CQRE - Speakers corner - rump session
----------------------------------------------------------------
Part II - Technical Aspects:
Thursday, December 2, 1999
----------------------------------------------------------------
09.00 R.Baumgart : Good morning 
09.15 P.Landrock: Mobile Commerce
10.15 Four parallel tracks:
I. Mobile Security
      M.Borchering: "Mobile Security - an
        Overview of GSM, SAT and WAP"
      S.Pütz, R.Schmitz, B.Tiez: "Secure Transport of
        Authentication Data in Third Generation Mobile
        Phone Networks"
II. Cryptography
      J.P. Seifert, N.Howgrave: "Extending Wiener`s 
        attack in the Presence of many decrypting
        exponents"
      S.Micali, L.Reyzin: "Improving The Exact 
        Security of Fiat-Shamir Signature Schemes"

III. Network Security
      C.Yuen-yan: "On Privacy Issues of Internet 
        Access Services via Proxy Servers"
      Jorge Davila, Javier Lopez and Rene Peralta: 
        "VPN solutions in diverse layers of the 
         TCP/IP stack"
      B.Schneier, Mudge, D.Wagner: "Cryptanalysis of
        Microsofts PPTP Authentification Extensions
       (MS-CHAPv2)"
IV. Tutorial
      I.Winkler: "How to fight the inner enemy"
12.00 J.S. Coron: "On the security of RSA padding"
12.45 Lunch
14.15 Four parallel tracks:
I. PKI
      A.Young, M.Yung: "Auto-Recoverable 
       Auto-Certifiable Cryptosystems (a survey)"
II. Intrusion Detection
      D.Bulatovic, D.Velasevic: "A Distributed Intrusion 
       Detection System based on Bayesian Alarm
       Networks"
III. Espionage
      M.Fink: "Espionage - State of the Art and 
        Countermeasures"
      W.Haas: "Informational Self Defense"
IV.  Tutorial
      A.Philip: "Secure E-business"
15.00 S.Kent: "Security for Certification Authorities 
        - A system approach"
16.00 Four parallel tracks: 
I. Interoperability
      S.Gupta, J.Mulvenna, S.Ganta, L.Keys, D.Walters: 
        "Interopreability Characteristics of S/MIME
         Products"
      M.Rubia, J.C.Cruellas, M.Medina: "The DEDICA 
         Project: The Solution to the Interoperability 
         Problems between the X.509 and EDIFACT Public 
         Key Infrastructures"
II. Biometrics 
      H.Arendt: "Biometrics - State of the Art"
      A.P.Gonzales-Marcos, C.Sanchez-Avila,
        R.Sanchez-Reillo: "Multiresolution Analysis and
        Geometric Measure for Biometric Identification"
III. Signature Laws 
      Workshop - Leader, K.Keus: "German Signature Act -
        Expiriences made for Europe?"
IV. Tutorial
      J.Massey: "Cryptography at a glance"
17.45 S.Baker, R.Schlechter, T.Peters, T.Barassi:
      "Panel: Perspectives for a global signature law"
18.30 R.Baumgart: Closing Remarks

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Diffie-Hellman Proof-of-Possession Algorithms to Proposed Standard
Reply-to: [email-masked]
Date: Wed, 13 Oct 1999 08:32:41 -0400
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider Diffie-Hellman Proof-of-Possession
Algorithms <draft-ietf-pkix-dhpop-02.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by October 27, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-02.txt

From: "Andrew Probert" <[email-masked]>
To: <[email-masked]>, "Russ Housley" <[email-masked]>
Subject: Re: End-Entity Certificate Policies
Date: Wed, 13 Oct 1999 21:02:31 +1000

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01BF15BE.4401C740
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

CAs would never use the *same* policy OID as they surely they would be
issuing policies prefixed by their own unique company's / CAs OID!

That's why cross-certification and policy-mapping was invented.

I think the process breaks down if you take the shared policy OID approach.

Regards.

----- Original Message -----
From: Russ Housley <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 10, 1999 4:00 AM
Subject: RE: End-Entity Certificate Policies

> I want to send a quick message to summarize the impact that this thread
has
> had on my thinking.  This thoughts have not been coordinated with the
other
> RFC 2459 authors.
>
> First, I have been convinced that there are times when it is appropriate
to
> include more than one certificate policy OID in an end
> entity-certificate.  However, it is clear to me that some policies should
> not be combined in one certificate.  I guess that there are many errors
> that a CA could make, and that this is just one more.  Can anyone suggest
a
> subjective rule for the types of policies that might appear in one
> end-entity certificate?  If not, how about a subjective rule for the types
> of policies that should not appear in one end-entity certificate?
>
> Second, I remain concerned about the use of qualifier with certificate
> policies in CA certificates.
>
> The certificate policy qualifiers do not impact the certificate path
> validation algorithm.  Rather, the certificate policy qualifiers are
> provided as an output of the algorithm to the certificate user (a.k.a.
> relying party) to help determine whether or not the end-entity certificate
> is appropriate for the task at hand.
>
> While the X.509 path validation algorithm does not prohibit an
> implementation from returning information that tells which certificate
> provided particular qualifiers, the algorithm does not require that this
> information be provided.  Therefore, we must assume that this information
> is not available to the certificate user.
>
> I still think that it is important that the set of certificate policy
> qualifiers not include contradictions.
>
> I belive that it is possible that two CAs can support the same certificate
> policy using different CPSs.  Thus, certificates issued by the two CAs
> would have the same certificate policy OID, but they would include
> different values for the CPS pointer qualifier.  If a path includes
> certificates from both of these CAs, the output of the certificate path
> validation algorithm would include the common certificate policy OID and
> two different CPS pointer qualifiers.
>
> Since the certificate validation algorithm does not use certificate policy
> qualifiers, how do certificate policy qualifiers in CA certificates help
> the certificate user?
>
> Russ
>

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

------=_NextPart_000_0012_01BF15BE.4401C740--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-laap-00.txt
Date: Wed, 13 Oct 1999 06:53:58 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Limited AttributeCertificate Acquisition Protocol
	Author(s)	: S. Farrell, D. Chadwick
	Filename	: draft-ietf-pkix-laap-00.txt
	Pages		: 11
	Date		: 12-Oct-99
	
The PKIX working group is profiling the use of X.509 attribute
certificates. This document specifies a deliberately limited
protocol for requesting an attribute certificate from a server. It
is intended to be complementary to the use of LDAP for AC retrieval,
covering those cases where use of an LDAP server is not suitable due
to the type of authorization model being employed. For many other
cases, the use of LDAP is preferred.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-laap-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-laap-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-laap-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-laap-00.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 13 Oct 1999 12:24:36 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "Manger, James" <[email-masked]>
CC: [email-masked]
Subject: Re: Timestamp: 03: TSP version 3

James,

It has been long since you posted these comments. :-( Since I am now
in the process of revising the document and publish a new version
before the dead line, here are my answers:

> > Comments on version 3 of the timestamp draft:
> >
> > 2.2
> > Highlights from the 1st sentence: ".. requesting .. requests .. request
> > ..Req ..".  :-)

Any better proposal ? :-) 

> > 2.4.1
> > Please use integer 1 for version 1 - it avoids confusion.
> >       version INTEGER {v1(1)},

OK. 

> > 4) ..TSA offers no guarantee about the strength of the hash functions..
> > But the paragraph after the MessageImprint definition still says 'It is up
> > to the TSA to decide whether or not the given has algorithm is
> > "sufficient"'.  

Ooops ! I forgot to delete that one. Good catch.

> > Rename the 'messageImprint' field as 'opaque' to make it
> > obvious that the TSA is making no claim about the value, other than its
> > existence, even though it is signing it.
> >       opaque  [2] MessageImprint,
> > Why is it optional?

I do not think renaming it is necessary. Since the field is now
mandatory, I will change SHOULD by SHALL in the text.

> > 2.4.2
> > Why repeat selected definitions from CMS (SignedData etc.)?  You still
> > have to read CMS because not all definitions are repeated (e.g.
> > CMSVersion).  Don't bother repeating any - it just opens the possibility
> > of incompatibility or confusion.

It helps the reading anyway.

> > Time is the whole reason for the timestamp.  Call the field 'time', not
> > 'genTime'; put it at the top of the token (after the version) and don't
> > bury it in a TSTTime construct (make 'accuracy' the 3rd field in TSTInfo).
> > Now the major items are directly visible in the definition of the major
> > type.

I will change the ordering to place all mandatory fields first
followed by optional fields and will suppress the TSTTime construct
as you suggest.

> > Don't restrict the 'seconds' accuracy field to 1..59.  This is an
> > unnecessary & arbitrary limit.  My clock may only be synchronized to UTC
> > to +/-2 minutes (I may wish to use a very conservative estimate).  You
> > don't, of course, need a new 'minutes' choice in the Accuracy type, just
> > allow values like 120 seconds.

OK.

> > Show the syntax as: YYYYMMDDhhmmss[.s...]Z
> > This implies all the DER-encoding rules it can (keep the sentence about
> > omitting trailing 0's in the fractional second component & the decimal
> > point if the fractional seconds is 0).
> > The syntax in the current draft does not show the full options of the
> > GeneralizedTime syntax (e.g. does not show decimal comma option), nor does
> > it imply all the DER-encoding restrictions (e.g. terminate with Z).
> >
> > 3.2
> > time-to-check-back
> > Surely a relative time would be far more appropriate here, i.e. number of
> > seconds from now until you should poll again.

This is part of an issue that I am currently discussing with the
co-editors.

> > 3.4
> > How about an easier HTTP request:
> >
> > http://aaa.bbb.com/cgi-bin/timestamp?alg=sha1&hash=A9993E364706816ABA3E257
> > 17850C26C9CD0D89D

 ... but this would mean that we are no more transport independent.
:-(

> >
> > 6.
> > CMS has been published as RFC 2630.

OK.

> > A.
> > Providing a syntax to hold a timestamp & its associated data is a good
> > idea, but there is no need for this to have extra security - the timestamp
> > is already signed & contains a hash of the data!

I personally agree.

> > Given that a major identified use of timestamps is to timestamp a digital
> > signature it is likely that a CMS SignedData structure is already being
> > used.  A sensible place to store a timestamp is in this existing structure
> > - as an unauthenticatedAttribute.
> >
> > A timestamp could apply to the content being signed (e.g. PDF doc), the
> > signature on the content or the signature plus the certificates & CRLs.

This is an interesting proposal. In order to keep things simple I
would propose to limit the case to the signature itself only.
Including certificates and CRLs does not always make sense since the
certificates and CRLs that MAY be present in a CMS structure do not
necessarilly reflect a valid certification path. As advertised on
this mailing list, an ETSI draft document on a foramt of an
*electronic* signature is adding two unsigned attributes which may
contain a certification path and revocation information for that
path and it makes sense to time stamp all that information together.
However this would mean defining additional unsigned attributes
which are clearly out of the scope of this document. Hence the
reason to support only one of your proposals. 

> > Perhaps three attributes are required:
> >       timestampedContent      ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> > id-at-??? 1 }
> >               -- msgImprint is the same value as the MessageDigest
> > auth.att. value
> >       timestampedSignature    ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> > id-at-??? 2 }
> >               -- msgImprint is the hash of the encryptedDigest field
> > (DER-encoded)
> >       timestampedCertSig      ATTRIBUTE ::= { WITH SYNTAX ContentInfo  ID
> > id-at-??? 2 }
> >               -- msgImprint is the hash of the concatenation of the
> > certificates, crls &
> >               -- encryptedDigest fields (all DER-encoded)
> >
> > Alternatively, or in addition, define how the data can be stored in the
> > timestamp itself.
> >       "Data can be stored with its associated timestamp as the contents of
> > an octet string held as the value of a attribute of type 'data' in the
> > unauthenticatedAttributes field of the timestamp."

Before I read your proposal I had never thought things this way !
This is quite original and would be a way to keep things together. I
see it as an alternative to the method described in the appendix A.
I would however like to hear some other opinions from the list on
that topic. 

> >
> > x.
> > The I-D ACTION e-mail had an extra sentence at the end of the Annex,
> > compared to the actual draft.
> >       "..(TDA) .. proves in addition that a datum existed before a
> > particular unpredictable event."
> > This should say "after", not "before".

This is now gone.

Thanks for your very valuable comments.

Denis

Date: Wed, 13 Oct 1999 10:54:20 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Phillip M Hallam-Baker <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, xme <[email-masked]>
Subject: Re: FW: OCSP-X  Internet Draft: Extensions to OCSP

Phill,

When SCVP was originally proposed, I voiced a number of 
questions and objections. I guess its time to repeat them, 
since I don't believe they were addressed at the time. 
Now that OCSP-X has entered the picture, I also have 
a few new ones to do with authorization.

>From my reading of the situation, the only potential 
benefits of these protocols are:

	- to allow centralisation of PKI policy 
          enforcement, and,
	- to remove certificate path discovery from 
	  the client.

(NB: I said "discovery", a.k.a. path constuction, 
*not* path validation, about which I remain to
be convinced, but see later.)

1) For centralisation of policy, I'd assert that the 
PKIX WG is *not* the place where this should be considered.
We simply don't have sufficient input on the range
of applications which give rise to requirements to
do a good job. 

For example, the policy and AAA WGs are both examining
many of these issues, in broader contexts, and with
more familiarity with the actual issues which arise. 
I do believe that some of these WGs outputs will show
up a need for PKIX to tackle some issues, but we're
not yet at that point. To be concrete, I've been
doing some work on authorization in the AAA WG, and
there are many environments in which the authorization
approach proposed with OCSP-X just won't work!
(E.g. mobileip or remote access when there are brokers
involved. There'll be an updated authorization
requirements draft from the AAA WG in the next few days
which should clarify the point.) It may be that we
can make some progress on centralising PKI policies,
but if the clients still have to get their other
equally important policy some other way, then I'm 
not sure we're helping them very much.

2) Certificate path discovery, OTOH, is an issue which
PKIX should and can address. Personally, I'm open as
to whether this uses a new protocol, an OCSP extension
or a CMP or CMC extension, or all whether we provide
all of the above options.

2) One of the major difficulties with SCVP and OCSP-X that
I do see is with the whole idea of a server deciding 
which paths are trustworthy.I think the onus is on 
those proposing this functionality to answer, in 
detail:

	What are the *concrete* applications or protocols
	which need this functionality today?
	For each application:
		- how will SCVP/OCSP-X work?
		- what RFCs will need to be changed?
		- what deployed base will need to be
		changed or extended?
		- how will the switch from client 
		processing to server processing
		occur?
		- what *specific* benefit does SCVP/OCSP-X
		offer?

I'd be happier with all of this if someone could
convincingly show how an an S/MIME, IPSec, or TLS 
implementation would be improved. They need so
much other ASN.1 & crypto code that the savings
are very unclear.

So, in conclusion I think PKIX should:

- progress with server-side path construction
- think hard about policy and authorization, after
  taking a look at what other WGs need and 
  what they're doing
- provide a real justification for server-side
  path validation with concrete examples as 
  requested above.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Date: Wed, 13 Oct 1999 12:05:11 +0800
From: "Xiong Shao Jun" <[email-masked]>
Organization: China Merchants Bank
To: [email-masked]
Subject: questions on rfc2587

Hi, there. I'm currently working on a PKIX project, and I have some
questions about
LDAP v2 schema.
1) If a user have more than one certificates from one or more CA, how to
represent
    it in a pkiUser object class?
2) If a subject has a NULL DN, how to represent it?

Best regards,
Xiong Shaojun
China Merchants Bank

From: "Kingdon, Kevin" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: OCSP-X  Internet Draft: Extensions to OCSP
Date: Tue, 12 Oct 1999 16:50:17 -0700

A few comments and questions about the OCSP-X draft (mostly about the
ASN.1):

Why use EXPLICIT context tagging for the SingleExtendedStatus CHOICE?
Wouldn't IMPLICIT tagging produce a more efficient encoding without
increased complexity for "hand-written" encoders?

What are the semantics implied by the SEQUENCE OF SEQUENCE { OBJECT
IDENTIFIER } definition of Rules? What purpose is served by wrapping the
Rule oid in a sequence?

I believe the Evaluate type would be better defined as a BIT STRING of named
bits. The current structure should at least define the SEQUENCE elements as
OPTIONAL.

The AuthorizationMode type would also be better defined as a BIT STRING of
named bits. If defined as a SEQUENCE, the elements should be OPTIONAL and
use IMPLICIT tagging.

The AuthorizationStatus type is not completely defined. I believe it should
be a CHOICE of IMPLICIT-ly tagged NULLs.

It would help me to understand how OCSP-X fits into OCSP if some example
PDUs were included. I would suggest using the ASN.1 value notation for these
examples.

Kevin W. Kingdon
RSA Security, Inc.

		-----Original Message-----
		From:	Phillip M Hallam-Baker [mailto:[email-masked]]
		Sent:	Tuesday, October 12, 1999 11:34 AM
		To:	[email-masked]'
		Subject:	FW: OCSP-X  Internet Draft: Extensions to
OCSP

		 << File: Certificate Extensions to OCSP III.txt >> All,

			Attached is an Internet Draft written by myself,
based on comments
		by Mike Myers, recent proposals to the list by Ambarish
Malpani, conference
		submissions from Barbara Fox & Brian LaMachia, and comments
thereto on the
		list (for a fuller list please see the draft, if anyone
thinks they have
		been
		forgotten please email me).

			At the time OCSP was first introduced it was agreed
that the protocol
		could be a vehicle to support much more than certificate
revocation status
		checking. It was also the consensus that the draft should be
extreemly
		narrowly focused in order to make progress. For this reason
extensions such
		as trust path processing, time stamping and such were tabled
for later
		discussion. It is now 'later' and time to have that
discussion.

			The draft addresses two shortcommings of SCVP.
First, as discussed in
		Oslo all the functions of SCVP may be addressed in the OCSP
syntax and
		there is no need to duplicate all the work already done on
OCSWP. Second,
		SCVP addresses only trust path processing. This only
addresses half of the
		issue that an ISV with a product to be PKI enabled must
address, if a client
		is to delegate trust processing for authentication then it
might as well
		delegate authorization as well.

			My belief that this is a natural functionality set
is confirmed by
		the appearence of several commercial products offering
precisely these
		functions.

			The approach I have taken in OCSP-X is substantially
different in
		approach however. In the first place the transfer protocol
is OCSP/HTTP
		rather than LDAP, in the second URIs are used to identify
resources.

			The reason for choosing OCSP/HTTP over LDAP is that
this is a
		machine/machine interaction in which both sides know
a-priori the exact
		reference terms to be employed. The value add of LDAP over
HTTP is a
		resource discovery protocol which in this case is unneeded.
By avoiding
		the LDAP data model the issue of schema conflicts is
avoided. I believe
		that convergence on a common specification will be
considerably easier
		using OCSP/HTTP as a technology base than attempting to
agree on a
		common directory schema.

			Additionally the protocol proposal made here is a
'thin client -
		fat server' approach rather than the 'fat client - thin
server' approach
		directories are designed to support.

			The use of URIs as names for authenticatable
resources takes some
		explanation and for this reason an appendix provides some
worked examples.
		I believe it may be prudent to separate these examples into
a second,
		non-authoritative draft at a later date to avoid the risk
that conventions
		used in the examples be assumed to be dependable parts of
the standard.

			Essentially this protocol employs URIs as names in
that it uses
		the URI to refer to a resource without actually retrieving
it. This was
		the original intention of URNs.

					Phill

		Phillip Hallam-Baker
		Principal Consultant, VeriSign Inc.
		+1 (781)245-6996 x227
		[email-masked]

Date: Tue, 12 Oct 1999 16:20:23 -0700
From: Ed Gerck <[email-masked]>
To: Phillip M Hallam-Baker <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Sentient applications, was Re: FW: OCSP-X  Internet Draft: Extensions to  OCSP

Phillip M Hallam-Baker wrote:

> All,
>
>         Attached is an Internet Draft written by myself, based on comments
> by Mike Myers, recent proposals to the list by Ambarish Malpani, conference
> submissions from Barbara Fox & Brian LaMachia, and comments thereto on the
> list (for a fuller list please see the draft, if anyone thinks they have
> been forgotten please email me).

Phill:

The draft begins:

 For an application to make an informed decision as to whether it trusts a
 digital certificate the application must have knowledge of the certificate
 itself,

where the "humanization" of applications extends to the entire text. To talk
about "informed decision", "have knowledge" and so on is not only a style
slip but IMO also a dangerous overslight inducer. For example, rephrasing the
above for applications that are not sentient would produce:

 For an application to decide whether a digital certificate is trusted, the
 application must [be programmed with a trust metric, defined here to
 include, exclusively,] trust on the certificate itself,

where one should note not only the passive role of the application as
an evaluator of trust (actually, a proxy for the end user) but also the now
clear input that must be provided to the application: the trust metric.
Which was not mentioned in  the original section and which is still not
specified simply by specifying its components (the trust points).

Besides, I encounter the words "trust management".  Of course, we are all
familiar with the words "trust", "trusted system" and "'trusted third party".

However, it is IMO unfortunate to call "trust management" what actually
is "decision management" or, at most, "authorization management".

First, because if "trust management" would exist then it would imply
managing what you do not control. So, "trust management" is  an
oxymoron and one which leads to a series of unrelated assumptions
regarding the usefullness of that "management" .

Second, because trust is not boolean -- while the RFC constructs are
entirely boolean, yes or no.

Third, the fact that people introduce soundbites like "trust management"
instead of using clear words like "authorization management", does not
mean that any relevant conclusions can be drawn from the misuse
of terms like "trust" in the soundbite.

In other words, if you can successfully "manage" something, there is
nothing left to "trust" about it. That is, "trust" is qualified reliance
upon a "value" that cannot be directly observed or controlled at the
moment a decision is to be made that would depend upon that value
-- and which does *not* depend upon you at all, so there is nothing
you can "manage" about it.  Calling it "trust management" may be
reassuring, that we have everything under control, but such is not
true otherwise there would no need to trust -- you would control it.

However, and in a positive note, since a decision is *always* boolean,
decision management is a boolean problem amenable to the RFC. Even
though the whole process of authorization is not represented in your
RFC (for example, I miss the issues of delegation), one could still also
use it for authorization management of certificate validity in a restricted
(and, not sentient) sense.

Thus, my suggestion is that the trust points as well as the trust metric
used in the RFC must be made clear, and not "humanized", so that they
can be rendered as a logical process amenable to a protocol. Perhaps,
other options for trust metric could also be made available, including
the question of transtitive trust (depth of certificate chains acceptable),
fresheness of each component, reliance of each component in a risk model
as defined by CPS, insurance policies, etc.  If this is too complex, then the
RFC should mention what it is implictly assuming.

Cheers,

Ed Gerck

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Peter Williams" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: OCSP-X  Internet Draft: Extensions to OCSP
Date: Tue, 12 Oct 1999 15:51:51 -0400
Importance: Normal

> Phil,
> 
> Was OCSP (and any variants) not intended to be transport
> independent? OCSP should be available as value-add
> on CMP-based products soon, for example.

I believe you have misunderstood me. OCSP and OCSP-X are both
transport independent. CMP would remain an appropriate transport 
layer.

What I was attempting to explain (perhaps poorly) was the 
reason for using OCSP as a base technology as opposed to LDAP
which I anticipated might be the subject of extensive 
protestations if not arguments.

The ability to run over CMP (or for that matter SMTP!) would be 
one further reason to adopt the OCSP approach.

> This would
> be inappropriate in certain quite typical military
> contexts whose infrastructure requires
> separation of these two management needs,
> and where LOCAL authorization control is a
> requirement. See SDN 801 and later MISSI work...
> as reported by Ford and others )

Quite so, the argument I was trying to make was that the 
specification having addressed one aspect of the should 
really go the whole way and address both. This is not the
same thing as saying that applications must USE the features,
just that they should be there.

The degree of authorization delgation must as you point
out be left to the specific configuration. I very much
agree on the issue of LOCAL authorization information
management as the examples in the draft discuss at length.

		Phill

From: "Peter Williams" <[email-masked]>
To: "Phillip M Hallam-Baker" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: OCSP-X  Internet Draft: Extensions to OCSP
Date: Tue, 12 Oct 1999 12:28:24 -0700
Importance: Normal

Phil,

Was OCSP (and any variants) not intended to be transport
independent? OCSP should be available as value-add
on CMP-based products soon, for example.

Why do you propose that OCSP, when extended to address
additional PKI-related semantics, have this
transport independence removed?

This web-centric change of direction seems at odds
with what is an otherwise highly articulate argument.

(Though I praise your argument, above, this does
not mean I agree with all its design
assumptions or your beliefs concerning seemingly
MANDATORY co-location of authentication and
authorization providers. This would
be inappropriate in certain quite typical military
contexts whose infrastructure requires
separation of these two management needs,
and where LOCAL authorization control is a
requirement. See SDN 801 and later MISSI work...
as reported by Ford and others )

> -----Original Message-----
> From: Phillip M Hallam-Baker [mailto:[email-masked]]
> Sent: Tuesday, October 12, 1999 11:34 AM
> To: [email-masked]'
> Subject: FW: OCSP-X Internet Draft: Extensions to OCSP
>
>
> All,
>
> 	Attached is an Internet Draft written by myself, based on comments
> by Mike Myers, recent proposals to the list by Ambarish Malpani,
> conference
> submissions from Barbara Fox & Brian LaMachia, and comments thereto on the
> list (for a fuller list please see the draft, if anyone thinks they have
> been
> forgotten please email me).
>
> 	At the time OCSP was first introduced it was agreed that
> the protocol
> could be a vehicle to support much more than certificate revocation status
> checking. It was also the consensus that the draft should be extreemly
> narrowly focused in order to make progress. For this reason
> extensions such
> as trust path processing, time stamping and such were tabled for later
> discussion. It is now 'later' and time to have that discussion.
>
> 	The draft addresses two shortcommings of SCVP. First, as
> discussed in
> Oslo all the functions of SCVP may be addressed in the OCSP syntax and
> there is no need to duplicate all the work already done on OCSWP. Second,
> SCVP addresses only trust path processing. This only addresses half of the
> issue that an ISV with a product to be PKI enabled must address,
> if a client
> is to delegate trust processing for authentication then it might as well
> delegate authorization as well.
>
> 	My belief that this is a natural functionality set is confirmed by
> the appearence of several commercial products offering precisely these
> functions.
>
> 	The approach I have taken in OCSP-X is substantially different in
> approach however. In the first place the transfer protocol is OCSP/HTTP
> rather than LDAP, in the second URIs are used to identify resources.
>
> 	The reason for choosing OCSP/HTTP over LDAP is that this is a
> machine/machine interaction in which both sides know a-priori the exact
> reference terms to be employed. The value add of LDAP over HTTP is a
> resource discovery protocol which in this case is unneeded. By avoiding
> the LDAP data model the issue of schema conflicts is avoided. I believe
> that convergence on a common specification will be considerably easier
> using OCSP/HTTP as a technology base than attempting to agree on a
> common directory schema.
>
> 	Additionally the protocol proposal made here is a 'thin client -
> fat server' approach rather than the 'fat client - thin server' approach
> directories are designed to support.
>
>
> 	The use of URIs as names for authenticatable resources takes some
> explanation and for this reason an appendix provides some worked examples.
> I believe it may be prudent to separate these examples into a second,
> non-authoritative draft at a later date to avoid the risk that conventions
> used in the examples be assumed to be dependable parts of the standard.
>
> 	Essentially this protocol employs URIs as names in that it uses
> the URI to refer to a resource without actually retrieving it. This was
> the original intention of URNs.
>
> 			Phill
>
> Phillip Hallam-Baker
> Principal Consultant, VeriSign Inc.
> +1 (781)245-6996 x227
> [email-masked]
>

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: OCSP-X  Internet Draft: Extensions to OCSP
Date: Tue, 12 Oct 1999 14:33:52 -0400
Importance: Normal

This is a multi-part message in MIME format.

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

All,

	Attached is an Internet Draft written by myself, based on comments
by Mike Myers, recent proposals to the list by Ambarish Malpani, conference
submissions from Barbara Fox & Brian LaMachia, and comments thereto on the
list (for a fuller list please see the draft, if anyone thinks they have
been
forgotten please email me).

	At the time OCSP was first introduced it was agreed that the protocol
could be a vehicle to support much more than certificate revocation status
checking. It was also the consensus that the draft should be extreemly
narrowly focused in order to make progress. For this reason extensions such
as trust path processing, time stamping and such were tabled for later
discussion. It is now 'later' and time to have that discussion.

	The draft addresses two shortcommings of SCVP. First, as discussed in
Oslo all the functions of SCVP may be addressed in the OCSP syntax and
there is no need to duplicate all the work already done on OCSWP. Second,
SCVP addresses only trust path processing. This only addresses half of the
issue that an ISV with a product to be PKI enabled must address, if a client
is to delegate trust processing for authentication then it might as well
delegate authorization as well.

	My belief that this is a natural functionality set is confirmed by
the appearence of several commercial products offering precisely these
functions.

	The approach I have taken in OCSP-X is substantially different in
approach however. In the first place the transfer protocol is OCSP/HTTP
rather than LDAP, in the second URIs are used to identify resources.

	The reason for choosing OCSP/HTTP over LDAP is that this is a
machine/machine interaction in which both sides know a-priori the exact
reference terms to be employed. The value add of LDAP over HTTP is a
resource discovery protocol which in this case is unneeded. By avoiding
the LDAP data model the issue of schema conflicts is avoided. I believe
that convergence on a common specification will be considerably easier
using OCSP/HTTP as a technology base than attempting to agree on a
common directory schema.

	Additionally the protocol proposal made here is a 'thin client -
fat server' approach rather than the 'fat client - thin server' approach
directories are designed to support.

	The use of URIs as names for authenticatable resources takes some
explanation and for this reason an appendix provides some worked examples.
I believe it may be prudent to separate these examples into a second,
non-authoritative draft at a later date to avoid the risk that conventions
used in the examples be assumed to be dependable parts of the standard.

	Essentially this protocol employs URIs as names in that it uses
the URI to refer to a resource without actually retrieving it. This was
the original intention of URNs.

			Phill

Phillip Hallam-Baker
Principal Consultant, VeriSign Inc.
+1 (781)245-6996 x227
[email-masked]

------=_NextPart_000_0052_01BF14BE.CE077440
Content-Type: text/plain;
	name="Certificate Extensions to OCSP III.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="Certificate Extensions to OCSP III.txt"

Internet Draft                                         Phillip =
Hallam-Baker
draft-ietf-pkix-ocspx-01                                      VeriSign =
Inc.
September 03, 1999
Expires in six months

OCSP Extensions=20

Status of this memo

This document is an Internet-Draft and is in full conformance with all =
pro-
visions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task=20
Force (IETF), its areas, and its working groups.  Note that other groups =

may also distribute working documents as Internet-Drafts.=20

Internet-Drafts are draft documents valid for a maximum of six months =
and=20
may be updated, replaced, or obsoleted by other documents at any time.  =
It=20
is inappropriate to use Internet-Drafts as reference material or to cite =

them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

The OCSP protocol [RFC2560] enables online validation of the reliability =
of=20
a digital certificate. RFC2560  defines a mandatory-to-implement =
mechanism=20
supporting the revocation status of the certificate and defines and op-
tional extension mechanism to support a richer set of semantics (e.g. =
full=20
path validation by the OCSP server).

This document defines Internet-standard  extensions to OCSP that enable =
a =20
client to delegate processing of certificate acceptance functions to a=20
trusted server. The client may control the degree to which delegation =
takes=20
place. In addition limited support is provided for delegating =
authorization=20
decisions.

1	Introduction

For an application to make an informed decision as to whether it trusts =
a=20
digital certificate the application must have knowledge of the =
certificate=20
itself, a set of trusted public keys from which certificate chains may =
be=20
constructed, a set of intermediate certificate authorities from which =
the=20
trust chain may be constructed and the validation status of every =
certifi-
cate used to construct the trust chain.=20

In a typical PKI deployment these data frequently originate from =
multiple=20
sources. Certificates and certificate status information will be issued =
by=20
multiple Certification Authorities. In the typical case authorization =
data=20
will be maintained separately. As the task of managing these disparate=20
sources of data required to decide upon the acceptability of digital =
cer-
tificates increases it is advantageous to delegate this task to one or =
more=20
specialist applications.

These data must then be integrated into certificate path processing =
compli-
ant to RFC 2459 [RFC2459]. In some environments, it may be useful to =
defer=20
this integration to a trusted server, thereby relieving certificate =
using=20
functions of the need to acquire this information and integrate it into=20
compliant path processing logic.  It may also be useful to defer this =
inte-
gration to a trusted server due to the server=92s ability to more easily =
com-
bine certificate path processing with other authorization data.  =
Finally, a=20
trusted-server approach to certificate validation enables =
straightforward=20
design and implementation of a trust management system capable of =
immediate=20
response to certificate or authorization revocation.

The basic OCSP protocol [RFC2560] provides a simple mechanism for =
communi-
cating certificate revocation status and an extension mechanism for =
commu-
nicating additional types of certificate validation information. The =
exten-
sibility mechanism can accommodate advanced needs for certificate =
valida-
tion beyond simple revocation status.

This document defines Internet-standard OCSP extensions to ensure=20
interoperability among diverse PKI-based trust management systems or =
net-
works.

These extensions allow a client to delegate the tasks of deciding =
whether a=20
certificate should be relied upon and whether it is acceptable for a =
par-
ticular operation.

2 	Principal Applications

Before presenting the specific requirements for the extensions proposed =
we=20
first consider some applications whose needs have motivated this =
protocol.

2.1 Embedded Systems

We anticipate a substantial increase in the use of PKI by embedded =
systems.=20
In the short term this increase will be driven by the deployment of =
IPSEC=20
capable gateways such as routers and firewalls. In the longer term, how-
ever, it is to be expected that most embedded systems will support some=20
kind of security based on PKI.

Such devices are typically subject to significant constraints in the =
proc-
essing power and persistent storage that may be allocated to PKI =
support.=20
Support for operator interaction is limited, if indeed the device has =
any=20
I/O capability at all other than the network interface. Neither =
constraint=20
is likely to be affected by progress in technology since market demand=20
tends towards low cost devices.

Moreover, embedded devices are typically expected to have an operating=20
lifetime significantly longer than application software. Suppliers are =
con-
cerned to minimize the amount of maintenance required. Offloading =
certifi-
cate related processing functionality maximizes the useful lifetime of =
an=20
installed base of such devices while trust management technology moves =
for-
ward.

2.2	Wireless Devices

We also anticipate a substantial increase in the use of PKI enabled =
wire-
less devices. These devices share many of the constraints of embedded =
sys-
tems. Processing and memory resources are highly constrained, in this =
case=20
by battery lifetime as well as cost. Nor is it practical to support a =
com-
plex user interface on a handheld device.

It is possible for wireless devices to communicate directly with each=20
other. In a typical application however the wireless device communicates =

with a static base station which in turn is connected to a network. It =
is=20
highly desirable to offload processing tasks from the mobile unit to the =

base station.

2.3	Centralized Trust and Authorization Management

As previously discussed, determination of the acceptability of a =
certifi-
cate for a particular operation requires a substantial quantity of data, =

management of which is a complex task. In a large enterprise it is =
desir-
able to centralize this task, or at least restrict the number of systems =

performing it.

In addition to eliminating the need to distribute significant quantities =
of=20
data to relying applications, centralization of certificate acceptance=20
functions improves enterprise-wide consistency in the enforcement of =
poli-
cies relating to certificate acceptance.=20

Centralized management also yields advantages in auditing and control. =
Sus-
picious behavior patterns may be more readily detected if audit =
information=20
is centralized. If a suspicious behavior pattern is detected, further =
ac-
cess may be denied, either by automatic revocation or suspension of the=20
certificate, or by withdrawing authorization.

2.4	Use of Attribute Certificates

Attribute Certificates provide a means of distributing auxiliary =
informa-
tion which, for certain reasons, it is not desirable to include within a =

public key certificate. Such information is typically used to make =
authori-
zation decisions.

Attribute Certificates present the advantages of distributing =
authorization=20
information in a non-repudiable form. However, use of attribute certifi-
cates has been widely criticized as overburdening client =
implementations,=20
particularly since effective use of authorization certificates appears =
to=20
require application specific processing rules.

Delegating certificate-based access control decision functions, =
including=20
the processing of attribute certificate chains to an OCSP-X responder =
miti-
gates these objections. Client implementations need only implement the=20
OCSP-X request and response protocol. Sites may construct conventions =
and=20
processing rules of arbitrary complexity for enforcement of =
authorization=20
attributes and still rely on standard clients, regardless of the use or=20
non-use of attribute certificates.

2.5	Single Sign-On

A principal advantage for PKI based security is the ability to support =
sin-
gle sign-on. Password based authentication has the substantial =
disadvantage=20
that the authentication process itself requires the password to be =
revealed=20
to or previously known by the authenticating party. Public key based=20
authentication does not require a secret to be revealed or known in =
order=20
for the authenticating party to know that it is known.

Although PKI provides comprehensive support for authentication, access =
con-
trol requires both authentication and authorization to take place. It is =

not enough to know who a person is, it is equally important to know what =

that person is permitted to do.

Although many protocols already exist to support distribution of =
authoriza-
tion information there is considerable advantage to supporting =
delegation=20
to a single enterprise-level authority of all aspects of the access =
control=20
decision that require external data.

3	Requirements

The following requirements have been identified as important in the =
meeting=20
of the needs of the applications described above.

3.1	Support for Aggregation of Trust Information

On the basis of the prior analysis, there exists a need to aggregate at =
a=20
trusted server all information relevant to determining the acceptability =
of=20
a digital credential in a given context.  This information includes but =
is=20
not limited to:

*  End-user Public Key Certificates
*  CA public key certificates
*  Attribute Certificates
*  Certificate Revocation Lists or certificate status databases
*  Data provided by other OCSP and OCSP-X responders

The means by which this information is obtained by an OCSP-X server is =
be-
yond the scope of this specification.

3.2	Support for Intelligent Query

The extensions SHOULD support intelligent queries, that is queries which =

are specifically relevant to the client decision to trust a certificate.

This requirement is distinct from the type of query supported by =
directory=20
servers, including LDAP servers and X.500 servers. The data model upon=20
which these servers are designed does not support the specific types of=20
query required. Nevertheless it would be highly appropriate for a single =

server to support both OCSP-X and LDAP retrievals from a common =
database.

3.3	Delegated Trust Decision

The extensions SHOULD allow a client to delegate all aspects of deciding =

the authenticity and validity of a certificate.

It is NOT a requirement that every response be justified by providing =
in-
formation such as the certificate chain generated and relevant CRLs. The =

objective of OCSP-X is to permit a client to simplify certificate =
valida-
tion decisions by offloading them to an external client. This objective =
is=20
negated if the client is then required to duplicate the trust decision.

3.4	Delegated Authorization Decision

The extensions SHOULD support the delegation of authorization decisions =
to=20
the OCSP-X responder.

It is not however a requirement for that the OCSP-X responder provide =
in-
formation to the relying application so that the relying application may =

duplicate the authorization decision.

3.5	Support for Status Update Notification Protocols

In many circumstances it is necessary for an application to track =
changes=20
in the validity of a certificate after the initial decision to trust the =

certificate has been made.

A wide variety of architectural approaches are appropriate to meet this =
re-
quirement and the specification of a specific protocol for the purpose =
is=20
outside the scope of this particular draft. It is not therefore a =
require-
ment that these extensions propose a specific notification protocol but =
use=20
of such a protocol SHOULD be supported.

Pending the development of such a protocol, clients which need to track=20
changes in certificate validity may do so by polling the OCSP-X =
responder.=20
It is therefore a requirement that the protocol support this mode of use =

efficiently.

4	Non-Requirements

Support for the following features was considered but rejected.

4.1	Delegated Key Exchange

Support for delegation of key exchange processing was considered but re-
jected as being more appropriate for independent discussion.

A client relying on an OCSP server for trust path evaluation might also=20
delegate other aspects of a cryptographic negotiation scheme such as key =

exchange.

While it is highly desirable for embedded devices such as IPSEC routers =
to=20
offload complex processing tasks to other processors support for such a=20
feature would inevitably involve strong interdependencies with the key =
ex-
change protocols to be supported. The complexity of such a protocol =
would=20
therefore be considerable and it is not clear that a sufficient degree =
of=20
generality across protocols could be achieved.

4.2	Alternate Response Syntax

Support for an alternative response syntax was considered but rejected =
as=20
being more appropriate for independent discussion.

The advantage of an alternate response syntax is that it would permit =
de-
vices with limited processing capability to receive responses encoded in =
a=20
simpler syntax than ASN.1. While construction of an ASN.1 BER encoded =
re-
quest message is not unduly burdensome on a client implementation the =
pars-
ing of OCSP responses is considered unnecessarily complex by many.

4.3	Modification of Authorization Data

Support for client requests to modify authorization data was considered =
but=20
rejected as introducing an unacceptable degree of additional complexity=20
into the protocol.

Support for such a feature would permit implementation of client =
=91owner-
ship=92 of resources whose authorization data is managed by the OCSP-X=20
server. Such support would however require a considerably more detailed=20
definition of the authorization framework than specification of the re-
sources for which authorization is requested and the mode of access re-
quested. In particular it would be necessary to commit to a data model =
for=20
the authorization data.

While support for such a feature is likely to prove necessary in time, =
the=20
substantial degree of additional complexity involved strongly suggests =
that=20
it preferable to address the issue separately.

5  OCSP Message Framework

The OCSP message format is defined in RFC 2560. This section describes =
the=20
use made of the OCSP message format within this document.

5.1	Extension Framework

The OCSP extension framework permits additional data to be incorporated =
in=20
an OCSP message such that the extension data applies to an entire =
request=20
or to specific certificate in a response. Similarly the framework =
permits=20
extensions in a response to apply to either the response as a whole or =
to a=20
specific certificate in the response.

In this document we refer to extensions which apply to a message as a =
whole=20
as =91message extensions=92. Extensions which apply only to a specific =
certifi-
cate are referred to as =91certificate specific extensions=92.  =
Extensions that=20
MAY be employed in either manner are referred to as simply =
=91extensions=92.

These terms correspond to the ASN.1 structures defined in RFC 2560 as =
fol-
lows:

Identification                    Structure           Element

Response Message                  OCSPRequest     requestExtensions
Certificate Specific Response     Request         =
singleRequestExtensions=20
Reply Message                     ResponseData    responseExtensions
Certificate Specific Reply        SingleResponse  singleExtensions=20

5.2	Status Reporting

OCSP-X defines a number of extended response codes. It is intended that=20
these augment the response codes defined by RFC2560, providing =
additional=20
status information where needed.

OCSP-X extended status codes SHALL be reported using the id-pkix-ocspx-
status extension OID in the response as defined bellow.

6	Extension Elements

All extensions are tagged using OIDs formed of the existing OCSP arc.

id-pkix-oscpx		OBJECT IDENTIFIER ::=3D { id-pkix-ocsp [TBS] }

An OCSP client MAY signal support for OCSP response extensions by =
including=20
the id-pkix-ocspx-support OID as an OCSP acceptable response type. =
Alterna-
tively, clients that include OCSP extensions in their request SHALL be =
ca-
pable of support for OCSP response extensions in the manner defined by =
this=20
specification.

id-pkix-ocspx-support	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 1 }

A server MAY advertise that it supports the OCSP-X extensions by =
including=20
the id-pkix-ocspx-support OID as a message extension in any OCSP =
response.=20
The OID id-pkix-ocspx-support MUST NOT be included as a certificate spe-
cific extension.

If a server receives no signal from the client as defined above, it MAY =
in-
clude response extensions, but MUST be capable of basic OCSP as defined =
in=20
RFC2560.

Where extended status codes are defined these are returned as response =
ex-
tensions using the id-pkix-ocspx-status OID and ExtendedStatus =
structure:

id-pkix-ocspx-support	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 2 }

ExtendedStatus :=3D=3D SEQUENCE OF SingleExtendedStatus

SingleExtendedStatus :=3D=3D CHOICE {
    TRUST_NOT_SUPPORTED          [1] 	EXPLICIT NULL
    ROOT_NOT_ACCEPTABLE          [2] 	EXPLICIT NULL
    TRUST_ROOT_REQUIRED          [3] 	EXPLICIT NULL
    RULE_NOT_SUPPORTED           [4] 	EXPLICIT NULL
    TRUST_PATH_NOT_FOUND         [5] 	EXPLICIT NULL
    TRUST_PATH_VALIDATED         [6] 	EXPLICIT NULL
    CERTIFICATE_NOT_TRUSTED      [7] 	EXPLICIT NULL
    REGISTRATION_NOT_SUPPORTED   [8]	EXPLICIT NULL
    AUTHORIZATION_NOT_SUPPORTED  [9]	EXPLICIT NULL
    }

6.1	Specify Trust Root

The specify trust root extension is used to specify the trust root(s) =
for a=20
trust delegation request.

If the trust root is not specified in the request the selection of trust =

roots is delegated to the OCSP status server.

Request

id-pkix-ocspx-root	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 3 }

TrustRoot ::=3D SEQUENCE {
        certificates SEQUENCE OF CertID }

By including a specific trust root, client indicate a need to determine =
if=20
the certificate identified in the request is trusted by the server under =

the authority of the identified root.  An affirmative response from the=20
server confirms that the server has, among other functions, =
cryptographi-
cally proven by trust path logic that the signature on the subject =
certifi-
cate is valid under the indicated root.  The means by which the server =
ac-
quires the information necessary to arrive at this conclusion is beyond =
the=20
scope of this specification.  One means could be by prior acquisition of =

the appropriate cross-certificate.

Response

If the server is unable to develop a trust chain from the subject =
certifi-
cate to the indicated trust root, an error code is returned.

TRUST_NOT_SUPPORTED  Trust Root Processing is not supported
ROOT_NOT_ACCEPTABLE  The specified trust root is not known to the =
server-=20
TRUST_ROOT_REQUIRED  Explicit specification of the trust root is =
required    =20
                     to permit trust delegation.

6.2	Specify Processing Rules

In certain circumstances a client may require the OCSP server to apply a =

particular set of certificate path processing rules

Request

The client may specify the processing rules under which the trust chain =
is=20
to be constructed. If no trust rules are specified the responder SHOULD =
em-
ploy the processing rules specified by RFC2459.

id-pkix-ocspx-rules	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 4 }

Rules ::=3D SEQUENCE {
        rules 	SEQUENCE OF Rule }

Rule ::=3D SEQUENCE {
        oid		OBJECT IDENTIFIER}

Response

If the server is unable to support all of the path processing rules =
speci-
fied it MUST return an error.

RULE_NOT_SUPPORTED  The requested processing rules are not supported by =
the
                    server.

6.3	Evaluate Trust Path

The client requests that the OCSP-X responder attempt to construct a =
valid=20
trust path originating from a trust root. Optionally the client may =
request=20
that the responder return part or all of the data used to construct and=20
validate the certificate chain.

Request

id-pkix-ocspx-evaluate	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 5 }

Evaluate ::=3D SEQUENCE {
        reportTrustChain            [1] IMPLICIT NULL
        reportValidation            [2] IMPLICIT NULL
        returnTrustChain            [3] IMPLICIT NULL
        returnValidation           [4] IMPLICIT NULL }

Response

CERTIFICATE_NOT_TRUSTED          The certificate is not trusted
=20
TRUST_PATH_VALIDATED             The certificate is trusted
=20
TRUST_PATH_NOT_FOUND             The trust status of the certificate =
could
                                 not be determined.

6.4	Register Trust Path

A client may employ the register trust path extension to notify the =
server=20
that the validity of a trust path will be of ongoing significance to the =

client during a specified time interval A client MAY optionally request =
no-
tification if a certificate reported to the client as being valid is re-
voked during the specified time interval.

The specific actions to be taken if a trust path be invalidated while a=20
client is relying upon it are a matter for site specific policy. =20

OCSP-X responders MAY support the use of an OCSP response as a =
notification=20
mechanism. In this case the notifyUri member is present and specifies by =

means of a URI both the transfer protocol (e.g. HTTP) and the address to =

which the notification is to be sent.

The use of OCSP-X messages over HTTP as a notification protocol is =
vulner-
able to a denial of service attack however. An extension mechanism is =
sup-
ported to allow improved notification mechanisms to be specified in =
future=20
documents.

Request

id-pkix-ocspx-register	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 6 }

Register ::=3D SEQUENCE {
      until                     [0] EXPLICIT GeneralizedTime OPTIONAL
      notifyUri                 [1] EXPLICIT OCTET STRING OPTIONAL
      notificationExtensions    [2] EXPLICIT Extensions OPTIONAL}

Response

REGISTRATION_NOT_SUPPORTED        Registration is not supported

NOTIFICATION_NOT_SUPPORTED        Notification is not supported

6.5	Authorization Delegation

The basic OCSP response provides only authentication information. In =
many=20
applications it is desirable to supply both authentication and =
authoriza-
tion from a centralized source.

A request for authorization delegation must specify both the party which =

requests access and the resource for which access is requested. In =
addition=20
a request for authorization MAY present a chain of attribute =
certificates=20
containing information relevant to the authorization decision.

Resources are identified using URIs according to a convention chosen by =
the=20
client, the definition of which is outside this document. URIs provide a =

uniform syntax for identification of resources in a hierarchical =
fashion.

A request for authorization delegation need specify only the URI of the =
re-
source for which access is being requested and the specific mode of =
access=20
requested.

Four modes of access control are supported, GET, PUT, EXECUTE and LINK. =
The=20
GET and PUT and EXECUTE modes correspond respectively to the traditional =

Read and Write and EXECUTE modes supported by conventional operating =
sys-
tems. The LINK mode corresponds to a superset of the CONTROL mode of a =
con-
ventional operating system and when granted permits the recipient to =
spec-
ify and meta-information related to the resource, including =
authorization=20
information.

Where finer grained access control is required than is supported by =
these=20
four modes implementations may specify access control at an arbitrary=20
granularity by using an extended URI convention.

Each authorization request specifies one or more URIs that identify re-
sources for which authorization is requested. The convention by which =
URIs=20
refer to resources is discussed further in Appendix A. Specification of=20
this convention is outside the scope of this document.

The responder SHALL either return the extended response code=20
AUTHORIZATION_NOT_SUPPORTED or return an AuthorizationResponse =
certificate=20
specific extension.

The AuthorizationResponse SHALL consist of a number (possibly zero) of =
Re-
sourceResponse structures. Each ResourceResponse structure SHALL =
describe=20
the authorization status of the entity identified by the respective cer-
tificate with respect to the range of resources identified by the =
specified=20
URI.

The range of resources identified by the URIs in the authorization =
response=20
MAY be more specific, less specific or equally specific as the range =
speci-
fied in the request.

In cases where the party for whom authorization is requested has =
authoriza-
tion to access a broad range of resources and the client requests access =
to=20
a specific resource within that range the responder MAY specify the =
broader=20
range in its response. This permits the client to cache the =
authorization=20
response, eliminating the need for repeated authorization requests for=20
closely related resources.

In cases where the party for whom authorization is requested has =
authoriza-
tion to access a specific range of resources the and client requests =
access=20
to a broad range of resources which encompasses it the responder MAY =
spec-
ify the more specific range in its response. This permits the client to=20
provide navigation menus tailored to the specific set of resources to =
which=20
the party is permitted access.

Request

The request specifies a list of one or more resources for which =
authoriza-
tion is requested.

id-pkix-ocspx-authorize	OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 7 }

AuthorizationRequest ::=3D {
      requests    SEQUENCE OF ResourceData
      certs       [0] EXPLICIT SEQUENCE OF Certificate
      }

ResourceData {
      uri         Uri
      mode        AuthorizationMode}

AuthorizationMode	::=3D SEQUENCE {
      get         [1] NULL
      put         [2] NULL
      execute     [3] NULL
      link        [4] NULL }

Uri   ::=3D OCTET STRING

Response

The id-pkix-ocspx-authorize-response certificate specific response =
exten-
sion specifies a sequence of one or more ResourceResponse structures =
each=20
of which reports the authorization status of the party identified in the =

respective certificate with respect to a range of resources.

The following authorization statuses may be reported:

permit      Access to the specified resource is permitted

deny        Access to the specified resource is denied

unknown     The responder does not know the authorization status of the
            resource.

refused     The responder refuses to disclose the authorization status
            of the resource.

id-pkix-ocspx-authorize-response
                       OBJECT IDENTIFIER ::=3D { id-pkix-ocspx 8 }

AuthorizationResponse ::=3D SEQUENCE OF ResourceResponse

ResourceResponse :=3D=3D SEQUENCE {
      resource    ResourceData
      status      AuthorizationStatus }

AuthorizationStatus :=3D=3D CHOICE {
      permit      [1] EXPLICIT
      deny        [2] EXPLICIT=20
      unknown     [3] EXPLICIT
      refused     [4] EXPLICIT}

AUTHORIZATION_NOT_SUPPORTED	The OCSP-X responder does not support the=20
authorization extensions.

7	Security Issues

7.1	Security of the OCSP-X Responder

Compromise of an OCSP-X responder would severely impact the security of =
any=20
application relying upon it.

Centralized management of information required for trust path processing =

could potentially introduce the possibility of a denial of service =
attack.=20
The scope for denial of service attacks does not appear to be =
substantially=20
increased in the typical enterprise implementation scenarios however.

In the case where applications delegate any or all of the trust decision =

process itself to the OCSP-X responder, compromise of the OCSP-X =
responder=20
constitutes compromise of the application itself for all practical pur-
poses.

Both risks may if necessary be mitigated by means of deployment of =
multiple=20
OCSP-X servers configured in such a manner that the decisions made by =
each=20
server are audited by one or more other servers.

7.2	Audit

An OCSP-X server may be employed to enforce system audit requirements. =
In=20
such a configuration the use of wildcard responses in authorization re-
sponses must be carefully considered if the audit trail is to be suffi-
ciently detailed.

7.3 Notification Protocol Subject to Denial of Service Attack

The simple notification protocol described is vulnerable to a denial of=20
service attack. Nevertheless the protocol described has value in =
applica-
tions where either the possibility of a denial of service attack is not=20
present or where such an attack is prevented by a separate protocol, =
defi-
nition of which is outside the scope of this draft.

8	Collected Syntax

[To be specified]

9.  References

[RFC2560]  X.509 Internet Public Key Infrastructure Online Certificate
           Status Protocol, M. Myers, R. Ankney, A. Malpani, S. =
Galperin,
           C. Adams, RFC 2560, March 1999

10	Acknowledgements

The author would like to acknowledge the extensive contribution made to=20
this draft at an early stage by Michael Myers and Warwick Ford. In =
addition=20
some of the ideas presented were previously presented by Ambarish =
Malpani=20
and Paul Hoffman in their August 1999 Internet draft Simple Certificate=20
Validation Protocol (SCVP). This draft builds upon this earlier work and =
on=20
comments made on both documents and to the IETF mailing list by many =
people=20
including Carlisle Adams, Barbara Fox, Todd Glassey, Mack Hicks, Bob =
Juene-
man, Steve Kent, Dennis Pinkas, Brian LaMachia, Alan Lloyd, Rich Saltz, =
Pe-
ter Williams and Michael Zolotarev.

11	Author=92s Address

Dr Phillip M. Hallam-Baker
VeriSign Inc.
301 Edgewater Place
Wakefield
MA 01880
[email-masked]

Appendix A Authorization Example

	For either authorization or authentication to be performed in a uni-
form manner across a network it is of course essential that the relevant =

parties agree on a uniform namespace for 'who' and 'what'.

	The case of 'who' is already dealt with by X.509v3 / PKIX. The case=20
of 'what' is more complex since most of the resources to be identified =
are=20
local. Some form of abstract namespace is required. It is essential that =

the central database(s) in which authorization data is maintained and =
the=20
parties relying upon those databases have a common agreement as to whats =

what.

Example:

	Widgets 'R Us (wideget.test) has two departments, manufacturing and=20
sales. Both departments separately manage ERP systems which are =
primarily=20
for their own use but a limited number of personnel need access to both.

	The sales ERP system is maintained on a collection of servers called:
=20
	erp1.sales.widget.test
	erp2.sales.widget.test

	The ERP system supports three basic access levels, Salesman, Manager=20
and Administrator. These access levels are mapped onto URIs as follows:

	Salesperson		URN:sales-widget.test/erp/salesperson
	Manager		URN:sales-widget.test/erp/manager
	Administrator	URN:sales-widget.test/erp/administrator

	Note that the sysops have decided to hide the fact that the ERP sys-
tem is maintained on two separate systems since they want both to use =
iden-
tical=20

	In this particular case the delegation of authorization functions to=20
the central system is only partial. The ERP system accepts external =
input=20
that informs it of the seniority/access role of the individual concerned =
-=20
the type of information that would generally be handled by a corporate=20
admin and is usefully shared between applications.

	The ERP system is also tracking the ownership status of resources=20
created by its users. When a salesman creates a particular customer ac-
count, that salesman has 'ownership' of that resource and may well have=20
privileged access to it.

	What the central authorization system is doing is offloading the need=20
to create new user accounts in the ERP system as salespeople join and=20
leave. A typical interaction therefore is:

1. Alice is hired as a salesperson.
	1: She is issued a digital certificate	'alice'
	2: An authorization record is created of the form
		PERMIT alice URN:sales-widget-test/erp/salesperson

2. Alice accesses the ERP system for the first time
	1: There is no account for alice
	2: An OCSP-X request is made to see if alice is authorized
		[access URN:sales-widget-test/erp/salesperson/menu]
	   The responder reports Alice is authorized to do anything under
		URN:sales-widget-test/erp/salesperson
	3: The ERP application notes that alice is authorized to be
	a salesperson and creates an account for her.

3. Alice accesses the ERP system for the second (or nth) time
	1: The ERP system notes there is an account for alice
	2: An OCSP-X request is made to see if alice is still
		authorized [access URN:sales-widget-test/erp/salesperson]
	3: alice is still authorized - good!

4. Alice is promoted to manager
	1: Her entry in the OCSP-X server is modified to reflect her
		new status.

5. Alice is suspended after refusing to use the CSR system to report
	that the CSR system is down and not accepting reports.
	1: Her authorizations for operations are withdrawn at the=20
		OCSP-X system. Her certificate is neither revoked, nor
		suspended however since she still is Alice and she still
		needs access to her 401K plan (she is going to need it=20
		soon!)

6. Alice is fired
	1: Her certificate is revoked
	2: The OCSP-X server is informed

	3: OPTIONAL, if the notification process has been used the
	OCSP-X server could notify the certificate management system
	of any applications currently relying on the certificate for
	authorization]

7. Alice attempts to access the ERP system
	1: The ERP system notes there is an account for alice
	2: An OCSP-X request is made to see if alice is still
		authorized [access URN:sales-widget-test/erp/salesperson]
	3: alice is not authenticated - and refused access

There is a variant of this scenario which is worth mention. In this =
variant=20
it is important that Alice be only presented with menu items for which =
she=20
is permitted access. The relying application must therefore know her =
per-
missions without actually instigating an operation itself.

Requirement: Support some sort of generic query interface.

This may be supported by permitting a responder to reply with the least=20
specific mode of access permitted when an over-general request is made.

In this scenario the OCSP-X responder would generate its initial startup =

screen by requesting whether Alice had permission to access URN:sales-
widget-test/erp/ The responder would then reply that she only had =
permis-
sion to access URN:sales-widget-test/erp/salesperson

Example 2: Manufacturing server

The needs of manufacturing are slightly different. In this case there =
are=20
many applications which need to share authorization data between them. =
For=20
example, the machine shop contains a press and a lathe, each controlled =
by=20
a computer. Jobs are passed from the press to the lathe. Authorization =
data=20
attaches principally to the job and not to the specific machinery.

Bob is authorized to use the lathe, the press and the fleam. Carol is=20
authorized to use the lathe and the press

Bob owns jobs 1, 2, 5 and 6
Carol owns jobs 3, 4 and 7

The two sets of authorization data are tracked separately by
two separate OCSP-X servers. Access to the machinery is controlled by =
the=20
accreditation group who run exams in the use of the machinery. Ownership =
of=20
jobs is tracked by the job track and dispatch ERP system

Bob's authorizations are therefore:

URN:credit-widgets-test/machines/lathe
URN:credit-widgets-test/machines/press
URN:credit-widgets-test/machines/fleam

URN:shop-widgets-test/jobs/1
URN:shop-widgets-test/jobs/2
URN:shop-widgets-test/jobs/5
URN:shop-widgets-test/jobs/6

Conclusion:

Clearly configuration of such a system leaves much to the implementers =
who=20
must decide issues such as namespace conventions.

The objective is to permit application vendors to ship products in such =
a=20
manner that it is possible to readily support the decisions made by the =
en-
terprise without requiring custom code for each application - as use of =
API=20
toolkits tends to do.

The ERP applications in these examples establish the convention for the=20
lower level of the hierarchy [i.e. the suffix]. The enterprise =
establishes=20
the convention for the higher level of the hierarchy - the prefix.=20

Quite where the boundary should lie is probably best left to the enter-
prise. OCSP-X responders and applications should probably both provide a =

degree of flexibility. For example the sales ERP application could =
provide=20
no more flexibility than allowing the enterprise to specify the prefix =
and=20
a list of valid responder addresses with public keys to authenticate =
them=20
by:

OCSP-X
	Prefix =3D	URN:sales-widget-test/erp
	Server =3D	{
		url		http://ocspx1.sales.widget.test/
		priority	50
		[key info]	}
	Server	{
		url		http://ocspx2.sales.widget.test/
		priority	50
		[key info]	}

A more flexible approach however would allow each of the resources =
defined=20
to be mapped to URIs of the enterprise's choosing.

For example the enterprise may have already allocated roles for a =
particu-
lar project and it may be simplest to map these roles in the application =
as=20
opposed to the OCSP-X system.

OCSP-X
	Resources =3D	{
		salesperson		URN:sales-widget-test/erp/user
		manager		URN:sales-widget-test/erp/admin
		administrator	URN:sales-widget-test/erp/admin }
	Server =3D	{
		url		http://ocspx1.sales.widget.test/
		priority	50
		[key info]	}
	Server	{
		url		http://ocspx2.sales.widget.test/
		priority	50
		[key info]	}

------=_NextPart_000_0052_01BF14BE.CE077440--

From: [email-masked]
To: "'Phillip M Hallam-Baker'" <[email-masked]>, Carlisle Adams <[email-masked]>
Date: Tue, 12 Oct 1999 19:48:06 +0400
Subject: RE: Delta CRL Distribution Points
Reply-to: [email-masked]
CC: Trevor Freeman <[email-masked]>, "Pkix List (E-mail)"	 <[email-masked]>
Priority: normal

On 5 Oct 99, at 11:35, Carlisle Adams wrote:

> Hi Phill,
> 
> > ----------
> > From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
> > Sent: 	Thursday, September 30, 1999 11:24 AM
> > To: 	Trevor Freeman; Pkix List (E-mail)
> > Subject: 	RE: Delta CRL Distribution Points
> > 
> > As I said earlier, delta CRLs are problematic and managing them is
> > intrinsically complex. Scope CRLs offer considerably more flexibility,
> > are intrinsically simpler and in many cases address the same need.
>  
> I don't understand your comment that deltas are problematic and that
> managing them is intrinsically complex.  Perhaps it stems from your earlier
> comment:
> 
> 	I believe that the root of the complexity in this case is attempting
> to
> 	manage a situation where multiple signed documents issued at
> different
> 	times must be combined to validate a certificate. This is an
> intrinsic
> 	problem with both Delta CRLs and Paul Kocher's CRTs. If the voulme
> of
> 	updates becomes large there is a scalability problem which manifests
> 	itself as a reliability issue as opposed to a performance issue.
> 
> In practice, there are not "multiple signed documents ... that must be
> combined to validate a certificate".  There's no real combining going on.  I
> have a base cached on my local system and I want to check an incoming
> certificate.  I retrieve the latest delta.  
	
Excuse me, in this point of CRL processing I have a question:
Say, a system has only baseCRL ( retrieved with certificate CRL 
distribution point ). Okay, certificate is checked and good. But
here is some doubt - Is it possible that certificate has been revoked 
in delta-CRL? Okay, let me think... look around what I have at the
moment: CRLDP and the same IDP in CRL (say it looks like 
http://somefirm/revokedcerts.crl). How can I find any information
where I can get deltaCRL? I see only one possibility:
	default distribution point - value of attribute deltaRevocationList
      in CA entry of Directory;

What have I miss?

> Is the cert serial number on the
> base?  (Yes or No.)  If not, is it on the delta?  (Yes or No.)
> 
> Conceptually, you can think of the relying party combining the base and
> delta into a single larger CRL and checking that, but in actual code nobody
> needs to combine these things at all.  A sequential check of the two lists
> is sufficient.  Checking two lists instead of one does not seem to me to be
> inherently "problematic" or an "intrinsically complex" management task.
> 
> What have I missed?
> 
> Carlisle.
> 
> P.S., Scopes are great, and offer wonderful flexibility.  But do they really
> help with the timeliness issue (which is where deltas are particularly
> intended to be useful)?  In other words, do scopes and deltas really address
> the same need in many cases?
> 
> 

____________
Pavel Krylov

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ac509prof-01.txt
Date: Tue, 12 Oct 1999 06:57:10 -0400
Sender: [email-masked]

--NextPart

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

	Title		: An Internet Attribute Certificate Profile for         
                          Authorization
	Author(s)	: S. Farrell, R. Housley
	Filename	: draft-ietf-pkix-ac509prof-01.txt
	Pages		: 32
	Date		: 11-Oct-99
	
Authorization services are required for numerous Internet protocols,
including TLS, IPSec, and S/MIME. The X.509 Attribute Certificate
provides a structure that can form the basis for such services
[X.509]. This specification defines a profile for the use of X.509
Attribute Certificates to provide authorization services for
Internet protocols. Some optional features are also specified which
are not required for conformance to the base profile.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-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-ac509prof-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-ac509prof-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-ac509prof-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 11 Oct 1999 14:35:26 +0200
From: Raffaello Galli <[email-masked]>
Organization: C&A
To: [email-masked]
Subject: Timestamp protocol and IssuerAndSerialNumber OID

This is a cryptographically signed message in MIME format.

--------------msA41B5AFC6A262C68717B9F54
Content-Type: multipart/mixed;
 boundary="------------D572F01FB8E51BA214420FB1"

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

Hi,

Since the PKIX Time Stamp protocol (draft) requires to include
"IssuerAndSerialNumber" as an authenticated attribute in a  "SignerInfo"

sequence our question is:

Any of you know which OID is bounded to IssuerAndSerialNumber ?

Thanks for your help

Raffaello and Thomas

--------------D572F01FB8E51BA214420FB1
Content-Type: text/x-vcard; charset=us-ascii;
 name="r.galli.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Raffaello Galli
Content-Disposition: attachment;
 filename="r.galli.vcf"

begin:vcard 
n:Galli;Raffaello
tel;fax:++.39.2.24791826
tel;home:Please call me at work.
tel;work:++.39.2.24791823
x-mozilla-html:FALSE
url:www.com-and.com
org:C & A   Improve Your Security
adr:;;Viale Fulvio testi 126 ;Cinisello Balsamo   (MI);ITALY;20092;ITALY
version:2.1
email;internet:[email-masked]
title:Responsabile Tecnologie
note;quoted-printable:-------------------------  Improving Your Security  -------------------------=0D=0ACertification Authority -  X509 V3  -  RSA Strong  =0D=0AWeb Server SSL3 Strong  - Proxy SSL =0D=0ACrypto Smart Card - PKCS#11=0D=0AKey Manager -  Time Manager=0D=0ATime Stamping Authority  -  Corba (IIOP over SSL)=0D=0A-------------------------  Improving Your Security  -------------------------
x-mozilla-cpt:;-1
end:vcard

--------------D572F01FB8E51BA214420FB1--

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

--------------msA41B5AFC6A262C68717B9F54--

Date: Wed, 06 Oct 1999 17:46:00 -0700
From: "Kelly D. Lucas" <[email-masked]>
Organization: Kroll-O'Gara
To: [email-masked]
CC: Stephen Kent <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Huge CRLs

I think that ValiCert is addressing this problem, with their Global
Validation Authority Service.  It's currently in beta, and will bet
out soon.  Basically, they are acting as a consolidation point for
CA's, and Enterprises that run their own CA's, and then they are
sending this info to all subscribed.

Check out:

http://www.valicert.com/products/

and then look at the ValiCert Global VA Service.

kdl

Ed Gerck wrote:
> 
> Stephen Kent wrote:
> 
> > >Revocation is one of the most critical problems that must be addressed and
> > >tons of smart people are working on it.  Some of my team/partners/members are
> > >spending nearly all of their time trying to make revocation work the way we
> > >need it to work.   The financial services sector is providing significant
> > >input on requirements, technology, and resources to try to make PKI work for
> > >us.
> > >
> > >No offense intended, but the nature of our businesses and the limitations of
> > >the technology do not lend themselves to the use of CRLs.  The how and why
> > >will have to wait for a later message (tonight).
> >
> > Not all the world is the financial services sector.  Criticisms of CRL use
> > models based primarily on difficulties encountered in employing them in
> > that environment, or based on poor implementations, or based on poor
> > management parameter choices, etc.  do not necessarily mean that CRLs are
> > unworkable.
> 
> CRLs, which were first thought to be a positive aspect of relying on CAs
> as compared to PGP for instance, presents several unsolvable problems.
> 
> For example, there may be a considerable delay (no warranties can be
> found on on CAs contracts about upper limits for such delays) between the
> actual need to revoke a certificate and the reflection of this need in a
> certificate chain with different CAs.
> 
> Also, requiring the user to check with a CA before sending a message
> makes the use of multiple CAs much more difficult, unless they can be
> convinced to work together, an interesting problem for competing
> businesses.  Constant checking with a single CA also makes traffic
> analysis much easier. Even if the attacker cannot intercept the
> message which is sent, if the attacker can monitor the central CA
> (with a single administrative order and a GAKware system to circumvent
> any encryption), everyone's communication patterns can be seen.
> Also, an attacker can fool a CA into revoking a key -- a denial of service
> attack.
> 
> Further, the major X.509 security application today, SSL, does not
> check revocation lists -- so they are near to useless. Also, the user is
> not able to check server certificates (and certificates in the CA chains)
> against revocation lists.
> 
> An examplary case regarding  CRLs, is that they are a will to revoke but
> not an actual revocation. Few recognize that CRLS are a solution to a
> non-existent problem ... while the real problem is left utterly unsolved. The
> non-existent problem solved by CRLs is how to communicate that a
> certificate is no longer valid ... because if a certificate were really no
> longer valid (as it should be) then no one would need to find a CRL
> to know about it.
> 
> Cheers,
> 
> Ed Gerck
> ______________________________________________________________________
> Dr.rer.nat. E. Gerck                                    [email-masked]
> 
> +-------------------------------------------------------------+
> + For information about the cert-talk mailing list, including +
> + archives and how to subscribe and unsubscribe, visit:       +
> +          http://www.structuredarts.com/cert-talk            +
> +-------------------------------------------------------------+

-- 
Kelly D. Lucas            |  Kroll-O'Gara
Security Consultant       |  Information Security Group
[email-masked]          |  650-812-9400 x 117
"Any opinions that I state are my own, and not Kroll-O'Gara's"

From: "Ambarish Malpani" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: FW: DER encoding of OPTIONAL sequences with nothing
Date: Wed, 6 Oct 1999 16:31:11 -0700
Importance: Normal

This is mainly a style issue. I prefer tagging anything that is
part of a choice, so that if, in the future, somebody else adds
another thing in there, they don't screw it up by mistake.

You are absolutely right - the tag isn't required.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: Magnus Nystrom [mailto:[email-masked]]
> Sent: Monday, October 04, 1999 11:58 PM
> To: Ambarish Malpani
> Cc: [email-masked]
> Subject: Re: FW: DER encoding of OPTIONAL sequences with nothing
> 
> 
> 
> Hi Ambarish,
> 
> On Mon, 4 Oct 1999, Ambarish Malpani wrote:
> 
> [...] 
> > but do them as:
> > 
> >  Top ::= SEQUENCE {
> >      i    INTEGER,
> >      something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
> >  }
> 
> But why the [0] EXPLICIT? The tags (INTEGER, SEQUENCE) are 
> unique anyway.
> 
> -- Magnus
> Magnus Nystrom		Email: [email-masked]
> RSA Laboratories
> 

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "IETF-PKIX (E-mail)" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-dhpop-02.txt
Date: Wed, 6 Oct 1999 10:57:33 -0700 

This draft was re-released for techinical reasons.  We have updated Appendix
B so that is now uses the Q parameter on the big-number for DH and DSS.
This is to bring it into line with RFC2459.  No other changes have been
made.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 06, 1999 3:56 AM
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dhpop-02.txt

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		: Diffie-Hellman Proof-of-Possession Algorithms
	Author(s)	: H. Prafullchandra, J. Schaad
	Filename	: draft-ietf-pkix-dhpop-02.txt
	Pages		: 21
	Date		: 05-Oct-99
	
This document describes two methods for producing a signature from a
Diffie-Hellman key pair.  This behavior is needed for such
operations as creating a signature of a PKCS #10 certification
request.  These algorithms are designed to provide a proof-of-
possession rather than general purpose signing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-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-dhpop-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-dhpop-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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dhpop-02.txt
Date: Wed, 06 Oct 1999 06:55:44 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Diffie-Hellman Proof-of-Possession Algorithms
	Author(s)	: H. Prafullchandra, J. Schaad
	Filename	: draft-ietf-pkix-dhpop-02.txt
	Pages		: 21
	Date		: 05-Oct-99
	
This document describes two methods for producing a signature from a
Diffie-Hellman key pair.  This behavior is needed for such
operations as creating a signature of a PKCS #10 certification
request.  These algorithms are designed to provide a proof-of-
possession rather than general purpose signing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dhpop-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-dhpop-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-dhpop-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-dhpop-02.txt

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

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

--OtherAccess--

--NextPart--

From: "ani" <[email-masked]>
To: "Ambarish Malpani" <[email-masked]>, <[email-masked]>
Subject: Re: DER encoding of OPTIONAL sequences with nothing
Date: Wed, 6 Oct 1999 10:24:14 +0530

It is incorrect to say that this prevents 2 different DER encodings of a
*single object*. It is actually not a single object. The fact of an empty
SEQUENCE being present makes it a different object than the SEQUENCE being
absent. And DER, correctly, allows two different encodings to represent
these two data objects. It is worth noting that the the above two objects
could convey different meanings to the application looking at the encodings.

So, in general, there is nothing wrong with the first ASN.1 definition. The
ASN.1 toolset which an application developer uses should have the ability to
allow the developer to represent these two objects separately. For example,
if the toolset generates equivalent 'C' structures, the generated 'C'
structure should have a provision for specifying the empty SEQUENCE and an
absent SEQUENCE differently.

As an aside, another way of "disambiguating" the ASN.1 structure is to write
it as:

Top ::= SEQUENCE {
    i    INTEGER,
    something [0] EXPLICIT SEQUENCE OF Foo
}

Of course, as Magnus Nystrom put it, all the above arguments would hold even
if [0] EXPLICIT was not present.

Regards,

Ani

-------------------------------------------
Aniruddha P. Shrotri (ani)
VP, Software Development, E-Lock Technologies Inc.
[email-masked]
http://www.elock.com
-------------------------------------------

----- Original Message -----
From: Ambarish Malpani <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 05, 1999 12:21 AM
Subject: FW: DER encoding of OPTIONAL sequences with nothing

>
> Hi PKIX-land,
>     Just learnt something of the ASN.1 mailing list that I
> think will be of general interest.
>
> In a nutshell, try not to have definitions like:
>
>  Top ::= SEQUENCE {
>      i    INTEGER,
>      something [0] EXPLICIT SEQUENCE OF Foo OPTIONAL
>  }
>
> but do them as:
>
>  Top ::= SEQUENCE {
>      i    INTEGER,
>      something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
>  }
>
>
> This prevents you from allowing 2 different DER encodings of a
> single object.
>
> Please ignore the mail if this was obvious.
>
> Regards,
> Ambarish
>
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of Ambarish Malpani
> > Sent: Monday, October 04, 1999 10:35 AM
> > To: [email-masked]
> > Subject: RE: DER encoding of OPTIONAL sequences with nothing
> >
> >
> >
> > Hi John,
> >     Okay, that clarifies the issue.
> >
> > Next time, I will make sure I specify top as:
> >
> > Top ::= SEQUENCE {
> >     i    INTEGER,
> >     something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
> > }
> >
> > Some people do it this way and I had never figured out why.
> >
> > Thanks,
> > Ambarish
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                650.567.5457
> > ValiCert, Inc.                                  [email-masked]
> > 1215 Terra Bella Ave.                         http://www.valicert.com
> > Mountain View, CA 94043-1833
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On Behalf Of John Larmouth
> > > Sent: Saturday, October 02, 1999 3:20 AM
> > > To: [email-masked]
> > > Subject: Re: DER encoding of OPTIONAL sequences with nothing
> > >
> > >
> > > I am afraid we need to discuss angels on pin-heads here!
> > The issue is
> > > the set of abstract values in Top.  DER guarantees a unique
> > > encoding for
> > > each separate abstract value,  but equally an application can put
> > > different semantics on different abstract values,  so all abstract
> > > values in the type have to have different endcodings.
> > >
> > > In the case of an OPTIONAL element (or whatever type),  ASN.1
> > > takes the
> > > view that a SEQUENCE value with an OPTIONAL element present is a
> > > different abstract value (carries different semantics) from
> > > one where it
> > > is absent.
> > >
> > > This is quite clearly correct in the general case.  It just looks a
> > > little funny in the case that you quote!
> > >
> > > So the principle is that a value of Top with something missing is a
> > > distinct abstract value (and may carry different semantics)
> > > from a value
> > > with something present as an empty sequence of.  DER
> > therefore allows
> > > (has to allow) different encodings for the two cases.
> > >
> > > John L
> > >
> > >
> > > Ambarish Malpani wrote:
> > > >
> > > > Hi Guys,
> > > >     A question was raised in the IETF PKIX working group that
> > > > would benefit from some input from this group.
> > > >
> > > > If I define
> > > >
> > > > Top ::= SEQUENCE {
> > > >     i    INTEGER,
> > > >     something [0] EXPLICIT SEQUENCE OF Foo OPTIONAL
> > > > }
> > > >
> > > > And I am trying to do a DER encoding of a top, where the
> > > > something contains no Foo's, is the right encoding to not put any
> > > > bytes, or to encode it as a tag 0, length 2, and sequence
> > > > of length 0?
> > > >
> > > > Is this a bug in the DER encoding rules (which promise a unique
> > > > encoding), or is the correct encoding specified in the rules?
> > > >
> > > > Regards,
> > > > Ambarish
> > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > Ambarish Malpani
> > > > Architect
> > > 650.567.5457
> > > > ValiCert, Inc.
> > > [email-masked]
> > > > 1215 Terra Bella Ave.
> > http://www.valicert.com
> > > Mountain View, CA 94043-1833
> >
> > --
> > ==============================================================
> > ==========
> >                           Prof John Larmouth
> >    1 Blueberry Road,  Bowdon,  Altrincham,  Cheshire WA14
> > 3LS,  England.
> >      j.larmouth @ salford.ac.uk              Tel: +44 161 928 1605
> >         Fax (work): +44 161 745 8169  Tel (work): +44 161 295 5657
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - - -
> >
> >

Date: Tue, 05 Oct 1999 16:38:58 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Nationality / country of citizenship attribute question

I could translate it for you, but then I'd have to shoot you. :-)

>>> Peter Gutmann <[email-masked]> 10/06/99 10:48AM >>>
[email-masked] writes:

>MIIj6QYJKoZIhvcNAQcCoIIj2jCCI9YCAQExCzAJBgUrDgMCGgUAMIIXiAYJKoZIhvcNAQcBoIIX
>eQSCF3VGcm9tOiBCSlVFTkVNQU5Abm92ZWxsLmNvbQ0KU3ViamVjdDogUmFN0RdhdGlvbmFsaXR5
>IC8gY291bnRyeSBvZiBjaXRpemVuc2hpcCBhdHRyaWJ1dGUgcXVlc3Rpb24NClRvOiAic2FtaWts
>b0BtaXNzaS5uY3NjLm1pbCIsIGlldGYtcGtpeEBpbDRinKCoCAcOlA50ZW50LVR5cGU6IG11bHRp
>cGFydC9taXhlZDsgYm91bmRhcnk9Il9fX19GVldIWlpLQ0VCTFlUQ0FFRkZBWV9

JvdXQgaXQsIHlvJlIGFyZSByZWFsbHkgdHdvIHF1ZXN0a.  ZSB0b28gbWFueSBleGNlcHRpb25zI
GNhdXNlIG - BhIGhvc3BpdGFsLCBiZSBhIG.  YXBhY2l0eT8iDQoNClRoZSBFbnRlcnByaXNlIE
lEIGlzIHV?

>LS1fX19fRlZXSFpaS0NFQkxZVENBRUZGQVlfX19fDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47
>IGNoFNOrDXQ9aXNvLTg4NTktMQ0KQ29udGVudC1UcmFuc2Zlci1FnoRdZGluZzogcXVvdGVkLXBy
>aW50YWJsZQ0KDQpTYW5keSwNCg0KUmVnYXJkaW5nIHRoZSBlbXBsb3ltZW50IHN0YXR1cyBhbmQg
>c2ltaWxhciBpc3N1ZXMgcmVsYXRlZCB0byAicmlnaH

BwYXRoIG9mID0NCmRlcGVuZGl!!!

>b2YgdGhlIEVudGVycHJpc2UgSUQgYXMgdXNlZCBpbiB0aGUgTm92ZWxsIFNlY3VyaXR5ID0NCkF0
>dHJpYnV

RzIiwgPQ0KY2hlY2sgb3V0IHRoZSB1c2Ug.  wZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJ
pYnV0, 0ZXMgKGh0dHA6Ly9kZXZlbG9.

>ZXMvY2VydGF0dHJzX3YxMD0NCi5odG0pLiA9MjANCg0KVGhlcmUgYXJlIGxvdHMgb2YgcG9zc2li
>bGUgYWIloVewINDowS4gcmVsYXRpb25zaGlwcyB0aGF0IG1pZ2h0IGV2ZW50dWFsbHkgPQ0KaGF2
>ZSB0byBiZSBleHByZXNzZWQuICBFbXBsb3ltZW50IGl

YmNvbnRyYWN0b3Igd29ya2luZ, zIG1lcmVseSBvbmUgb2YgdGhlbS4gIHNv, N1cml0eSBndWFyZ
CwgY2FmZXRlcmlhIHdvcmtlciwgdHJhdmVsIGFnZW5je.  gdGhlID0NClVuaXRlZCBTdGF0ZXMuI
CBXaGVu.

iB5b3UgdG,
Peter.

Date: Tue, 05 Oct 1999 15:51:36 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Bob Jueneman" <[email-masked]>
Subject: Re: Nationality / country of citizenship attribute question

I inadvertently clicked on the "sign" button, and compounded the 
problem because my default was set for base64 encoding.

Here is the message unencumbered, for those who are 
S/MIME challenged.

Bob

>>> <[email-masked]> 10/05/99 03:12PM >>>
Sandy,

Regarding the employment status and similar issues related to "rights", 
check out the use of the Enterprise ID as used in the Novell Security Attributes (http://developer.novell.com/repository/attributes/certattrs_v10.htm).  

There are lots of possible affiliation relationships that might eventually 
have to be expressed.  Employment is merely one of them.  Someone 
might be a visiting professor, have staff privileges at a hospital, be a 
contract or contingent worker, a subcontractor working on the 
premises (such as a security guard, cafeteria worker, travel agency employee).

So there are really two questions that have to be answered:  
(1) "Affiliated with whom?" and (2) "in what capacity?"

The Enterprise ID is unique to the given Enterprise, which 
answers the question "related to whom".

(If you think about it, you really don't want to go down the 
path of depending on the uniquely encoded name of the 
organization to represent the Enterprise -- there are too many 
exceptions cause by holding companies, Doing Business As 
and Trading As names, etc.  And that's just here in the 
United States.  When I was with GTE, for example, their 
corporate organization chart filled an 8-1/2x11 page with
blocks so small you could scarcely read the labels.  Because 
of state PUC requirements against cross-subsidization between 
states, every telephone company in every state was a 
separate corporation.)

(In  reality, most of the telco employees worked for say 
"GTE of Pennsylvania".  A relatively small number worked 
for the GTE Corporate staff, which had a "Group" (really an 
OU) called "GTE Telephone Operations".  Yet almost 
everyone who worked for the telephone side of the 
business had a business card that identified them as
 been "employed(?)" by "GTE Telephone Operations"
Is that sufficiently confusing? )

(The point is that the legal NAME of some organizations 
may be subject to legal and intellectual property constraints 
that aren't particularly meaningful or useful in answering 
other kinds of questions.  And I haven't even brought up the 
issue of multinational companies that have different legal 
names depending on what country they are operating in, or 
even dual or multiple names, as in Canada, Belgium, or 
(worst case) India, with 14 official languages and who 
knows how many dialects.)

The other bits in the Enterprise label, either at the 
Registry level or the Enterprise level, can answer 
the question of capacity, in the form of secrecy and 
integrity (read and write) levels and categories.]

If you stop to think about it, citizenship is merely another t
ype of affiliation.  It's really a pretty blunt instrument -- 
the real question is one of loyalty and national interest, 
not citizenship. But there is no reason in principle why 
the same type of encoding scheme could not be used.  
The Enterprise that one is affiliated with is a country, and 
the affiliation could take multiple forms -- citizen, permanent 
resident, student or work visa, temporary visitor, etc.

Bob

>>> "Miklos, Sue A." <[email-masked]> 10/01/99 12:51PM >>>

All, 
I have a requirement for an attribute to represent nationality (country of citizenship) with two constraining factors.  First, it must be multi-valued, as many nations permit dual-citizenship and second, it must be extensible to use the ISO-3166-1 trigraphs.  
Several multinational security policies expressly state that the Release To fields contain, in alphabetical order, a trigraph indication of those countries to which the information may be released.
I have looked at the nationality attribute in ACP 133 as well as the countryOfCitizenship attribute in the Qualified Certificates. They are both single valued and constrained to digraph usage only.
I would ask assistance in either modifying the existing attributes, or, creating (yet another) new one.  
Additionally, I have a requirement for an attribute that can represent the employment status of a given individual.  While initially thinking that a bit map would work, I quickly realized that although that would support access control processing more easily, it is not extensible.  I would like to propose a new attribute type that is (short sighted?) single valued and a Directory string, that indicates the status of one's employment.  For example, it woould contain a corporate name or country government affiliation.
Sandi Miklos 

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Nationality / country of citizenship attribute question
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 6 Oct 1999 10:48:41 (NZDT)

[email-masked] writes:

>MIIj6QYJKoZIhvcNAQcCoIIj2jCCI9YCAQExCzAJBgUrDgMCGgUAMIIXiAYJKoZIhvcNAQcBoIIX
>eQSCF3VGcm9tOiBCSlVFTkVNQU5Abm92ZWxsLmNvbQ0KU3ViamVjdDogUmFN0RdhdGlvbmFsaXR5
>IC8gY291bnRyeSBvZiBjaXRpemVuc2hpcCBhdHRyaWJ1dGUgcXVlc3Rpb24NClRvOiAic2FtaWts
>b0BtaXNzaS5uY3NjLm1pbCIsIGlldGYtcGtpeEBpbDRinKCoCAcOlA50ZW50LVR5cGU6IG11bHRp
>cGFydC9taXhlZDsgYm91bmRhcnk9Il9fX19GVldIWlpLQ0VCTFlUQ0FFRkZBWV9

JvdXQgaXQsIHlvJlIGFyZSByZWFsbHkgdHdvIHF1ZXN0a.  ZSB0b28gbWFueSBleGNlcHRpb25zI
GNhdXNlIG - BhIGhvc3BpdGFsLCBiZSBhIG.  YXBhY2l0eT8iDQoNClRoZSBFbnRlcnByaXNlIE
lEIGlzIHV?

>LS1fX19fRlZXSFpaS0NFQkxZVENBRUZGQVlfX19fDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47
>IGNoFNOrDXQ9aXNvLTg4NTktMQ0KQ29udGVudC1UcmFuc2Zlci1FnoRdZGluZzogcXVvdGVkLXBy
>aW50YWJsZQ0KDQpTYW5keSwNCg0KUmVnYXJkaW5nIHRoZSBlbXBsb3ltZW50IHN0YXR1cyBhbmQg
>c2ltaWxhciBpc3N1ZXMgcmVsYXRlZCB0byAicmlnaH

BwYXRoIG9mID0NCmRlcGVuZGl!!!

>b2YgdGhlIEVudGVycHJpc2UgSUQgYXMgdXNlZCBpbiB0aGUgTm92ZWxsIFNlY3VyaXR5ID0NCkF0
>dHJpYnV

RzIiwgPQ0KY2hlY2sgb3V0IHRoZSB1c2Ug.  wZXIubm92ZWxsLmNvbS9yZXBvc2l0b3J5L2F0dHJ
pYnV0, 0ZXMgKGh0dHA6Ly9kZXZlbG9.

>ZXMvY2VydGF0dHJzX3YxMD0NCi5odG0pLiA9MjANCg0KVGhlcmUgYXJlIGxvdHMgb2YgcG9zc2li
>bGUgYWIloVewINDowS4gcmVsYXRpb25zaGlwcyB0aGF0IG1pZ2h0IGV2ZW50dWFsbHkgPQ0KaGF2
>ZSB0byBiZSBleHByZXNzZWQuICBFbXBsb3ltZW50IGl

YmNvbnRyYWN0b3Igd29ya2luZ, zIG1lcmVseSBvbmUgb2YgdGhlbS4gIHNv, N1cml0eSBndWFyZ
CwgY2FmZXRlcmlhIHdvcmtlciwgdHJhdmVsIGFnZW5je.  gdGhlID0NClVuaXRlZCBTdGF0ZXMuI
CBXaGVu.

iB5b3UgdG,
Peter.

From: [email-masked]
Date: Tue, 5 Oct 1999 15:12:00 -0600
Subject: Re: Nationality / country of citizenship attribute question
To: "[email-masked]", [email-masked]

From: Carlisle Adams <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>
Cc: Trevor Freeman <[email-masked]>, "Pkix List (E-mail)" <[email-masked]>
Subject: RE: Delta CRL Distribution Points
Date: Tue, 5 Oct 1999 11:35:01 -0400 

Hi Phill,

> ----------
> From: 	Phillip M Hallam-Baker[SMTP:[email-masked]]
> Sent: 	Thursday, September 30, 1999 11:24 AM
> To: 	Trevor Freeman; Pkix List (E-mail)
> Subject: 	RE: Delta CRL Distribution Points
> 
> As I said earlier, delta CRLs are problematic and managing them is
> intrinsically complex. Scope CRLs offer considerably more flexibility,
> are intrinsically simpler and in many cases address the same need.
 
I don't understand your comment that deltas are problematic and that
managing them is intrinsically complex.  Perhaps it stems from your earlier
comment:

	I believe that the root of the complexity in this case is attempting
to
	manage a situation where multiple signed documents issued at
different
	times must be combined to validate a certificate. This is an
intrinsic
	problem with both Delta CRLs and Paul Kocher's CRTs. If the voulme
of
	updates becomes large there is a scalability problem which manifests
	itself as a reliability issue as opposed to a performance issue.

In practice, there are not "multiple signed documents ... that must be
combined to validate a certificate".  There's no real combining going on.  I
have a base cached on my local system and I want to check an incoming
certificate.  I retrieve the latest delta.  Is the cert serial number on the
base?  (Yes or No.)  If not, is it on the delta?  (Yes or No.)

Conceptually, you can think of the relying party combining the base and
delta into a single larger CRL and checking that, but in actual code nobody
needs to combine these things at all.  A sequential check of the two lists
is sufficient.  Checking two lists instead of one does not seem to me to be
inherently "problematic" or an "intrinsically complex" management task.

What have I missed?

Carlisle.

P.S., Scopes are great, and offer wonderful flexibility.  But do they really
help with the timeliness issue (which is where deltas are particularly
intended to be useful)?  In other words, do scopes and deltas really address
the same need in many cases?

Date: Tue, 5 Oct 1999 08:57:42 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[email-masked]>
Reply-To: [email-masked]
To: Ambarish Malpani <[email-masked]>
cc: [email-masked]
Subject: Re: FW: DER encoding of OPTIONAL sequences with nothing

Hi Ambarish,

On Mon, 4 Oct 1999, Ambarish Malpani wrote:

[...] 
> but do them as:
> 
>  Top ::= SEQUENCE {
>      i    INTEGER,
>      something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
>  }

But why the [0] EXPLICIT? The tags (INTEGER, SEQUENCE) are unique anyway.

-- Magnus
Magnus Nystrom		Email: [email-masked]
RSA Laboratories

Date: Mon, 04 Oct 1999 13:13:45 -0400
To: Robert Moskowitz <[email-masked]>, "David P. Kemp" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: ASN.1 question on 2459
Cc: [email-masked]

Bob:

The use of SIZE (1..MAX) says that zero items are not allowed, just one or 
more.  Thus, when zero is a possibility, OPTIONAL means that the item 
should be absent if there are zero items.

By using these two together, there is only one legal way to represent zero 
items.  Our intent was to reduce complexity by not admitting multiple ways 
to include zero items.

Dave:

The use of NULL parameters with several algorithms has to do with the way 
that they were registered.  When the 1988 syntax for AlgorithmIdentifier 
was translated to the 1997 syntax, the OPTIONAL associated with the 
parameters got lost.  Later, via a defect report, it was recovered.  So, 
many people thought that algorithm parameters were mandatory.  If algorithm 
parameters were mandatory and there was nothing useful to include, NULL is 
a reasonable selection.

Russ

At 09:24 AM 9/30/99 -0400, Robert Moskowitz wrote:
>At 05:10 PM 9/29/1999 -0400, Robert Moskowitz wrote:
> >What is the difference between the following two structures:
> >
> >::= SEQUENCE SIZE (1..MAX) OF
> >
> >::= SET OF
> >
>Thank you all of you that answered.
>
>In 2459, SET seems to be used only in Name things.  SEQUENCE SIZE is used
>most of the time, and it always starts with 1..
>
>But some of them are 'optional':
>
>         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>                                 PolicyQualifierInfo OPTIONAL }
>
>
>Again this is a bit confusing to the casual reader.  The only LOGICAL
>interpretation is a SEQUENCE of SIZE 0 is different in the cert than not
>present and this is desireable.  OK.
>
>Some of this stuff is wicked.
>
>
>Robert Moskowitz
>ICSA
>Security Interest EMail: [email-masked]

From: "Ambarish Malpani" <[email-masked]>
To: <[email-masked]>
Subject: FW: DER encoding of OPTIONAL sequences with nothing
Date: Mon, 4 Oct 1999 11:51:17 -0700
Importance: Normal

Hi PKIX-land,
    Just learnt something of the ASN.1 mailing list that I
think will be of general interest.

In a nutshell, try not to have definitions like:

 Top ::= SEQUENCE {
     i    INTEGER,
     something [0] EXPLICIT SEQUENCE OF Foo OPTIONAL
 }

but do them as:

 Top ::= SEQUENCE {
     i    INTEGER,
     something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
 }

This prevents you from allowing 2 different DER encodings of a
single object.

Please ignore the mail if this was obvious.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043-1833

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ambarish Malpani
> Sent: Monday, October 04, 1999 10:35 AM
> To: [email-masked]
> Subject: RE: DER encoding of OPTIONAL sequences with nothing
> 
> 
> 
> Hi John,
>     Okay, that clarifies the issue.
> 
> Next time, I will make sure I specify top as:
> 
> Top ::= SEQUENCE {
>     i    INTEGER,
>     something [0] EXPLICIT SEQUENCE SIZE (1..MAX) OF Foo OPTIONAL
> }
> 
> Some people do it this way and I had never figured out why.
> 
> Thanks,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [email-masked]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043-1833
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of John Larmouth
> > Sent: Saturday, October 02, 1999 3:20 AM
> > To: [email-masked]
> > Subject: Re: DER encoding of OPTIONAL sequences with nothing
> > 
> > 
> > I am afraid we need to discuss angels on pin-heads here!  
> The issue is
> > the set of abstract values in Top.  DER guarantees a unique 
> > encoding for
> > each separate abstract value,  but equally an application can put
> > different semantics on different abstract values,  so all abstract
> > values in the type have to have different endcodings.
> > 
> > In the case of an OPTIONAL element (or whatever type),  ASN.1 
> > takes the
> > view that a SEQUENCE value with an OPTIONAL element present is a
> > different abstract value (carries different semantics) from 
> > one where it
> > is absent.
> > 
> > This is quite clearly correct in the general case.  It just looks a
> > little funny in the case that you quote!
> > 
> > So the principle is that a value of Top with something missing is a
> > distinct abstract value (and may carry different semantics) 
> > from a value
> > with something present as an empty sequence of.  DER 
> therefore allows
> > (has to allow) different encodings for the two cases.
> > 
> > John L
> > 
> > 
> > Ambarish Malpani wrote:
> > > 
> > > Hi Guys,
> > >     A question was raised in the IETF PKIX working group that
> > > would benefit from some input from this group.
> > > 
> > > If I define
> > > 
> > > Top ::= SEQUENCE {
> > >     i    INTEGER,
> > >     something [0] EXPLICIT SEQUENCE OF Foo OPTIONAL
> > > }
> > > 
> > > And I am trying to do a DER encoding of a top, where the
> > > something contains no Foo's, is the right encoding to not put any
> > > bytes, or to encode it as a tag 0, length 2, and sequence
> > > of length 0?
> > > 
> > > Is this a bug in the DER encoding rules (which promise a unique
> > > encoding), or is the correct encoding specified in the rules?
> > > 
> > > Regards,
> > > Ambarish
> > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > Ambarish Malpani
> > > Architect                                                
> > 650.567.5457
> > > ValiCert, Inc.                                  
> > [email-masked]
> > > 1215 Terra Bella Ave.                         
> http://www.valicert.com
> > Mountain View, CA 94043-1833
> 
> -- 
> ==============================================================
> ==========
>                           Prof John Larmouth
>    1 Blueberry Road,  Bowdon,  Altrincham,  Cheshire WA14 
> 3LS,  England.
>      j.larmouth @ salford.ac.uk              Tel: +44 161 928 1605
>         Fax (work): +44 161 745 8169  Tel (work): +44 161 295 5657
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
> - - - - -
> 
> 

Date: Mon, 04 Oct 1999 14:45:34 -0400
To: [email-masked]
From: Robert Moskowitz <[email-masked]>
Subject: Requested change for 2459
Cc: Tim Polk <[email-masked]>

Change to validityDate Choice rule:

Background:

in 

4.1.2.4  Issuer

We set a 'flag date' of 1/1/2004:

   The DirectoryString type is defined as a choice of PrintableString,
   TeletexString, BMPString, UTF8String, and UniversalString.  The
   UTF8String encoding is the preferred encoding, and all certificates
   issued after December 31, 2003 MUST use the UTF8String encoding of
   DirectoryString (except as noted below).  Until that date, conforming
   CAs MUST choose from the following options when creating a
   distinguished name, including their own:

Then in

4.1.2.5  Validity

we set a very indeterminant date with:

   CAs conforming to this profile MUST always encode certificate
   validity dates through the year 2049 as UTCTime; certificate validity
   dates in 2050 or later MUST be encoded as GeneralizedTime.

So sometime around 2040 or earlier, long-live root certs will start
appearing using GeneralizedTime, long after most of us are out of this
business.  I propose the following change to 4.1.2.5:

   CAs conforming to this profile MUST always encode certificate
   validity dates using GeneralizedTime for all certificates
   issued after December 31, 2003.  Y2K proccessing of UTCTime will
   assume century 19 if UTCTime is greater than 49 and century 20 if
   UTCTime is less than 50.

This gives PKIX one clear flag date for both UTF8String and GeneralizedTime
support.

It also makes sure that all of the programmers and product managers are
still around to answer to any failures....

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

To: Peter Lewis <[email-masked]>
cc: ietf-pkix <[email-masked]>, [email-masked]
Subject: Re: From Firewall to IPSec VPNs
Date: Mon, 04 Oct 1999 14:51:13 +0100
From: Peter KIRSTEIN <[email-masked]>

In message <[email-masked]>you write:
>This is a multi-part message in MIME format.
>
>------=_NextPart_000_0060_01BF0E7B.D3AD9D00
>Content-Type: text/plain;
>	charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>Security services and protection mechanisms
>IPv6 promises regarding IPSec
>Certification infrastructure
>Standardization update
>Case Studies: ISPs, carriers, private networks
>AH and ESP protocols description
>Possible future extensions and modifications of the IKE protocol
>Complementarity between IPSec and firewalls
>Global Site-to-Site IPSec VPN's with End-to-End SLA's
>Managing widespread IPSEC virtual private networks
>Solving IPSec VPNs scalability
>Results of some interoperability tests
>IPSec architectures and non-standardized aspects of IPSec
>Adding IPSec VPN functions in an existing router network
>Impact of fragmentation on the performance of IPSec coding
>
>IPSEC 99 Conference
>From Firewall to IPSec VPNs
>
>October 26, 27, 28, 29, 1999
>Paris - France
>
>More infos: www.upperside.fr/baipsec.htm
>
Do you have a student rate? I am considering sending a graduate
student, but there is no relevant rate shown.

Peter Kirstein
X*********************************************************************X
* Prof Peter Kirstein		   Telephone:  +44 171 380 7286	
* Department of Computer Science   Fax:        +44 171 387 1397
* University College London        Telex:      28722
* Gower Street                     Internet:   [email-masked]
* London 
* WC1E 6BT                      
* U.K			URL    : http://www.cs.ucl.ac.uk/staff/kirstein
X*********************************************************************X

From: "Peter Lewis" <[email-masked]>
To: <[email-masked]>
Subject: From Firewall to IPSec VPNs
Date: Mon, 4 Oct 1999 15:19:18 +0200
Organization: Upperside

This is a multi-part message in MIME format.

------=_NextPart_000_0060_01BF0E7B.D3AD9D00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Security services and protection mechanisms
IPv6 promises regarding IPSec
Certification infrastructure
Standardization update
Case Studies: ISPs, carriers, private networks
AH and ESP protocols description
Possible future extensions and modifications of the IKE protocol
Complementarity between IPSec and firewalls
Global Site-to-Site IPSec VPN's with End-to-End SLA's
Managing widespread IPSEC virtual private networks
Solving IPSec VPNs scalability
Results of some interoperability tests
IPSec architectures and non-standardized aspects of IPSec
Adding IPSec VPN functions in an existing router network
Impact of fragmentation on the performance of IPSec coding

IPSEC 99 Conference
>From Firewall to IPSec VPNs

October 26, 27, 28, 29, 1999
Paris - France

More infos: www.upperside.fr/baipsec.htm

------=_NextPart_000_0060_01BF0E7B.D3AD9D00
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 size=3D2>
<DIV><FONT size=3D2>
<DIV>Security services and protection mechanisms<BR>IPv6 promises =
regarding=20
IPSec<BR>Certification infrastructure<BR>Standardization update<BR>Case =
Studies:=20
ISPs, carriers, private networks<BR>AH and ESP protocols =
description<BR>Possible=20
future extensions and modifications of the IKE =
protocol<BR>Complementarity=20
between IPSec and firewalls<BR>Global Site-to-Site IPSec VPN's with =
End-to-End=20
SLA's<BR>Managing widespread IPSEC virtual private networks<BR>Solving =
IPSec=20
VPNs scalability<BR>Results of some interoperability tests<BR>IPSec=20
architectures and non-standardized aspects of IPSec<BR>Adding IPSec VPN=20
functions in an existing router network<BR>Impact of fragmentation on =
the=20
performance of IPSec coding<BR><BR>IPSEC 99 Conference<BR>From Firewall =
to IPSec=20
VPNs<BR><BR>October 26, 27, 28, 29, 1999<BR>Paris - France<BR><BR>More =
infos: <A=20
href=3D"http://www.upperside.fr/baipsec.htm">www.upperside.fr/baipsec.htm=
</A></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0060_01BF0E7B.D3AD9D00--

From: "nKrypt-IT Ltd." <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Tony Selmes" <[email-masked]>, "Bigbadbob" <[email-masked]>
Subject: Registartion Authority Functionality
Date: Sun, 3 Oct 1999 07:48:13 +0100

I am not sure this has a place here, but comments/ suggestions would be
useful.

Microsoft have recently 'requested' the abrogation of international
standards for Chat or Instant messaging.

Our product includes encrypted chat messaging and also encrypted voice over
IP and video messaging using public key protection.

One of the major problems here, is knowing the IP addresses of users
connected using a dial-up connection with dynamic IP address allocation.
Could this not be a function of the Registration Authority and, if so could
the appropriate message structures be added to those given in RFC2510 ?

The registration authority would certainly be in a position to determine the
'right' of another user to be given a specific users on-line connection
details.

As I mention above, I am not sure that this is appropriate or may well be
supported in other areas of the proposed pkix standards.

Any comments, further information, suggestions would be appreciated.

Martin Anderson,
Senior Developer
nKrypt-IT Ltd.
http://www.nKrypt-IT.co.uk

Date: Fri, 01 Oct 1999 22:30:40 +0100
From: Ben Laurie <[email-masked]>
Organization: A.L. Group plc
To: Trevor Freeman <[email-masked]>
CC: "'Phillip M Hallam-Baker'" <[email-masked]>, "Pkix List (E-mail)" <[email-masked]>
Subject: Re: Publishing Base CRL's & replicating publication mechanisms

Trevor Freeman wrote:
> 
> As a group of practical people, the futility of mandating creating something
> which has no intrinsic benefit is plain for all to see. So I hope we don't
> end up there, and I am open to any creative wordsmith input for
> alternatives.

Is that really a problem? No-one will buy something that is useless, but
you can't dictate how it should be made useful in this case, so why
worry?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

From: Trevor Freeman <[email-masked]>
To: "'David A. Cooper'" <[email-masked]>
Cc: "Pkix List (E-mail)" <[email-masked]>
Subject: RE: Publishing Base CRLs
Date: Fri, 1 Oct 1999 13:15:59 -0700 

I have looked there and CRLscope is not an extension I would want to
consider at this time due to its complexity.
Perhaps we should name these efforts Lightweight Delta CRL's

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]]
Sent: Friday, October 01, 1999 1:10 PM
To: Trevor Freeman; Pkix List (E-mail)
Subject: Re: Publishing Base CRLs

At 11:51 AM 10/1/99 -0700, Trevor Freeman wrote:
>Therefore my proposal is to remove the current mandate that a base CRL be
>published every time a delta CRL is published.
>Trevor

I would suggest looking at the X.509 FPDAM on certificate extensions
(available
at ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc
or
ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.pdf).

In particular, look at the proposed text for the CRL scope field (section
12.5.2.5) and
the delta CRL indicator field (section 12.6.3.3). Also look at section
12.6.4.

Dave

From: Trevor Freeman <[email-masked]>
To: "'Phillip M Hallam-Baker'" <[email-masked]>, "Pkix List (E-mail)" <[email-masked]>
Subject: RE: Publishing Base CRL's & replicating publication mechanisms
Date: Fri, 1 Oct 1999 13:10:50 -0700 

As a group of practical people, the futility of mandating creating something
which has no intrinsic benefit is plain for all to see. So I hope we don't
end up there, and I am open to any creative wordsmith input for
alternatives.
I don't know why this has been mandated, and it may be that this kind of
scenario was not foreseen when the stipulation was laid down. 
Multiple servers with replicating information is a proven solution for the
customer need for high availability so I don't think we can back off this
issue.

Original Message-----
From: Phillip M Hallam-Baker [mailto:[email-masked]]
Sent: Friday, October 01, 1999 12:50 PM
To: Trevor Freeman; Pkix List (E-mail)
Subject: RE: Publishing Base CRL's & replicating publication mechanisms

I believe the answer lies in your reading of the term 'published' which
as has previously been established cannot be mandated by the spec.

I believe that last time we looked at this it was decided that the spec
could mandate CREATION of a base CRL each time a delta was created but
could not mandate that it be sent anywhere! So an implementation that
'published' the CRL straight to /dev/null could be seen as 'compliant'!

This tends to support the idea that mandating a base update is not a
reasonable requirement since it cannot be enforced.

I believe that the motivation for this requirement was to allow
implementation of delta CRLs to be made optional since some consider
systems in which two CRLs (base and delta) must be obtained and
corellated to be intrinsically more complicated than systems in which
only one CRL (base) need be obtained.

		Phill

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, October 01, 1999 2:52 PM
> To: Pkix List (E-mail)
> Subject: Publishing Base CRL's & replicating publication mechanisms
>
>
> Partitioned CRL's helps the client out by reducing the size of the
> individual CRL that needs to be downloaded. It may seem an obvious
> observation, but it does nothing to help out the impact on the
> infrastructure if you have a replicating publication mechanism.
> If a CA has
> 100K revocations on its list, then the impact of publishing new revocation
> data on the infrastructure is pretty much the same if you have 1 or 1K
> CRL's. The underlying infrastructure is understandably oblivious to the
> details of the change, only to the fact that a change has been made and
> needs to be replicated.  Publishing a delta CRL without publishing a base
> CRL would address this problem. More current revocation
> information can then
> be published, while minimizing the impact on the infrastructure.
> Therefore my proposal is to remove the current mandate that a base CRL be
> published every time a delta CRL is published.
> Trevor
>

Date: Fri, 01 Oct 1999 16:10:00 -0400
To: Trevor Freeman <[email-masked]>, "Pkix List (E-mail)" <[email-masked]>
From: "David A. Cooper" <[email-masked]>
Subject: Re: Publishing Base CRLs

At 11:51 AM 10/1/99 -0700, Trevor Freeman wrote:
>Therefore my proposal is to remove the current mandate that a base CRL be
>published every time a delta CRL is published.
>Trevor

I would suggest looking at the X.509 FPDAM on certificate extensions (available
at ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc or
ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.pdf).

In particular, look at the proposed text for the CRL scope field (section 12.5.2.5) and
the delta CRL indicator field (section 12.6.3.3). Also look at section 12.6.4.

Dave

From: "Phillip M Hallam-Baker" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Pkix List (E-mail)" <[email-masked]>
Subject: RE: Publishing Base CRL's & replicating publication mechanisms
Date: Fri, 1 Oct 1999 15:49:47 -0400
Importance: Normal

I believe the answer lies in your reading of the term 'published' which
as has previously been established cannot be mandated by the spec.

I believe that last time we looked at this it was decided that the spec
could mandate CREATION of a base CRL each time a delta was created but
could not mandate that it be sent anywhere! So an implementation that
'published' the CRL straight to /dev/null could be seen as 'compliant'!

This tends to support the idea that mandating a base update is not a
reasonable requirement since it cannot be enforced.

I believe that the motivation for this requirement was to allow
implementation of delta CRLs to be made optional since some consider
systems in which two CRLs (base and delta) must be obtained and
corellated to be intrinsically more complicated than systems in which
only one CRL (base) need be obtained.

		Phill

> -----Original Message-----
> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Friday, October 01, 1999 2:52 PM
> To: Pkix List (E-mail)
> Subject: Publishing Base CRL's & replicating publication mechanisms
>
>
> Partitioned CRL's helps the client out by reducing the size of the
> individual CRL that needs to be downloaded. It may seem an obvious
> observation, but it does nothing to help out the impact on the
> infrastructure if you have a replicating publication mechanism.
> If a CA has
> 100K revocations on its list, then the impact of publishing new revocation
> data on the infrastructure is pretty much the same if you have 1 or 1K
> CRL's. The underlying infrastructure is understandably oblivious to the
> details of the change, only to the fact that a change has been made and
> needs to be replicated.  Publishing a delta CRL without publishing a base
> CRL would address this problem. More current revocation
> information can then
> be published, while minimizing the impact on the infrastructure.
> Therefore my proposal is to remove the current mandate that a base CRL be
> published every time a delta CRL is published.
> Trevor
>

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: Publishing Base CRL's & replicating publication mechanisms
Date: Fri, 1 Oct 1999 11:51:52 -0700 

Partitioned CRL's helps the client out by reducing the size of the
individual CRL that needs to be downloaded. It may seem an obvious
observation, but it does nothing to help out the impact on the
infrastructure if you have a replicating publication mechanism. If a CA has
100K revocations on its list, then the impact of publishing new revocation
data on the infrastructure is pretty much the same if you have 1 or 1K
CRL's. The underlying infrastructure is understandably oblivious to the
details of the change, only to the fact that a change has been made and
needs to be replicated.  Publishing a delta CRL without publishing a base
CRL would address this problem. More current revocation information can then
be published, while minimizing the impact on the infrastructure. 
Therefore my proposal is to remove the current mandate that a base CRL be
published every time a delta CRL is published.
Trevor

From: "Miklos, Sue A." <[email-masked]>
To: [email-masked]
Subject: Nationality / country of citizenship attribute question
Date: Fri, 1 Oct 1999 14:51:01 -0400 

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_01BF0C3D.EBCD2CF6
Content-Type: text/plain;
	charset="iso-8859-1"

All,

I have a requirement for an attribute to represent nationality (country of
citizenship) with two constraining factors.  First, it must be multi-valued,
as many nations permit dual-citizenship and second, it must be extensible to
use the ISO-3166-1 trigraphs.  

Several multinational security policies expressly state that the Release To
fields contain, in alphabetical order, a trigraph indication of those
countries to which the information may be released.

I have looked at the nationality attribute in ACP 133 as well as the
countryOfCitizenship attribute in the Qualified Certificates. They are both
single valued and constrained to digraph usage only.

I would ask assistance in either modifying the existing attributes, or,
creating (yet another) new one.  

Additionally, I have a requirement for an attribute that can represent the
employment status of a given individual.  While initially thinking that a
bit map would work, I quickly realized that although that would support
access control processing more easily, it is not extensible.  I would like
to propose a new attribute type that is (short sighted?) single valued and a
Directory string, that indicates the status of one's employment.  For
example, it woould contain a corporate name or country government
affiliation.

Sandi Miklos

------_=_NextPart_001_01BF0C3D.EBCD2CF6
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.2232.0">
<TITLE>Nationality / country of citizenship attribute question</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I have a requirement for an attribute to represent =
nationality (country of citizenship) with two constraining =
factors.&nbsp; First, it must be multi-valued, as many nations permit =
dual-citizenship and second, it must be extensible to use the =
ISO-3166-1 trigraphs.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Several multinational security policies expressly =
state that the Release To fields contain, in alphabetical order, a =
trigraph indication of those countries to which the information may be =
released.</FONT></P>

<P><FONT SIZE=3D2>I have looked at the nationality attribute in ACP 133 =
as well as the countryOfCitizenship attribute in the Qualified =
Certificates. They are both single valued and constrained to digraph =
usage only.</FONT></P>

<P><FONT SIZE=3D2>I would ask assistance in either modifying the =
existing attributes, or, creating (yet another) new one.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Additionally, I have a requirement for an attribute =
that can represent the employment status of a given individual.&nbsp; =
While initially thinking that a bit map would work, I quickly realized =
that although that would support access control processing more easily, =
it is not extensible.&nbsp; I would like to propose a new attribute =
type that is (short sighted?) single valued and a Directory string, =
that indicates the status of one's employment.&nbsp; For example, it =
woould contain a corporate name or country government =
affiliation.</FONT></P>

<P><FONT SIZE=3D2>Sandi Miklos</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BF0C3D.EBCD2CF6--

From: [email-masked]
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: ASN.1 question on 2459
Date: Fri, 1 Oct 1999 11:58:43 -0400 

I meant to add the following.

David Kemp wrote, "the only reason to encode an optional element as a NULL
would
be, as Peter says, to bulk up your certificates"

The reason to encode an optional element as a NULL is because the
specification says to do so. Below are examples of specifications that say
to do so.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 01, 1999 11:42 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: ASN.1 question on 2459

ASN.1 is unusual in that it formally defines a type for null (i.e., NULL).

In the case of AlgorithmIdentifier for an RSA signature, PKCS #1 specifies
what to do in section 11:

<quote>
These object identifiers are intended to be used in the algorithm field of a
value of type AlgorithmIdentifier. The parameters field of that type, which
has the algorithm-specific syntax ANY DEFINED BY algorithm, would have ASN.1
type NULL for these algorithms.
</quote>

RFC 2459 describes the same thing in section 7.2.1:

<quote>
When any of these three OIDs appears within the ASN.1 type
AlgorithmIdentifier, the parameters component of that type shall be the
ASN.1 type NULL.
</quote>

Most of this stuff makes sense. You just need to dig a little.

Frank Balluffi
CertCo

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Thursday, September 30, 1999 4:33 PM
To: [email-masked]; [email-masked]
Subject: RE: ASN.1 question on 2459

> From: "Salter, Thomas A" <[email-masked]>
>  > 
>  > But wait ... there are more ways to represent nothing!  Some people
>  > encode an OPTIONAL item that is not used as a BER NULL (0x05 0x00)
>  > instead of just leaving it out.  I understand that there is a
>  > legitimate semantic difference between a sequence of zero 
>  > elements and
>  > a sequence that is absent.  But as far as I know there is no semantic
>  > distinction between a NULL that is present and an element that is
>  > absent; the only reason to encode an optional element as a NULL would
>  > be, as Peter says, to bulk up your certificates.
>  > 
> 
> If they do that, then some people are wrong.  A NULL can only be used if
it
> is allowed by the ASN.1 definition.  Some people might write the ASN.1 so
> that an item is a CHOICE of some element or NULL, but otherwise you cannot
> do what you describe.

The RFC 2459 definition of Algorithm Identifier is:

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

AlgorithmIdentifier ::= SEQUENCE {
  algorithm   ALGORITHM-ID.&id({SupportedAlgorithms}),
  parameters  ALGORITHM-ID.&Type({SupportedAlgorithms}
                                 { @algorithm} ) OPTIONAL )
                                 
ALGORITHM-ID ::= CLASS {
  &id  OBJECT IDENTIFIER UNIQUE,
  &Type OPTIONAL }
  WITH SYNTAX { OID &id [PARMS &Type] }
  
SupportedAlgorithms ALGORITHM-ID ::= { ..., --extensible
  rsaMD2 |
  dsaSHA-1 |
      -- and others
}

rsaMD2    ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL }
dsaSHA-1  ALGORITHM-ID ::= { OID id-dsa-with-sha1     PARMS Dss-Parms }

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

The RFC 2459 examples show an RSA certificate with explicit NULL
parameters (example D3) and DSA certificates with absent
parameters in the two signature fields (examples D1 and D2).

The use of an explicit NULL is allowed by the ASN.1 definitions of the
RSA algorithms, but there seems to be no semantic associated with a
present NULL as opposed to an absent NULL.  The only apparent effect of
encoding three NULLs in example D3 is to increase the size of the
certificate by six octets.

From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: RE: ASN.1 question on 2459
Date: Fri, 1 Oct 1999 11:42:14 -0400 

ASN.1 is unusual in that it formally defines a type for null (i.e., NULL).

In the case of AlgorithmIdentifier for an RSA signature, PKCS #1 specifies
what to do in section 11:

<quote>
These object identifiers are intended to be used in the algorithm field of a
value of type AlgorithmIdentifier. The parameters field of that type, which
has the algorithm-specific syntax ANY DEFINED BY algorithm, would have ASN.1
type NULL for these algorithms.
</quote>

RFC 2459 describes the same thing in section 7.2.1:

<quote>
When any of these three OIDs appears within the ASN.1 type
AlgorithmIdentifier, the parameters component of that type shall be the
ASN.1 type NULL.
</quote>

Most of this stuff makes sense. You just need to dig a little.

Frank Balluffi
CertCo

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Thursday, September 30, 1999 4:33 PM
To: [email-masked]; [email-masked]
Subject: RE: ASN.1 question on 2459

> From: "Salter, Thomas A" <[email-masked]>
>  > 
>  > But wait ... there are more ways to represent nothing!  Some people
>  > encode an OPTIONAL item that is not used as a BER NULL (0x05 0x00)
>  > instead of just leaving it out.  I understand that there is a
>  > legitimate semantic difference between a sequence of zero 
>  > elements and
>  > a sequence that is absent.  But as far as I know there is no semantic
>  > distinction between a NULL that is present and an element that is
>  > absent; the only reason to encode an optional element as a NULL would
>  > be, as Peter says, to bulk up your certificates.
>  > 
> 
> If they do that, then some people are wrong.  A NULL can only be used if
it
> is allowed by the ASN.1 definition.  Some people might write the ASN.1 so
> that an item is a CHOICE of some element or NULL, but otherwise you cannot
> do what you describe.

The RFC 2459 definition of Algorithm Identifier is:

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

AlgorithmIdentifier ::= SEQUENCE {
  algorithm   ALGORITHM-ID.&id({SupportedAlgorithms}),
  parameters  ALGORITHM-ID.&Type({SupportedAlgorithms}
                                 { @algorithm} ) OPTIONAL )
                                 
ALGORITHM-ID ::= CLASS {
  &id  OBJECT IDENTIFIER UNIQUE,
  &Type OPTIONAL }
  WITH SYNTAX { OID &id [PARMS &Type] }
  
SupportedAlgorithms ALGORITHM-ID ::= { ..., --extensible
  rsaMD2 |
  dsaSHA-1 |
      -- and others
}

rsaMD2    ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL }
dsaSHA-1  ALGORITHM-ID ::= { OID id-dsa-with-sha1     PARMS Dss-Parms }

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

The RFC 2459 examples show an RSA certificate with explicit NULL
parameters (example D3) and DSA certificates with absent
parameters in the two signature fields (examples D1 and D2).

The use of an explicit NULL is allowed by the ASN.1 definitions of the
RSA algorithms, but there seems to be no semantic associated with a
present NULL as opposed to an absent NULL.  The only apparent effect of
encoding three NULLs in example D3 is to increase the size of the
certificate by six octets.

Date: Fri, 01 Oct 1999 11:14:25 +0200
From: Peter Biltzinger <[email-masked]>
Organization: TC TrustCenter for Security in Data Networks GmbH
To: [email-masked]
Subject: Re: CMP-polling

This is a cryptographically signed message in MIME format.

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

Dear Amit,

> > Couldn't it be possible to start a denial-of-service attack
> > when using the current polling mechanism without SSL? Aren't
> > the following protocols conceivable?
> >
> > a)
> >
> > 1. The RA sends a signed pkiMsg to the CA and the CA sends
> >    a unsigned pollRep to the RA.
> >
> > 2. The Attacker snoops the pollingReferenceNumber and
> >    sends the unsigned pollReq to the CA (before the RA
> >    does this) and the CA sends the signed pkiMsg or
> >    the unsigned pollRep (with new pollingReferenceNumber)
> >    to the attacker.
> >
> >    In the case of sending a new pollingReferenceNumber by the
> >    CA the RA never gets this number and cannot send a pollReq
> >    which includes this new number in order to get the
> >    certificates. The communication between RA and CA is interrupt.
> >    In the case of sending a signed pkiMsg by the CA to the
> >    attacker the CA couldn't recognize the attack until
> >    the CA administrator is missing the PKIConfirmation.
> >    In both cases manual activity would be necessary to
> >    recognize and handle this attack.
> 
>         Yes, this is possible.  But manual activity is not
>         necessary.  The CA/RA can time out on a stored request
>         for which no signed confirm has been received.
> 

In the case of sending a signed pkiMsg by the CA
to the attacker you are in principle right, but
all the difficulties regarding the account between the RA and CA
are avoidable when using signed pollReq:
(1) In the case of a snooped signed pollReq the CA would
be able to recognize the attack as replay attack and
(2) in the case of a signed pollMsg signing with a wrong certificate,
    the CA would be able to recognize this also.

In the case of sending only a new pollingReferenceNumber by
the CA to the attacker, your argument regarding the missing
signed confirmation message accesses not, because the CA
expected no such message. The RA sends  a wrong
(not current) pollingReferenceNumber to CA and gets a
error message which again avoidable (by using signed pollReq)
difficulties implies.

This attack is a too easy way to disturb a CA.

> >
> > b) Even worse, if the man in the middle intercepts a RA-pollReq,
> >    he would get the signed CA-pkiMsg and could forward a
> >    new unsigned CA-pollRep with a new pollingReferenceNumber
> >    and a new 'time-to-ckeck-back' parameter to the RA.
> >    Both parties (RA and CA) would be satisfied until the
> >    CA administrator is missing the PKIConfirmation. Again,
> >    manual activity would be necessary to recognize and handle
> >    this attack.
> 
>         Yes, but again no manual intervention is necessary.
> 

The same arguments as in point a). All difficulties
regarding the account between the RA and CA
are avoidable when using signed pollReq. This attack
is also a too easy way to disturb a CA.

> >
> > c) The attacker sends unsigned pollReq with snooped
> >    old pollingReferenceNumbers or with random numbers to
> >    the CA and the CA sends signed pkiMsg or unsigned
> >    pollRep to the attacker. In the case of a hard attack
> >    of this kind the CA can be overloaded which is equal
> >    to a denial-of-service attack. (A signed pollReq would have
> >    the advantage, that the verification of the RSA signature
> >    is very much faster than the generation of the
> >    RSA signature regarding the CA-pkiMsg to be generated
> >    and perhaps to be encrypted.)
> >    Nevertheless, in the case of signed pollReq (PKIMessages which
> >    should contain the pollingReferenceNumber) the attacker can
> >    snoop a signed RA-pollReq and send this one to the CA. But in
> >    this case, the CA can verify the recipNonce in this kind of
> >    PKIMessage and would be able to recognize a replay attack.
> >
> > Are these attacks not conceivable?
> >
> 
>         The end entity not getting the new polling reference number
>         is feasible without a attack also.  Say, I send a IR, get
>         back a poll response, send a poll request, and the poll
>         response (with a new poll reference) is lost on the
>         network.  Both sides, client and server, have to be
>         aware of this and be ready to take suitable action.
> 
>         You are completely correct in that all the above attacks
>         are feasible.  However, these are denial of service attacks
>         and if someone wants to really do that, they do not have
>         to go to such pains as snooping, trying to get in the
>         middle.  I would just send tons of signed certificate
>         requests and let the server verify them and realize it
>         does not know me, wasting lots of processor bandwidth.
>         Or even send incorrectly encoded PKIMessages or even
>         signed poll requests or create TCP connections or ...
> 

In this point you are right, there are a lot of possible
denial-of-service attacks.
But a CA have to protect itself in the best way as possible. So, why
still add
further possible denial-of-service attacks?

The loss of messages in the network is possible, but this is
a rare event and must be handled. I mean a systematically
disturbance of the communication between the RA and CA
in a way, that the CA and RA cannot do their job in a
correctly and securely way over a long period with a
very high frequency of requests AND only minimal human
interventions.

Perhaps you can tell me why all messages are optional signed (depending
on
the CA policy) except the pollRep and pollReq? And why is the assignment
of new pollingReferenceNumbers intended, if the response by the CA
regarding
a pollReq is not yet finished ( in contrast to using always the same
pollingReferenceNumber regarding a given EE/RA-request )?

regards,

            Peter

----------------------------- 
Peter Biltzinger
TC TrustCenter for Security in Data Networks GmbH
Am Werder 1, 22073 Hamburg, Germany    
http://www.trustcenter.de
mailto:[email-masked]
--------------ms827920EF4A00B5D95C669059
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

--------------ms827920EF4A00B5D95C669059--