Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

From: Carlisle Adams <[email-masked]>
Date: Mon, 16 Oct 2000 13:15:13 -0400

Hi Polar,

> ----------
> From: 	Polar Humenn[SMTP:[email-masked]]
> Sent: 	Monday, October 16, 2000 12:25 PM
> To: 	Carlisle Adams
> Cc: 	Al Arsenault; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; Stephen McConnell; Kent
> Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
> Subject: 	RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> Hi Carlisle,
> 
> On Mon, 16 Oct 2000, Carlisle Adams wrote:
> 
> > > Well, at the very least, I'm glad that some people in the group
> actually
> > > see the problem. Whether it amounts to anything significant, I can
> only
> > > hope.
> >  
> > Yes, I think people see the problem.  Furthermore, I've outlined the
> > conditions under which it is not a problem.  These conditions (a single
> PKI,
> > formed through responsible cross-certification) are not overly
> restrictive
> > and make perfect sense for interoperation between domains that care
> about
> > security, especially since they need to do this anyway in order to
> > authenticate each other.
> 
> But this condition of operation for the AA still hinges on the fact that
> the DN space MUST be unique after cross certifying PKI's.
 
Not quite.  It hinges on the fact that whatever name space will be used,
MUST be unique.  Name constraints do not have to be applied to DNs; they can
be applied to e-mail domains, or Kerberos realms, or whatever is used within
the subject AND subjectAltNames fields (and, in fact, can be applied to
multiple name spaces simultaneously, if this is deemed to be appropriate).
The idea is similar to PEM's name subordination, but is much more general
and flexible.

> Can you really see that happening?
 
Yes.

> I cannot see that happening in the real world. Especially with many
> players, and especally when you need to do things quickly. Forcing one
> organization or both to comply with the other, is a lot of work, and
> figuring out name constraints for both could be a daunting effort, not
> mentioning getting it correct.
 
As one example, company A has the e-mail domain A.com and company B has the
domain B.com.  When they cross-certify, the cross-cert that A issues says
that entities in B's space must be in the B.com domain, and the cross-cert
that B issues says that entities in A's space must be in the A.com domain.
This seems quite straightforward and intuitive.  AND, as I keep saying, they
need to do this anyway in order to authenticate (this is not some special
situation that needs to be artificially put in place just so that
authorization can work).

Other example name constraints could equally well have been chosen.  I don't
see the difficulty.

Carlisle.

---

From: "Rich Ankney" <[email-masked]>
Date: Tue, 17 Oct 2000 22:32:35 -0400

I agree.  This sounds like good clarifying text.

Regards,
Rich

-----Original Message-----
From: Al Arsenault <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Date: Tuesday, October 17, 2000 10:06 PM
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

>
>
>Russ Housley wrote:
>>
>> I would like to redirect this thread.  We should be discussing the
changes
>> to the document.
>>
>
>AWA: An excellent suggestion!
>
>> What changes are needed to the base document that make it clear that
>> certification paths must be validated before the authorization
information
>> contained in an attribute certificate can be safely used?
>>
>
>AWA:  Section 5., Attribute Certificate Validation:
>
> Add a new 1., and renumber other items appropriately:
>
> To be valid an AC MUST satisfy all of the following:
>
>   1.   The AC holder's PK certificate must be found, and the entire
>certification path of that PKC MUST be verified in accordance with
>[PKIXPROF].
>
> 2. The AC signature must be cryptographically correct, and the AC
>        issuer's entire PKC certification path MUST be verified in
>        accordance with [PKIXPROF].
> ...
>> What changes need to be made to the Security Considerations section to
>> avoid many of the problems discussed in this thread.  Carlisle Adams made
>> the constructive comment that name constraints can be used to eliminate
>> many of these concerns.
>>
>
>AWA: I'm not wedded to the exact wording, but I'll propose:
>
> There is a potential security issue when an attribute certificate is
>issued to a holder and the holder's PKC chains back to a root CA that is
>independent from the root CA to which the AC issuer's PKC chains.
>"Independent" means that neither root CA is subordinate to the other,
>and they are not cross-certified.  The security issue is that two
>different PKCs, one under each of the two roots, can have the same
>issuer name and serial number, and this information will be in the AC
>holder field.  In this case, it may not be possible to identify to which
>PKC the AC is supposed to belong, and thus attributes may be associated
>with the wrong holder.
>
> The primary solution to this issue is for RPs to only accept AC/PKC
>combinations that chain back to a common root CA, or to CAs that (1) are
>cross-certified; and (2) enforce name constraints to ensure that there
>are not two issuers with the same names.
>
>
>> Can we focus on the text?
>>
>>    -- Russ
>
>
>Okay, take your shots at it.
>
> Al Arsenault
> Chief Security Architect
> Diversinet Corp.

---

From: [email-masked]
Date: Wed, 18 Oct 2000 11:28:22 -0400

Rather than making IETF's format completely incompatible with X.509,
there are two other possibilities which come to mind:

     First, adding the changed baseCertificateID as another option in
holder, as follows:

           Holder ::= SEQUENCE {
                 baseCertificateID   [0] IssuerSerial OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate
                 entityName          [1] GeneralNames OPTIONAL,
                          -- the name of the claimant or role
                 objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
                          -- if present, version must be v2
     verifiedBaseCertificateID     FullESSCertID OPTIONAL
           }

   Full ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial
   }

     Second, adding the needed field as an extra field (the order of the
extra field is arbitrary, and some might prefer it immediately after
baseCertificateID):
           Holder ::= SEQUENCE {
                 baseCertificateID   [0] IssuerSerial OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate
                 entityName          [1] GeneralNames OPTIONAL,
                          -- the name of the claimant or role
                 objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
                          -- if present, version must be v2
     baseCertHash   Hash OPTIONAL -- only present if baseCertificateID is
also
           }

     Third, defining an extension to contain the base certificate hash.

     Any of these changes would leave all legal X.509:2000 AC's still
legal, which is presumably desirable.  The first two options involve a
defect report against X.509.  I have avoided tags as they are not needed
here - and hardly ever are when all the existing members have them.

          Tom Gindin

Denis Pinkas <[email-masked]> on 10/18/2000 10:35:31 AM

To:   Al Arsenault <[email-masked]>, Sharon Boeyen <[email-masked]>
cc:   Russ Housley <[email-masked]>, [email-masked],
      [email-masked], [email-masked], [email-masked]
Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt

changes
> AWA: An excellent suggestion!

I guess that everybody strongly agrees. :-)

information
> PKC the AC is supposed to belong, and thus attributes may be associated

There is a way to (partially) "fix" this security hole. We currently have:

           Holder ::= SEQUENCE {
                 baseCertificateID   [0] IssuerSerial OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate  ...

if we use ESSCertID (defined in RFC 2634 - CMS) instead of IssuerSerial
then
we have:

           Holder ::= SEQUENCE {
                 baseCertificateID   [0] ESSCertID OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate ...

with

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

and, in that case, having IssuerSerial present.

Then we would need some additional text in the explanations to say that the
hash of the certificate should also be tested.

In this way, at the time of verification, there is no ambiguity about the
link between the AC and the certificate, even if the CA has the same name
as
another CA certified from a different root key.

The only problem is that this makes an ASN.1 definition different from the
ISO X.509 definition. If we plan to adopt that change, then we should raise
a defect report to ISO, which is, I think, a real defect: a comment for
such
a change was raised by AFNOR (comment numbered 43) and is marked in the
disposition of comments "accepted in principal". I had not checked the text
changes (I am always trusting Sharon), but apparently there has been no
change done. :-(

==========================================================================

Copy of the original comment 43 from AFNOR.

43. Page 30. Section 13.7. Attribute certificate syntax. There is a
security
weakness in the linkage of the attribute certificate with a public key
certificate, even when the baseCertificateId is used.

The current proposal provides no protection if the key of the CA is
compromised.

In such a case an attribute certificate could point to "CA from Delta
company, number 1234567" which is the certificate from Mr Dupont, but if
the
CA key is compromised then the attacker could forge a certificate with the
same serial number that would contain the name Mr Durand. The way to
counter
that threat is to include the hash of the public key certificate as well.
The ASN1 should be changed to a sequence of both the serial number and the
hash of the certificate and the corresponding explanations should be
adjusted accordingly.

IssuerSerial within the ASN1 syntax of Owner should be changed into:

CertificateUniqueIdentifier

with:

CertificateUniqueIdentifier ::= SEQUENCE {
     certSerialNumber    CertificateSerialNumber,
     certDigestInfo ObjectDigestInfo
}

==========================================================================

> are not two issuers with the same names.

If there is a single trusted root CA, then the problem vanishes, :-) bit we
cannot mandate this.

For (1), we cannot either mandate cross-certificates and a single root.

For (2), name constraints are not that easy to handle. I would prefer the
use of the certificate hash, as indicated above to solve the issue and
others as indicated in the AFNOR comment 43. This is also simpler.

Denis

---

From: [email-masked]
Date: Wed, 18 Oct 2000 22:45:34 -0400

Polar:

     I am actually not trying to tie an AC to a single PKC, just to allow
AA constraints on AC-PKC mapping to be enforced by RP's.  What the
suggestions I made were intended to do was to allow an RP to verify such a
tie when the AA intends one in the first place, and also to permit an AA to
verifiably tie an AC to a small set of PKC's characterized by the same
naming attribute (I think this attribute would be likelier to be e-mail
address or PI than DN, but I may be prejudiced).  If an AA wants to allow
future PKC's with the specified naming attribute to have access to the AC,
I would let him do so.  I gather that you (and probably Bob J.) would like
to prevent that on the grounds that it's a security risk.  Certainly a
comment in security considerations that the absence of ObjectDigest places
relatively high demands on the rigor of the entire web of cross-certified
CA's would be appropriate.
     If ObjectDigest is used, or the extension with multiple
ObjectDigest's, I think having a single PKI is not a major security issue,
although it certainly simplifies verification.

          Tom Gindin

Polar Humenn <[email-masked]> on 10/18/2000 09:50:23 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   Russ Housley <[email-masked]>, [email-masked],
      [email-masked], [email-masked], [email-masked]
Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Tom,

I like your suggestion of tying the AC to a particular certificate, or a
effectively its public key.

The requirements I stated in my proposed text for using only DNs to
identify the Holder or its issuer are flawed.

They required the AA to decide the root CA certificate was used to
identify the Holder along with itself , i.e. a single PKI as Carlisle
suggested.  Unfortunately, I think that is not such a good idea since
cross-certifications can be all over the place. Therefore, that
requirement for using only DNs to identify Holders isn't even good enough.

The AA may not have any idea of who the RPs are or will be. (I think this
was mentioned before). Specifically, I can imagine, that whoever the AA
thinks is its root CA may not be what the RP thinks the AA's root CA is
because of cross-certification. Correct? If this is the case, how could
the RP really tell what the AA thought the root of its PKI is?

In other words, the RP would have to find the root CA certificate that was
used by the AA to make its decision that the Holder's DN was actually
within the AA's PKI. Unfortunately that is on the other side of the
stockade fence. The RP may have the "can't get there from here" problem
with respect to finding the exact root CA cert that the AA used to make
its decision about the Holder being in its own PKI.

The AC has to point to the Holder PKC, as Tom's suggestion point out, so
the RP emphatically knows who has been authorized by the AC.

It seems that one of the key factors here that is causing the problems is
that is NOT desirable to restrict the AC to an entity certificate (or
really its public key). This seems to be the crux of the problem. If the
AC were restricted to the public key, then the problem goes away.

I am tending to agree with Bob Juenema that affixing privileges to names
in this arena is pretty dangerous. Especially for critical applications.
At least there is that option of basing the AC on the public key of the
holder. Although unfortunately, the profile says that it doesn't have to
be supported.

So, is verifiably TRUSTED, unique, worldwide DN naming with enforceable,
recursively consistent naming constraints, a reality? If not then the AC
cannot name the Holder via DN unless it knows who the RPs will be and
knows that the RPs know who the Holders will eventually. That would be a
highly controlled, closed, and protected environment.

I understand how it's suppose to work. Mathematically, there should be a
least upper bound for all AA, RP, and Holders based on public key
signatures through the proper cross-certifications amongst all parties.
Names are completely factored out of that reasoning, only public keys
matter.

In practice, I don't see ACs with just DNs working all the time because of
naming conflicts, and I don't see a way to make that work unless all
parties are guarranteed to work in environmental constraints, perhaps
by legal means instead of technical ones.

I'll regretfully back off, as I cannot really see how to make it work
verifiably in general.

The solution in an wide open environment must be to always bind the AC to
the public key. Alternatively, the only reason I can see to bind the AC to
the holders PKC is to ensure proper advisory information is used, such as
in auditing with the subject Alt names, and other possibly other policy
constraints. Is that correct?

Cheers,
-Polar

On Wed, 18 Oct 2000 [email-masked] wrote:

>      Since ObjectDigestInfo is already in the standard, those new
syntaxes
> I suggested earlier today are redundant, and I hope that I will be
forgiven
> for them.  IMO the correct thing to do in the profile is to recommend
that
> all uses of baseCertificateID SHOULD also use the objectDigestInfo field
> with digestedObjectType publicKeyCert.  In those cases where entityName
is
> used with underlying PKC authentication but it is the AA's intent that
only
> one PKC be permitted, the objectDigestInfo field with digestedObjectType
> publicKeyCert SHOULD also be used.
>      Do we need a new extension to permit the listing of multiple PKC's
(by
> cert digest) for the same entityName when it is the AA's intent to allow
> the use of such for a single AC and all the intended PKC's already exist?
>
>           Tom Gindin
>
>
> Russ Housley <[email-masked]> on 10/18/2000 02:23:10 PM
>
> To:   Polar Humenn <[email-masked]>
> cc:   [email-masked], [email-masked], [email-masked], [email-masked]
> An attribute or extension is the only acceptable approach to me, unless
we
> coordinate with X.509 agrees to make the same change to the base syntax.
>
> Russ
>
>
> At 02:09 PM 10/18/2000 -0400, Polar Humenn wrote:
> >On Wed, 18 Oct 2000, Russ Housley wrote:
> >
> > > Polar:
> > >
> > > You are proposing syntax that is no longer compatible with X.509.  I
am
> > > very unhappy with such a deviation.
> >
> >Hmmm. I only went on that taking into account Tom and Denises
suggestion.
> >Do you feel that an attribute extension would be warranted instead?
> >
> >Cheers,
> >-Polar
> >
> > >
> > > Russ
> > >
> > >
> > >    At 12:38 PM 10/18/2000 -0400, Polar Humenn wrote:
> > > >On Wed, 18 Oct 2000, Denis Pinkas wrote:
> > > >
> > > > >> [SNIP]
> > > > >    ESSCertID ::=  SEQUENCE {
> > > > >         certHash                 Hash,
> > > > > Then we would need some additional text in the explanations to
say
> > that the
> > > > > link between the AC and the certificate, even if the CA has the
> same
> > > > name as
> > > >Dennis,
> > > >I still think that this solution doesn't quite solve the problem,
but
> is a
> > > >good start.  In fact Tom Gindin's suggestion just came in and
includes
> > > >yours. So I'll sort of work off of that.
> > > >
> > > >The fact is that the entityName option still contains a DN and the
RP
> MUST
> > > >be prepared to accept it. However, on what conditions should the RP
> accept
> > > >the Holder as a DN? (Especially if this verification is offloaded to
> some
> > > >remote verification engine).
> > > >
> > > >Perhaps there is a way to word the USE of a DN entityName?
> > > >
> > > >When using an AC that contains the Holder specification as a DN
> entityName
> > > >option, the DN MUST verifiable and uniquely name an entity within
the
> PKI
> > > >of the AA, (i.e. resolved under the same RootCA as the AC). The AA
> MUST
> > > >ONLY create AttributeCertificates with the Holder as a DN entityName
> in
> > > >this fashion. This constraint is subject to the entire PKI for which
> the
> > > >AA belongs belongs to behave in its creation of unique DN.
Therefore,
> > > >verification is subject to the trust the RP places in the AA and its
> PKI
> > > >together to conform to this behavior.
> > > >
> > > >[Note: this approach still does not solve the problem that Denis
> brings up
> > > >below as comment 43. A subordinate CA may be compromised within the
> PKI of
> > > >the AA and create impostor certificates, grabbing privileges.]
> > > >
> > > >Therefore, it would still probably be better to use the
Issuer/Serial
> and
> > > >a hash of the Issuer's certificate, even if in the same PKI.
> > > >
> > > >Of course, when an application authenticates to an RP using PKCs
this
> ties
> > > >the authorization to a particular certificate. Apparently that was
not
> > > >desirable due to the effect of key rollover and new certificates
being
> > > >issued to the same subject entity.
> > > >
> > > >However, I think that if as Carlise pointed out, that if the DN is
> only
> > > >used in the case of a single trusted Root, then everything will be
> fine.
> > > >
> > > >So, as Russ asked me to propose text, here it goes:
> > > >
> > > >Using Tom's suggestion (I took the liberty to use the
ObjectDigestInfo
> > > >that is already defined in the document for the certificate Hash).
> > > >
> > > >Section 4.1:
> > > >
> > > >    Holder ::= SEQUENCE {
> > > >         verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
> > > >    }
> > > >
> > > >    IssuerSerialCertID ::=  SEQUENCE {
> > > >         isserCertDigest          ObjectDigestInfo,
> > > >In section 4.2.2 Holder add:
> > > >
> > > >When using an entityName that contains a DN, the DN MUST verifiably
> and
> > > >uniquely name an entity within the PKI of the AC issuer. The PKC
named
> by
> > > >the DN MUST verify back to the root CA of the AC issuer. The AC
issuer
> > > >MUST ONLY create AttributeCertificates with the Holder as a DN
> entityName
> > > >in this fashion. This constraint is subject to the entire PKI for
> which
> > > >the AC issuer belongs to behave in its creation of unique DNs.
> Therefore,
> > > >verification is also subject to the trust the RP places in the AC
> issuer's
> > > >PKI to conform to this behavior.
> > > >
> > > >In Section 5 the AC Validation Criteria is as follows: (keeping 1 as
> 1,
> > > >inserting 2, 3, and 4 below, and renumbering accordingly).
> > > >
> > > >1. The AC signature MUST be cryptographically correct, and the AC
> > > >2. When the AC holder is named by a DN using the entityName option,
> > > >    the holder's PK certificate MUST be uniquely found under the
same
> root
> > > >    CA as the AC issuer. The entire certification path of that PKC
> MUST be
> > > >    verified in accordance with [PKIXPROF].
> > > >
> > > >3. When the AC holder is named by a baseCertificateId, the issuer's
PK
> > > >    certificate MUST be uniquely found under the same root CA as
> > > >    the AC issuer. The entire certificate path of that PKC MUST
> > > >    be verified in accordance with [PKIXPROF].
> > > >
> > > >4. When the AC holder is named by a verifiedBaseCertificateID, the
> > > >    named holder issuer's PKC must be found, and that PKC MUST
> correctly
> > > >    digest to the digest value contained in the
> verifiedBaseCertificateID.
> > > >    The entire certificate path starting with the holder's PKC and
the
> PKC
> > > >    of the issuer the holder's PKC MUST be verified in accordance
> > > >    with [PKIXPROF].
> > > >
> > > >.....
> > > >
> > > >Note: there is *still* a problem with AC targeting and proxying
using
> > > >just DNs.
> > > >
> > > >Cheers,
> > > >-Polar
> > > >
> > > >
> > > >-------------------------------------------------------------------
> > > >Polar Humenn                  Adiron, LLC
> > > >mailto:[email-masked]      2-212 CST
> > > >Phone: 315-443-3171           Syracuse, NY 13244-4100
> > > >Fax:   315-443-4745           http://www.adiron.com
> > >
> >
> >-------------------------------------------------------------------
> >Polar Humenn                  Adiron, LLC
> >mailto:[email-masked]      2-212 CST
> >Phone: 315-443-3171           Syracuse, NY 13244-4100
> >Fax:   315-443-4745           http://www.adiron.com
>
>
>
>

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com

---

From: Michael Myers <[email-masked]>
Date: Thu, 19 Oct 2000 18:10:26 -0700

Polar,

Earlier you wrote to Al that:

> . . . an Attribute Certificte Authority must be separate
> from a Identity Certificate Authority . . .

I disagree.  An authority in control of identity may also be authoritative
for attributes associated with that identity.

Mike

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 23 Oct 2000 15:17:39 -0600

Steve,

We have discussed this before, but unfortunately, name subordination does NOT solve all of the problems, in part because of the legal entanglements caused by treating wholly own subsidiary corporations, Doing Business As firms, franchises, etc., as though they were organization units of a larger parent organization.

I got a very stern, lecture on that subject from the lawyers when I was with GTE.  GTE Laboratories, Inc. is NOT an OU of GTE Corp., no way no how, according to them.  And neither is GTE of Pennsylvania, GTE of California, etc.

The concern that was expressed was that to identify such organizations, which are wholly owned but separate corporations, as organizational units might subject the holding company to liability that was incurred by the subordinate organization, which (in general) is precisely the reason why separate corporations were created in the first place -- to shelter the overall corporate structure from lower level liabilities.

Granted, this approach doesn't always work -- witness the Dow Corning vs. Dow Chemical breast implant suits.  But the corporate attorneys I have talked to are virtually unanimous in agreeing with this position, at least as long as the conventional name of the attribute is "organizationalUnit".

If this is the position with respect to holding companies, I have to believe that it would also be the position of any CAs with competent attorneys -- they are not going to allow the name of the CA to used to used for such purposes either, even if the sequence of RDNs is O=My CA, O=Your Corp.

Bob

>
>>>> Stephen Kent <[email-masked]> 10/23/00 11:01AM >>>
>Polar,
>
>As you and I discussed off list, while one cannot guarantee DN 
>uniqueness across all CAs, one can use the nameConstraints extension 
>in a cross-certificate to ensure that certificates issued by a given 
>CA, and evaluated in the domain of the issuer of the cross 
>certificate, are within a specified name space. This approach 
>addresses the naming concern cited in your message.
>
>Steve

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 24 Oct 2000 11:08:23 -0600

Someone complained that the page I cited locked up his browser, for unknown reasons.

If that happens, try http://developer.novell.com/repository/attributes/pkisv10.pdf

Regards,

Bob

---

From: "Covey, Carlin" <[email-masked]>
Date: Thu, 26 Oct 2000 09:51:47 -0700

Steve,

I wholeheartedly agree with you!  Let's move the AttrCert profile forward.

Here are some comments I prepared on the same topic.  Steve, I apologize if 
they are redundant with your comments, in part; I was just completing them 
when I received your email.

- Carlin Covey
  Cylink Corp.

----------------------
COMMENTS ON THE NAME COLLISION PROBLEM

Assertions made by CA's and AA's

When a CA issues a PKC, the CA is asserting to the world that the subject of
the PKC (or the subject's agent) has presented sufficient proofs to convince
the CA to accept a certain amount of liability concerning misidentification
of the subject and the subject's public key.  Similarly, when an AA issues
an AC the AA is asserting to the world that the holder of the AC (or the
holder's agent) has presented sufficient proofs to convince the AA to accept
a certain amount of liability concerning misidentification of the holder and
whatever holder attributes are expressed in the AC. 

Authentication by AC Verifier

When a Relying party wishes to verify that the public key in a PKC is
associated with some particular EE, the RP authenticates the PKC via the
usual certificate path validation.  But the RP is free to choose the method
by which the RP becomes convinced that the "John Smith" who is the subject
of the PKC is the same "John Smith" with whom the RP wishes to communicate.
The situation is similar for AC's.  The AC verifier must validate the AC via
the usual certificate path validation, and now must become convinced (or
not) that a particular privilege requester is the same EE as the holder of
the AC. 

The requester may present to the AC verifier some cryptographic evidence
that is associated with a particular PKC, and the AC verifier may choose to
verify both that evidence and the PKC.  Assuming that these verify properly,
the AC verifier now knows that the presenter of the evidence has the
identity asserted in the PKC. 

The AC verifier still faces the "John Smith" problem.  That is, the AC
verifier must now become convinced that the "John Smith" known to the CA is
the same as the holder of the AC.  If the AC identifies the subject via a
particular PKC, the cryptographic evidence mentioned earlier is convincing.
However, if the AC uses some other identifier for the subject, then some
other mechanism is necessary to bridge the gap between the holder identifier
in the AC and the subject identifier in the PKC. 

Name Collision Problem

This brings us to the crux of the discussion concerning name collisions. 

Some persons have suggested that name collisions be eliminated via name
constraints or other techniques.  Other persons have expressed the opinion
that this is insufficient.  I believe that this is really up to the AC
verifier.  Different solutions, technical or not, may be acceptable to
different AC verifiers.  IMHO, the AC Draft should not mandate what is
acceptable to all AC verifiers, not should it be thrown out because it does
not mandate this. If the AA expects the AC verifier to authenticate the AC's
subject via a PKC that is linked to the AC via a DN, then the AA's practice
statement should either point out the possibility of name collisions, or
claim that significant effort has been made to avoid name collisions. 

The AC verifier has to make other fuzzy "is this MY John Smith?"
correlations, and this is just one more.  The AC verifier may choose, either
because the privilege being requested is minor, or based upon other
supporting evidence, that "John Smith" in the AC is the same person as "John
Q Smith" in some PKC (despite the admonition in the AC draft not to do so).
However, if the AC asserts some particularly critical attributes ("John
Smith is a board-certified brain surgeon"), then the AC verifier should
probably insist on some convincing evidence linking the privilege requestor
to the AC before turning over the scalpel to (the presumed) Dr. Smith.
Note that the convincing evidence need not be cryptographic.  The AC could
contain biometric identification information that might be presented as
evidence. 

AA's Evidence Recommendations

I believe that the AA should identify the holder authentication evidence
that the AA believes is convincing.  This may be the same information that
the AA used when issuing the AC, or it may be some other evidence that the
AA has reason to believe is convincing.  Here's an example of the former:
"I may not be certain of the name of the AC holder, but the person whose
fingerprint matches the digest in this AC passed the driver's license exam
because I graded the exam and I took the fingerprint."  An example of the
latter is the case when the CA and AA are affiliated:  "I haven't proofed
the subject of the PKC myself, but the HR person who issued the PKC vouches
for the person's identity and I, the HR AA, am now granting the subject of
that PKC the right to change the subject's home address and telephone number
in the company database via a request signed using that PKC." 

How should the AA identify the evidence that the AA thinks the AC verifier
should use?  If the AC identifies the holder only by baseCertificateID, this
implies that the AC verifier should use cryptographic evidence related to
the PKC named by the baseCertificateID.  Otherwise, the recommended evidence
should probably be identified in the AA's practice statement.  (The same
attribute authorizer could run multiple AAs, each with its own practice
statement.) If the same AA issues different types of AC's that require
different authentication evidence, then the required evidence should be
identified within the AC.  This identification could be a PKC digest, a DN,
a biometric, or some required or optional combination of these.  Note that
the AC draft permits more than one identifier for the AC Holder, but does
not indicate what evidence the AC verifier should use with the different
identifiers.  This is OK.  That information can go in the AA's practice
statement.  A later version of the AC standard can deal with more
complicated evidentiary scenarios.  

- Carlin Covey
  Cylink Corp.

> From: Steve Hanna [mailto:[email-masked]]
> Sent: Thursday, October 26, 2000 8:29 AM
> To: [email-masked]
> It seems to me that this discussion boils down to a rehash of 
> some old,
> oft-debated issues: whether to use names in certificates and how
> authorization information and other attributes can be 
> accessed securely.
> Here's my summary:
> 
> If your PMI is based on names (using ACs whose Holder is only a
> baseCertificateID and/or entityName, for instance), you must be very
> careful about how you map names to public keys. In 
> particular, you must
> ensure that you can't be tricked into mapping the name of an 
> authorized
> user to the public key of an unauthorized user.
> 
> But that's exactly the job of a PKI! If you can't run a PKI securely,
> why bother implementing a PMI? It *is* possible to run a secure PKI.
> Have a small number of trust anchors (one is best). Make sure 
> that they
> (and any cross-certified CAs) are managed carefully to ensure that
> duplicate names are not possible. If you want to include less trusted
> CAs and certificates in your PKI, use name constraints and certificate
> policies to ensure that they cannot be used to gain access to more
> secure applications.
> 
> If you can't run a PKI securely or don't believe in names, 
> you can base
> your PMI on public keys instead (by using ObjectDigestInfo). But I see
> no reason why we should recommend this in general. So I don't support
> discouraging the use of baseCertificateID or entityName (although a
> warning about their dependence on PKI integrity would be wise).
> 
> Likewise, if you don't want to use ACs for your PMI, you are perfectly
> welcome to include attributes in a PKC or store privilege 
> information in
> a directory (or in a database or whereever you like). But 
> many customers
> want to separate management of authorization and authentication. Let's
> enable this by moving the AttrCert profile forward.
> 
> Steve Hanna
>

---

From: "Tom Gindin/Watson/IBM" <[email-masked]>
Date: Thu, 26 Oct 2000 16:00:51 -0400

Response below.  If an organization wishes its RP's to use one or a
few SOA's but a fair number of reputable CA's, ObjectDigestInfo with
baseCertificateID or entityName seems like a good precaution.

          Tom Gindin

P.S. - The opinions in this memo are mine, and not necessarily those of my
employer.

Steve Hanna <[email-masked]> on 10/26/2000 11:28:31 AM

To:   [email-masked]
cc:

It seems to me that this discussion boils down to a rehash of some old,
oft-debated issues: whether to use names in certificates and how
authorization information and other attributes can be accessed securely.
Here's my summary:
(snip)
If you can't run a PKI securely or don't believe in names, you can base
your PMI on public keys instead (by using ObjectDigestInfo). But I see no
reason why we should recommend this in general. So I don't support
discouraging the use of baseCertificateID or entityName (although a warning
about their dependence on PKI integrity would be wise).

[Tom Gindin] I don't think anyone is discouraging the use of
baseCertificateID.  What I and some others are suggesting is to use
ObjectDigestInfo with it to make it unbreakable.  It is perfectly true that
if you have a single trusted root you don't really need to do this.  As far
as entityName is concerned, the current draft seems to prefer
baseCertificateID when either might be used.

Likewise, if you don't want to use ACs for your PMI, you are perfectly
welcome to include attributes in a PKC or store privilege information in a
directory (or in a database or whereever you like). But many customers want
to separate management of authorization and authentication. Let's enable
this by moving the AttrCert profile forward.

Steve Hanna

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 26 Oct 2000 17:49:31 -0400 (EDT)

I agree with Steve that the profile should accommodate both privileges
attached to names, and privileges attached to public keys.

In the case where privileges are attached to names, Holder can only be
entityName [1] alone.

In the case where privileges are attached to a public key, any of the
other 6 combinations ( [0], [2], [0]+[1], [0]+[2], [1]+[2], [0]+[1]+[2])
are possible for Holder.  I see nothing wrong with having the AC
profile make a recommendation changing:

   Implementations conforming to this profile are not required to
   support the use of the objectDigest field. However, section 7.3
   specifies how this optional feature MAY be used.

to:

   Implementations conforming to this profile are not required to
   support the use of the objectDigest field.  However, if the holder
   field uses the baseCertificateID option, the holder field SHOULD 
   also include the objectDigestInfo option.  Implementations MAY also
   use objectDigestInfo without baseCertificateID or entityName as
   specified in section 7.3.

Following this recommendation causes no loss of generality in the
privileging model.  But there may be circumstances where calculating or
verifying the objectDigestInfo is problematic, so I don't think the
profile should raise the SHOULD to a MUST.

The profile does not specify how to handle an AC where both entityName
and baseCertificateID are present; it treats them as mutually exclusive
options.  What should happen if both are included in the AC and
entityName matches and baseCertificateID does not, or vice versa?  I
suggest that the AC profile formalize the mutual exclusion assumption
and say:

   If the holder field uses the entityName option, the holder field MUST
   NOT include baseCertificateID or objectDigestInfo.

But my top priority is Steve's last recommendation - if either of the
suggestions above are at all controversial, then forget about them.
Let's move the AC profile forward.

Dave

> [Steve Hanna] If you can't run a PKI securely or don't believe in names, you 
can base

---

From: "Tom Gindin/Watson/IBM" <[email-masked]>
Date: Thu, 26 Oct 2000 18:35:44 -0400

I hope the following quibble will not be considered as so
controversial that it causes your rewording to be dropped.  It is legal for
an entityName to be attached to a single PKC if the PKC is not passed with
the message or protocol, so entityName need not be mutually exclusive with
objectDigestInfo.  I have a suggested rewording of your mutual exclusion
rule below.

          Tom Gindin

"David P. Kemp" <[email-masked]> on 10/26/2000 05:49:31 PM

Please respond to "David P. Kemp" <[email-masked]>

To:   [email-masked]
cc:

to:

The profile does not specify how to handle an AC where both entityName and
baseCertificateID are present; it treats them as mutually exclusive
options.  What should happen if both are included in the AC and entityName
matches and baseCertificateID does not, or vice versa?  I suggest that the
AC profile formalize the mutual exclusion assumption and say:

[Tom Gindin] If the holder field uses the entityName option, the holder
field MUST NOT include baseCertificateID.  If a holder field using the
entityName refers to a single known PKC, it MAY include objectDigestInfo,
but otherwise it MUST not include objectDigestInfo.

Dave

can base
> discouraging the use of baseCertificateID or entityName (although a
warning

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 27 Oct 2000 09:00:46 +0200

Al,

<snip>

>Anders, my company firmly believes that that ACs have a very bright
>future in e-commerce.  In fact, we believe it so much that we're
>spending a lot of money building a line of products that
>issue/manage/consume ACs.  (Okay, they're actually ACs augmented with
>some other stuff; we call the conglomeration "digital permits".) Here
>are a couple of quotes from the web site (which is www.dvnet.com, by the
>way; we're not www.diversinet.com :-)  :
>
>     "Digital Permits are digitally signed documents that are linked to
>the public-key certificates
>      of users.  Digital Permits could be used in a wide variety of
>applications, including
>      coupons in loyalty programs, lines of credit for auctions, access
>control for applications,
>      receipts for financial and stock trading, pay per view tickets via
>set-top-boxes, and 
>      assigning digital rights for subscription services."

These applications look possible although I remain skeptical about receipts linked 
to a user's PKC instead of just being a digitally signed document referring to the
user's name and customer number. The link to a user PKC make things a bit too 
"fragile" IMHO. 

Coupons: I don't understand how this works. What you would like to have is a 
digital non-forgeable coupon that does not require the coupon-consumer to identify the user 
Otherwise you only need some kind of trivial bookkeeping behind the scene. 

I.e. none of the above scenarios seem to justify the inclusion of a *user* PKC reference 
and then you are back to square one: You simply need (AA-)signed data objects and for 
that purpose we already have CMS, PKCS #7 and hopefully soon XML-sign. Or you use 
Bob's solution and include authority in the user PKC itself. 

I.e. the whole idea to cryptographically link a user PKC to an AC is IMO flawed. If this
is optional (?) ACs are just a restricted form of signed messages and therefore superfluous.  

>Let's fix up the wording and get this document published as an RFC, please.

That XML is not taken seriously in this context is pretty alarming as this is where the 
rest of this industry is going. 

<snip> 

Regards 
Anders Rundgren 
X-OBI 
co-founder

---

From: Michael Zolotarev <[email-masked]>
Date: Fri, 27 Oct 2000 18:19:05 +1000

Anders,

>although I remain skeptical 
> about receipts linked 
<skip>
> messages and therefore superfluous.  

Yes, it is optional. You don;t have to reference PKC from AC. The draft
allows defining the Holder using just GeneralNames. So that the attribute
certificate efectively links the name to the set of roles/priviliges. Isn't
it what you are asking for?

Michael

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 27 Oct 2000 09:57:35 +0200

Michael,
 
>it what you are asking for?

No, 
There are already a lot of other groups, forums, consortiums that work with defining 
signed data object for various uses. BizTalk to name one. Few if any have AFAIK based
their work on  ACs. And equally few newer schemes use ASN.1. They typically use XML. 

So ACs w.o. a cryprographically secure PKC link have plenty of competitors while 
ACs with such links have too few applications to be justifiable.

IMHO, regardless the application, it looks pretty bad for ACs. 

Note: 2-3 years ago when this was initiated things looked different but this happens 
all the time: Solutions become obsolete. Sometimes already on the drawing board! 

To proceed to RFC-level should probably be a snap.  To get this implemented
by the manufacturers that control the world is unlikely as Bob pointed out.

Do I have a problem with this? Nah, the problem is that there will be a few people that will
ask for ACs and won't get it and they will not understand why they can't get it when
it is an Internet "standard".

Anders

---

From: Michael Zolotarev <[email-masked]>
Date: Fri, 27 Oct 2000 20:02:15 +1000

Anders,
> it is an Internet "standard".

That wouldn't be a problem. If the standard is out, but renders itself
useless or obsolete or deficient, you can always justify supporting 'other'
standards to your clients.

It took us too long to get the draft to its current stage, and the industry
in the mean time has moved on significantly. So that the image and the avail
of AC is greatly distorted by the abudance of the other approaches and
initiatives. Yet, there is nothing currently defined by the IETF which can
fill the need for PKI-based authorisation. You are saying 'we don't need
PKI-based authorisation'? Probably. But not definitely. You are also saying
'there are other initiatives addressing and solving the same problem'? Well,
that is always true with almost every standard and solution. We don't have a
time machine, so we cannot go back and stop the standard on its track 2
years ago. I believe that IETF will have enough dignity to say, if it comes
to it, that AC is dead, long live the King. But today I suggest we let it
proceed to RFC, and we call for fair judgment when the mud settles down.

Just my personal opinion (as always :)

Michael

---

From: Sharon Boeyen <[email-masked]>
Date: Fri, 27 Oct 2000 15:51:34 -0400

Yep I can explain - the second text is not text from the standard, but my 
explanation of what I believe is intended and you are correct that in the 
Holder, the order is not as I indicated (it is in issuer though and that's 
where the confusion krept in). What I meant specifically was:

- if entity name and baseCertificateID are present, then ONLY
baseCertificateID
  may be used and entityName is a potentially helpful search tool
- if entityName and objectDigestInfo are present, then ONLY objectDigestInfo
may
  be used and entityName is a potentially helpful search tool
- if baseCertificateID and objectDigestInfo are present, then ONLY
objectDigestInfo
  may be used and baseCertificateID is a potentially helpful search tool
- if entityName, baseCertificateID and objectDigestInfo are present, the
ONLY 
  objectDigestInfo may be used and entityName and baseCertificateID are
potentially 
  helpful search tools.

Sorry for the confusion and thanks for catching it. I shouldn't have tried
to lump it all together.

Sharon

> Sent: Friday, October 27, 2000 1:00 PM
> To: Sharon Boeyen
> Cc: [email-masked]
> I think there's an inconsistency here:
> 
> > Sharon Boeyen wrote:
> > "If baseCertificateID and entityName are both present, only the
> > certificate specified by baseCertificateID may be used. In this case
> > entityName is included only as a tool to help the privilege verifier
> > locate the identified public-key certificate."
> 
> ... then later ...
> 
> > the final present element is the ONLY one that is to be 
> used and that
> > any other elements of the SEQUENCE that are also present 
> are provided
> > ONLY as hints to enable verifiers to find the object.
> 
> If baseCertificateID and entityName are both present, this would argue
> that entityName should be the ONLY element used for validation (since
> entityName is the second element in the Holder SEQUENCE and
> baseCertificateID is the first).
> 
> Can you explain this?
> 
> -Steve
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 28 Oct 2000 09:35:55 +0200

Dale et al,

>Actually, I'm hopeful but not sure.
>
>Had you asked me three or four years ago to predict when I could routinely exchange secure email with others or login to a commercial web server using a private key / certificate rather than a simple user name and password, I would have guessed a year, maybe 18 months at the outside.  That hasn't happened yet and we have to wait for that to be put into place before subsequent elements, like Timestamp servers and ACs, can come into play.
>
>So, we appear to be in a similar position to the people who worked on x.509 v1 certificates back before SSL and S/MIME were proposed >then standardized -- they may have felt that good things were likely to happen but they must have been taking quite a lot on faith early on.

Question: What does support for ACs really mean?

Being an implementor/deployer I see some problems for let's say Microsoft to actually know what to support
as the "Product Matrix" is pretty large given the current AC draft.

Issuing: To issue ACs with cryptographic links to existing PKCs is very different compared to issuing ACs with
just a name reference.

PULL model: Easy to support (and to replace with other systems).  But is it that useful? Does it scale?

PUSH model: This *could* require changes in TLS, browsers, Client OSes and is therefore a major task/risk to pursue.

I.e. the AC *format* is only the tip of the iceberg.

This is a product manager's nightmare which typically causes a "wait-and-see" situation.

Just my 2 öres.

/Anders

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 31 Oct 2000 16:46:36 -0500 (EST)

Sharon,

Thanks for clarifying the distinction between the "controlling" Holder
option and other options used only as search aids.  That's what I get
for reading the AC profile without being thoroughly familiar with the
base X.509 document :-(.

I agree that the precedence shown below is correct, and withdraw my
suggestion for mutual exclusion between entityName and the other
options.

Dave

> From: Sharon Boeyen <[email-masked]>
> To: "'Steve Hanna'" <[email-masked]>
> Cc: [email-masked]
> Date: Fri, 27 Oct 2000 15:51:34 -0400
> 
> - if entityName and baseCertificateID are present, then ONLY baseCertificateID 
> - if entityName and objectDigestInfo are present, then ONLY objectDigestInfo may 
> - if baseCertificateID and objectDigestInfo are present, then ONLY objectDigestInfo 
> - if entityName, baseCertificateID and objectDigestInfo are present, the ONLY 
>   objectDigestInfo may be used and entityName and baseCertificateID are potentially 
>   helpful search tools. 
> 
> Sorry for the confusion and thanks for catching it. I shouldn't have
> tried to lump it all together. 
> 
> Sharon 

Date: Tue, 31 Oct 2000 16:46:36 -0500 (EST)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
To: [email-masked]
Content-MD5: ErIfFE6qjuml4VjDp4o9Ug==

Sharon,

Thanks for clarifying the distinction between the "controlling" Holder
option and other options used only as search aids.  That's what I get
for reading the AC profile without being thoroughly familiar with the
base X.509 document :-(.

I agree that the precedence shown below is correct, and withdraw my
suggestion for mutual exclusion between entityName and the other
options.

Dave

> From: Sharon Boeyen <[email-masked]>
> To: "'Steve Hanna'" <[email-masked]>
> Cc: [email-masked]
> Date: Fri, 27 Oct 2000 15:51:34 -0400
> 
> - if entityName and baseCertificateID are present, then ONLY baseCertificateID 
> - if entityName and objectDigestInfo are present, then ONLY objectDigestInfo may 
> - if baseCertificateID and objectDigestInfo are present, then ONLY objectDigestInfo 
> - if entityName, baseCertificateID and objectDigestInfo are present, the ONLY 
>   objectDigestInfo may be used and entityName and baseCertificateID are potentially 
>   helpful search tools. 
> 
> Sorry for the confusion and thanks for catching it. I shouldn't have
> tried to lump it all together. 
> 
> Sharon 

Date: Mon, 30 Oct 2000 22:08:32 +0100 (MET)
From: Magnus Nystrom <[email-masked]>
Reply-To: Magnus Nystrom <[email-masked]>
To: Tom Arnold <[email-masked]>
cc: [email-masked]
Subject: Re: WAP X.509 Certificate profile specification

Hi Tom,

I would suggest that you send them directly to me, unless they are
pkix-related. I will make sure to forward them to WAP's security group
mailing list - and Cc: you.

Thanks,
-- Magnus

On Mon, 30 Oct 2000, Tom Arnold wrote:

> I've downloaded the document and am beginning to review it.  My company is 
> not a member of the Wap Forum...  As such, if I have comments, where should 
> I send them? I'm assuming the PKIX list is not the correct location...
> 
> At 04:19 PM 10/26/2000 +0200, you wrote:
> >Dear PKIX members,
> >
> >On behalf of WAP's security group WSG, I would like to inform you that
> >a document named "WAPCert-20000309" can be found at
> >
> >http://www.wapforum.org/what/technical.htm.
> >
> >This document describes X.509 certificate profiles to be used for those
> >cases when X.509-compliant certificates will be sent over-the-air in WAP
> >protocols (or stored locally in WAP clients).
> >
> >An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
> >
> >Comments and suggestions related to these documents are welcome and
> >solicited.

Date: Mon, 30 Oct 2000 12:04:19 -0800
To: Magnus Nystrom <[email-masked]>
From: Tom Arnold <[email-masked]>
Subject: Re: WAP X.509 Certificate profile specification
Cc: [email-masked]

I've downloaded the document and am beginning to review it.  My company is 
not a member of the Wap Forum...  As such, if I have comments, where should 
I send them? I'm assuming the PKIX list is not the correct location...

At 04:19 PM 10/26/2000 +0200, you wrote:
>Dear PKIX members,
>
>On behalf of WAP's security group WSG, I would like to inform you that
>a document named "WAPCert-20000309" can be found at
>
>http://www.wapforum.org/what/technical.htm.
>
>This document describes X.509 certificate profiles to be used for those
>cases when X.509-compliant certificates will be sent over-the-air in WAP
>protocols (or stored locally in WAP clients).
>
>An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
>
>Comments and suggestions related to these documents are welcome and
>solicited.
>
>Thanks,
>-- Magnus
>Magnus Nystrom
>RSA Security

Thomas A. Arnold
Chief Technical Officer
CyberSource Corporation
1295 Charleston Road
Mountain View, CA 94043-1307
email: [email-masked]
Main: 650.965.6000
PGP Fingerprint: 2EB6 F7F0 6D80 A8E5 9BEC  A05A 0295 0ADE 8F42 EB0D
PGP keys located on PGP and MIT servers at pgp.com and mit.edu

---------------------------------------------------------------------------
This Email and any attached files are confidential and may also be
privileged. It is intended only for the individual or entity to whom
it is addressed. If you are not the recipient or an authorized agent
of the recipient, you are hereby notified that any use, dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this message in error, please contact CyberSource
Corporation immediately at 650.965.6000.

Thank you.

Content-return: allowed
Date: Mon, 30 Oct 2000 10:41:31 -0800
From: Peter Williams <[email-masked]>
Subject: RE: TSP-11 comments.
To: "'Denis Pinkas'" <[email-masked]>, Parag Namjoshi <[email-masked]>
Cc: IETF-PXIX <[email-masked]>
Deferred-delivery: Mon, 30 Oct 2000 10:43:00 -0800

The various policy signals are appropriately
signaled by the certificate policy ids, as qualified
by users, for each signing algorithm, by WIPO usage
control parameters noticed in the OCSP
or TSA signing block.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Monday, October 30, 2000 5:08 AM
To: Parag Namjoshi
Cc: IETF-PXIX
Subject: Re: TSP-11 comments.

Parag,
 
> Hi Denis,
> 
> Some comments about TSP-11 draft.
> 
> 1. The sixth point in security considerations text does seem to consider
> the possibility of deliberate replay of requests. Consider a service
> provider who charges for timestamping. Client sends a (possibly signed)
> request. The attacker replays the request as many times as he likes !!!
> The attack will be detected when the subscriber gets an impressive bill at
> the end of the month :-) This can mess up any logging done by the server.
> The server could possibly maintain a window of recent nonces to reduce the
> intensity of this attack (Replay then can be attempted again after the
> window has moved on.) This can cause big problems with billing systems of
> the server. To defeat this attack, the requester should include his local
> time in the request. Server can then verify the timeliness of the request
> by verifying the time included in the request against its timesource and
> issue token accordingly.

Authentication of requests is outside the scope of this document and can be
made using various means. Replay protection is dependent upon the data
origin authentication mechanism which is outside the scope of this document.
 
> 2. The text for the sixth point is little unclear. Perhaps replay
> detection at server & client should treated under two different bullets.

If you have a better text, I would be happy to consider it so that it could
possibly be included next year when we will go from Proposed Standard to
Standard.

> 3. Removal of 'policyQualifiers' effectively disallows CPS like structures
> for TSA. I feel "Timestamp Practices Statement" (TPS) is a legitimate
> requirement for a TSA. Wouldn't it be worthwhile to reintroduce
> TSAPolicyQualifiers or is it so detestable, that we  sacrifice TPS
> capability to avoid it ?

Russ Housley gave arguments. This is not necessary. 

> 4. The draft does not define OID's for  "standard" policies.e.g.
> * The conditions under which the time stamp may be used.
> * The availability of a time-stamp log, to allow later verification that a
> time-stamp token is authentic
> This may lead to interop problems. Could the draft define a few standard
> policy OID's like RFC2459 ?

This is a valid proposal. This could be the topic of new document. Let us
discuss this on the amiling list and/or at the coming San Diego meeting. If
this is agreed we would need to extend our charter.

Regards,

Denis
 
> Parag.

Date: Mon, 30 Oct 2000 16:04:40 +0100
From: tho <[email-masked]>
To: [email-masked]
Subject: a TSP-11 compliant implementation

hello,
we have upgraded our timestamper in order to meet version 11 specs and 
we also added the http protocol interface in addition to the "tcp" based
one.
if you are interested in doing some testing the following is the url
where you can find further informations: http://195.223.2.6:8080

thanks to Peter Sylvester for being the very first to test it. :)

tho
-- 
(__)                
(oo)                       
 \/-------\         
  ||     | \    
  ||---W||  *  

Date: Mon, 30 Oct 2000 14:07:42 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Parag Namjoshi <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: Re: TSP-11 comments.

Parag,
 
> Hi Denis,
> 
> Some comments about TSP-11 draft.
> 
> 1. The sixth point in security considerations text does seem to consider
> the possibility of deliberate replay of requests. Consider a service
> provider who charges for timestamping. Client sends a (possibly signed)
> request. The attacker replays the request as many times as he likes !!!
> The attack will be detected when the subscriber gets an impressive bill at
> the end of the month :-) This can mess up any logging done by the server.
> The server could possibly maintain a window of recent nonces to reduce the
> intensity of this attack (Replay then can be attempted again after the
> window has moved on.) This can cause big problems with billing systems of
> the server. To defeat this attack, the requester should include his local
> time in the request. Server can then verify the timeliness of the request
> by verifying the time included in the request against its timesource and
> issue token accordingly.

Authentication of requests is outside the scope of this document and can be
made using various means. Replay protection is dependent upon the data
origin authentication mechanism which is outside the scope of this document.
 
> 2. The text for the sixth point is little unclear. Perhaps replay
> detection at server & client should treated under two different bullets.

If you have a better text, I would be happy to consider it so that it could
possibly be included next year when we will go from Proposed Standard to
Standard.

> 3. Removal of 'policyQualifiers' effectively disallows CPS like structures
> for TSA. I feel "Timestamp Practices Statement" (TPS) is a legitimate
> requirement for a TSA. Wouldn't it be worthwhile to reintroduce
> TSAPolicyQualifiers or is it so detestable, that we  sacrifice TPS
> capability to avoid it ?

Russ Housley gave arguments. This is not necessary. 

> 4. The draft does not define OID's for  "standard" policies.e.g.
> * The conditions under which the time stamp may be used.
> * The availability of a time-stamp log, to allow later verification that a
> time-stamp token is authentic
> This may lead to interop problems. Could the draft define a few standard
> policy OID's like RFC2459 ?

This is a valid proposal. This could be the topic of new document. Let us
discuss this on the amiling list and/or at the coming San Diego meeting. If
this is agreed we would need to extend our charter.

Regards,

Denis
 
> Parag.

From: "Parag Namjoshi" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "IETF-PXIX" <[email-masked]>
Subject: TSP-11 comments.
Date: Mon, 30 Oct 2000 18:17:33 +0530

This is a multi-part message in MIME format.

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

Hi Denis,

Some comments about TSP-11 draft.

1. The sixth point in security considerations text does seem to consider =
the possibility of deliberate replay of requests. Consider a service =
provider who charges for timestamping. Client sends a (possibly signed) =
request. The attacker replays the request as many times as he likes !!! =
The attack will be detected when the subscriber gets an impressive bill =
at the end of the month :-) This can mess up any logging done by the =
server. The server could possibly maintain a window of recent nonces to =
reduce the intensity of this attack (Replay then can be attempted again =
after the window has moved on.) This can cause big problems with billing =
systems of the server. To defeat this attack, the requester should =
include his local time in the request. Server can then verify the =
timeliness of the request by verifying the time included in the request =
against its timesource and issue token accordingly.

2. The text for the sixth point is little unclear. Perhaps replay =
detection at server & client should treated under two different bullets.

3. Removal of 'policyQualifiers' effectively disallows CPS like =
structures for TSA. I feel "Timestamp Practices Statement" (TPS) is a =
legitimate requirement for a TSA. Wouldn't it be worthwhile to =
reintroduce TSAPolicyQualifiers or is it so detestable, that we  =
sacrifice TPS capability to avoid it ?

4. The draft does not define OID's for  "standard" policies.e.g.
* The conditions under which the time stamp may be used.
* The availability of a time-stamp log, to allow later verification that =
a time-stamp token is authentic
This may lead to interop problems. Could the draft define a few standard =
policy OID's like RFC2459 ?

Regards,
Parag.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT face=3DArial size=3D2>
<DIV>Hi Denis,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Some&nbsp;comments&nbsp;about TSP-11 draft.</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>1. The sixth point in security considerations text does seem to =
consider=20
the possibility of deliberate replay of requests. Consider a service =
provider=20
who charges for timestamping. Client sends a (possibly signed) =
request.&nbsp;The=20
attacker&nbsp;replays the request&nbsp;as many times as he likes !!! The =
attack=20
will be detected when the&nbsp;subscriber&nbsp;gets an impressive bill =
at the=20
end of the month :-) This can mess up&nbsp;any logging done by the =
server. The=20
server could possibly maintain a window of&nbsp;recent=20
nonces&nbsp;to&nbsp;reduce the intensity of&nbsp;this attack (Replay =
then can=20
be&nbsp;attempted again after the window has moved on.) This =
can&nbsp;cause big=20
problems&nbsp;with&nbsp;billing systems of the server.&nbsp;To defeat =
this=20
attack, the requester should include his local time in the =
request.&nbsp;Server=20
can then verify the timeliness of the request by verifying the time =
included in=20
the request against its timesource and issue token accordingly.</DIV>
<DIV>&nbsp;</DIV>
<DIV>2. The text for the sixth point is little unclear. Perhaps replay =
detection=20
at server &amp; client should&nbsp;treated&nbsp;under two different=20
bullets.</DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV>3.&nbsp;Removal of 'policyQualifiers' effectively disallows CPS =
like=20
structures for TSA. I feel "Timestamp Practices Statement"&nbsp;(TPS) is =
a=20
legitimate requirement for a TSA.&nbsp;Wouldn't it&nbsp;be worthwhile to =

reintroduce TSAPolicyQualifiers or is it so detestable, that we&nbsp; =
sacrifice=20
TPS capability to avoid it ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>4. The draft does not define OID's for&nbsp; "standard" =
policies.e.g.</DIV>
<DIV>* The conditions under which the time stamp may be used.<BR>* The=20
availability of a time-stamp log, to allow later verification&nbsp;that =
a=20
time-stamp token is authentic</DIV>
<DIV>This&nbsp;may lead to interop problems. Could the draft define a =
few=20
standard policy OID's like RFC2459 ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>Parag.</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_01C4_01C0429D.AC0C9BA0--

Date: Mon, 30 Oct 2000 11:55:00 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: Call for papers: INFOSEC 2001

INFOSEC 2001

15th exhibition and conference on the security of information systems and
communications

29.30.31 May - CNIT Paris-La D�fense - FRANCE

CALL FOR PAPERS

Topics may be addressed from a technical, juridical or organizational
perspective. For 2001, the Programmes Committee will essentially, though not
exclusively, emphasise the following themes:

E-business, e-commerce - Insurance coverage for information systems -
Personal data: risks, means of protection - Competitive Intelligence (CI)
and counter-CI - Crisis management - Law : digital signature - Employees
control - Digital evidence and computer forensic - Specific product security
(NT, Linux, Oracle, etc.) - etc.

PROGRAMMES COMMITTEE

President: Pascal LOINTIER, ACE Insurance

Members: Prof. Danilo BRUSCHI, Universit� de Milan, Italie - Mich�le
COPITET, EGONA CONSULTING - Michel DUPUY, SGDN/DCSSI - Cert A - Paul
GRASSART, CLUSIF - Fr�d�ric HUYNH, ARTHUR ANDERSEN - Jean-Philippe JOUAS,
2SI - Me Bruno P. LANGLOIS, ALAIN BENSOUSSAN - AVOCATS - Patrick LAUTIER,
CLUSIF - Robert LONGEON, CNRS - Pierre-Marie LORANG, THOMSON CSF-DETEXIS -
Marie-Christine MARTEL, SGDN/DCSSI - Denis PINKAS, BULL - Paul RICHY, FRANCE
TELECOM - BR/DACR - Philippe ROSE, LE MONDE  - INFORMATIQUE - St�phane
ROUHIER, CIGREF - Serge SAGHROUNE, ACCOR - Paul TRESCASES, GIE Cartes
Bancaires - Marcel VIGOUROUX, OCLCTIC

Organisation: Maryse DELERIS, M.C.I.

Sponsorship of CLUSIF ([email-masked]) Club de la S�curit� des
Syst�mes d'Information Fran�ais and SGDN Premier Ministre - Direction
Centrale de la S�curit� des Syst�mes d'Information (DCSSI).

DEADLINE TO SUBMIT A PROPOSAL : 31.12.2000

PRACTICAL INFORMATION

Authors have to send their proposal to M.C.I. (letter, fax or e-mail:
[email-masked]) by December 31st, 2000: an abstract (maximum of 3
pages) indicating: TITLE of the subject - and complete address of author(s)

At the end of January 2001, authors will receive the Programmes Committee's
decision. Selected authors will have to send the paper (following detailed
instructions) by February 25th, 2001 to be reviewed and definitively
accepted. Authors will have to certify their paper will not be published
prior to May 31st, 2001. Overtly " commercial " presentations are
inappropriate. 

Free admission offered for speakers (congress and exhibition).

INFORMATION  & ORGANISATION
M.C.I. - Manifestations & Communications Internationales
19 Rue d'Ath�nes - 75009 PARIS - FRANCE
T�l. : (33) 01.44.53.72.20 - Fax : (33) 01.44.53.72.22
E-mail : [email-masked] - 
Web : http://www.mci-salons.fr/infosec

Date: Sun, 29 Oct 2000 14:03:25 -0500 (EST)
From: Polar Humenn <[email-masked]>
To: "Covey, Carlin" <[email-masked]>
cc: "'Dale Gustafson'" <[email-masked]>, [email-masked], "Linn, John" <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

On Fri, 27 Oct 2000, Covey, Carlin wrote:

> Polar, see comments embedded below.
> 
> > From: Polar Humenn [mailto:[email-masked]]
> > Sent: Friday, October 27, 2000 2:02 PM
> > To: Linn, John
> > Cc: 'Dale Gustafson'; [email-masked]
> > A public key can be cross certified by an "attribute authority"
> > merely by issuing another PKC hand it back to the Holder. 
> 
> (snip)
> 
> > Granted the CA/RA of the original public key would be different, 
> > but that information may be included in the PKC as an extension should 
> > that matter to the Relying Party (it might and it might not, depending 
> > on RP's belief in the attribute authority's due diligence).
> 
> [Carlin]:  By "cross certified by an 'attribute authority' " I assume
> that you mean that a CA acting in the capacity of an attribute
> authority (as opposed to an AC Issuer as defined in the AC Draft)
> issues a new PKC using the subject identifier and public key from an
> existing PKC?

Yes, I believe that's what a cross-certification is. I was told that
basically, any public key certificate that is not self signed is a cross
certificate.

> To this new PKC the CA-cum-AA adds some extensions that specify
> certain attributes. At first glance this is appealingly simple, but
> upon reflection it does raise some issues.

Yep.
 
> Issue #1:  PKC's are supposed to be accepted by the subject before
> they are made generally available, whereas there appears to be no such
> requirement with respect to AC's.  

There might be a convention that the subject accepts a certificate before
it's "deployed", but that doesn't really have to happen. What does
"accept" and "generally available" really mean without some context of an
specific application?

> Do you envision that the subject would request the new PKC via some
> standard protocol that incorporates a notification of acceptance?

The only real purpose for these attribute certs as I see it, is so that
effort of retrieving them them and possibly caching them is left to the
client, not the Relying Party, which may be a high throughput server. I
was told that these kinds of servers don't want the overhead of the
authorization lookup. However if that is the reasoning, then with ACs now
they have to do not one, but *two* fairly expensive path discovery and
chain verifications, which may require two calls to an OCSP server at the
very least, if not countless look ups for CRLs, etc.

> Do you envision that the CA-cum-AA might initiate the issuance of the
> new "attribute-enhanced PKC", and would solicit an acknowledgment of
> acceptance from the subject?

I imagine so. I would think that the Client would have to get the
certificate (although that's not strictly necessary).

> Issue #2:  The same public key now appears in two different PKC's
> issued by different CA's.  The CA-cum-AA is obligated to maintain the
> revocation status of the new PKC.  I suppose the new PKC could include
> a pointer to the original CA for certificate status (or to the status
> distribution point specified in the original PKC), but this would not
> allow the attributes in the new PKC to be revoked independent of
> original PKC.  This would not be a problem if the new PKC were
> short-lived and was not intended to be revocable.  But if the new PKC
> were longer-lived, then the CA-cum-AA would be obligated to track the
> revocation status of the original PKC as well as the revocation status
> of the attributes in the new PKC, and for the benefit of RP's for the
> new PKC.

Well, therein lies the crux of all the problems with public key
certificates, revocation. Certificates in my mind, merely certify that a
public key is associated with certain attributes, such as the DN, and a
validity period for the CERTIFICATE, NOT the public key.

I would imagine that if my "new" PKC is valid only on the revocation
status of the "original" PKC (of which you really have no absolute
knowledge that it is "original"). Yes, you would need a pointer to the
status of that certificate. Okay, so? revocation isn't that complex
already?

> Issue #3: The original PKC might be "renewed" prior to its
> "not-valid-after date" by being revoked and replaced by a new PKC with
> the same public key, but a later validity date.  Must the
> "attribute-enhanced PKC"  also be revoked and reissued?

I don't see why. When you issue a new PKC all you are doing is naming a
context for which the public/private key will be used. If its valid enough
for the Relying Party, then fine. The user who acts with the Relying party
has to do what he has to do. If that means getting a new
"attribute-enhanced PKC" then so be it. If you have such complex
revocation strategies/policies, you got a problem anyway, especially if
the public key is cross certified elsewhere. I don't see what the
difference really is.

> Issue #4: Is the CA-cum-AA obligated to mimic the original CA in the
> RP's trust model?  

I would tend to doubt that. The Relying Party may have it's own PKI where
it is a single level CA, and just issues the new "attribute enhanced" PKC
with the public key from some users PKC that it trusts in some form or
another. That CA performs what ever due diligence is needed. The user is
given the new "attribute-enhanced PKC" which she can use for
authentication, signature, authorization in the context of that PKI and is
subscribing Relying Parties. I had thought that is the real way
cross-certification is supposed to work, except for merely the
"convention" of only cross-certifying CAs and not "users".

> If the original CA was directly trusted by the RP,
> then I suppose the CA-cum-AA must also be directly trusted by the RP.

Quite obviously. However, let's get rid of this notion of the "original
CA". As far as a Relying Party is concerned, if the CA-cum-AA is trusted,
then the "original" doesn't enter into the equation, unless there is
something in the "new" PKC that says it should.

> If the original CA is cross-certified with other CA's I guess the
> CA-cum-AA is not obligated to cross certify with those other CA's.  

I don't see why it would. It's only cross certifying the public key to be
used in the context of authentication, signature, and authorization that
is relevant to the Relying Party.

> But is it permissible for the CA-cum-CA to cross-certify with CA's
> with which the original CA is not cross-certified?  Note that this
> would make the subject's signature valid outside of its original
> context.

No, the subject's signature is valid for the context for which the
certificate is created. Any cross-certifications merely put further
constraints on that validity with respect to the Relying Party.

Cheers,
-Polar

> Polar, I don't expect you to address these issues (unless you want
> to).  I was just trying to point out that the simple approach may not
> be so simple after all.
> 
> - Carlin Covey
>   Cylink Corp.
>                       
>  
> 

From: "Gary W. Seehousz" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: unsubscribe
Date: Sat, 28 Oct 2000 11:25:58 -0400

From: "Anders Rundgren" <[email-masked]>
To: "Dale Gustafson" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Sat, 28 Oct 2000 09:35:55 +0200

Dale et al,

Just my 2 �res.

/Anders

From: "Covey, Carlin" <[email-masked]>
To: Polar Humenn <[email-masked]>
Cc: "'Dale Gustafson'" <[email-masked]>, [email-masked], "Linn, John" <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 15:37:21 -0700

Polar, see comments embedded below.

> From: Polar Humenn [mailto:[email-masked]]
> Sent: Friday, October 27, 2000 2:02 PM
> To: Linn, John
> Cc: 'Dale Gustafson'; [email-masked]

(snip) 

> A public key can be cross certified by an "attribute authority"
> merely by issuing another PKC hand it back to the Holder. 

(snip)

> Granted the CA/RA of the original public key would be different, 
> but that information may be included in the PKC as an extension should 
> that matter to the Relying Party (it might and it might not, depending 
> on RP's belief in the attribute authority's due diligence).

[Carlin]:  By "cross certified by an 'attribute authority' " I assume that
           you mean that a CA acting in the capacity of an attribute
authority
           (as opposed to an AC Issuer as defined in the AC Draft) issues a
new 
           PKC using the subject identifier and public key from an existing
PKC?
           To this new PKC the CA-cum-AA adds some extensions that specify
certain
           attributes. At first glance this is appealingly simple, but upon 
           reflection it does raise some issues.  

           Issue #1:  PKC's are supposed to be accepted by the subject
before they
                      are made generally available, whereas there appears to
be no
                      such requirement with respect to AC's.  Do you
envision that
                      the subject would request the new PKC via some
standard
                      protocol that incorporates a notification of
acceptance?
                      Do you envision that the CA-cum-AA might initiate the
issuance 
                      of the new "attribute-enhanced PKC", and would solicit
an
                      acknowledgement of acceptance from the subject?

           Issue #2:  The same public key now appears in two different PKC's
issued
                      by different CA's.  The CA-cum-AA is obligated to
maintain the
                      revocation status of the new PKC.  I suppose the new
PKC could
                      include a pointer to the original CA for certificate
status (or
                      to the status distribution point specified in the
original PKC),
                      but this would not allow the attributes in the new PKC
to be
                      revoked independent of original PKC.  This would not
be a problem
                      if the new PKC were short-lived and was not intended
to be revocable.
                      But if the new PKC were longer-lived, then the
CA-cum-AA would be
                      obligated to track the revocation status of the
original PKC as well
                      as the revocation status of the attributes in the new
PKC, and 
                      merge these into a single revocation status mechanism
for the 
                      benefit of RP's for the new PKC.

            Issue #3: The original PKC might be "renewed" prior to its
"not-valid-after 
                      date" by being revoked and replaced by a new PKC with
the same public 
                      key, but a later validity date.  Must the
"attribute-enhanced PKC" 
                      also be revoked and reissued?  

            Issue #4: Is the CA-cum-AA obligated to mimic the original CA in
the RP's trust 
                      model?  If the original CA was directly trusted by the
RP, then I 
                      suppose the CA-cum-AA must also be directly trusted by
the RP.  If
                      the original CA is cross-certified with other CA's I
guess the CA-cum-AA 
                      is not obligated to cross certify with those other
CA's.  But is it
                      permissible for the CA-cum-CA to cross-certify with
CA's with which the
                      original CA is not cross-certified?  Note that this
would make the subject's 
                      signature valid outside of its original context.

Polar, I don't expect you to address these issues (unless you want to).  I
was just trying to
point out that the simple approach may not be so simple after all.

- Carlin Covey
  Cylink Corp.

Date: Fri, 27 Oct 2000 17:02:24 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: "Linn, John" <[email-masked]>
cc: "'Dale Gustafson'" <[email-masked]>, [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

On Fri, 27 Oct 2000, Linn, John wrote:

> Dale wrote:
> > Hi Anders,
> > Had you asked me three or four years ago to predict when I 
> > could routinely exchange secure email with others or login to 
> > a commercial web server using a private key / certificate 
> > rather than a simple user name and password, I would have 
> > guessed a year, maybe 18 months at the outside.  That hasn't 
> > happened yet and we have to wait for that to be put into 
> > place before subsequent elements, like Timestamp servers and 
> > ACs, can come into play.
> > 
> > So, we appear to be in a similar position to the people who 
> > worked on x.509 v1 certificates back before SSL and S/MIME 
> > were proposed then standardized -- they may have felt that 
> > good things were likely to happen but they must have been 
> > taking quite a lot on faith early on.
> 
> Recalling those pre-PKIX days, when PEM was the motivating driver for
> considering PKI's application to the Internet, makes me conclude that faith
> should be carefully measured.  As experiences suggest, infrastructures
> usually take longer to deploy than is first anticipated; the "inevitable"
> can spend a long time "just around the corner" and may or may not still be
> inevitable if and when it emerges, depending on how the world has changed in
> the interim.  PKI is now increasingly mainstream in the Internet (yes!!),
> but this result follows more than a decade's worth of activity.  
> 
> I believe that a separate PMI can afford powerful generality and that
> specification of ACs should be pursued. Against the historic backdrop,
> however, I'm also concerned that such a PMI may take a long time to become
> pervasive.  Given this concern, the prospect of placing attributes in PKCs
> and thereby leveraging the now-existing PKI directly and incrementally seems
> attractive, where consistent with organizational responsibilities and
> attribute lifetimes. 

I agree. A public key can be cross certified by an "attribute authority"
merely by issuing another PKC hand it back to the Holder. The holder can
then use that certificate to certify that he indeed does have those
privileges should he have the capability, such as in SSL, to deliver the
Relying Party the certificate which only defines the privilege context in
which the user is using its authentication. Granted the CA/RA of the
original public key would be different, but that information may be
included in the PKC as an extension should that matter to the Relying
Party (it might and it might not, depending on RP's belief in the
attribute authority's due diligence).

I also agree with Bob Jeuneman that when coming to attribute authorities,
there may need to be certificate chains of authorities constraining, just
as the name constraints work in PKCs, the ability to grant only certian
privileges, and the prevention of granting certian privileges to
constituents. I don't see that working currently with ACs.

However, I imagine if somebody will build some of this stuff, somebody
will buy (or get sold) it somewhere down the line, and spend a lot of time
and money integrating their applications with it. I don't see that as a
bad thing, that's the way we all make money. 

Cheers,
-Polar

From: "Linn, John" <[email-masked]>
To: "'Dale Gustafson'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 16:38:23 -0400

Dale wrote:

> Hi Anders,
> Had you asked me three or four years ago to predict when I 
> could routinely exchange secure email with others or login to 
> a commercial web server using a private key / certificate 
> rather than a simple user name and password, I would have 
> guessed a year, maybe 18 months at the outside.  That hasn't 
> happened yet and we have to wait for that to be put into 
> place before subsequent elements, like Timestamp servers and 
> ACs, can come into play.
> 
> So, we appear to be in a similar position to the people who 
> worked on x.509 v1 certificates back before SSL and S/MIME 
> were proposed then standardized -- they may have felt that 
> good things were likely to happen but they must have been 
> taking quite a lot on faith early on.

Recalling those pre-PKIX days, when PEM was the motivating driver for
considering PKI's application to the Internet, makes me conclude that faith
should be carefully measured.  As experiences suggest, infrastructures
usually take longer to deploy than is first anticipated; the "inevitable"
can spend a long time "just around the corner" and may or may not still be
inevitable if and when it emerges, depending on how the world has changed in
the interim.  PKI is now increasingly mainstream in the Internet (yes!!),
but this result follows more than a decade's worth of activity.  

I believe that a separate PMI can afford powerful generality and that
specification of ACs should be pursued. Against the historic backdrop,
however, I'm also concerned that such a PMI may take a long time to become
pervasive.  Given this concern, the prospect of placing attributes in PKCs
and thereby leveraging the now-existing PKI directly and incrementally seems
attractive, where consistent with organizational responsibilities and
attribute lifetimes. 

--jl

From: Sharon Boeyen <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 15:51:34 -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_01C0404F.4FA0B4A0
Content-Type: text/plain;
	charset="iso-8859-1"

Sharon

> baseCertificateID is the first).

------_=_NextPart_001_01C0404F.4FA0B4A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.67">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Yep I can explain - the second text is not text from the standard, but my </FONT>
<BR><FONT SIZE=2>explanation of what I believe is intended and you are correct that in the </FONT>
<BR><FONT SIZE=2>Holder, the order is not as I indicated (it is in issuer though and that's </FONT>
<BR><FONT SIZE=2>where the confusion krept in). What I meant specifically was:</FONT>
</P>

<P><FONT SIZE=2>- if entity name and baseCertificateID are present, then ONLY baseCertificateID</FONT>
<BR><FONT SIZE=2>&nbsp; may be used and entityName is a potentially helpful search tool</FONT>
<BR><FONT SIZE=2>- if entityName and objectDigestInfo are present, then ONLY objectDigestInfo may</FONT>
<BR><FONT SIZE=2>&nbsp; be used and entityName is a potentially helpful search tool</FONT>
<BR><FONT SIZE=2>- if baseCertificateID and objectDigestInfo are present, then ONLY objectDigestInfo</FONT>
<BR><FONT SIZE=2>&nbsp; may be used and baseCertificateID is a potentially helpful search tool</FONT>
<BR><FONT SIZE=2>- if entityName, baseCertificateID and objectDigestInfo are present, the ONLY </FONT>
<BR><FONT SIZE=2>&nbsp; objectDigestInfo may be used and entityName and baseCertificateID are potentially </FONT>
<BR><FONT SIZE=2>&nbsp; helpful search tools.</FONT>
</P>

<P><FONT SIZE=2>Sorry for the confusion and thanks for catching it. I shouldn't have tried to lump it all together.</FONT>
</P>

<P><FONT SIZE=2>Sharon</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Steve Hanna [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Friday, October 27, 2000 1:00 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Sharon Boeyen</FONT>
<BR><FONT SIZE=2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think there's an inconsistency here:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Sharon Boeyen wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &quot;If baseCertificateID and entityName are both present, only the</FONT>
<BR><FONT SIZE=2>&gt; &gt; certificate specified by baseCertificateID may be used. In this case</FONT>
<BR><FONT SIZE=2>&gt; &gt; entityName is included only as a tool to help the privilege verifier</FONT>
<BR><FONT SIZE=2>&gt; &gt; locate the identified public-key certificate.&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; ... then later ...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; the final present element is the ONLY one that is to be </FONT>
<BR><FONT SIZE=2>&gt; used and that</FONT>
<BR><FONT SIZE=2>&gt; &gt; any other elements of the SEQUENCE that are also present </FONT>
<BR><FONT SIZE=2>&gt; are provided</FONT>
<BR><FONT SIZE=2>&gt; &gt; ONLY as hints to enable verifiers to find the object.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If baseCertificateID and entityName are both present, this would argue</FONT>
<BR><FONT SIZE=2>&gt; that entityName should be the ONLY element used for validation (since</FONT>
<BR><FONT SIZE=2>&gt; entityName is the second element in the Holder SEQUENCE and</FONT>
<BR><FONT SIZE=2>&gt; baseCertificateID is the first).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Can you explain this?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -Steve</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0404F.4FA0B4A0--

Date: Fri, 27 Oct 2000 12:59:47 -0400
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: Sharon Boeyen <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

... then later ...

> the final present element is the ONLY one that is to be used and that
> any other elements of the SEQUENCE that are also present are provided

Can you explain this?

-Steve

Date: Fri, 27 Oct 2000 12:05:00 -0500
From: Dale Gustafson <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Hi Anders,

So, we appear to be in a similar position to the people who worked on x.509 v1 certificates back before SSL and S/MIME were proposed then standardized -- they may have felt that good things were likely to happen but they must have been taking quite a lot on faith early on.

Best Regards,

--dg

Anders Rundgren wrote:

> Dale,
> You seem convinced that ACs have a bright future. How about e-commerce and ACs?
> I have yet to see a single *practical* example of what the AC-promoters expect the application
> of ACs in e-commerce will be. Do ACs have any use in conjunction with digitally signed
> orders, quotes or bills? Just to take the 99% of the e-commerce field.
>
> Or are ACs rather a [complex] competitor (I like to think in those terms) to Kerberos for internal systems?
>
> To me ACs "feels" like a wet dream (*) for the military and governmental sector but
> for the business sector....
>
> Anders Rundgren
> X-OBI
> co-founder
>
> *) Some dreams are only good as long as they are not materialized.
>
> From: Dale Gustafson <[email-masked]>
> To: Bob Jueneman <[email-masked]>
> Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
> Date: Wednesday, October 25, 2000 15:55
> >Hi Bob,
> >A couple of comments:
> >1) I meant the group clearly appears to agree there is a "need" for the functionality of what has been called an Attribute Certificate (e.g., a tamper-resistant data object containing application or user group specific data), not the separate AC form described in the draft.  Obviously there is substantial agreement on that particular form as well since we do have a well-crafted draft document on the table.
> >
> >2) Didn't intend to imply the typical user would have only one or two key pairs / certificates.
> >
> >3) A complex AC (that includes an embedded PKC) hasn't been discussed much.  It's not the same as an ID certificate that includes special attributes.  The distinction between AC and PKC is well articulated in the draft and I think would apply here as well.  A combo object has distinct implications beyond that.  I suggest we don't have the bandpass to discuss this right now.
> >
> >4) At this time, I think it's much more important to make an effort to find / enhance the value of the approach outlined in the draft and resist the temptation to dismiss it.  It's too easy to find fault with a good, new idea before it's had a chance to become fully developed.
> >
> >5) At first I was a little troubled by the implication that the only way to to move ahead in a timely fashion with this stuff is for individual vendors to create essentially proprietary solutions, albeit using all standards-defined components.  But it's more important to get the necessary interoperability standards in place -- so the real issue is whether others rally around your proposal and "how long it takes" for that to happen.  Good Luck.
> >
> >Best Regards,
> >
> >--dg
> >
> >
> >Bob Jueneman wrote:
> >
> >> Dale,
> >>
> >> You are of course entitled to your opinion,  and who knows -- you might even be correct in your assertions!  Accurate crystal balls are hard to come by..  But I would submit that the discussions on this list indicate that there is far from unanimous consensus as whether or not there is a genuine need for attribute certificates.  Certainly my position at present is that I see NO such compelling need, and I am highly skeptical of the wisdom of adding more and more complexity on top of a PKI that field experience is showing to be of daunting complexity  when it comes to implementing it and making it all work.
> >>
> >> Saying that does NOT mean that I don't see the need for a Privilege Management Infrastructure (PMI) , however -- far from it.  In fact, it is increasingly obvious (at least to me), that PMI is going to be where the real action is, and that the vision of say five to ten years ago of stranger-to-stranger electronic commerce being facilitated by Identity certificates seems less and less likely to materialize.  (The problem, of course, is that even if I know beyond a shadow of a doubt what someone's name is, and even if that name is globally unique, that doesn't mean that he has any money in the bank, or that he is particularly trustworthy, or that I know where to send the sheriff after he drives off with my Maserati demonstrator car and never returns, leaving his electronic driver's license with me as some kind of collateral.)
> >>
> >> But please allow me to break apart your hypothesis line by line -- maybe we can identity some individual elements that we can agree on, and move forward from there.
> >>
> >> >Al, Polar,
> >> >
> >> >Let me also try to summarize.
> >> >
> >> >I think we've arrived at the current state because the group genuinely perceives
> >> >the need for Attribute Certificates.
> >>
> >> As I said, that level of consensus is far from obvious, and there is NO marketing data I am aware of that would support such a contention.
> >>
> >> >I think there is a common sense that there
> >> >is or will soon be a compelling need for secure applications to distribute and
> >> >utilize tamper-resistant, application specific data elements within the global
> >> >PKI.
> >>
> >> On the other hand, I DO agree with that statement -- individual applications really need to be able to specify or determine which  end-entities are entitled to perform certain functions.  One way to do this is to use a directory that is trusted by the Relying Party, and to look up the relevant attributes within that directory.  Unfortunately, although it might be technically possible to harmonize the schemas and eventually federate multiple directories defining such levels of privilege, at present it seems to be an impossible management problem to solve.  So we DO need to distribute "attributes" (rights) within a PKI/PMI infrastructure -- no argument about that.  The question is whether that implies the need for Attribute Certificates per se.
> >>
> >> >It is envisioned that authoritative entities will deploy Attribute
> >> >Authority systems that manage the life cycle of these special certificates.
> >>
> >> I could agree with that.
> >>
> >> >We
> >> >further speculate that each authoritative entity will work with it's various
> >> >constituents to define the form, fit, and function of a specific attribute
> >> >certificate that will be utilized by a well-defined set of applications.  This
> >> >application specific certificate's format and content will be updated from time
> >> >to time as the applications evolve, etc. under some management process
> >> >controlled by the authoritative entity.
> >>
> >> If by that you were to mean a standard X.509 v3 cert that contained specific rights attributes, I would agree.
> >> >
> >> >Past experience has strongly suggested what NOT to do but has not necessarily
> >> >indicated the most appropriate course of action.
> >> >
> >> >Logically, and assuming the need is real, there are at least three possible
> >> >approaches:
> >> >
> >> >1. Embed the Attribute Certificate information in x.509 v3 Identification
> >> >Certificates
> >>
> >> This is of course my strong preference.
> >> >
> >> >Each industry or market group (banking, finance, insurance, communications,
> >> >government, et. al.) can create a set non-critical extensions that allow their
> >> >application-specific information to be carried in a common public key
> >> >certificate or certificates.
> >>
> >> Agreed.  Actually, what is likely to happen is that individual enterprises will define a set of rights that will fit their needs, and then they will try to communicate those rights to someone else, who will have used a slightly different set of semantics and/or syntactic definitions, and those will then have to be harmonized with policy-based controls applied at each Relying Party.  Then some of the industry leaders will get together and define a common schema for such rights, so that everyone can interpret all of the other certificates, assuming the trust the issuing CA.
> >> >
> >> >In the near term (at least) this is the most effective approach because each
> >> >design can take a free ride on all of the PKI infrastructure that is being put
> >> >in place at great expense.
> >>
> >> Exactly.
> >>
> >> >The downside is that the combined certificate
> >> >retains all of the properties of a public key certificate irrespective of
> >> >whether that makes sense for the attribute information and the secure
> >> >application(s) that will utilize it.
> >>
> >> Well, maybe and maybe not.  The assumption you are making is that only one certificate is created, that contains everything.  That might be desirable, especially for relatively static attributes, but it isn't absolutely necessary.  For that matter, the certificate that specifies a user's rights might not contain the user's DN at all -- it certainly wouldn't have to.  But on the other hand, the general requirement for auditing is probably going to require that the user be identified somehow, which at a minimum means a user ID.  And requiring the user to enter a user ID requires a password to confirm it. And although server-enforced passwords have some value as a means of providing multifactor authentication and to prevent a complete collapse if the user's private key is compromised, it seems rather a nuisance to enter all of this when the same information could easily be included int eh certificate itself.
> >> >
> >> >2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate
> >> >
> >> >This has been suggested in the past but was not well received, likely because it
> >> >was obvious that significant additional overhead would be added to each
> >> >attribute certificate but it could not be shown that such a close coupling of
> >> >the attribute certificate and public key certificate would have technical merit
> >> >that justifies the cost.  Problems of keeping the ID certificate and attribute
> >> >together are eliminated but there are still two certificate chains.  The
> >> >infrastructure for and deployment of ID certificates can be utilized "as is".
> >>
> >> This is just the flip side of putting the rights information int he X.509 cert, but this adds the expense of validating two certificate chains.
> >> >
> >> >3. Provide a Link from the Attribute Certificate to the Public Key Certificate
> >> >
> >> >This approach appeared at the outset to be the most elegant and, most
> >> >importantly, appeared to be the most flexible.  It has just now become more
> >> >apparent that creating a reliable, "dynamic" link between the two certificates
> >> >is difficult.  This has been discussed at length recently.
> >>
> >> If people can really, really establish the need for an independent attribute certificate, which I am prepared to accept in theory if not in practice, then at a minimum this coupling seems to require a cryptographic linkage between the attribute cert and the PKI cert.  And that very linkage means that the attribute cert effectively expires or is revoked along with the PKI certs, since the linkage would  no longer be valid.
> >> >
> >> >Perhaps others can recall other approaches that have been suggested.
> >>
> >> The fourth approach, which really hasn't been discussed, is simply to put the "rights" attribute in a directory which is trusted by the Relying Party.  That certainly works, but it lacks a bit of cryptographic elegance, of course.  Now, someone will probably say that the directory isn't sufficiently trusted, to which I would say that the attributes in the directory could be signed. Now we are almost back to an attribute cert, except that it is the Relying Party's organization that is doing the signing, so presumably the checking is simpler.
> >> >
> >> >My sense is that the real value of a separate attribute certificate is that it
> >> >invites others with specific application expertise to join the process "earlier"
> >> >without making everyone's work overly complex -- if (and only if) that's true,
> >> >will people be willing to pay some reasonable price to accomplish the necessary
> >> >up-front planning.
> >> >
> >> >What appears to be missing is a framework that enables secure application
> >> >builders to understand when they can "have at it" knowing they have a reasonably
> >> >stable environment around them.  That is, allows and encourages their innovative
> >> >work to move forward in  parallel with that of other industry and market
> >> >groups.  In order for that to happen, there needs to be a common understanding
> >> >that the basic problem is bounded and within range.
> >> >
> >> >A framework for attribute certificates might better define many of the things we
> >> >have recently discussed:
> >> >
> >> > - encode / decode methods supported (ASN.1, XML, other)
> >> > - commonly used data elements
> >> > - encryption methods (selected attributes, full certificate)
> >> > - delivery methods (SSL, S/MIME, directories, other)
> >> > - certificate path creation / signature validation
> >> > - certificate status checking
> >> > - summary:  distinction between ID certificates and attribute certificates
> >> > - other ?
> >> >
> >> >Perhaps this has already been done elsewhere.  I suspect even an all-knowing
> >> >expert would have to look long and hard at the overall requirements for
> >> >attribute certificates before deciding that a single approach would suffice.
> >> >
> >> >Comments?
> >> >
> >> >Best Regards,
> >> >
> >> >Dale Gustafson
> >>
> >> You might guess that I would not have been quite so sure of myself in this area if we hadn't already done something in this area, and you would be right.  I believe, but don't know the details, that some other vendors have done similar things.
> >>
> >> But Novell has already issued several million certificates that provide the necessary infrastructure to support these kinds of systems, and we are willing to license the technology to anyone who will agree to honor the semantics of the attributes, in particular what we refer to as the certificate quality portion of the Novell Security Attributes.
> >>
> >> For more information, cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm.  For those of you who may have looked at that document previously, it hasn't changed, but I am about to update it, and so I would be delighted to receive comments and suggestions for improvements.
> >>
> >> Regards,
> >>
> >> Bob
> >>
> >> Robert R. Jueneman
> >> Security Architect
> >> Novell, Inc. -- the leading provider of Net services software.
> >

From: Sharon Boeyen <[email-masked]>
To: "'David P. Kemp'" <[email-masked]>, [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 08:53:27 -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_01C04014.E68DF340
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Dave, I want to clear up one point that you raised, from an X.509
perspective:

--stuff deleted--

> Let's move the AC profile forward.

------> 

X.509 is very clear on the situation where both entityName and
baseCertificateID are present. In clause 12.1, in the paragraph that begins
with "The entityName component, if present..., you'll find the following
text:

"If baseCertificateID and entityName are both present, only the certificate
specified by baseCertificateID may be used. In this case entityName is
included only as a tool to help the privilege verifier locate the identified
public-key certificate."

That is the reason that the syntax was made a SEQUENCE with all optional
elements. If you include only the baseCertificateID, what you have is the
"issuer" name and a serial number. This is probably not going to be terribly
helpful to a verifier that may need to try to locate that public-key
certificate for a holder in a repository. At present, at least, these
end-entity public-key certificates are typically stored in the subject's
directory entry. The issuer name isn't very helpful from a searching
standpoint. Therefore the ability to also provide an entityName (ie a name
that identifies the subject of referenced public-key certificate) for the
holder is there. There is NO requirement that the value of entityName also
be contained in the publicKeyCertificate pointed to by baseCertificateID
however. entityName is nothing more than helpful hints to the verifier to
try to locate the actual certificate that is REQUIRED to be used.

As X.509 editor, I believe that I inadvertently did not include the same
text for the combination of baseCertificateID with objectDigestInfo, the
combination of entityName with objectDigestInfo or the combination of all 3.
This is probably because we had followup discussions with the PKIX editors
following the X.509 meeting to finalize syntax and the primary issue was the
objectDigestInfo. Once we agreed the syntax, I suspect I forgot to add the
appropriate text. I have raised this with Hoyt Kesterson (who chaired the
X.509 meeting) and a few other folks who were present. Hoyt and I both agree
that the text should have been added and that the intent was identical to
that which is currently there for entityName baseCertificateID (i.e. that
the final present element is the ONLY one that is to be used and that any
other elements of the SEQUENCE that are also present are provided ONLY as
hints to enable verifiers to find the object. For objectDigestInfo then, if
it is present in the SEQUENCE, then that is the ONLY thing that can may be
used. entityName and baseCertificateID, if present are included only as
tools to help the privilege verifier locate the identified object. We have
not finished digging into our notes from that meeting to ensure that this is
in fact an editorial error, so I can't say for sure that this is how it will
be fixed. We also need to discuss it further with those who were present at
the meeting. However I did want to clarify that the entityName
baseCertificateID combination is valid and actually quite important from an
X.509 perspective. I believe the other combinations are as well. In some
operating environments, the object that was hashed (e.g. a public-key, a
public-key certificate, a software object), may be provided to the verifier
at the time the privilege is asserted. In those cases the additional hints
are not required. However in other operating environments, the object will
not be provided and the verifier will need to retrieve the object. If the
verifier has nothing other the hash it will have a very difficult time
locating the object.

Sharon

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Dave, I want to clear up one point that you =
raised, from an X.509 perspective:</FONT>
</P>

<P><FONT SIZE=3D2>--stuff deleted--</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The profile does not specify how to handle an =
AC where both entityName</FONT>
<BR><FONT SIZE=3D2>&gt; and baseCertificateID are present; it treats =
them as mutually </FONT>
<BR><FONT SIZE=3D2>&gt; exclusive</FONT>
<BR><FONT SIZE=3D2>&gt; options.&nbsp; What should happen if both are =
included in the AC and</FONT>
<BR><FONT SIZE=3D2>&gt; entityName matches and baseCertificateID does =
not, or vice versa?&nbsp; I</FONT>
<BR><FONT SIZE=3D2>&gt; suggest that the AC profile formalize the =
mutual exclusion assumption</FONT>
<BR><FONT SIZE=3D2>&gt; and say:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; If the holder field uses the =
entityName option, the holder </FONT>
<BR><FONT SIZE=3D2>&gt; field MUST</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; NOT include baseCertificateID =
or objectDigestInfo.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; But my top priority is Steve's last =
recommendation - if either of the</FONT>
<BR><FONT SIZE=3D2>&gt; suggestions above are at all controversial, =
then forget about them.</FONT>
<BR><FONT SIZE=3D2>&gt; Let's move the AC profile forward.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Dave</FONT>
</P>

<P><FONT SIZE=3D2>------&gt; </FONT>
</P>

<P><FONT SIZE=3D2>X.509 is very clear on the situation where both =
entityName and baseCertificateID are present. In clause 12.1, in the =
paragraph that begins with &quot;The entityName component, if =
present..., you'll find the following text:</FONT></P>

<P><FONT SIZE=3D2>&quot;If baseCertificateID and entityName are both =
present, only the certificate specified by baseCertificateID may be =
used. In this case entityName is included only as a tool to help the =
privilege verifier locate the identified public-key =
certificate.&quot;</FONT></P>

<P><FONT SIZE=3D2>That is the reason that the syntax was made a =
SEQUENCE with all optional elements. If you include only the =
baseCertificateID, what you have is the &quot;issuer&quot; name and a =
serial number. This is probably not going to be terribly helpful to a =
verifier that may need to try to locate that public-key certificate for =
a holder in a repository. At present, at least, these end-entity =
public-key certificates are typically stored in the subject's directory =
entry. The issuer name isn't very helpful from a searching standpoint. =
Therefore the ability to also provide an entityName (ie a name that =
identifies the subject of referenced public-key certificate) for the =
holder is there. There is NO requirement that the value of entityName =
also be contained in the publicKeyCertificate pointed to by =
baseCertificateID however. entityName is nothing more than helpful =
hints to the verifier to try to locate the actual certificate that is =
REQUIRED to be used.</FONT></P>

<P><FONT SIZE=3D2>As X.509 editor, I believe that I inadvertently did =
not include the same text for the combination of baseCertificateID with =
objectDigestInfo, the combination of entityName with objectDigestInfo =
or the combination of all 3. This is probably because we had followup =
discussions with the PKIX editors following the X.509 meeting to =
finalize syntax and the primary issue was the objectDigestInfo. Once we =
agreed the syntax, I suspect I forgot to add the appropriate text. I =
have raised this with Hoyt Kesterson (who chaired the X.509 meeting) =
and a few other folks who were present. Hoyt and I both agree that the =
text should have been added and that the intent was identical to that =
which is currently there for entityName baseCertificateID (i.e. that =
the final present element is the ONLY one that is to be used and that =
any other elements of the SEQUENCE that are also present are provided =
ONLY as hints to enable verifiers to find the object. For =
objectDigestInfo then, if it is present in the SEQUENCE, then that is =
the ONLY thing that can may be used. entityName and baseCertificateID, =
if present are included only as tools to help the privilege verifier =
locate the identified object. We have not finished digging into our =
notes from that meeting to ensure that this is in fact an editorial =
error, so I can't say for sure that this is how it will be fixed. We =
also need to discuss it further with those who were present at the =
meeting. However I did want to clarify that the entityName =
baseCertificateID combination is valid and actually quite important =
from an X.509 perspective. I believe the other combinations are as =
well. In some operating environments, the object that was hashed (e.g. =
a public-key, a public-key certificate, a software object), may be =
provided to the verifier at the time the privilege is asserted. In =
those cases the additional hints are not required. However in other =
operating environments, the object will not be provided and the =
verifier will need to retrieve the object. If the verifier has nothing =
other the hash it will have a very difficult time locating the =
object.</FONT></P>

<P><FONT SIZE=3D2>Sharon</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C04014.E68DF340--

From: Michael Zolotarev <[email-masked]>
To: Anders Rundgren <[email-masked]>, Michael Zolotarev <[email-masked]>, PKIX-List <[email-masked]>, Al Arsenault <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 20:02:15 +1000

Anders,

Michael

From: "Anders Rundgren" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>, "PKIX-List" <[email-masked]>, "Al Arsenault" <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 09:57:35 +0200

Michael,

No, 

Anders

From: Michael Zolotarev <[email-masked]>
To: Anders Rundgren <[email-masked]>, PKIX-List <[email-masked]>, Al Arsenault <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 18:19:05 +1000

Anders,

<skip>

Michael

From: "Anders Rundgren" <[email-masked]>
To: "PKIX-List" <[email-masked]>, "Al Arsenault" <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 27 Oct 2000 09:00:46 +0200

Al,

<snip>

<snip> 

Regards 
Anders Rundgren 
X-OBI 
co-founder

Date: Thu, 26 Oct 2000 18:26:43 -0700
From: Aram Perez <[email-masked]>
Subject: Re: Help! question about cert thumbprint
To: [email-masked]

Hi Carol,

> 
> Hello, everyone !
> 
> When I double click a cert file , it'll display details of certificate.
> There are a thumbprint algorithm and a thmbprint value.
> I calculate in many ways, but no one lead to the same result .
> Who can tell me how to calculate thmbprint ?

The thumbprint (or fingerprint) of the certificate is the hash of the binary
certificate (DER encoding). The hash algorithm is either MD5 or SHA-1.

Hope this helps,
Aram Perez

From: pki_wby_cn <[email-masked]>
To: [email-masked]
Subject: Help! question about cert thumbprint
Date: Fri Oct 27 00:49:06 2000

------------97260774617571SINAEMAIL---
Content-Disposition: inline
Content-Transfer-Encoding: binary
Content-Type: text/plain;charset="gb2312"

   Hello, everyone !
   
   When I double click a cert file , it'll display details of certificate.
   There are a thumbprint algorithm and a thmbprint value. 
   I calculate in many ways, but no one lead to the same result .
   Who can tell me how to calculate thmbprint ?

   Thanks a lot !
               
                                                             Carol

______________________________________

===================================================================
������ѵ������� http://mail.sina.com.cn
�����Ƴ����˶���Ϣ�ֻ��㲥���� 
http://sms.sina.com.cn/

------------97260774617571SINAEMAIL---
Content-Disposition: attachment;
Content-Transfer-Encoding: 7bits
Content-Type: message/rfc822;

From: pki_wby_cn<[email-masked]>
To: [email-masked]
Subject: About Thumbprint
Date: Thu Oct 26 08:24:38 2000

   Hello, everyone !
   
   When I double click a cert file , it'll display details of certificate.
   There are a thumbprint algorithm and a thmbprint value. 
   I calculate in many ways, but no one lead to the same result .
   Who can tell me how to calculate thmbprint ?

   Thanks a lot !
               
                                                             Carol

______________________________________

===================================================================
������ѵ������� http://mail.sina.com.cn
�����Ƴ����˶���Ϣ�ֻ��㲥���� 
http://sms.sina.com.cn/------------97260774617571SINAEMAIL-----

Importance: Normal
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: "David P. Kemp" <[email-masked]>
Cc: [email-masked]
From: "Tom Gindin/Watson/IBM" <[email-masked]>
Date: Thu, 26 Oct 2000 18:35:44 -0400

          Tom Gindin

To:   [email-masked]
cc:

to:

Dave

can base
warning
> this by moving the AttrCert profile forward.

Date: Thu, 26 Oct 2000 17:49:31 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: [email-masked]
Content-MD5: aDvlpKIKmsOExzOOfAXMtw==

to:

Dave

can base
> this by moving the AttrCert profile forward.

Date: Thu, 26 Oct 2000 15:35:24 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Attribute certificates and extranets

Dale,

Thanks for your courteous and thoughtful reply.  

I understand that people are getting tired of this issue and want to vote it up or down, but when someone is suggesting that a draft standard that a number of people have worked on is either premature or a less than optimal solution to some problem, as I and a few others have suggested, "a decent respect for the opinions of mankind" requires some justification for that position, I believe.

I certainly do agree with the need for a "tamper-resistant data object containing application or user group specific data," and I think there is a clear consensus on that point (although even that need is developing rather slowly).  The question on the table is how best way to implement this requirement, and whether the time is ripe.

The real issue, which I think is appropriate at a Final Call stage, is whether the complexity and cost of implementing the Attribute Certificate solution is justified by the benefits, or whether we should go back to the drawing board and look for alternative solutions to whatever problem we think we are solving.  Although I have no doubt that Attribute Certificates as presently defined could be made to work, the overall complexity and the amount of additional code that would be required in both certificate issuing software, and in particular the changes to existing relying party software, is completely out of proportion to the benefits that would be derived, IMO, and particularly when compared to the option of including those same kinds of attributes as an extension within an X.509 v3 certificate.

In a sense, an attribute certificate without a public key is similar to a directory attribute that is bound to a user's object, e.g., by reference or association with the user's directory name.  The attribute certificate at least contains the signature of the authority who issued it, but it isn't organized in directory form.  That is a good news/bad news situation.

The good news, I suppose, is that the user wouldn't have to have a PKI certificate or a private key at all  They could use whatever authentication mechanism the authorization function supports, and have their additional attributes or rights conveyed by the attribute certs.  This would be essentially the equivalent of a user logging on to a directory or some other authorization service, using user name and password or whatever, except for the fact that the user's attributes are not viewable or manageable (from the Relying Party's standpoint) at any kind of a centralized location. 

The bad news is that those "attributes" (rights) may end up being granted to someone based on a very weak identification and authentication function that is not necessarily tied to a public key, and that the only coupling between the user's identification and the rights being granted is a not necessarily distinguished name, i.e., not necessarily globally unambiguous, for all the reason Polar has described.  Worse yet, the organization that is granting those rights does not necessarily know the strength of the authentication mechanism that will be used to make use of them.

If the rights were only being granted to employees and associates within an single Enterprise, as they might be by referring to a locally trusted directory, then this problem wouldn't be too bad, because the local directory can almost surely be trusted to disambiguate names.  The major problem, however, comes when people want to do what is really hard, but presumably very valuable, and that is to control access to users on an extranet basis, i.e., to semi-strangers that are outside of the local Enterprise.  I may not know the individual in question, but I do know the organization he belongs to, and I will trust what they say about him, at least to a reasonable level.

The original model of attribute certificates, as I understand it, was that an authoritative agency would issue identity certificates as though they were the equivalent of passports or at least driver's licenses.  Then other "attribute authorities", whether the Provo Board of Realtors, or the California Medical Association, or Ford Motor Co. would issue attribute certificate that tied back to that well-established identity certificate in order to grant specific rights for use within their community of interest.

Although that is still a possible model, and especially within Europe with their Qualified Certificates initiative; based on the various discussions we have had with our customers, that model really doesn't seem to be going anywhere from a business perspective, especially within the US.

What I envision as happening instead is that commercial enterprises are increasingly going to issue their own certificate to their employees, either using  CA toolkits to create certificates themselves, or by using RA software to request that a certificate be issued by an outsourced CA function such as VeriSign or Digital Signature Trust.

Within those enterprises, the names CAN be unambiguous, either because they are qualified by OUs down to a level where no name collisions occur, or by the use of a unique identifier such as employee number to qualify the name.

Now, here comes the really important question.  How are people outside of that organization or enterprise going to be authorized to gain access to resources within that enterprise, and what mechanisms can be used to assure that the right person, and only that individual, is granted the appropriate rights?

One solution, whether you use a directory type of authorization server or a collection of attribute certificates, is to require Enterprise A to know the name of every individual within Enterprise B that will be likely to require access to Enterprise A's resources, and for Enterprise A to explicitly preauthorize each such user.  This is of course technically feasible, but it is highly unlikely that this will scale well from a management perspective. In most organizations Enterprise A has no way of knowing all of the employees of Enterprise B, much less know which of them are entitled to certain rights, or when those rights should be revoked because someone leaves Enterprise B.  So that approach doesn't work very well, whether the solution is a local directory or attribute certs issued by Enterprise A.

An approach that would seem to be workable would be to have Enterprise B grant certain rights or role to their employees, and then have Enterprise A recognize and honor those roles within their own organization.

>From a purely technical access control perspective, this type of role-based access control doesn't even require a name at all, just the role-based privilege.  In the case of a hospital, for example, it wouldn't matter what the doctor's name was, only the fact that he was a doctor.  But realistically, we know that this is almost never the case.  The requirement that events be audited normally means that the individual causing some action to be taken has to be identified by name, or at the very least identifiable by some unique identifier that can be traced back to a specific individual in case something goes wrong.  And in that case, I contend that the Attribute Authority probably knows that individual's name/identity at least as well, and perhaps better than, the PKI certificate issuer.  So there is no really good reason not to include the name. And if we did, and if the attribute cert also contained a public key, we'd be done.  We'd have an X.509 cert with a rights label in it, which is what I would like to see.

In addition to the issue of unique naming, there is the issue of whether a given Attribute Authority is considered acceptable by a given Relying Party, and in particular for what rights.  IMO, it is absolutely unacceptable for this process to be managed by controlling the root certificate of each Attribute Authority.   Not only does that make the already too-difficult issue of out of band trusted root management that much more onerous, but it tends to require a root per individual privilege. Now the number of "trusted" roots will really balloon.

If I am the Relying Party (access control mediator) within Enterprise A, I may choose to allow someone with role or rights X as granted by Enterprise B to access some resource, but NOT allow someone with role X in Enterprise C.  Vice versa, someone with role Y in Enterprise C may be allowed access to that same resource or some other, but not someone with that same role from Enterprise B.

For example, let's take something as simple as order processing.  If Enterprise B is a legitimate customer, I will allow Parts Department personnel within Enterprise B to order parts.  But if Enterprise C is my supplier for those same parts, I will NOT allow their Parts Department to cause orders to be placed though me back to their own company, for obvious reasons.  Likewise, I may allow the Account manager that handles my account within Enterprise C to look at my inventory status and run-rate information, in order to give them a heads up on demand  to facilitate just-in-time shipments. But I would not allow some Accounts Manager in my customer, Enterprise B, to access the same data.  If the data were to show that I had an excess of inventory, he might demand a lower price, and if it showed that I was very low on stock, he might order more out of fear, leading to boom and bust demand cycle.

So if I am allowing Enterprise B and C to issue rights to their employees, whether in the form of an attribute certificate or some other method, then I absolutely must have some highly granular way of controlling precisely which individuals within those enterprises are allowed to have such rights, and which are not.

In particular, since Enterprise A is not issuing the certificates to those individuals, I believe it is absolutely necessary to have a way of DENYING someone a particular right, and even more importantly the ability to deny a particular right to an entire class of users based on their Enterprise or particular Attribute Authority.  Just controlling the roots is NOT sufficient, because one Attribute Authority may be acceptable for some right and not others.

At a minimum, I believe that this requires an entire chain of Attribute Authorities, and the ability to either grant OR DENY particular rights to a given AA and any of their subordinate AAs or end users.

But as currently defined, since the rights being granted are not contained within the certificate that contains the public key, nor are they deposited in a centralized directory the relying party can manage, then all rights must be granted positively -- granting a root AA all rights and then denying those rights to lower level AAs is not an option.  And because Attribute Certs don't contain a public key, I can't create a chain of attribute certs in the normal PKI fashion. Instead, I would have to have both an attribute cert and a normal PKI cert for each Attribute Authority, as well as for the end-entity.

It therefore appears that the Relying Party must somehow apply or grant a set of rights to the EACH root AA, and then each AA must explicitly grant or withhold those rights from subordinate AAs and end-entities.

Unless I have missed something, this requires a total of THREE completely independent sets or chains of certificate: One for the end-entity's PKI certificate, one for each of the AA's public key certificate (since the AA can't be a CA, according to the spec), and a set (nor really a chain) of attribute certs tied back to the public key of each AA to manage the rights that are delegated to those AA's.

Now all three of those sets/chains are going to have to be managed, each certificate is going to have to be checked for validity, expiration, and most importantly revocation, using either CRLs or some kind of online check such as OCSP.

The total signature validation processing time has now increased by a factor of three, as has the bandwidth required to retrieve all of those certificate chains and CRLs/OCSP responses.  And nearly all of this processing is on the server side of the system, where the resources are the scarcest.  

And for the privilege of spending three times as much in the way of resources to do something that could easily be accommodate within a basic PKI certificate, we get to write a lot more software, modify a lot of existing applications, and introduce a LOT more incompatibilities and instability into an industry that is still struggling to implement some meaningful basic PKI capabilities.

Such a deal! :-)

Sorry, but I think the answer has to be NO.  There has to be a better way.  (There is, I believe, but modesty suggests ...)

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software

>Hi Bob,
>
>A couple of comments:
>
>1) I meant the group clearly appears to agree there is a "need" for the functionality of what has been called an Attribute 
>Certificate (e.g., a tamper-resistant data object containing application or user group specific data), not the separate AC form 
>described in the draft.  Obviously there is substantial agreement on that particular form as well since we do have a well-crafted 
>draft document on the table.
>
>2) Didn't intend to imply the typical user would have only one or two key pairs / certificates.
>
>3) A complex AC (that includes an embedded PKC) hasn't been discussed much.  It's not the same as an ID certificate that 
>includes special attributes.  The distinction between AC and PKC is well articulated in the draft and I think would apply here 
>as well.  A combo object has distinct implications beyond that.  I suggest we don't have the bandpass to discuss this right 
>now.
>
>4) At this time, I think it's much more important to make an effort to find / enhance the value of the approach outlined in the 
>draft and resist the temptation to dismiss it.  It's too easy to find fault with a good, new idea before it's had a chance to 
>become fully developed.
>
>5) At first I was a little troubled by the implication that the only way to to move ahead in a timely fashion with this stuff is for 
>individual vendors to create essentially proprietary solutions, albeit using all standards-defined components.  But it's more 
>important to get the necessary interoperability standards in place -- so the real issue is whether others rally around your 
>proposal and "how long it takes" for that to happen.  Good Luck.
>
>Best Regards,
>
>--dg

Importance: Normal
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: Steve Hanna <[email-masked]>
Cc: [email-masked]
From: "Tom Gindin/Watson/IBM" <[email-masked]>
Date: Thu, 26 Oct 2000 16:00:51 -0400

          Tom Gindin

To:   [email-masked]
cc:

Steve Hanna

Date: Thu, 26 Oct 2000 14:42:40 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Anders Rundgren <[email-masked]>
CC: Dale Gustafson <[email-masked]>, [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Anders Rundgren wrote:
> 
> Dale,
> You seem convinced that ACs have a bright future. How about e-commerce and ACs?
> I have yet to see a single *practical* example of what the AC-promoters expect the application
> of ACs in e-commerce will be. Do ACs have any use in conjunction with digitally signed
> orders, quotes or bills? Just to take the 99% of the e-commerce field.
> 
> Or are ACs rather a [complex] competitor (I like to think in those terms) to Kerberos for internal systems?
> 
> To me ACs "feels" like a wet dream (*) for the military and governmental sector but
> for the business sector....
> 
> Anders Rundgren
> X-OBI
> co-founder
> 

First off, I'll apologize to one and all for what might be interpreted
as a plug for my company's products.  I'd like to follow the excellent
examples set by folks like Steve, Carlisle, Russ, Stephen, et alia and
keeping product stuff off this list in favor of technical discussion. 
However, the only way to respond to this message from Anders is to
mention something.

     "Permits are associated with X509- based or Diversinet public-key
certificates"

And, to the best of my knowledge, none of our current customers using
these products are military or even Government at any level. 

Now, will this be the "winning model" of e-commerce five years from
now?  Darned if I know.  This is our best guess at the best technology
right now. We're certainly not as big as Novell or even many of the
other PKI companies whose employees are active in PKIX, and we might
wind up missing the technology boat completely.  But we really don't
think so.

Thus, I think that Steve Hanna said it best (certainly better than I
did).  If you can run a PKI securely, then you almost certainly can add
a PMI without blowing up your security.  Further, there are enough
people who believe that there's a business case to refute arguments that
we shouldn't do this because there is no business case. 

Let's fix up the wording and get this document published as an RFC,
please.

                  Al Arsenault
                  Chief Security Architect
                  Diversinet Corp.

(PS: I removed a couple of the omg mail lists from the cc list.  If
those folks are still interested, feel free to forward this message to
'em, but we ought not bomb other mail lists with PKIX discussions unless
they're really, really interested - in which case we can show them how
to subscribe to PKIX.)

From: "Covey, Carlin" <[email-masked]>
To: Steve Hanna <[email-masked]>, [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Thu, 26 Oct 2000 09:51:47 -0700

Steve,

- Carlin Covey
  Cylink Corp.

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

Name Collision Problem

- Carlin Covey
  Cylink Corp.

> enable this by moving the AttrCert profile forward.

Sender: [email-masked]
From: Bruce Stephens <[email-masked]>
To: Steve Hanna <[email-masked]>
Cc: [email-masked]
Subject: Re: WAP X.509 Certificate profile specification
Date: 26 Oct 2000 17:07:01 +0100
Lines: 15

Steve Hanna <[email-masked]> writes:

> Before I can download and read these documents, I apparently must agree
> to a license stating that I will not "do or permit others to do any act
> or omission in relation to a Document which is contrary to the
> objectives of the Licensor as stated in its Memorandum and Articles of
> Association." I cannot find the Memorandum and Articles of Association
> on your web site. Could you supply a copy (or a URL)?

The document is available from here
<http://www.wapforum.org/who/qualify.htm>, in MS Word format.

-- 
Bruce Stephens			[email-masked]
MessagingDirect(UK) Ltd		<URL:http://www.MessagingDirect.com/>

From: "Anders Rundgren" <[email-masked]>
To: "Dale Gustafson" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Thu, 26 Oct 2000 17:51:00 +0200

Dale, 
You seem convinced that ACs have a bright future. How about e-commerce and ACs? 
I have yet to see a single *practical* example of what the AC-promoters expect the application 
of ACs in e-commerce will be. Do ACs have any use in conjunction with digitally signed 
orders, quotes or bills? Just to take the 99% of the e-commerce field. 

Or are ACs rather a [complex] competitor (I like to think in those terms) to Kerberos for internal systems? 

To me ACs "feels" like a wet dream (*) for the military and governmental sector but 
for the business sector.... 

Anders Rundgren
X-OBI
co-founder

*) Some dreams are only good as long as they are not materialized.

-----Original Message-----
From: Dale Gustafson <[email-masked]>
To: Bob Jueneman <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Date: Wednesday, October 25, 2000 15:55
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

>Hi Bob,
>
>A couple of comments:
>
>1) I meant the group clearly appears to agree there is a "need" for the functionality of what has been called an Attribute Certificate (e.g., a tamper-resistant data object containing application or user group specific data), not the separate AC form described in the draft.  Obviously there is substantial agreement on that particular form as well since we do have a well-crafted draft document on the table.
>
>2) Didn't intend to imply the typical user would have only one or two key pairs / certificates.
>
>3) A complex AC (that includes an embedded PKC) hasn't been discussed much.  It's not the same as an ID certificate that includes special attributes.  The distinction between AC and PKC is well articulated in the draft and I think would apply here as well.  A combo object has distinct implications beyond that.  I suggest we don't have the bandpass to discuss this right now.
>
>4) At this time, I think it's much more important to make an effort to find / enhance the value of the approach outlined in the draft and resist the temptation to dismiss it.  It's too easy to find fault with a good, new idea before it's had a chance to become fully developed.
>
>5) At first I was a little troubled by the implication that the only way to to move ahead in a timely fashion with this stuff is for individual vendors to create essentially proprietary solutions, albeit using all standards-defined components.  But it's more important to get the necessary interoperability standards in place -- so the real issue is whether others rally around your proposal and "how long it takes" for that to happen.  Good Luck.
>
>Best Regards,
>
>--dg
>
>
>Bob Jueneman wrote:
>
>> Dale,
>>
>> You are of course entitled to your opinion,  and who knows -- you might even be correct in your assertions!  Accurate crystal balls are hard to come by..  But I would submit that the discussions on this list indicate that there is far from unanimous consensus as whether or not there is a genuine need for attribute certificates.  Certainly my position at present is that I see NO such compelling need, and I am highly skeptical of the wisdom of adding more and more complexity on top of a PKI that field experience is showing to be of daunting complexity  when it comes to implementing it and making it all work.
>>
>> Saying that does NOT mean that I don't see the need for a Privilege Management Infrastructure (PMI) , however -- far from it.  In fact, it is increasingly obvious (at least to me), that PMI is going to be where the real action is, and that the vision of say five to ten years ago of stranger-to-stranger electronic commerce being facilitated by Identity certificates seems less and less likely to materialize.  (The problem, of course, is that even if I know beyond a shadow of a doubt what someone's name is, and even if that name is globally unique, that doesn't mean that he has any money in the bank, or that he is particularly trustworthy, or that I know where to send the sheriff after he drives off with my Maserati demonstrator car and never returns, leaving his electronic driver's license with me as some kind of collateral.)
>>
>> But please allow me to break apart your hypothesis line by line -- maybe we can identity some individual elements that we can agree on, and move forward from there.
>>
>> >Al, Polar,
>> >
>> >Let me also try to summarize.
>> >
>> >I think we've arrived at the current state because the group genuinely perceives
>> >the need for Attribute Certificates.
>>
>> As I said, that level of consensus is far from obvious, and there is NO marketing data I am aware of that would support such a contention.
>>
>> >I think there is a common sense that there
>> >is or will soon be a compelling need for secure applications to distribute and
>> >utilize tamper-resistant, application specific data elements within the global
>> >PKI.
>>
>> On the other hand, I DO agree with that statement -- individual applications really need to be able to specify or determine which  end-entities are entitled to perform certain functions.  One way to do this is to use a directory that is trusted by the Relying Party, and to look up the relevant attributes within that directory.  Unfortunately, although it might be technically possible to harmonize the schemas and eventually federate multiple directories defining such levels of privilege, at present it seems to be an impossible management problem to solve.  So we DO need to distribute "attributes" (rights) within a PKI/PMI infrastructure -- no argument about that.  The question is whether that implies the need for Attribute Certificates per se.
>>
>> >It is envisioned that authoritative entities will deploy Attribute
>> >Authority systems that manage the life cycle of these special certificates.
>>
>> I could agree with that.
>>
>> >We
>> >further speculate that each authoritative entity will work with it's various
>> >constituents to define the form, fit, and function of a specific attribute
>> >certificate that will be utilized by a well-defined set of applications.  This
>> >application specific certificate's format and content will be updated from time
>> >to time as the applications evolve, etc. under some management process
>> >controlled by the authoritative entity.
>>
>> If by that you were to mean a standard X.509 v3 cert that contained specific rights attributes, I would agree.
>> >
>> >Past experience has strongly suggested what NOT to do but has not necessarily
>> >indicated the most appropriate course of action.
>> >
>> >Logically, and assuming the need is real, there are at least three possible
>> >approaches:
>> >
>> >1. Embed the Attribute Certificate information in x.509 v3 Identification
>> >Certificates
>>
>> This is of course my strong preference.
>> >
>> >Each industry or market group (banking, finance, insurance, communications,
>> >government, et. al.) can create a set non-critical extensions that allow their
>> >application-specific information to be carried in a common public key
>> >certificate or certificates.
>>
>> Agreed.  Actually, what is likely to happen is that individual enterprises will define a set of rights that will fit their needs, and then they will try to communicate those rights to someone else, who will have used a slightly different set of semantics and/or syntactic definitions, and those will then have to be harmonized with policy-based controls applied at each Relying Party.  Then some of the industry leaders will get together and define a common schema for such rights, so that everyone can interpret all of the other certificates, assuming the trust the issuing CA.
>> >
>> >In the near term (at least) this is the most effective approach because each
>> >design can take a free ride on all of the PKI infrastructure that is being put
>> >in place at great expense.
>>
>> Exactly.
>>
>> >The downside is that the combined certificate
>> >retains all of the properties of a public key certificate irrespective of
>> >whether that makes sense for the attribute information and the secure
>> >application(s) that will utilize it.
>>
>> Well, maybe and maybe not.  The assumption you are making is that only one certificate is created, that contains everything.  That might be desirable, especially for relatively static attributes, but it isn't absolutely necessary.  For that matter, the certificate that specifies a user's rights might not contain the user's DN at all -- it certainly wouldn't have to.  But on the other hand, the general requirement for auditing is probably going to require that the user be identified somehow, which at a minimum means a user ID.  And requiring the user to enter a user ID requires a password to confirm it. And although server-enforced passwords have some value as a means of providing multifactor authentication and to prevent a complete collapse if the user's private key is compromised, it seems rather a nuisance to enter all of this when the same information could easily be included int eh certificate itself.
>> >
>> >2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate
>> >
>> >This has been suggested in the past but was not well received, likely because it
>> >was obvious that significant additional overhead would be added to each
>> >attribute certificate but it could not be shown that such a close coupling of
>> >the attribute certificate and public key certificate would have technical merit
>> >that justifies the cost.  Problems of keeping the ID certificate and attribute
>> >together are eliminated but there are still two certificate chains.  The
>> >infrastructure for and deployment of ID certificates can be utilized "as is".
>>
>> This is just the flip side of putting the rights information int he X.509 cert, but this adds the expense of validating two certificate chains.
>> >
>> >3. Provide a Link from the Attribute Certificate to the Public Key Certificate
>> >
>> >This approach appeared at the outset to be the most elegant and, most
>> >importantly, appeared to be the most flexible.  It has just now become more
>> >apparent that creating a reliable, "dynamic" link between the two certificates
>> >is difficult.  This has been discussed at length recently.
>>
>> If people can really, really establish the need for an independent attribute certificate, which I am prepared to accept in theory if not in practice, then at a minimum this coupling seems to require a cryptographic linkage between the attribute cert and the PKI cert.  And that very linkage means that the attribute cert effectively expires or is revoked along with the PKI certs, since the linkage would  no longer be valid.
>> >
>> >Perhaps others can recall other approaches that have been suggested.
>>
>> The fourth approach, which really hasn't been discussed, is simply to put the "rights" attribute in a directory which is trusted by the Relying Party.  That certainly works, but it lacks a bit of cryptographic elegance, of course.  Now, someone will probably say that the directory isn't sufficiently trusted, to which I would say that the attributes in the directory could be signed. Now we are almost back to an attribute cert, except that it is the Relying Party's organization that is doing the signing, so presumably the checking is simpler.
>> >
>> >My sense is that the real value of a separate attribute certificate is that it
>> >invites others with specific application expertise to join the process "earlier"
>> >without making everyone's work overly complex -- if (and only if) that's true,
>> >will people be willing to pay some reasonable price to accomplish the necessary
>> >up-front planning.
>> >
>> >What appears to be missing is a framework that enables secure application
>> >builders to understand when they can "have at it" knowing they have a reasonably
>> >stable environment around them.  That is, allows and encourages their innovative
>> >work to move forward in  parallel with that of other industry and market
>> >groups.  In order for that to happen, there needs to be a common understanding
>> >that the basic problem is bounded and within range.
>> >
>> >A framework for attribute certificates might better define many of the things we
>> >have recently discussed:
>> >
>> > - encode / decode methods supported (ASN.1, XML, other)
>> > - commonly used data elements
>> > - encryption methods (selected attributes, full certificate)
>> > - delivery methods (SSL, S/MIME, directories, other)
>> > - certificate path creation / signature validation
>> > - certificate status checking
>> > - summary:  distinction between ID certificates and attribute certificates
>> > - other ?
>> >
>> >Perhaps this has already been done elsewhere.  I suspect even an all-knowing
>> >expert would have to look long and hard at the overall requirements for
>> >attribute certificates before deciding that a single approach would suffice.
>> >
>> >Comments?
>> >
>> >Best Regards,
>> >
>> >Dale Gustafson
>>
>> You might guess that I would not have been quite so sure of myself in this area if we hadn't already done something in this area, and you would be right.  I believe, but don't know the details, that some other vendors have done similar things.
>>
>> But Novell has already issued several million certificates that provide the necessary infrastructure to support these kinds of systems, and we are willing to license the technology to anyone who will agree to honor the semantics of the attributes, in particular what we refer to as the certificate quality portion of the Novell Security Attributes.
>>
>> For more information, cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm.  For those of you who may have looked at that document previously, it hasn't changed, but I am about to update it, and so I would be delighted to receive comments and suggestions for improvements.
>>
>> Regards,
>>
>> Bob
>>
>> Robert R. Jueneman
>> Security Architect
>> Novell, Inc. -- the leading provider of Net services software.
>

Date: Thu, 26 Oct 2000 11:28:31 -0400
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

If your PMI is based on names (using ACs whose Holder is only a
baseCertificateID and/or entityName, for instance), you must be very
careful about how you map names to public keys. In particular, you must
ensure that you can't be tricked into mapping the name of an authorized
user to the public key of an unauthorized user.

Have a small number of trust anchors (one is best). Make sure that they

Likewise, if you don't want to use ACs for your PMI, you are perfectly
welcome to include attributes in a PKC or store privilege information in
a directory (or in a database or whereever you like). But many customers
want to separate management of authorization and authentication. Let's
enable this by moving the AttrCert profile forward.

Steve Hanna

Date: Thu, 26 Oct 2000 17:43:09 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[email-masked]>
To: Steve Hanna <[email-masked]>
cc: [email-masked]
Subject: Re: WAP X.509 Certificate profile specification

Sorry Steve,

It is not "my" documents, it is the WAP forum's documents. I am working
for RSA, who is a member of the WAP forum (as Sun is), not for the WAP
forum, and furthermore, I am not a lawyer. I read through the license
agreement before posting my message, and found it somewhat reasonable. I
don't know where the Memorandum in question is.

-- Magnus
Magnus Nystrom
RSA Security

On Thu, 26 Oct 2000, Steve Hanna wrote:

> Before I can download and read these documents, I apparently must agree
> to a license stating that I will not "do or permit others to do any act
> or omission in relation to a Document which is contrary to the
> objectives of the Licensor as stated in its Memorandum and Articles of
> Association." I cannot find the Memorandum and Articles of Association
> on your web site. Could you supply a copy (or a URL)?
> 
> I hope this is not "denigrating the integrity of the Copyright"
> (prohibited in the license agreement), but I find it a bit much to
> require us to agree to a license in order to read or download your
> documents!
> 
> -Steve
> 
> Magnus Nystrom wrote:
> > 
> > Dear PKIX members,
> > 
> > On behalf of WAP's security group WSG, I would like to inform you that
> > a document named "WAPCert-20000309" can be found at
> > 
> > http://www.wapforum.org/what/technical.htm.
> > 
> > This document describes X.509 certificate profiles to be used for those
> > cases when X.509-compliant certificates will be sent over-the-air in WAP
> > protocols (or stored locally in WAP clients).
> > 
> > An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
> > 
> > Comments and suggestions related to these documents are welcome and
> > solicited.

Date: Thu, 26 Oct 2000 10:53:12 -0400
From: Steve Hanna <[email-masked]>
Organization: Sun Microsystems, Inc.
To: Magnus Nystrom <[email-masked]>
CC: [email-masked]
Subject: Re: WAP X.509 Certificate profile specification

Before I can download and read these documents, I apparently must agree
to a license stating that I will not "do or permit others to do any act
or omission in relation to a Document which is contrary to the
objectives of the Licensor as stated in its Memorandum and Articles of
Association." I cannot find the Memorandum and Articles of Association
on your web site. Could you supply a copy (or a URL)?

I hope this is not "denigrating the integrity of the Copyright"
(prohibited in the license agreement), but I find it a bit much to
require us to agree to a license in order to read or download your
documents!

-Steve

Magnus Nystrom wrote:
> 
> Dear PKIX members,
> 
> On behalf of WAP's security group WSG, I would like to inform you that
> a document named "WAPCert-20000309" can be found at
> 
> http://www.wapforum.org/what/technical.htm.
> 
> This document describes X.509 certificate profiles to be used for those
> cases when X.509-compliant certificates will be sent over-the-air in WAP
> protocols (or stored locally in WAP clients).
> 
> An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
> 
> Comments and suggestions related to these documents are welcome and
> solicited.
> 
> Thanks,
> -- Magnus
> Magnus Nystrom
> RSA Security

Date: Thu, 26 Oct 2000 16:19:51 +0200 (W. Europe Daylight Time)
From: Magnus Nystrom <[email-masked]>
To: [email-masked]
Subject: WAP X.509 Certificate profile specification

Dear PKIX members,

On behalf of WAP's security group WSG, I would like to inform you that
a document named "WAPCert-20000309" can be found at

http://www.wapforum.org/what/technical.htm.

This document describes X.509 certificate profiles to be used for those
cases when X.509-compliant certificates will be sent over-the-air in WAP
protocols (or stored locally in WAP clients).

An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.

Comments and suggestions related to these documents are welcome and
solicited.

Thanks,
-- Magnus
Magnus Nystrom
RSA Security

From: pki_wby_cn <[email-masked]>
To: [email-masked]
Subject: About Thumbprint
Date: Thu Oct 26 08:24:38 2000

   Hello, everyone !
   
   When I double click a cert file , it'll display details of certificate.
   There are a thumbprint algorithm and a thmbprint value. 
   I calculate in many ways, but no one lead to the same result .
   Who can tell me how to calculate thmbprint ?

   Thanks a lot !
               
                                                             Carol

______________________________________

===================================================================
������ѵ������� http://mail.sina.com.cn
�����Ƴ����˶���Ϣ�ֻ��㲥���� 
http://sms.sina.com.cn/

From: "Covey, Carlin" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Request for consensus call on AC draft
Date: Wed, 25 Oct 2000 13:12:48 -0700

Mike,

Thanks for suggesting that the chairs "call the question."  My feeling is
that we should make only minor tweaks to the AC draft, and vote the draft up
or down as it stands in December.  That said, I reserve the right to propose
some minor tweaks, as below.

- Carlin Covey
  Cylink Corporation. 

-----------------------------------------------
Proposed tweak 1

[Quoting from the AC Draft]: "4.2.9 Extensions 
<snip> If any other critical extension is used, then the AC does not conform
to this profile. However, if any other non-critical extension is used, then
the AC does conform to this profile." 

[Carlin]: Perhaps this is nit-picking, but if an AC contains both an "any
other critical extension" and an "any other non-critical extension" then the
AC both conforms and does not conform to the profile (for any arbitrary
definition of "any other").  Perhaps the wording could be changed slightly
to 

[Suggested change]: "If any other critical extension is used, then the AC
does not conform to this profile. However, the use of any non-critical
extension does not make the AC nonconforming to this profile."  

------------------------------------------------
Proposed tweak 2

[Quoting from the AC Draft]: "4.3.2 AC Targeting 
To target an AC, the target information extension, imported from
[X.509-2000], MAY be used to specify a number of servers/services. The
intent is that the AC SHOULD only be usable at the specified
servers/services. An (honest) AC verifier who is not amongst the named
servers/services MUST reject the AC. "

[Carlin]: Why does this draft contain imperative language with respect to
the AC verifier?  The same server could choose to grant the same privileges
without any AC.  If a "non-targeted" server chooses to accept a AC targeted
for some other server, does that make the first server dishonest, or merely
foolish? It seems to me that such imperative language belongs in the AA's
practice statement, prefaced by words like "This AA will not be liable for
any damages resulting from a server relying on a targeted AC if such server
is not a target of that AC."  I suggest that the Draft be reworded to say 

[Suggested change]: "An AC verifier who is not amongst the named
servers/services SHOULD reject the AC."
 
-----------------------------------------------
Proposed tweak 3

[Quoting from the AC Draft]: "4.5 Profile of AC issuer's PKC 
The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage extension
in the PKC MUST NOT explicitly indicate that the AC issuer's public key
cannot be used to validate a digital signature. In order to avoid confusion
regarding serial numbers and revocations, an AC issuer MUST NOT also be a
PKC Issuer. That is, an AC issuer cannot be a CA as well. So, the AC
issuer's PKC MUST NOT have a basicConstraints extension with the CA BOOLEAN
set to TRUE. "

[Carlin]: So the AA's PKC cannot also be a CA's PKC.  But could the AA's
public key be the same as a CA's public key, or even a public key used to
sign simple email?  Nothing here seems to preclude this, so I suppose this
is permissible (but probably not desirable).  I suggest that the following
words be added to section 4.5 of the Draft:

[Suggested addition]: "It is considered to be poor practice for an AC
Issuer's keypair to be used in any context other than that of an AC Issuer."

-----------------------------------------------
Proposed tweak 4

[Quoting from the AC Draft]: "7.4 AA Controls
<snip>
When AAControls are used, the following additional checks on an AA's
   PKC chain MUST all succeed for the AC to be valid:

   1.   Some CA on the ACs certificate path MUST be directly trusted to
        issue PKCs which precede the AC issuer in the certification
        path, call this CA the "AA CA".
   2.   All PKCs on the path from the AA CA down to and including the
        AC issuer's PKC MUST contain an AAControls extension; however,
        the AA CA's PKC 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 check
        MUST be applied to the set of attributes following attribute
        decryption, and the id-aca-encAttrs type MUST also be checked.

[Carlin]: Due to cross certification or multiple trusted roots, there can be
more than one CA that meets the definition of "AA CA" in check #1.  In this
case, should checks #2 and #3 be interpreted to mean that there must exist
at least one certificate path that passes both these checks?

[Suggested change]: "When AAControls are used, the following additional
checks MUST all succeed on at least one AA PKC chain for the AC to be
valid:"

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

> From: Michael Myers [mailto:[email-masked]]
> Sent: Tuesday, October 24, 2000 9:09 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Request for consensus call on AC draft
> 
> 
> Chairs,
> 
> The multi-authority AC model is ultimately the more likely 
> while the single
> authority model has near term practical utility.
> 
> Stephen Farrell's text is responsive to this polarization.  I 
> propose a
> structured consensus call on that text.
> 
> It's otherwise predictable that this issue will come to the 
> floor in San
> Diego with a likelihood it'll go back to the list anyway.  I 
> for one would
> just as soon avoid that given all the bandwidth already spent 
> on this issue.
> 
> Mike
> 

Date: Wed, 25 Oct 2000 08:48:23 -0500
From: Dale Gustafson <[email-masked]>
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Hi Bob,

A couple of comments:

1) I meant the group clearly appears to agree there is a "need" for the functionality of what has been called an Attribute Certificate (e.g., a tamper-resistant data object containing application or user group specific data), not the separate AC form described in the draft.  Obviously there is substantial agreement on that particular form as well since we do have a well-crafted draft document on the table.

2) Didn't intend to imply the typical user would have only one or two key pairs / certificates.

3) A complex AC (that includes an embedded PKC) hasn't been discussed much.  It's not the same as an ID certificate that includes special attributes.  The distinction between AC and PKC is well articulated in the draft and I think would apply here as well.  A combo object has distinct implications beyond that.  I suggest we don't have the bandpass to discuss this right now.

4) At this time, I think it's much more important to make an effort to find / enhance the value of the approach outlined in the draft and resist the temptation to dismiss it.  It's too easy to find fault with a good, new idea before it's had a chance to become fully developed.

5) At first I was a little troubled by the implication that the only way to to move ahead in a timely fashion with this stuff is for individual vendors to create essentially proprietary solutions, albeit using all standards-defined components.  But it's more important to get the necessary interoperability standards in place -- so the real issue is whether others rally around your proposal and "how long it takes" for that to happen.  Good Luck.

Best Regards,

--dg

Bob Jueneman wrote:

> Dale,
>
> You are of course entitled to your opinion,  and who knows -- you might even be correct in your assertions!  Accurate crystal balls are hard to come by..  But I would submit that the discussions on this list indicate that there is far from unanimous consensus as whether or not there is a genuine need for attribute certificates.  Certainly my position at present is that I see NO such compelling need, and I am highly skeptical of the wisdom of adding more and more complexity on top of a PKI that field experience is showing to be of daunting complexity  when it comes to implementing it and making it all work.
>
> Saying that does NOT mean that I don't see the need for a Privilege Management Infrastructure (PMI) , however -- far from it.  In fact, it is increasingly obvious (at least to me), that PMI is going to be where the real action is, and that the vision of say five to ten years ago of stranger-to-stranger electronic commerce being facilitated by Identity certificates seems less and less likely to materialize.  (The problem, of course, is that even if I know beyond a shadow of a doubt what someone's name is, and even if that name is globally unique, that doesn't mean that he has any money in the bank, or that he is particularly trustworthy, or that I know where to send the sheriff after he drives off with my Maserati demonstrator car and never returns, leaving his electronic driver's license with me as some kind of collateral.)
>
> But please allow me to break apart your hypothesis line by line -- maybe we can identity some individual elements that we can agree on, and move forward from there.
>
> >Al, Polar,
> >
> >Let me also try to summarize.
> >
> >I think we've arrived at the current state because the group genuinely perceives
> >the need for Attribute Certificates.
>
> As I said, that level of consensus is far from obvious, and there is NO marketing data I am aware of that would support such a contention.
>
> >I think there is a common sense that there
> >is or will soon be a compelling need for secure applications to distribute and
> >utilize tamper-resistant, application specific data elements within the global
> >PKI.
>
> On the other hand, I DO agree with that statement -- individual applications really need to be able to specify or determine which  end-entities are entitled to perform certain functions.  One way to do this is to use a directory that is trusted by the Relying Party, and to look up the relevant attributes within that directory.  Unfortunately, although it might be technically possible to harmonize the schemas and eventually federate multiple directories defining such levels of privilege, at present it seems to be an impossible management problem to solve.  So we DO need to distribute "attributes" (rights) within a PKI/PMI infrastructure -- no argument about that.  The question is whether that implies the need for Attribute Certificates per se.
>
> >It is envisioned that authoritative entities will deploy Attribute
> >Authority systems that manage the life cycle of these special certificates.
>
> I could agree with that.
>
> >We
> >further speculate that each authoritative entity will work with it's various
> >constituents to define the form, fit, and function of a specific attribute
> >certificate that will be utilized by a well-defined set of applications.  This
> >application specific certificate's format and content will be updated from time
> >to time as the applications evolve, etc. under some management process
> >controlled by the authoritative entity.
>
> If by that you were to mean a standard X.509 v3 cert that contained specific rights attributes, I would agree.
> >
> >Past experience has strongly suggested what NOT to do but has not necessarily
> >indicated the most appropriate course of action.
> >
> >Logically, and assuming the need is real, there are at least three possible
> >approaches:
> >
> >1. Embed the Attribute Certificate information in x.509 v3 Identification
> >Certificates
>
> This is of course my strong preference.
> >
> >Each industry or market group (banking, finance, insurance, communications,
> >government, et. al.) can create a set non-critical extensions that allow their
> >application-specific information to be carried in a common public key
> >certificate or certificates.
>
> Agreed.  Actually, what is likely to happen is that individual enterprises will define a set of rights that will fit their needs, and then they will try to communicate those rights to someone else, who will have used a slightly different set of semantics and/or syntactic definitions, and those will then have to be harmonized with policy-based controls applied at each Relying Party.  Then some of the industry leaders will get together and define a common schema for such rights, so that everyone can interpret all of the other certificates, assuming the trust the issuing CA.
> >
> >In the near term (at least) this is the most effective approach because each
> >design can take a free ride on all of the PKI infrastructure that is being put
> >in place at great expense.
>
> Exactly.
>
> >The downside is that the combined certificate
> >retains all of the properties of a public key certificate irrespective of
> >whether that makes sense for the attribute information and the secure
> >application(s) that will utilize it.
>
> Well, maybe and maybe not.  The assumption you are making is that only one certificate is created, that contains everything.  That might be desirable, especially for relatively static attributes, but it isn't absolutely necessary.  For that matter, the certificate that specifies a user's rights might not contain the user's DN at all -- it certainly wouldn't have to.  But on the other hand, the general requirement for auditing is probably going to require that the user be identified somehow, which at a minimum means a user ID.  And requiring the user to enter a user ID requires a password to confirm it. And although server-enforced passwords have some value as a means of providing multifactor authentication and to prevent a complete collapse if the user's private key is compromised, it seems rather a nuisance to enter all of this when the same information could easily be included int eh certificate itself.
> >
> >2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate
> >
> >This has been suggested in the past but was not well received, likely because it
> >was obvious that significant additional overhead would be added to each
> >attribute certificate but it could not be shown that such a close coupling of
> >the attribute certificate and public key certificate would have technical merit
> >that justifies the cost.  Problems of keeping the ID certificate and attribute
> >together are eliminated but there are still two certificate chains.  The
> >infrastructure for and deployment of ID certificates can be utilized "as is".
>
> This is just the flip side of putting the rights information int he X.509 cert, but this adds the expense of validating two certificate chains.
> >
> >3. Provide a Link from the Attribute Certificate to the Public Key Certificate
> >
> >This approach appeared at the outset to be the most elegant and, most
> >importantly, appeared to be the most flexible.  It has just now become more
> >apparent that creating a reliable, "dynamic" link between the two certificates
> >is difficult.  This has been discussed at length recently.
>
> If people can really, really establish the need for an independent attribute certificate, which I am prepared to accept in theory if not in practice, then at a minimum this coupling seems to require a cryptographic linkage between the attribute cert and the PKI cert.  And that very linkage means that the attribute cert effectively expires or is revoked along with the PKI certs, since the linkage would  no longer be valid.
> >
> >Perhaps others can recall other approaches that have been suggested.
>
> The fourth approach, which really hasn't been discussed, is simply to put the "rights" attribute in a directory which is trusted by the Relying Party.  That certainly works, but it lacks a bit of cryptographic elegance, of course.  Now, someone will probably say that the directory isn't sufficiently trusted, to which I would say that the attributes in the directory could be signed. Now we are almost back to an attribute cert, except that it is the Relying Party's organization that is doing the signing, so presumably the checking is simpler.
> >
> >My sense is that the real value of a separate attribute certificate is that it
> >invites others with specific application expertise to join the process "earlier"
> >without making everyone's work overly complex -- if (and only if) that's true,
> >will people be willing to pay some reasonable price to accomplish the necessary
> >up-front planning.
> >
> >What appears to be missing is a framework that enables secure application
> >builders to understand when they can "have at it" knowing they have a reasonably
> >stable environment around them.  That is, allows and encourages their innovative
> >work to move forward in  parallel with that of other industry and market
> >groups.  In order for that to happen, there needs to be a common understanding
> >that the basic problem is bounded and within range.
> >
> >A framework for attribute certificates might better define many of the things we
> >have recently discussed:
> >
> > - encode / decode methods supported (ASN.1, XML, other)
> > - commonly used data elements
> > - encryption methods (selected attributes, full certificate)
> > - delivery methods (SSL, S/MIME, directories, other)
> > - certificate path creation / signature validation
> > - certificate status checking
> > - summary:  distinction between ID certificates and attribute certificates
> > - other ?
> >
> >Perhaps this has already been done elsewhere.  I suspect even an all-knowing
> >expert would have to look long and hard at the overall requirements for
> >attribute certificates before deciding that a single approach would suffice.
> >
> >Comments?
> >
> >Best Regards,
> >
> >Dale Gustafson
>
> You might guess that I would not have been quite so sure of myself in this area if we hadn't already done something in this area, and you would be right.  I believe, but don't know the details, that some other vendors have done similar things.
>
> But Novell has already issued several million certificates that provide the necessary infrastructure to support these kinds of systems, and we are willing to license the technology to anyone who will agree to honor the semantics of the attributes, in particular what we refer to as the certificate quality portion of the Novell Security Attributes.
>
> For more information, cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm.  For those of you who may have looked at that document previously, it hasn't changed, but I am about to update it, and so I would be delighted to receive comments and suggestions for improvements.
>
> Regards,
>
> Bob
>
> Robert R. Jueneman
> Security Architect
> Novell, Inc. -- the leading provider of Net services software.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-11.txt
Date: Wed, 25 Oct 2000 06:16:07 -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 (TSP)
	Author(s)	: C. Adams, P. Cain, D. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-11.txt
	Pages		: 24
	Date		: 24-Oct-00
	
A time stamping service supports assertions of proof that a datum 
existed before a particular time. This document describes the format 
of a request sent to a Time Stamping Authority (TSA) and of the 
response that is returned. It also establishes several security-
relevant requirements for TSA operation, with regards to processing 
requests to generate responses. A TSA may be operated as a Trusted 
Third Party (TTP) service, though other operational models may be 
appropriate, e.g. an organization might require a TSA for internal 
time stamping purposes. 

Non-repudiation services [ISONR] require the ability to establish the 
existence of data before specified times. This protocol may be used as 
a building block to support such services. An example of how to prove 
that a digital signature was generated during the validity period of 
a 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-11.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-11.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-11.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-11.txt

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

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

--OtherAccess--

--NextPart--

Sender: [email-masked]
Date: Tue, 24 Oct 2000 16:05:26 -0700
From: Michael Sierchio <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: FW: I-D ACTION:draft-legg-ldapext-component-matching-00.txt

Steven Legg wrote:

The source of many evils, including URL wrap:
	X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0

> Behalf Of [email-masked]
> Sent: Tuesday, 24 October 2000 21:10

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-legg-ldapext-component-matching-00
> .txt

http://www.ietf.org/internet-drafts/draft-legg-ldapext-component-matching-00.txt

Reply-To: <[email-masked]>
From: "Steven Legg" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: FW: I-D ACTION:draft-legg-ldapext-component-matching-00.txt
Date: Wed, 25 Oct 2000 09:48:32 +1100
Importance: Normal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, 24 October 2000 21:10
To: IETF-Announce: ;
Cc: [email-masked]
Subject: I-D ACTION:draft-legg-ldapext-component-matching-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: LDAP & X.500 Component Matching Rules
	Author(s)	: S. Legg
	Filename	: draft-legg-ldapext-component-matching-00.txt
	Pages		: 44
	Date		: 23-Oct-00

The syntaxes of attributes in an LDAP or X.500 directory range from
simple data types, such as text string, integer, or boolean, to
complex structured data types, such as the syntaxes of the directory
schema operational attributes.  The matching rules defined for the
complex syntaxes, if any, usually only provide the most immediately
useful matching capability.  This document defines generic matching
rules that can match any user selected component parts in an
attribute value of any arbitrarily complex attribute syntax.  Generic
string encodings for attribute and assertion values of arbitrary
syntax are also defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-legg-ldapext-component-matching-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-legg-ldapext-component-matching-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-legg-ldapext-component-matching-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.

Date: Tue, 24 Oct 2000 15:31:51 -0400 (EDT)
From: Paul Koning <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

>>>>> "Tom" == Tom Gindin/Watson/IBM <[email-masked]> writes:

 Tom> By the way, a typical US driver's license is also a Permanent
 Tom> Identifier with an assignment authority of C=US, ST=xx,
 Tom> O=Division of Motor Vehicles (or DMV).  The opaqueness and
 Tom> meaningless to outsiders of a driver's license number (at least
 Tom> in those states which don't use SSN's) are typical features of
 Tom> PI's.

Clearly SSNs are neither opaque nor meaningless, but there are also
non-SSN examples where the same is true.

New Hampshire uses a simple and well-known algorithm to derive license
numbers; if you know a person's name and birthdate, you get the number
directly.  For example, assuming your birthdate is April 1, 1952,
you'd get 04TGN52011 (or, with low probability, 04TGN52012).

	paul

From: Carlisle Adams <[email-masked]>
To: "'todd glassey'" <[email-masked]>
Cc: Denis Pinkas <[email-masked]>, IETF-PXIX <[email-masked]>
Subject: The Time Stamp Protocol (v10)...
Date: Tue, 24 Oct 2000 15:19:46 -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_01C03DEF.5F0205A0
Content-Type: text/plain

Hi Todd,

> ----------
> From: 	todd glassey[SMTP:[email-masked]]
> Sent: 	Tuesday, October 24, 2000 12:34 PM
> To: 	Denis Pinkas; IETF-PXIX
> Subject: 	Re: TSP. Version 10
> 
> What I suggest is rather than advancing this effort to a Draft Standard,
> that some thought of what the protocol is supposed to accomplish in the
> real
> world and under what constraints it must be operated to accomplish these
> things be added to the draft as well as the processes it already
> memorializes.
 
The plan is NOT to advance this effort to "Draft Standard", but rather to
"Proposed Standard" (i.e., the first step in the standardization process,
not the second -- although this has taken so long it's surprising we're not
at the third step by now!).

As far as I can tell from occasional glimpses at the never-ending threads on
time stamping, you are the only one asking for the above additions to the
draft.  Not only does no one else seem interested in these "use models",
constraints, etc., but such things appear in no other PKIX documents either.
Is it, perhaps, a fair observation that "rough consensus" is not on your
side with respect to this topic?  In fact, it seems to me that "rough
consensus" is rather on the other side, and so is "running code", which
suggests to me that we're done (i.e., this document can be submitted to IESG
as-is).

> With that said I am off to rewrite the opening paragraphs of the draft - I
> will post them shortly!
 
The first couple of sentences of your posting go as follows:  "I figure this
will start several small brush fires and that is not my intent. So I
apologize to the group at the outset ...".  Regardless of the merits of your
proposed text, I think it's safe to say that the absolute *last* thing this
document needs at this point is new opening paragraphs that "start several
small brush fires".

Let's submit the -10.txt version to IESG.  There will be lots of time to
revise the opening paragraphs (if the group really feels this is necessary!)
in the future when we try to progress from Proposed to Draft.  Furthermore,
it has been suggested in the past that you write a separate Internet Draft
describing the "use models", constraints, etc., that you feel are an
important addition to this specification.  I whole-heartedly support this:
let this separate document be debated and advanced (according to rough
consensus) on its own, and let the protocol specification progress now.

Carlisle.

------_=_NextPart_001_01C03DEF.5F0205A0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>The Time Stamp Protocol (v10)...</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Todd,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">todd =
glassey[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Tuesday, October 24, 2000 12:34 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Denis Pinkas; =
IETF-PXIX</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: TSP. Version 10</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What I suggest is rather than =
advancing this effort to a Draft Standard,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that some thought of what the =
protocol is supposed to accomplish in the real</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">world and under what constraints it =
must be operated to accomplish these</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">things be added to the draft as well =
as the processes it already</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">memorializes.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The plan =
is NOT to advance this effort to &quot;Draft Standard&quot;, but rather =
to &quot;Proposed Standard&quot; (i.e., the first step in the =
standardization process, not the second -- although this has taken so =
long it's surprising we're not at the third step by now!).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As far as =
I can tell from occasional glimpses at the never-ending threads on time =
stamping, you are the only one asking for the above additions to the =
draft.&nbsp; Not only does no one else seem interested in these =
&quot;use models&quot;, constraints, etc., but such things appear in no =
other PKIX documents either.&nbsp; Is it, perhaps, a fair observation =
that &quot;rough consensus&quot; is not on your side with respect to =
this topic?&nbsp; In fact, it seems to me that &quot;rough =
consensus&quot; is rather on the other side, and so is &quot;running =
code&quot;, which suggests to me that we're done (i.e., this document =
can be submitted to IESG as-is).</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">With that said I am off to rewrite the =
opening paragraphs of the draft - I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will post them shortly!</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The first =
couple of sentences of your posting go as follows:&nbsp; =
&quot;</FONT><FONT SIZE=3D2 FACE=3D"Arial">I figure this will start =
several small brush fires and that is not my intent. So I apologize to =
the group at the outset ...</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Times New Roman">&quot;.&nbsp; Regardless of the merits of your =
proposed text, I think it's safe to say that the absolute *last* thing =
this document needs at this point is new opening paragraphs that =
&quot;start several small brush fires&quot;.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Let's =
submit the -10.txt version to IESG.&nbsp; There will be lots of time to =
revise the opening paragraphs (if the group really feels this is =
necessary!) in the future when we try to progress from Proposed to =
Draft.&nbsp; Furthermore, it has been suggested in the past that you =
write a separate Internet Draft describing the &quot;use models&quot;, =
constraints, etc., that you feel are an important addition to this =
specification.&nbsp; I whole-heartedly support this:&nbsp; let this =
separate document be debated and advanced (according to rough =
consensus) on its own, and let the protocol specification progress =
now.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03DEF.5F0205A0--

From: "todd glassey" <[email-masked]>
To: <[email-masked]>, "Denis Pinkas" <[email-masked]>
Subject: The rewritten opening statement and some thoughts on the goals!
Date: Tue, 24 Oct 2000 10:26:54 -0700

Hi all - and Denis,
I figure this will start several small brush fires and that is not my
intent. So I apologize to the group at the outset - but let me share a
bizarre concept with you - 'We humans are the problem, not the answer with
Digital Evidence Models' and by using Time Stamping digital trust operators
are supposed to address this.

Digital Evidence models are made weaker by having to have humans testify as
to their validity. Its a simple concept.  You see machines don't have any
consciousness, so they cant "lie" per se, but we as humans can, and do - all
the time. So any proofing model that does not include methods of abstracting
its reliability away form "Human Reliance" is broken (IMHO) and that is
really that.  What I think that this means is that the Time Stamps that are
produced by such a system have no way of separating themselves form the
system they were created on or the people that ran that system, and this is
the key flaw to the big picture.

And as long as I am talking about qualifying the parametric data the TSP
uses, we need to have a new document, a timing practices statement added to
the trust model.  This defines the proofing models for where the time data
came from, and needs to be a part of the evidentiary trail and since the
draft ignores the concept of  a Timing Practices Statement.

So I suggest something like the following to clean up the opening
statements:
-------------------------
Digital evidentiary models require that digital events have some a method of
stipulating the time in which a digital event took place. These models also
require the ability to be run in computers unattended as part of a larger
audit process and proofing system. Because of these emerging requirements,
this Draft proposes a distributed method of associating time and event data.
This document then describes this complete protocol  to provide this
Distributed
or TTP based Time Stamping.

The facility of the TSP provides a proofing process to demonstrate that a
digital
event  occurred or existed as per the policies of the Authority running the
Time
Stamping (TS) System.  Thus it can be used to satisfy both policy based
decisions
as well as stand for producing a basic level of evidentiary content. The TS
Draft
defines the infrastructure or format of a request  sent to a  Time Stamping
Authority
(TSA) and of the response that is returned. It also establishes several
security-relevant
requirements  for TSA operation, with regards to processing requests to
generate
responses.

The protocol defined herein is envisioned to be typically operated as a
Trusted Third
Party (TTP,  but its protocol (or API) may be implemented as an embedded
system
to address  single platform use of a time stamping.

< and then the ISO NR words!>

Non-repudiation services [ISONR] require the ability to establish the
existence of data before specified times. This protocol may be used as
a building block to support such services. An example of how to prove
that a digital signature was generated during the validity period of
a public key certificate is given in an annex.

Importance: Normal
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: "David P. Kemp" <[email-masked]>
Cc: [email-masked]
From: "Tom Gindin/Watson/IBM" <[email-masked]>
Date: Tue, 24 Oct 2000 13:54:29 -0400

     By the way, a typical US driver's license is also a  Permanent
Identifier with an assignment authority of C=US, ST=xx, O=Division of Motor
Vehicles (or DMV).  The opaqueness and meaningless to outsiders of a
driver's license number (at least in those states which don't use SSN's)
are typical features of PI's.

          Tom Gindin

"David P. Kemp" <[email-masked]> on 10/23/2000 07:38:37 PM

To:   [email-masked]
cc:

> From: Polar Humenn <[email-masked]>
>
> If we take this model. You don't just check the attribute certificate
> (i.e. the drivers license). You check some identifying information on
that
> license that ties the certificate to the person giving it to you. A
> picture, some bio information, (age, height, weight, eye color) (however,
> incorrect, I might add :) that correlates the "certificate" to the
entity.
> Those are *identifying* attributes, not authorization attributes. In the
> PKI space, the *identifying* attribute is the public key.
>
> A drivers license has only has one authorization attribute. The privilege
> to drive a car.
>
> And that certificate is really issued to an entity that matches the
> *identifying* attributes. On that certificate, the entity may be given a
> name, an address, and possibly a number, for easy look up. That look up
is
> only relevant in the DMV's own directory, not in the post office's
> directory, or at the hospital.

It's always dangerous to use analogies, but in this example, the driver's
license is an identity certificate.  The bio information (picture, height
weight, hair color, hair presence :-) is, as you say, the "public key".
The date of birth is a certified attribute which can legitimately be
used, contrary to Aram's claim, for purposes other than the privilege
to drive a car.  The common name and the number are part of the DN, which
in full, might be: "c=US, st=CA, o=DMV, sn=S-678-109-876-432, cn=John
Smith".
One does not have to be very imaginative to suppose that VeriCertCo and
DigSigZone and PkiBoys could all issue certificates for each of the 50
states, or for each of the state agencies, or for each person licensed
to drive in the US, and that a compelling case for fraud or malfeasance
could be made if there were a single collision in names following the
"USDriverPerson" (analogous to InetOrgPerson :-) schema.

> The amusement park "would like to" include sufficient identifying
> information (such as a name and a driver license number), but, it cannot,
> because by the standard, it is limited to the DN given, "CN=John Smith,
> O=Smith". If attribute certificate adds anything else to the DN, then the
> correlation fails where it should succeed.
>
> If there is insufficient information to begin with (i.e. capability for
two
> John Smith's one with a driver's license, and a Bob Smith's 13 year old
> named John) then the correlation can succeed where it should fail.
>
> Isn't this called a hole?

As above, no.

The driver's license number doesn't have to be meaningful outside the
DMV's database, it only has to be a unique identifier which the DMV
will not issue to some other person.  I use the same authentication
credential to request a music download attribute cert (paid for with
e-cash or a regular credit card) and to perform the downloads; the
identifying information is irrelevant as long as its unique.  If
I get a new ID cert with a new public key from the DMV, I can still
use all my old attribute certs.  And if the relying parties ignore
the CN when matching ACs to PKCs, I can even change my name.

Dave

Date: Tue, 24 Oct 2000 13:43:22 -0400
From: "Edward A. Feustel" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

<html><head></head><body>
<blockquote type="cite" cite="mid:v04220820b61a5d8e1f99@%5B171.78.30.107%5D">I do not believe that the
 proposed document: "X.509 Certificate Policy for the Federal Bridge Certification
 Authority (FBCA) Version 1.06, October 23, 2000" which can be obtained through NIST PKI Office has been mentioned. </blockquote>
Under section 3.1.4, Uniqueness of Names:<br>
" Name uniqueness across the FPKI (Federal Public Key Infrastructure) must
 be enforced. The FBCA, Agency CAs and RAs shall enforce name uniqueness
 within the X.500 name space which they have been authorized. When other
 name forms are used, they too must be allocated such that name uniqueness
 across the FPKI is ensured.<br>
<br>
The FBCA and Agency CAs shall document in their respective CPSs (Certificate Practice Statements) :<br>
<ul>
  <li>What name forms shall be used,</li>
  <li>How the FBCA,&nbsp; Agency CAs and RAs will interact with the FPKIPA to ensure this is accomplished, and</li>
  <li>How they will allocate names within the Subscriber community to guarantee
 name uniqueness among current and past Subscribers (e.g., if ' Joe Smith'
 leaves a CA's Community of Subscribers, and a new, different 'Joe Smith'
 enters the community of Subscribers, how will these two people be provided
 unique names)."</li>
</ul>
<br>
Under 3.1.5 Name claim dispute resolution procedure<br>
<br>
" The FPKIPA shall resolve any name collisions brought to its attention that may affect interoperability using the FBCA."<br>
<br>
Assuming this policy is signed off, if a community wants to do business with the Feds,<br>
they will need to keep their PKI aligned with the Feds in terms of using unique names.<br>
<br>
Ed Feustel<br>
<blockquote type="cite" cite="mid:v04220820b61a5d8e1f99@%5B171.78.30.107%5D"><br>
</blockquote>
</body>
</html>

Date: Tue, 24 Oct 2000 11:08:23 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

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

--=_EFB72E83.53325C07
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Someone complained that the page I cited locked up his browser, for =
unknown reasons.

If that happens, try http://developer.novell.com/repository/attributes/pkis=
v10.pdf

Regards,

Bob

--=_EFB72E83.53325C07
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN-TOP: 2px; FONT: 8pt MS Sans Serif; MARGIN-LEFT: =
2px">
<DIV>Someone complained that the page&nbsp;I cited locked up his browser, =
for=20
unknown reasons.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If that happens, try <A=20
href=3D"http://developer.novell.com/repository/attributes/pkisv10.pdf">http=
://developer.novell.com/repository/attributes/pkisv10.pdf</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Bob</DIV></BODY></HTML>

--=_EFB72E83.53325C07--

From: "todd glassey" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "IETF-PXIX" <[email-masked]>
Subject: Re: TSP. Version 10
Date: Tue, 24 Oct 2000 09:34:08 -0700

Denis - I want to rewrite the opening paragraphs and will have my versions
of them out to you and to the list in an hour or so..

Please understand I am not against this as a TSP, it is a very well thought
out scenario but I as you are well aware have some fundamental questions
about

    a)    how it is to be used to satisfy any digital evidence models and
which ones it ascribes to.
    b)    how it is totally leveraged against something it does not address
in the slightest, that being the Timing Practices Statement of the Time
provider, and how this is propagated into the marques that the TSA produces.

What I suggest is rather than advancing this effort to a Draft Standard,
that some thought of what the protocol is supposed to accomplish in the real
world and under what constraints it must be operated to accomplish these
things be added to the draft as well as the processes it already
memorializes.

With that said I am off to rewrite the opening paragraphs of the draft - I
will post them shortly!

Todd

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "IETF-PXIX" <[email-masked]>
Sent: Friday, October 13, 2000 4:02 AM
Subject: TSP. Version 10

>
> A new version of the Time Stamping Protocol has been placed on the web
> server. A URL for this Internet-Draft is:
>
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-10.txt
>
> This version addresses the comments received during the IESG last call
> period.
>
> Besides the changes made to accommodate the 24 comments raised by Russ
> Housley, the abstract and the introduction have been modified, by myself
and
> Steve Kent, in order to address some of the concerns raised by Todd
Glassey.
>
> If there are no major editorial errors, this version should (hopefully) be
> the version to be published as an RFC. Should there be a few minor errors
> left, please tell me, since they can still be corrected directly by myself
> when the RFC editor transforms the document into an RFC (there a 48 hours
> time window to do so).
>
> FYI, the abstract and the introduction are now as follows:
>
> Abstract
>
> A time stamping service allows to prove that a datum existed before
> a particular time. This document describes the format of a request
> sent to a Time Stamping Authority (TSA) and of the response that is
> returned. It also establishes several security-relevant requirements
> for TSA operation, with regards to processing requests to generate
> responses. A TSA may be operated as a Trusted Third Party (TTP)
> service, though other operational models may be appropriate, e.g. an
> organization might require a TSA for internal time stamping purposes.
>
> Non-repudiation services [ISONR] require the ability to establish the
> existence of data before specified times. This protocol may be used as
> a building block to support such services. An example of how to prove
> that a digital signature was generated during the validity period of
> a public key certificate is given in an annex.
>
> (...)
>
> 1.  Introduction
>
> (...)
>
> This standard does not establish overall security requirements for
> TSA operation, just like other PKIX standards do not establish such
> requirements for CA operation. Rather, it is anticipated that a TSA
> will make know to prospective clients the policies it implements to
> ensure accurate time stamp generation, and clients will make use of
> the services of a TSA only if they are satisfied that these policies
> meet their needs.
>
>
> Denis
>

From: Michael Myers <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Request for consensus call on AC draft
Date: Tue, 24 Oct 2000 09:09:26 -0700

Chairs,

The multi-authority AC model is ultimately the more likely while the single
authority model has near term practical utility.

Stephen Farrell's text is responsive to this polarization.  I propose a
structured consensus call on that text.

It's otherwise predictable that this issue will come to the floor in San
Diego with a likelihood it'll go back to the list anyway.  I for one would
just as soon avoid that given all the bandwidth already spent on this issue.

Mike

Reply-To: <[email-masked]>
From: "Steven Legg" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: comments on draft-ietf-pkix-ldap-schema-01.txt
Date: Tue, 24 Oct 2000 15:22:52 +1100
Importance: Normal

David & Tim,

> From: David Chadwick [mailto:[email-masked]]
> Sent: Sunday, 22 October 2000 2:08
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: comments on draft-ietf-pkix-ldap-schema-01.txt
> 
> 
> From:           	[email-masked]
> To:             	[email-masked]
> Subject:        	comments on draft-ietf-pkix-ldap-schema-01.txt
> Date sent:      	Thu, 21 Sep 2000 14:18:15 -0400
 
[snip]

> > 
> > Section 3.2:
> > ------------
> > In the BNF for "GeneralName", a single whitespace character appears
> > (e.g. "rfc822 +").  Was this intentional?  It seems out of
> 
> I dont really mind either way here. I will let Steven be the 
> authoritative voice on this

I'll strip out the spaces in the next revision.

> 
> > place/misleading.
> > 
> > Editor's note on AuthorityKeyIdentifier:
> > ----------------------------------------
> > Seems to me that authority issuer name and authority certificate
> > serial number could be useful.
> 
> What we really need is some LDAP server vendor (IBM??) to 
> implement these matching rules and to give some feedback about 
> which fields are really useful for users to use. At the moment we 
> can only guess at what people will want to use in practice.
> 
> 
> > 
> > Section 4.1:
> > ------------
> > In the BNF for "CertificateListExactAssertion", the "$" after "Time"
> > is OPTIONAL, correct?  It should only be needed if
> > "DistributionPointName" is specified, I think.
> 
> Yes we could change the ABNF to put the  $ inside the DP 
> construct.

I'll make the "$" conditional on DistributionPointName being present.

Regards,
Steven

Date: Mon, 23 Oct 2000 05:39:47 -0700
From: Aram Perez <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: [email-masked]

David Kemp wrote:

[snip]
> It's always dangerous to use analogies, but in this example, the driver's
> license is an identity certificate.  The bio information (picture, height
> weight, hair color, hair presence :-) is, as you say, the "public key".
> The date of birth is a certified attribute which can legitimately be
> used, contrary to Aram's claim, for purposes other than the privilege
> to drive a car. 

I never claimed that is could not be "legitimately" used, and I did state
that it is accepted business practice (in the "real world). But a liquor
store or cinema only asks me for my license if I don't meet certain
criteria, i.e., if I look too young. But I've reached that level of maturity
where I do not ever get asked to present my license :-(  In the PKIX world,
I *must* present my certificate every time, whether "I look too young" or
not. And if any of the attributes change (my weight), then my certificate is
no longer valid. Should a liquor store or a cinema ask to see my license,
they do not care whether my apparent weight matches what my driver license
states, only whether my picture is a "close enough resemblance", and if it
is, then I am old enough (based on the date of birth). You can't ignore
attributes that are no longer valid or have a "close enough resemblance" in
the PKIX world.

Regards,
Aram Perez

[snip]

Date: Mon, 23 Oct 2000 17:56:47 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Dale,  

You are of course entitled to your opinion,  and who knows -- you might even be correct in your assertions!  Accurate crystal balls are hard to come by..  But I would submit that the discussions on this list indicate that there is far from unanimous consensus as whether or not there is a genuine need for attribute certificates.  Certainly my position at present is that I see NO such compelling need, and I am highly skeptical of the wisdom of adding more and more complexity on top of a PKI that field experience is showing to be of daunting complexity  when it comes to implementing it and making it all work.

Saying that does NOT mean that I don't see the need for a Privilege Management Infrastructure (PMI) , however -- far from it.  In fact, it is increasingly obvious (at least to me), that PMI is going to be where the real action is, and that the vision of say five to ten years ago of stranger-to-stranger electronic commerce being facilitated by Identity certificates seems less and less likely to materialize.  (The problem, of course, is that even if I know beyond a shadow of a doubt what someone's name is, and even if that name is globally unique, that doesn't mean that he has any money in the bank, or that he is particularly trustworthy, or that I know where to send the sheriff after he drives off with my Maserati demonstrator car and never returns, leaving his electronic driver's license with me as some kind of collateral.)

But please allow me to break apart your hypothesis line by line -- maybe we can identity some individual elements that we can agree on, and move forward from there.

>Al, Polar,
>
>Let me also try to summarize.
>
>I think we've arrived at the current state because the group genuinely perceives
>the need for Attribute Certificates.  

As I said, that level of consensus is far from obvious, and there is NO marketing data I am aware of that would support such a contention.

>I think there is a common sense that there
>is or will soon be a compelling need for secure applications to distribute and
>utilize tamper-resistant, application specific data elements within the global
>PKI.  

On the other hand, I DO agree with that statement -- individual applications really need to be able to specify or determine which  end-entities are entitled to perform certain functions.  One way to do this is to use a directory that is trusted by the Relying Party, and to look up the relevant attributes within that directory.  Unfortunately, although it might be technically possible to harmonize the schemas and eventually federate multiple directories defining such levels of privilege, at present it seems to be an impossible management problem to solve.  So we DO need to distribute "attributes" (rights) within a PKI/PMI infrastructure -- no argument about that.  The question is whether that implies the need for Attribute Certificates per se.

>It is envisioned that authoritative entities will deploy Attribute
>Authority systems that manage the life cycle of these special certificates.  

I could agree with that.

>We
>further speculate that each authoritative entity will work with it's various
>constituents to define the form, fit, and function of a specific attribute
>certificate that will be utilized by a well-defined set of applications.  This
>application specific certificate's format and content will be updated from time
>to time as the applications evolve, etc. under some management process
>controlled by the authoritative entity.

If by that you were to mean a standard X.509 v3 cert that contained specific rights attributes, I would agree.
>
>Past experience has strongly suggested what NOT to do but has not necessarily
>indicated the most appropriate course of action.
>
>Logically, and assuming the need is real, there are at least three possible
>approaches:
>
>1. Embed the Attribute Certificate information in x.509 v3 Identification
>Certificates

This is of course my strong preference.
>
>Each industry or market group (banking, finance, insurance, communications,
>government, et. al.) can create a set non-critical extensions that allow their
>application-specific information to be carried in a common public key
>certificate or certificates.

Agreed.  Actually, what is likely to happen is that individual enterprises will define a set of rights that will fit their needs, and then they will try to communicate those rights to someone else, who will have used a slightly different set of semantics and/or syntactic definitions, and those will then have to be harmonized with policy-based controls applied at each Relying Party.  Then some of the industry leaders will get together and define a common schema for such rights, so that everyone can interpret all of the other certificates, assuming the trust the issuing CA.
>
>In the near term (at least) this is the most effective approach because each
>design can take a free ride on all of the PKI infrastructure that is being put
>in place at great expense.  

Exactly.

>The downside is that the combined certificate
>retains all of the properties of a public key certificate irrespective of
>whether that makes sense for the attribute information and the secure
>application(s) that will utilize it.

Well, maybe and maybe not.  The assumption you are making is that only one certificate is created, that contains everything.  That might be desirable, especially for relatively static attributes, but it isn't absolutely necessary.  For that matter, the certificate that specifies a user's rights might not contain the user's DN at all -- it certainly wouldn't have to.  But on the other hand, the general requirement for auditing is probably going to require that the user be identified somehow, which at a minimum means a user ID.  And requiring the user to enter a user ID requires a password to confirm it. And although server-enforced passwords have some value as a means of providing multifactor authentication and to prevent a complete collapse if the user's private key is compromised, it seems rather a nuisance to enter all of this when the same information could easily be included int eh certificate itself.
>
>2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate
>
>This has been suggested in the past but was not well received, likely because it
>was obvious that significant additional overhead would be added to each
>attribute certificate but it could not be shown that such a close coupling of
>the attribute certificate and public key certificate would have technical merit
>that justifies the cost.  Problems of keeping the ID certificate and attribute
>together are eliminated but there are still two certificate chains.  The
>infrastructure for and deployment of ID certificates can be utilized "as is".

This is just the flip side of putting the rights information int he X.509 cert, but this adds the expense of validating two certificate chains.
>
>3. Provide a Link from the Attribute Certificate to the Public Key Certificate
>
>This approach appeared at the outset to be the most elegant and, most
>importantly, appeared to be the most flexible.  It has just now become more
>apparent that creating a reliable, "dynamic" link between the two certificates
>is difficult.  This has been discussed at length recently.

If people can really, really establish the need for an independent attribute certificate, which I am prepared to accept in theory if not in practice, then at a minimum this coupling seems to require a cryptographic linkage between the attribute cert and the PKI cert.  And that very linkage means that the attribute cert effectively expires or is revoked along with the PKI certs, since the linkage would  no longer be valid.
>
>Perhaps others can recall other approaches that have been suggested.

The fourth approach, which really hasn't been discussed, is simply to put the "rights" attribute in a directory which is trusted by the Relying Party.  That certainly works, but it lacks a bit of cryptographic elegance, of course.  Now, someone will probably say that the directory isn't sufficiently trusted, to which I would say that the attributes in the directory could be signed. Now we are almost back to an attribute cert, except that it is the Relying Party's organization that is doing the signing, so presumably the checking is simpler.  
>
>My sense is that the real value of a separate attribute certificate is that it
>invites others with specific application expertise to join the process "earlier"
>without making everyone's work overly complex -- if (and only if) that's true,
>will people be willing to pay some reasonable price to accomplish the necessary
>up-front planning.
>
>What appears to be missing is a framework that enables secure application
>builders to understand when they can "have at it" knowing they have a reasonably
>stable environment around them.  That is, allows and encourages their innovative
>work to move forward in  parallel with that of other industry and market
>groups.  In order for that to happen, there needs to be a common understanding
>that the basic problem is bounded and within range.
>
>A framework for attribute certificates might better define many of the things we
>have recently discussed:
>
> - encode / decode methods supported (ASN.1, XML, other)
> - commonly used data elements
> - encryption methods (selected attributes, full certificate)
> - delivery methods (SSL, S/MIME, directories, other)
> - certificate path creation / signature validation
> - certificate status checking
> - summary:  distinction between ID certificates and attribute certificates
> - other ?
>
>Perhaps this has already been done elsewhere.  I suspect even an all-knowing
>expert would have to look long and hard at the overall requirements for
>attribute certificates before deciding that a single approach would suffice.
>
>Comments?
>
>Best Regards,
>
>Dale Gustafson

You might guess that I would not have been quite so sure of myself in this area if we hadn't already done something in this area, and you would be right.  I believe, but don't know the details, that some other vendors have done similar things.

But Novell has already issued several million certificates that provide the necessary infrastructure to support these kinds of systems, and we are willing to license the technology to anyone who will agree to honor the semantics of the attributes, in particular what we refer to as the certificate quality portion of the Novell Security Attributes.

For more information, cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm.  For those of you who may have looked at that document previously, it hasn't changed, but I am about to update it, and so I would be delighted to receive comments and suggestions for improvements.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.

Date: Mon, 23 Oct 2000 19:38:37 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: [email-masked]
Content-MD5: 4g82OrOAn8m/97vhvTUpUA==

> From: Polar Humenn <[email-masked]>
> 
> If we take this model. You don't just check the attribute certificate
> (i.e. the drivers license). You check some identifying information on that
> license that ties the certificate to the person giving it to you. A
> picture, some bio information, (age, height, weight, eye color) (however,
> incorrect, I might add :) that correlates the "certificate" to the entity.  
> Those are *identifying* attributes, not authorization attributes. In the
> PKI space, the *identifying* attribute is the public key.
> 
> A drivers license has only has one authorization attribute. The privilege
> to drive a car. 
> 
> And that certificate is really issued to an entity that matches the
> *identifying* attributes. On that certificate, the entity may be given a
> name, an address, and possibly a number, for easy look up. That look up is
> only relevant in the DMV's own directory, not in the post office's
> directory, or at the hospital.

It's always dangerous to use analogies, but in this example, the driver's
license is an identity certificate.  The bio information (picture, height
weight, hair color, hair presence :-) is, as you say, the "public key".
The date of birth is a certified attribute which can legitimately be
used, contrary to Aram's claim, for purposes other than the privilege
to drive a car.  The common name and the number are part of the DN, which
in full, might be: "c=US, st=CA, o=DMV, sn=S-678-109-876-432, cn=John Smith".
One does not have to be very imaginative to suppose that VeriCertCo and
DigSigZone and PkiBoys could all issue certificates for each of the 50
states, or for each of the state agencies, or for each person licensed
to drive in the US, and that a compelling case for fraud or malfeasance
could be made if there were a single collision in names following the
"USDriverPerson" (analogous to InetOrgPerson :-) schema.

> The amusement park "would like to" include sufficient identifying
> information (such as a name and a driver license number), but, it cannot,
> because by the standard, it is limited to the DN given, "CN=John Smith,
> O=Smith". If attribute certificate adds anything else to the DN, then the
> correlation fails where it should succeed.
> 
> If there is insufficient information to begin with (i.e. capability for two
> John Smith's one with a driver's license, and a Bob Smith's 13 year old
> named John) then the correlation can succeed where it should fail.
> 
> Isn't this called a hole?

As above, no.

The driver's license number doesn't have to be meaningful outside the
DMV's database, it only has to be a unique identifier which the DMV
will not issue to some other person.  I use the same authentication
credential to request a music download attribute cert (paid for with
e-cash or a regular credit card) and to perform the downloads; the
identifying information is irrelevant as long as its unique.  If
I get a new ID cert with a new public key from the DMV, I can still
use all my old attribute certs.  And if the relying parties ignore
the CN when matching ACs to PKCs, I can even change my name.

Dave

From: Michael Zolotarev <[email-masked]>
To: Peter Sylvester <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: TSP. Version 10, Removal of SIA Extension
Date: Tue, 24 Oct 2000 09:48:57 +1000

I second the proposal.

> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Tuesday, 24 October 2000 3:10
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: TSP. Version 10, Removal of SIA Extension
> 
> 
> 
> 
> A TS certificate contains the an access information was a feature in
> the text, having this removed may not easily allow to get it back
> in a next round. 
> 
> I would consider to include the complete definition of SIA in the
> TS text since it is not or not yet defined anywhere else, and
> maybe mention that it is expected that it will be removed later. 
> 
> In this way the feature is described and stable, and when
> as soon as part1 gets updated and the TS text gets moved from
> proposed to draft, one can remove it without having added
> or removed any functionality. 
>  
> > Michael,
> > 
> > > Sounds like its time to get SIA back to TSS draft, Denis :)
> > 
> > "son-of-RFC2459" has not yet passed WG last call, nor IESG 
> last call.
> > Waiting for it would create a delay that could be estimated 
> to be, at best,
> > about two months and thus would mean issuing the TSP RFC 
> next year. :-(
> > 
> > We now need this long-awaited RFC. 
> > 
> > Denis
> > 
> > Note: I have just posted to the web editor an update 
> (version 11) that
> > incorporates the changes that have been noticed (plus one, 
> un-noticed in the
> > ASN1 module !)
> 

Date: Mon, 23 Oct 2000 17:49:40 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: "David P. Kemp" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

On Mon, 23 Oct 2000, David P. Kemp wrote:

> Polar,
> 
> You keep paying lip service to the idea that "standards are not a
> substitute for system engineering", and then turn around and say that a
> technical interoperability profile MUST require certain behavior, and
> that PKIX must somehow mandate that whatever infrastructure is out
> there today must be made "secure".
> 
> That just isn't the way things work.
> 
> A driver's license is a paper certificate which binds some information
> (name, address, date of birth, photo) using some security info (special
> lamination, holograms, etc).  It is issued according to well known
> business practices which give relying parties some measure of the difficulty
> of obtaining one which contains incorrect information.
> 
> Relying parties (check cashers, liquor stores, cinemas) use the
> driver's license to make access control decisions based on their own
> judgement of the strength of the authentication mechanism and the risk
> of loss.  They DO NOT have a contractual relationship with the issuer
> of the driver's license, nor do they rely upon standards stating what a
> license must contain.  They rely on what's in front of them and on the
> generally accepted business principle that the 50 states can be trusted
> to issue ID cards usable for the purpose of keeping a check written out
> to one person from being cashed by someone else.

If we take this model. You don't just check the attribute certificate
(i.e. the drivers license). You check some identifying information on that
license that ties the certificate to the person giving it to you. A
picture, some bio information, (age, height, weight, eye color) (however,
incorrect, I might add :) that correlates the "certificate" to the entity.  
Those are *identifying* attributes, not authorization attributes. In the
PKI space, the *identifying* attribute is the public key.

A drivers license has only has one authorization attribute. The privilege
to drive a car. 

And that certificate is really issued to an entity that matches the
*identifying* attributes. On that certificate, the entity may be given a
name, an address, and possibly a number, for easy look up. That look up is
only relevant in the DMV's own directory, not in the post office's
directory, or at the hospital.

> An attribute authority (someone issuing a season pass to an amusement
> park) will include sufficient identifying information (such as a name
> and driver's license number) to ensure that John Smith's (senior) pass
> cannot be used by John junior, or by some other John Smith.  This is all
> done without any contractual relationship between the state DMV and the
> amusement park.

The amusement park "would like to" include sufficient identifying
information (such as a name and a driver license number), but, it cannot,
because by the standard, it is limited to the DN given, "CN=John Smith,
O=Smith". If attribute certificate adds anything else to the DN, then the
correlation fails where it should succeed.

If there is insufficient information to begin with (i.e. capability for two
John Smith's one with a driver's license, and a Bob Smith's 13 year old
named John) then the correlation can succeed where it should fail.

Isn't this called a hole?

If I issue an amusement park pass to a guy with a drivers license, I
really have to either extract the same identifying attributes, picture,
height, weight, eye color, (in PKI, the public key), or I have to name him
by including his indexing attributes, such as his name, address, and
possible number, BUT I also have to say where that index is relevant, i.e.
the DMV of California, if not further classified by the State Authority of
California, certified by the State Registry of the United States of
America, certified by the Nation Registry of the League of Nations,
certified by Verisign. :)

Cheers,
-Polar

> As PKI and PMI are used to automate real-world business processes,
> system engineering is required.  I don't consider the following, which
> you seem to be proposing, to be a reasonable approach:
> 
> 1) Look at all the SSL certificates that are already out there,
> 2) Impose technical constraints on attribute certificates, in an attempt to
> 3) Solve a general unspecified access control problem.
> 
> Don Flinn and others have well expressed the need for both due
> diligence and system engineering when applying PKI and PMI.  I agree
> with them, and I am unconvinced that your approach of applying
> technical constraints to solve a procedural problem will meet with any
> success whatsoever.  I am therefore opposed to specifying in an AC
> profile the precise (or even the imprecise) conditions under which a
> compliant AC issuer MUST link an AC to a particular PKC.

> Dave
> 
> 
> 
> 
> > From: Polar Humenn <[email-masked]>
> > 
> > Denis,
> > 
> > I am in agreement with you on your approach of including the objectDigest
> > Info along with entityName or baseCertificateID. I think in environments
> > where the Relying Parties, Attribute Certificate Issuers, and Subject
> > Entities do not know and trust a priori the certificate management
> > environment they all are emphatically working in, then the entityName
> > and/or baseCertificateID must only be used in conjunction with the
> > objectDigestInfo.
> > 
> > A good thing would be to figure out under the precise conditions in which
> > a compliant Attribute Certificate Issuer MUST include objectDigestInfo.
> > 
> > I can think of one of the conditions right off.
> > 
> > In applications where there is no absolute assurance by all three classes
> > of possible parties, i.e. subjects, attribute certificate issuers, and
> > relying parties, are privy to each others business practices about the
> > use of DN's.
> > 
> > I am not yet sure how you can write such requirements without getting
> > agreements from all three parties.
> > 
> > -Polar
> 

Date: Mon, 23 Oct 2000 17:32:23 -0400
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Bob,

>Steve,
>
>We have discussed this before, but unfortunately, name subordination 
>does NOT solve all of the problems, in part because of the legal 
>entanglements caused by treating wholly own subsidiary corporations, 
>Doing Business As firms, franchises, etc., as though they were 
>organization units of a larger parent organization.
>
>I got a very stern, lecture on that subject from the lawyers when I 
>was with GTE.  GTE Laboratories, Inc. is NOT an OU of GTE Corp., no 
>way no how, according to them.  And neither is GTE of Pennsylvania, 
>GTE of California, etc.

I appreciate your adherence to the advice of the lawyers for MY 
company, but we're working on an access control problem, not an NR 
problem, and I would not ask any lawyer for help in addressing 
technical issues in an access control framework.  After all, their 
assistance has been so great in the NR arena, ...

>The concern that was expressed was that to identify such 
>organizations, which are wholly owned but separate corporations, as 
>organizational units might subject the holding company to liability 
>that was incurred by the subordinate organization, which (in 
>general) is precisely the reason why separate corporations were 
>created in the first place -- to shelter the overall corporate 
>structure from lower level liabilities.

Like I said, I would not ask for their help. If we move this 
discussion to the DNS arena, we have plenty of experience, lots of 
history, and recent legal wrangling. In the case of your example, we 
have various DNS names for different parts of Verizon Communications, 
and setting up CAs aligned with the management of those DNS subtrees 
is not a bad idea.

>Granted, this approach doesn't always work -- witness the Dow 
>Corning vs. Dow Chemical breast implant suits.  But the corporate 
>attorneys I have talked to are virtually unanimous in agreeing with 
>this position, at least as long as the conventional name of the 
>attribute is "organizationalUnit".
>
>If this is the position with respect to holding companies, I have to 
>believe that it would also be the position of any CAs with competent 
>attorneys -- they are not going to allow the name of the CA to used 
>to used for such purposes either, even if the sequence of RDNs is 
>O=My CA, O=Your Corp.

I am not convinced that organizational CAs issuing certs for access 
control purposes need the help of corporate attorneys.  Did any of 
these attorneys advise us on appropriate password lengths, on the use 
of ACLs vs. capabilities, etc?

Steve

Date: Mon, 23 Oct 2000 15:17:39 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Steve,

Bob

>addresses the naming concern cited in your message.

Date: Tue, 24 Oct 2000 01:47:38 -0700
From: Aram Perez <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: PKIX <[email-masked]>

David Kemp wrote:

[snip]
> 
> A driver's license is a paper certificate which binds some information
> (name, address, date of birth, photo) using some security info (special
> lamination, holograms, etc).  It is issued according to well known
> business practices which give relying parties some measure of the difficulty
> of obtaining one which contains incorrect information.

There are at least three "attributes" with incorrect information on my
current California Drive License: the weight is wrong (I won't say in which
direction ;-) and my picture shows me with glasses (I wear contacts now) and
much darker hair (I have a bit more gray :-(

> 
> Relying parties (check cashers, liquor stores, cinemas) use the
> driver's license to make access control decisions based on their own
> judgement of the strength of the authentication mechanism and the risk
> of loss.  They DO NOT have a contractual relationship with the issuer
> of the driver's license, nor do they rely upon standards stating what a
> license must contain.  They rely on what's in front of them and on the
> generally accepted business principle that the 50 states can be trusted
> to issue ID cards usable for the purpose of keeping a check written out
> to one person from being cashed by someone else.

I've stayed out of this thread, but you've touched upon one of my "hot
buttons". I'd like to make two points:

1. Since when does my driver's license prove that I have enough money in my
bank account to write a check, or that I am "authorized" to buy liquor (and
get drunk) or that I can go see an R rated movie. The only thing that my
driver license states is "This license is issued as a license to drive a
motor vehicle: it does not establish eligibility for employment, voter
registration, or public benefits." So the only thing it "authorizes" me to
do is drive a motor vehicle. And given how I look, I'm sure that if I walked
into a liquor store and bought some whiskey, I wouldn't be asked to show my
license. Maybe I'll start a campaign to change the license so that it states
"... it does not establish eligibility for employment, voter registration,
or public benefits; not does it guarantee payment for check written by this
person, or authorizes the person to buy liquor or to watch adult movies" or
even better "This license is issued as a license to drive a motor vehicle,
to write checks, to buy liquor and to watch R and X rated movies: it does
not..." ;-)

2. I won't try to change the "real business world" where it's accepted
business practice to confuse identity with authorization. There is a big
difference between "generally accepted business practices and principles"
being used today and trying to develop technical standards based on
presumptions of only right and wrong. Electronic relying parties can not
follow the same business practices or principles because certificates
(whether identity or attribute) can't have "almost correct" information.
Should I ever be asked to show my license to buy liquor, I would be allowed
to because my picture is "close enough" to how I currently look.
Paraphrasing Ed Gerck, "The lifetime of a certificate is inversely
proportional to the number of its attributes." Why? Because changing 1 bit
invalidates the certificate, even though in the real world changing an
attribute does not invalidate my license.

Just my thoughts,
Aram Perez

[snip]

Date: Mon, 23 Oct 2000 13:54:24 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Content-MD5: Sdv7bt5DBMMTuuVlDN5kAA==

Polar,

You keep paying lip service to the idea that "standards are not a
substitute for system engineering", and then turn around and say that a
technical interoperability profile MUST require certain behavior, and
that PKIX must somehow mandate that whatever infrastructure is out
there today must be made "secure".

That just isn't the way things work.

A driver's license is a paper certificate which binds some information
(name, address, date of birth, photo) using some security info (special
lamination, holograms, etc).  It is issued according to well known
business practices which give relying parties some measure of the difficulty
of obtaining one which contains incorrect information.

Relying parties (check cashers, liquor stores, cinemas) use the
driver's license to make access control decisions based on their own
judgement of the strength of the authentication mechanism and the risk
of loss.  They DO NOT have a contractual relationship with the issuer
of the driver's license, nor do they rely upon standards stating what a
license must contain.  They rely on what's in front of them and on the
generally accepted business principle that the 50 states can be trusted
to issue ID cards usable for the purpose of keeping a check written out
to one person from being cashed by someone else.

An attribute authority (someone issuing a season pass to an amusement
park) will include sufficient identifying information (such as a name
and driver's license number) to ensure that John Smith's (senior) pass
cannot be used by John junior, or by some other John Smith.  This is all
done without any contractual relationship between the state DMV and the
amusement park.

As PKI and PMI are used to automate real-world business processes,
system engineering is required.  I don't consider the following, which
you seem to be proposing, to be a reasonable approach:

1) Look at all the SSL certificates that are already out there,
2) Impose technical constraints on attribute certificates, in an attempt to
3) Solve a general unspecified access control problem.

Don Flinn and others have well expressed the need for both due
diligence and system engineering when applying PKI and PMI.  I agree
with them, and I am unconvinced that your approach of applying
technical constraints to solve a procedural problem will meet with any
success whatsoever.  I am therefore opposed to specifying in an AC
profile the precise (or even the imprecise) conditions under which a
compliant AC issuer MUST link an AC to a particular PKC.

Dave

> From: Polar Humenn <[email-masked]>
> 
> Denis,
> 
> I am in agreement with you on your approach of including the objectDigest
> Info along with entityName or baseCertificateID. I think in environments
> where the Relying Parties, Attribute Certificate Issuers, and Subject
> Entities do not know and trust a priori the certificate management
> environment they all are emphatically working in, then the entityName
> and/or baseCertificateID must only be used in conjunction with the
> objectDigestInfo.
> 
> A good thing would be to figure out under the precise conditions in which
> a compliant Attribute Certificate Issuer MUST include objectDigestInfo.
> 
> I can think of one of the conditions right off.
> 
> In applications where there is no absolute assurance by all three classes
> of possible parties, i.e. subjects, attribute certificate issuers, and
> relying parties, are privy to each others business practices about the
> use of DN's.
> 
> I am not yet sure how you can write such requirements without getting
> agreements from all three parties.
> 
> -Polar

Date: Mon, 23 Oct 2000 13:08:03 -0400
To: Polar Humenn <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: [email-masked], [email-masked], [email-masked]

Polar,

Al pointed out in his experience, and the rule is true in a more 
general context, the folks responsible for managing access control 
are not the same as those responsible for managing identity (and 
maybe keys). This is a good motivation for use of ACs. Use of ACs 
allows each authority to manage authorization separate from one 
another, and from the identity issuer. Changes to your authorization 
in one context can be made without having to coordinate with other 
AAs, or with a CA.

Steve

From: Peter Sylvester <[email-masked]>
Date: Mon, 23 Oct 2000 19:09:55 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: TSP. Version 10, Removal of SIA Extension
Cc: [email-masked]

A TS certificate contains the an access information was a feature in
the text, having this removed may not easily allow to get it back
in a next round. 

I would consider to include the complete definition of SIA in the
TS text since it is not or not yet defined anywhere else, and
maybe mention that it is expected that it will be removed later. 

In this way the feature is described and stable, and when
as soon as part1 gets updated and the TS text gets moved from
proposed to draft, one can remove it without having added
or removed any functionality. 
 
> Michael,
> 
> > Sounds like its time to get SIA back to TSS draft, Denis :)
> 
> "son-of-RFC2459" has not yet passed WG last call, nor IESG last call.
> Waiting for it would create a delay that could be estimated to be, at best,
> about two months and thus would mean issuing the TSP RFC next year. :-(
> 
> We now need this long-awaited RFC. 
> 
> Denis
> 
> Note: I have just posted to the web editor an update (version 11) that
> incorporates the changes that have been noticed (plus one, un-noticed in the
> ASN1 module !)

Date: Mon, 23 Oct 2000 13:01:12 -0400
To: Polar Humenn <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: [email-masked], [email-masked], [email-masked]

Polar,

Steve

Date: Mon, 23 Oct 2000 18:35:43 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Michael Zolotarev <[email-masked]>
CC: [email-masked]
Subject: Re: TSP. Version 10, Removal of SIA Extension

Michael,

> Sounds like its time to get SIA back to TSS draft, Denis :)

"son-of-RFC2459" has not yet passed WG last call, nor IESG last call.
Waiting for it would create a delay that could be estimated to be, at best,
about two months and thus would mean issuing the TSP RFC next year. :-(

We now need this long-awaited RFC. 

Denis

Note: I have just posted to the web editor an update (version 11) that
incorporates the changes that have been noticed (plus one, un-noticed in the
ASN1 module !)

> > From: Russ Housley [mailto:[email-masked]]
> > Sent: Friday, 20 October 2000 6:26
> > To: Denis Pinkas
> > Cc: [email-masked]
> > Subject: Re: TSP. Version 10, Removal of SIA Extension
> >
> >
> > Tim and I have already started the addition of
> > subjectInfoAccess in the
> > next son-of-RFC2459 draft.  I assigned the OID for it
> > yesterday.  I posted
> > it to the IMC Web site earlier today.
> >
> > Russ
> >
> > At 05:15 PM 10/19/2000 +0200, Denis Pinkas wrote:
> > >Francois,
> > >
> > > > Hi Denis,
> > > >
> > > > I just noticed that in the latest draft you completely
> > remove from Section
> > > > 2.3 the text about a TSA's certificate possibly
> > containing a Subject
> > > > Information Access (SIA) extension. From the many
> > comments received during
> > > > last call against the previous draft, I did not recall
> > anyone asking for
> > > > the SIA extension to be removed.
> > > >
> > > > Did I miss anything or is there a particular reason why
> > the SIA extension
> > > > was removed?
> > >
> > >You read the draft very carefully, congratulations !
> > >
> > >I forgot to mention this point. At the Barcelona ISSE
> > meeting, I had a
> > >discussion with Stephen Kent about the progression of this
> > draft to RFC. We
> > >came to the conclusion that this draft should not be delayed
> > any longer.
> > >Since the SIA extension is not defined in RFC 2459, we would
> > have had to
> > >wait until "son-of-RFC 2459" is published. However, we did
> > not wanted to
> > >hold the draft until "son-of-RFC 2459" got its own RFC number.
> > >
> > >Since the SIA was not mandatory to implement, it has been
> > suppressed. We now
> > >have two options:
> > >
> > >1) either to re-incorporate it when the TSP Proposed
> > Standard will move to
> > >Standard,
> > >2) or define this extension directly in "son-of-RFC 2459"
> > (Tim can you hear
> > >me ???)
> > >
> > >Regards,
> > >
> > >Denis
> > >
> > > > Regards,
> > > >
> > > > Francois
> > > > ___________________________________
> > > > Francois Rousseau
> > > > Director of Standards and Conformance
> > > > Chrysalis-ITS
> > > > 1688 Woodward Drive
> > > > Ottawa, Ontario, CANADA, K2C 3R7
> > > > [email-masked]      Tel. (613) 723-5076 ext. 419
> > > > http://www.chrysalis-its.com     Fax. (613) 723-5078
> >

Date: Mon, 23 Oct 2000 11:53:18 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Denis Pinkas <[email-masked]>
cc: Russ Housley <[email-masked]>, [email-masked], Sharon Boeyen <[email-masked]>, "Hoyt L. Kesterson II" <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Denis,

I am in agreement with you on your approach of including the objectDigest
Info along with entityName or baseCertificateID. I think in environments
where the Relying Parties, Attribute Certificate Issuers, and Subject
Entities do not know and trust a priori the certificate management
environment they all are emphatically working in, then the entityName
and/or baseCertificateID must only be used in conjunction with the
objectDigestInfo.

A good thing would be to figure out under the precise conditions in which
a compliant Attribute Certificate Issuer MUST include objectDigestInfo.

I can think of one of the conditions right off.

In applications where there is no absolute assurance by all three classes
of possible parties, i.e. subjects, attribute certificate issuers, and
relying parties, are privy to each others business practices about the
use of DN's.

I am not yet sure how you can write such requirements without getting
agreements from all three parties.

-Polar

On Mon, 23 Oct 2000, Denis Pinkas wrote:

> Russ,
> 
> In my last E-mail on that topic I said: 
> 
> > Russ,
> > 
> > > An attribute or extension is the only acceptable approach to me, unless we
> > Since you said ... "unless we coordinate with X.509 agrees to make the same
> > change to the base syntax", there are two solutions, not a single acceptable
> > approach. On that basis, I agree with you.
> > 
> > We can certainly attempt to coordinate with ISO, since the Orlando meeting
> > is coming. I am a member of the ISO defect report team and can certainly
> > bring the attention of the ISO group on that topic. :-)
> 
> After some side discussion with Tom Guidin, Tom made a very good
> observation. The current syntax is:
> 
>    Holder ::= SEQUENCE {
>       objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
> This syntax could be used without any change, since we have, as Tom noticed,
> a SEQUENCE of OPTIONAL elements and not a CHOICE. So we would only need to
> fix the text without changing the ASN.1 syntax, by adversing the combination
> of the use of both the baseCertificateID and the objectDigestInfo
> parameters.
> 
> Here is an extract of the ISO text, which does not explicit mention that
> combination (but does not prevent it either):
> 
> " The version number differentiates between different versions of the
> attribute certificate. If holder includes objectDigestInfo or if issuer
> includes baseCertificateID or objectDigestInfo, version must be v2.
> 
> The holder field conveys the identity of the attribute certificate's holder.
>  
> The baseCertificateID component, if present, identifies a particular
> public-key certificate that is to be used to authenticate the identity of
> this holder when asserting privileges with this attribute certificate.
> 
> The entityName component, if present, identifies one or more names for the
> holder. If entityName is the only component present in holder, any
> public-key certificate that has one of these names as its subject can be
> used to authenticate the identity of this holder when asserting privileges
> with this attribute certificate. If baseCertificateID and entityName are
> both present, only the certificate specified by baseCertificateID may be
> used. In this case entityName is included only as a tool to help the
> privilege verifier locate the identified public-key certificate.
> 
> Note: There is a risk with the sole use of GeneralNames  to identify the
> holder, in that this points only to a name for the holder. This is generally
> insufficient to enable the authentication of a holder's identity for
> purposes of issuing privileges to that holder. Use of the issuer name and
> serial number of a specific public-key certificate, however, enables the
> issuer of attribute certificates to rely on the authentication process
> performed by the CA when issuing that particular public-key certificate.
> Also, some of the options in GeneralNames (e.g. IPAddress) are inappropriate
> for use in naming an attribute certificate holder, especially when the
> holder is a role and not an individual entity. Another problem with
> GeneralNames alone as an identifier for a holder is that many name forms
> within that construct do not have strict registration authorities or
> processes for the assignment of names.
>  
> The objectDigestInfo component, if present, is used directly to authenticate
> the identity of a holder, including an executable holder (e.g. an applet).
> The holder is authenticated by comparing a digest of the corresponding
> information, created by the privilege verifier with the same algorithm
> identified in objectDigestInfo with the content of objectDigest. If the two
> are identical, the holder is authenticated for purposes of asserting
> privileges with this attribute certificate."  
> 
> Some small changes to that text *might* be needed to say that the
> baseCertificateID may be used in conunction with the objectDigestInfo
> component. In fact the use of that combination might even only appear in the
> PKIX profile, while it would be "better" to have the two documents aligned.
> 
> Denis
> 

Date: Mon, 23 Oct 2000 11:41:14 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Don Flinn <[email-masked]>
cc: Stephen Farrell <[email-masked]>, Dale Gustafson <[email-masked]>, Stephen McConnell <[email-masked]>, Electronic Commerce DTF <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Impact on OMG's CSIv2 (was - RE: Comments on draft-ietf-pkix-ac509prof-05.txt)

Don,

In general PKI, has the problem that I "uncovered" with the Attribute
Certificate. So therefore CSIv2 does have this problem as well, especially
if it must rely on products and services in this space.

Trust relationships that you cite may be mandated by contract law,
provided you have contracts! However, if one is throwing around cliches,
then how about this one "Locking the barn door after the horse got out",
or "Houston, we have a problem". In open interoperable environments, you
may not have contracts, you may not have practical recourse of the law
anyway, say in international deployments.

All you can really get from PKI is the fact that the same entity that is
identified in the Attribute Certificate (the Holder) is the same entity
the Relying Party is correlating it with. That Holder is the "holder" of
the private key, not merely something named by an arbitrary DN. The
Attribute Certificate Issuer must be able to provide evidence that he is
indeed identifying the holder of a private key. A DN alone doesn't do it.
A DN of the entities issuer doesn't do it either for the same reasons.

BTW, a DN is just a bag of bits as far as I'm concerned. Its conventional
use cannot be enforced or relied upon. Its structure only serves as a
"tool" or an optimization of finding "things" that may be related to it.
You cannot infer an the subject's issuer from the subject's DN. If the
attribute certificate is not tied to a public key and you trust that. You
must have a highly constrained environment. That's not "interoperable".

Below you state only *one* situation in which all parties MUST "trust"
each other by basically subscribe to one TRUSTED DN server (which does DUE
DILIGENCE on updates), where all names are unique and all party's business
practices concerning DNs are well known to all parties, and contracts are
written on it between all parties together. Otherwise, you'll just get
into a finger pointing situation. If we want to make that a requirement
for CSIv2, then so be it. 

Cheers,
-Polar

On Mon, 23 Oct 2000, Don Flinn wrote:

> I assert that CSIv2 does not have the problem that Polar uncovered. Let's
> see if I can defend that assertion -:)
> 
> CSIv2 defines a wire protocol to facilitate secure interoperability.
> Therefore, if CSIv2 provides a way to support the resolution of the problem
> that Polar uncovered then CSIv2 is sound.
> 
> CSIv2 provides for the transfer of a chain of Authentication Certificates
> for the initiating client and a second chain of a Privilege Attribute
> Certificates (PAC) followed by the Authentication Certificate chain
> verifying the AA who issued the PAC.
> 
> The Holder field in the PAC points to one and only one Authentication
> Certificate identified by a CA and serial number which is unique to that CA.
> 
> Given the above, there are a series of trust relationships that must be
> supported by a security service implementation of CSIv2 and an application
> using that security service - namely:
> 
> The Application must trust the AA.  This can be accomplished by the
> application, supported by the security service implementation, using an
> authentication certificate in the PAC chain.  For example, the application
> stores authentication certificats of trusted AA's.  The security service
> implementation verifies the chain against one of the stored, trusted AA
> authentication certificates.
> 
> The application must trust the user's SSL certificate when using the default
> CSIv2 mechanism, SSL. (A similar statement holds true for other mechanisms.)
> This is accomplished the same way as above but for the user's certificate,
> i.e. establish trust in the user's CA or some CA in the chain.
> 
> The AA must trust the CA that issued the user's certificate.  In this case I
> am using the Holder field in the PAC.  The AA points to a user certificate
> issued by a CA that it trusts.
> 
> The CA has done due diligence in issuing the user certificate.  This is what
> I meant by the AA trusting the user's CA, i.e. the AA assures that the CA
> referenced in the Holder field of the PAC it issues has done its due
> diligence with respect to the user.
> 
> Given the above trust relationships lets look at the two "Henry Ford's".
> Henry Ford is defined by CA-1 as, e.g.
> o=Ford Motors,c=US,ou=Truck Division,ou=accounting_derborn,CN=Henry Ford.
> If the CA has done its due diligence then there can be only one Henry Ford
> with that full X.501 name.  If the full X.501 name does not point to a
> unique Henry Ford then that CA has not done its due diligence and can be
> sued to recover any damages done by its lack of due diligence.  If CA-2
> issues a certificate with the same full X.501 name then it is the same Henry
> Ford as that identified by CA-1, if CA-2 has done its due diligence. (I
> bring up law suites as an example of the recourses of an aggrieved party.
> An analogy is a bank which you trust and to which you have recourse if they
> fail in their due diligence and cost you money.  This is not the purview of
> the technology but of the law.)
> 
> If the AA issues a PAC that points to a incompetent or bogus CA then it has
> not done its due diligence and can be sued to recover any damage done by its
> negligence.
> 
> The trust relationships that I defined above are not the purview of CSIv2
> *nor* the draft-ietf-pkix-ac509prof-05 specifications.  The specification of
> the trust relationships are the purview of a higher level protocol or
> specification.  CSIv2 and the draft-ietf-pkix-ac509prof-05 specifications
> provide the protocols to support the ability to establish the trust
> relationships.  Note that I am not ignoring all the excellent discussion on
> the original thread related to tightening the language of the
> draft-ietf-pkix-ac509prof-05 specification.  What I am cautioning against is
> "throwing out the baby with the bathwater"  and mixing the intent and
> purview of these two specificcations with those of a higher level
> specification.
> 
> OMG is in the early stages of writing a Request for Proposal (RFP) which
> will/should address the higher level AA issues.  This RFP, I assert, should
> specify authentication servers and services and define their
> responsibilities as well as the interfaces to interact with them in a
> Federated situation.  The specification is tentatively called the
> Authorization Token Layer Acquisition Service, ATLAS, and has a mailing
> list - [email-masked] .  All who are interested in this issue are
> cordially invited to join.
> 
> Don
> 
> > From: Stephen McConnell [mailto:[email-masked]]
> > Sent: Thursday, October 19, 2000 12:10 PM
> > To: Polar Humenn; Dale Gustafson
> > Cc: [email-masked]; [email-masked]; [email-masked]; Electronic
> > Commerce DTF
> > Subject: Impact on OMG's CSIv2 (was - RE: Comments on
> > draft-ietf-pkix-ac509prof-05.txt)
> >
> >
> >
> > Polar et. al.
> >
> > Some comments from an OMG/EC perspective:
> >
> > 	- EC has a significant subscribed list of end-user
> > 	  organisations that will end up using this stuff,
> > 	  possibly not in the pure IETF model of data
> > 	  structures, but in terms of the real application
> >         level problems based on the emerging CSIv2
> > 	  OMG's cross-domain security interoperability spec).
> >
> >   	- Members of EC are watching closely the CSIv2 process,
> > 	  because we know the CORBA security doesn't work beyond a
> > 	  single enterprise, and the CSIv2 is the silver bullet.
> > 	  Because CSIv2 depends on Attribute Certificates, this
> > 	  means  that the strength of CSIv2 is limited by the
> > 	  strength of X509 (2000).  If there are holes in X509
> > 	  (2000) it means that there are holes in CSIv2.  CSIv2 has
> > 	  been adopted. It will be presumably enter a finalisation
> > 	  phase during the next meeting.  Based on several emails
> > 	  sent out on this thread, my conclusion is that
> > 	  X509 (2000) isn't ready for prime time - adding a
> > 	  "by-the-way there are security holes and there are
> > 	  optional vendor fixes (if they want to) but, ooh,
> > 	  by the way, you, the customer, you should be selecting
> > 	  your provider on the basis your technical due-diligence"
> > 	  (etc.) ... simply sucks. But lets look at what this means
> > 	  in terms of the impact on CSIv2:
> >
> > 	  1. CSIv2 is dependent on the strength of X509 (2000), in
> > 	     particular, the dependence that CSIv2 places on
> > 	     Attribute Certificates
> >
> > 	  2. Holes have been identified by Polar in the Attribute
> > 	     Certificate model and confirmed by several other
> > 	     authorities on this list.
> >
> > 	  3. What I'm missing here is this thread is the distinction
> > 	     between the following:
> >
> > 		   OMG CSIv2 functionality
> >
> > 	            - why CSIv2 needs Attribute Certificates
> > 			  in the first place ?
> >
> > 			- is there any reason why CSIv2 cannot use
> > 			  X509 Classic instead ?
> >
> > 		   OMG PKI Service functionality
> >
> > 			- currently defines mechanisms for
> > 			  certificate issue and verification,
> >
> > 			- is missing an extendable valuetype
> > 			  definition of a certificate to sync X509
> > 			  and CSIv2 with the PKI service
> >
> > 		   Application level functionality
> >
> > 			- getting a clear distinction between
> > 			  application level (which is where I would
> > 		  	  have through Attribute Certificates are
> > 			  relevant) as opposed to CSIv2 service
> > 			  functionality.
> >
> > Cheers, Steve.
> >
> > P.S.  Please consider this email as a vote for fully expanded
> > acronyms.  For
> > myself, AA stands for "Alcoholics Anonymous" and AC stands for "Andersen
> > Consulting"!
> >
> 

From: "Teiwes, Stephan (iT_SEC)" <[email-masked]>
To: "'Maxim Masiutin'" <[email-masked]>, "Teiwes, Stephan (iT_SEC)" <[email-masked]>, "Hartmann, Peter  (iT_SEC)" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Use of the IDEA Encryption Algorithm in CMS
Date: Mon, 23 Oct 2000 16:52:21 +0200

Dear Mr. Masuitin,

thanks a lot. We'll consider your comments and try to improve the draft
accordingly.

*Stephan Teiwes
iT_Security AG
www.it-sec.com

-----Original Message-----
From: Maxim Masiutin [mailto:[email-masked]]
Sent: Montag, 23. Oktober 2000 16:41
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Use of the IDEA Encryption Algorithm in CMS

Dear authors of "Use of the IDEA Encryption Algorithm in CMS" draft!

I have a question about following paragraph in
draft-ietf-smime-idea-07.txt:

-----------
If IV is specified as above, it MUST be used as initial vector. In
this case, the ciphertext MUST NOT include the initial vector. If
IV is not specified, the first 64 bits of the ciphertext MUST be
considered as the initial vector. However, this alternative of not
including the IV SHOULD NOT be applied in CMS or S/MIME.
-----------

  The last sentence:

"this alternative of not including the IV [into "iv OCTET STRING" of
IDEA-CBCPar|into the first 64 bits of the ciphertext] SHOULD NOT be
applied in CMS or S/MIME.

Could you please expand this sentence by adding one of the short
explanations that I've proposed?

I do also have a question about the following paragraph:

------------
The SMIMECapability SEQUENCE representing the IDEA symmetric
encryption algorithm MUST include the IDEA-CBC OID in the capabilityID
field and the parameters field MUST be absent. The SMIMECapability
SEQUENCE for IDEA encryption SHOULD be included in the symmetric
encryption algorithms portion of the SMIMECapabilities list. The
SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as
follows: 300D 060B 2B06 0104 0181 3C07 0101 02.
------------

  Why don't you give ASN.1 notation of SMIMECapability SEQUENCE
  representing IDEA as well as DER-encoded value? Please add ASN.1
  notation to the draft. Also, please clarify the byte order.

  And a test sample of CMS-message with IDEA will help me a lot!

  Thank you in advance.

-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/

From: "Don Flinn" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Dale Gustafson" <[email-masked]>, "Polar Humenn" <[email-masked]>, "Stephen McConnell" <[email-masked]>
Cc: "Electronic Commerce DTF" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Impact on OMG's CSIv2 (was - RE: Comments on draft-ietf-pkix-ac509prof-05.txt)
Date: Mon, 23 Oct 2000 10:49:23 -0400
Importance: Normal

I assert that CSIv2 does not have the problem that Polar uncovered. Let's
see if I can defend that assertion -:)

CSIv2 defines a wire protocol to facilitate secure interoperability.
Therefore, if CSIv2 provides a way to support the resolution of the problem
that Polar uncovered then CSIv2 is sound.

CSIv2 provides for the transfer of a chain of Authentication Certificates
for the initiating client and a second chain of a Privilege Attribute
Certificates (PAC) followed by the Authentication Certificate chain
verifying the AA who issued the PAC.

The Holder field in the PAC points to one and only one Authentication
Certificate identified by a CA and serial number which is unique to that CA.

Given the above, there are a series of trust relationships that must be
supported by a security service implementation of CSIv2 and an application
using that security service - namely:

The Application must trust the AA.  This can be accomplished by the
application, supported by the security service implementation, using an
authentication certificate in the PAC chain.  For example, the application
stores authentication certificats of trusted AA's.  The security service
implementation verifies the chain against one of the stored, trusted AA
authentication certificates.

The application must trust the user's SSL certificate when using the default
CSIv2 mechanism, SSL. (A similar statement holds true for other mechanisms.)
This is accomplished the same way as above but for the user's certificate,
i.e. establish trust in the user's CA or some CA in the chain.

The AA must trust the CA that issued the user's certificate.  In this case I
am using the Holder field in the PAC.  The AA points to a user certificate
issued by a CA that it trusts.

The CA has done due diligence in issuing the user certificate.  This is what
I meant by the AA trusting the user's CA, i.e. the AA assures that the CA
referenced in the Holder field of the PAC it issues has done its due
diligence with respect to the user.

Given the above trust relationships lets look at the two "Henry Ford's".
Henry Ford is defined by CA-1 as, e.g.
o=Ford Motors,c=US,ou=Truck Division,ou=accounting_derborn,CN=Henry Ford.
If the CA has done its due diligence then there can be only one Henry Ford
with that full X.501 name.  If the full X.501 name does not point to a
unique Henry Ford then that CA has not done its due diligence and can be
sued to recover any damages done by its lack of due diligence.  If CA-2
issues a certificate with the same full X.501 name then it is the same Henry
Ford as that identified by CA-1, if CA-2 has done its due diligence. (I
bring up law suites as an example of the recourses of an aggrieved party.
An analogy is a bank which you trust and to which you have recourse if they
fail in their due diligence and cost you money.  This is not the purview of
the technology but of the law.)

If the AA issues a PAC that points to a incompetent or bogus CA then it has
not done its due diligence and can be sued to recover any damage done by its
negligence.

The trust relationships that I defined above are not the purview of CSIv2
*nor* the draft-ietf-pkix-ac509prof-05 specifications.  The specification of
the trust relationships are the purview of a higher level protocol or
specification.  CSIv2 and the draft-ietf-pkix-ac509prof-05 specifications
provide the protocols to support the ability to establish the trust
relationships.  Note that I am not ignoring all the excellent discussion on
the original thread related to tightening the language of the
draft-ietf-pkix-ac509prof-05 specification.  What I am cautioning against is
"throwing out the baby with the bathwater"  and mixing the intent and
purview of these two specificcations with those of a higher level
specification.

OMG is in the early stages of writing a Request for Proposal (RFP) which
will/should address the higher level AA issues.  This RFP, I assert, should
specify authentication servers and services and define their
responsibilities as well as the interfaces to interact with them in a
Federated situation.  The specification is tentatively called the
Authorization Token Layer Acquisition Service, ATLAS, and has a mailing
list - [email-masked] .  All who are interested in this issue are
cordially invited to join.

Don

> From: Stephen McConnell [mailto:[email-masked]]
> Sent: Thursday, October 19, 2000 12:10 PM
> To: Polar Humenn; Dale Gustafson
> Cc: [email-masked]; [email-masked]; [email-masked]; Electronic
> Commerce DTF
> Subject: Impact on OMG's CSIv2 (was - RE: Comments on
> draft-ietf-pkix-ac509prof-05.txt)
>
>
>
> Polar et. al.
>
> Some comments from an OMG/EC perspective:
>
> 	- EC has a significant subscribed list of end-user
> 	  organisations that will end up using this stuff,
> 	  possibly not in the pure IETF model of data
> 	  structures, but in terms of the real application
>         level problems based on the emerging CSIv2
> 	  OMG's cross-domain security interoperability spec).
>
>   	- Members of EC are watching closely the CSIv2 process,
> 	  because we know the CORBA security doesn't work beyond a
> 	  single enterprise, and the CSIv2 is the silver bullet.
> 	  Because CSIv2 depends on Attribute Certificates, this
> 	  means  that the strength of CSIv2 is limited by the
> 	  strength of X509 (2000).  If there are holes in X509
> 	  (2000) it means that there are holes in CSIv2.  CSIv2 has
> 	  been adopted. It will be presumably enter a finalisation
> 	  phase during the next meeting.  Based on several emails
> 	  sent out on this thread, my conclusion is that
> 	  X509 (2000) isn't ready for prime time - adding a
> 	  "by-the-way there are security holes and there are
> 	  optional vendor fixes (if they want to) but, ooh,
> 	  by the way, you, the customer, you should be selecting
> 	  your provider on the basis your technical due-diligence"
> 	  (etc.) ... simply sucks. But lets look at what this means
> 	  in terms of the impact on CSIv2:
>
> 	  1. CSIv2 is dependent on the strength of X509 (2000), in
> 	     particular, the dependence that CSIv2 places on
> 	     Attribute Certificates
>
> 	  2. Holes have been identified by Polar in the Attribute
> 	     Certificate model and confirmed by several other
> 	     authorities on this list.
>
> 	  3. What I'm missing here is this thread is the distinction
> 	     between the following:
>
> 		   OMG CSIv2 functionality
>
> 	            - why CSIv2 needs Attribute Certificates
> 			  in the first place ?
>
> 			- is there any reason why CSIv2 cannot use
> 			  X509 Classic instead ?
>
> 		   OMG PKI Service functionality
>
> 			- currently defines mechanisms for
> 			  certificate issue and verification,
>
> 			- is missing an extendable valuetype
> 			  definition of a certificate to sync X509
> 			  and CSIv2 with the PKI service
>
> 		   Application level functionality
>
> 			- getting a clear distinction between
> 			  application level (which is where I would
> 		  	  have through Attribute Certificates are
> 			  relevant) as opposed to CSIv2 service
> 			  functionality.
>
> Cheers, Steve.
>
> P.S.  Please consider this email as a vote for fully expanded
> acronyms.  For
> myself, AA stands for "Alcoholics Anonymous" and AC stands for "Andersen
> Consulting"!
>

Date: Mon, 23 Oct 2000 16:40:46 +0200
From: Maxim Masiutin <[email-masked]>
Organization: RITLABS
To: [email-masked], [email-masked], [email-masked], <[email-masked]>
Subject: Use of the IDEA Encryption Algorithm in CMS

Dear authors of "Use of the IDEA Encryption Algorithm in CMS" draft!

I have a question about following paragraph in
draft-ietf-smime-idea-07.txt:

-----------
If IV is specified as above, it MUST be used as initial vector. In
this case, the ciphertext MUST NOT include the initial vector. If
IV is not specified, the first 64 bits of the ciphertext MUST be
considered as the initial vector. However, this alternative of not
including the IV SHOULD NOT be applied in CMS or S/MIME.
-----------

  The last sentence:

"this alternative of not including the IV [into "iv OCTET STRING" of
IDEA-CBCPar|into the first 64 bits of the ciphertext] SHOULD NOT be
applied in CMS or S/MIME.

Could you please expand this sentence by adding one of the short
explanations that I've proposed?

I do also have a question about the following paragraph:

------------
The SMIMECapability SEQUENCE representing the IDEA symmetric
encryption algorithm MUST include the IDEA-CBC OID in the capabilityID
field and the parameters field MUST be absent. The SMIMECapability
SEQUENCE for IDEA encryption SHOULD be included in the symmetric
encryption algorithms portion of the SMIMECapabilities list. The
SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as
follows: 300D 060B 2B06 0104 0181 3C07 0101 02.
------------

  Why don't you give ASN.1 notation of SMIMECapability SEQUENCE
  representing IDEA as well as DER-encoded value? Please add ASN.1
  notation to the draft. Also, please clarify the byte order.

  And a test sample of CMS-message with IDEA will help me a lot!

  Thank you in advance.

-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/

From: [email-masked]
Importance: Normal
Subject: Re: comments on draft-ietf-pkix-ldap-schema-01.txt
To: [email-masked]
Cc: <[email-masked]>, [email-masked]
Date: Mon, 23 Oct 2000 06:10:39 -0400

David,

Thanks for the comments - I've added further comments below prefaced with
TJH>

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

"David Chadwick" <[email-masked]> on 10/21/2000 11:08:25 AM

Please respond to [email-masked]

To:   Timothy Hahn/Endicott/IBM@IBMUS, <[email-masked]>
cc:   [email-masked]
Subject:  Re: comments on draft-ietf-pkix-ldap-schema-01.txt

From:               [email-masked]
To:                 [email-masked]
Subject:            comments on draft-ietf-pkix-ldap-schema-01.txt
Date sent:          Thu, 21 Sep 2000 14:18:15 -0400

> Greetings,
Tim
Apologies for the delay

>
> Section 2:
> ----------
> I would prefer that the phrase "use the subschemasubentry attribute in
> the root DSE" be changed to "use the subschemasubentry attribute from
> the namingContext entry which is found in the root DSE".

I disagree with your proposed change for the following reasons:

firstly the namingContext entry is not found in the root DSE, but
rather a pointer to the namingContext entry is found in the root
DSE. But this does not help, as the subschema subentry itself is
only mandatorily pointed to from the rootDSE, and not from the
namingContext entry. This is assuming I have read 2251 correctly,
viz:

If the server masters directory entries under one
   or more schema rules, there may be any number of values
of the
   subschemaSubentry attribute in the root DSE.

TJH> I should have used the phrase "namingContext attribute in the
TJH> root DSE".  The trouble I see with multiple values in the
TJH> subschemasubentry attribute in the root DSE is that because
TJH> attributes contain un-ordered sets of values, how does one
TJH> correlate a specific subschemasubentry value with the
TJH> particular namingContext value (DN) under which the client
TJH> intends to add, modify, or delete an entry?  Thus, I still
TJH> feel it is better to obtain the subschemasubentry value (DN)
TJH> by first getting the namingContext value (DN) from the
TJH> root DSE, then performing a base search against that DN
TJH> to get the subschemasubentry attribute value.  It's not
TJH> guaranteed that entries below that "namingContext entry"
TJH> aren't in yet another namingContext (in some other server)
TJH> but getting the subschemasubentry value in this fashion
TJH> would give you a much better chance of getting the schema
TJH> that governs the particular sub-tree (namingContext)
TJH> that the application is interested in interacting with.
TJH> Multiple subschemasubentry values in the root DSE is just
TJH> confusing because they aren't "correlated" to the
TJH> namingContext attribute values.

>
> Section 3.2:
> ------------
> In the BNF for "GeneralName", a single whitespace character appears
> (e.g. "rfc822 +").  Was this intentional?  It seems out of

I dont really mind either way here. I will let Steven be the
authoritative voice on this

> place/misleading.
>
> Editor's note on AuthorityKeyIdentifier:
> ----------------------------------------
> Seems to me that authority issuer name and authority certificate
> serial number could be useful.

What we really need is some LDAP server vendor (IBM??) to
implement these matching rules and to give some feedback about
which fields are really useful for users to use. At the moment we
can only guess at what people will want to use in practice.

>
> Section 4.1:
> ------------
> In the BNF for "CertificateListExactAssertion", the "$" after "Time"
> is OPTIONAL, correct?  It should only be needed if
> "DistributionPointName" is specified, I think.

Yes we could change the ABNF to put the  $ inside the DP
construct.

>
> Section 5 - ISSUE:
> ------------------
> I am not qualified to provide an opinion on this one.
>
> Section 5.3.2 - first Editor's note:
> ------------------------------------
> I would like to see attribute type names (not just OIDs) be allowed.

The AC profile specifies that the attribute MUST be identified by its
OID in the AC. Therefore if the user interface allows attribute
names to be presented by the user, something has to map this into
the correct OID, otherwise a wrong AC will be found by the LDAP
server. If we specify an OID in the matching rule, then it must be
the user interface that does the mapping. If we allow string names
in the matching rule, it must be the server that does the mapping.

What do you think?

TJH> I think that pushing OID <-> friendlyName mappings onto
TJH> clients is a bad think to rely on.  Anything we can do
TJH> to lessen complex schema interaction by client programs
TJH> is a good thing IMHO.

>
> Section 5.3.2 - second Editor's note:
> -------------------------------------
> I would find 5.3.9 Time Specification Match to be useful.  I don't
> have experience with the others.
>

Thanks for that.

David
>
> Regards,
> Tim Hahn
>
> Internet: [email-masked]
> Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
> phone: 607.752.6388     tie-line: 8/852.6388
> fax: 607.752.3681

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

Date: Mon, 23 Oct 2000 13:57:55 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Russ Housley <[email-masked]>, Polar Humenn <[email-masked]>, [email-masked], Sharon Boeyen <[email-masked]>, "Hoyt L. Kesterson II" <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Russ,

In my last E-mail on that topic I said: 

> Russ,
> 
> > An attribute or extension is the only acceptable approach to me, unless we
> Since you said ... "unless we coordinate with X.509 agrees to make the same
> change to the base syntax", there are two solutions, not a single acceptable
> approach. On that basis, I agree with you.
> 
> We can certainly attempt to coordinate with ISO, since the Orlando meeting
> is coming. I am a member of the ISO defect report team and can certainly
> bring the attention of the ISO group on that topic. :-)

After some side discussion with Tom Guidin, Tom made a very good
observation. The current syntax is:

   Holder ::= SEQUENCE {
      objectDigestInfo    [2] ObjectDigestInfo OPTIONAL

This syntax could be used without any change, since we have, as Tom noticed,
a SEQUENCE of OPTIONAL elements and not a CHOICE. So we would only need to
fix the text without changing the ASN.1 syntax, by adversing the combination
of the use of both the baseCertificateID and the objectDigestInfo
parameters.

Here is an extract of the ISO text, which does not explicit mention that
combination (but does not prevent it either):

" The version number differentiates between different versions of the
attribute certificate. If holder includes objectDigestInfo or if issuer
includes baseCertificateID or objectDigestInfo, version must be v2.

The holder field conveys the identity of the attribute certificate's holder.
 
The baseCertificateID component, if present, identifies a particular
public-key certificate that is to be used to authenticate the identity of
this holder when asserting privileges with this attribute certificate.

The entityName component, if present, identifies one or more names for the
holder. If entityName is the only component present in holder, any
public-key certificate that has one of these names as its subject can be
used to authenticate the identity of this holder when asserting privileges
with this attribute certificate. If baseCertificateID and entityName are
both present, only the certificate specified by baseCertificateID may be
used. In this case entityName is included only as a tool to help the
privilege verifier locate the identified public-key certificate.

Note: There is a risk with the sole use of GeneralNames  to identify the
holder, in that this points only to a name for the holder. This is generally
insufficient to enable the authentication of a holder's identity for
purposes of issuing privileges to that holder. Use of the issuer name and
serial number of a specific public-key certificate, however, enables the
issuer of attribute certificates to rely on the authentication process
performed by the CA when issuing that particular public-key certificate.
Also, some of the options in GeneralNames (e.g. IPAddress) are inappropriate
for use in naming an attribute certificate holder, especially when the
holder is a role and not an individual entity. Another problem with
GeneralNames alone as an identifier for a holder is that many name forms
within that construct do not have strict registration authorities or
processes for the assignment of names.
 
The objectDigestInfo component, if present, is used directly to authenticate
the identity of a holder, including an executable holder (e.g. an applet).
The holder is authenticated by comparing a digest of the corresponding
information, created by the privilege verifier with the same algorithm
identified in objectDigestInfo with the content of objectDigest. If the two
are identical, the holder is authenticated for purposes of asserting
privileges with this attribute certificate."  

Some small changes to that text *might* be needed to say that the
baseCertificateID may be used in conunction with the objectDigestInfo
component. In fact the use of that combination might even only appear in the
PKIX profile, while it would be "better" to have the two documents aligned.

Denis

To: [email-masked]
Subject: CA key pair changeover
Date: Mon, 23 Oct 2000 14:52:56 +0900
From: Mine Sakurai <[email-masked]>
Lines: 36

/FYI/

Hi,
We are managing experimental CAs in WIDE project. 
We had a CA key pair changeover experiment in June 2000, including
Apache+openSSL, Netscape Communicator, and Internet Explorer.

We wrote a report. You can get the report from the URL
http://www.wide.ad.jp/wg/moca/CAkeychangeover.txt 

(in japanese,
http://www.wide.ad.jp/wg/moca/CAkeychangeover-j.txt )

Any comments or suggestions are welcome. 

Abstract:
 A lot of CAs have been managed for several years, but we've not yet
 seen a situation where CA key pair was changed due to CA
 certificate expiration. We had an experiment of CA key pair
 changeover. In this experiment, we examined how a CA key pair
 changeover would make influences to existing applications. As a
 result, we found that some of the existing applications required
 change of CA distinguished name at the same time of CA key pair
 changeover for smooth transition.
 Have you ever discussed whether it is important for a CA management
 policy to change the CA distinguished name or not? If CA name change
 is not allowed in some CA management policies, we think existing
 applications should support the CA key pair changeover without change
 of CA distinguished name. 
 Please send any comments to "[email-masked]".

Best Regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mine Sakurai          E-mail: [email-masked]
5th Laboratory
Development Laboratories, NEC Networks, Tokyo, JAPAN

From: "David Chadwick" <[email-masked]>
Organization: University of Salford
To: [email-masked], <[email-masked]>
Date: Sat, 21 Oct 2000 16:08:25 +0100
Subject: Re: comments on draft-ietf-pkix-ldap-schema-01.txt
Reply-to: [email-masked]
CC: [email-masked]
Priority: normal

From:           	[email-masked]
To:             	[email-masked]
Subject:        	comments on draft-ietf-pkix-ldap-schema-01.txt
Date sent:      	Thu, 21 Sep 2000 14:18:15 -0400

> Greetings,
Tim
Apologies for the delay

> 
> Section 2:
> ----------
> I would prefer that the phrase "use the subschemasubentry attribute in
> the root DSE" be changed to "use the subschemasubentry attribute from
> the namingContext entry which is found in the root DSE".

I disagree with your proposed change for the following reasons:

firstly the namingContext entry is not found in the root DSE, but 
rather a pointer to the namingContext entry is found in the root 
DSE. But this does not help, as the subschema subentry itself is 
only mandatorily pointed to from the rootDSE, and not from the 
namingContext entry. This is assuming I have read 2251 correctly, 
viz:

If the server masters directory entries under one
   or more schema rules, there may be any number of values 
of the
   subschemaSubentry attribute in the root DSE.

> 
> Section 3.2:
> ------------
> In the BNF for "GeneralName", a single whitespace character appears
> (e.g. "rfc822 +").  Was this intentional?  It seems out of

I dont really mind either way here. I will let Steven be the 
authoritative voice on this

> place/misleading.
> 
> Editor's note on AuthorityKeyIdentifier:
> ----------------------------------------
> Seems to me that authority issuer name and authority certificate
> serial number could be useful.

What we really need is some LDAP server vendor (IBM??) to 
implement these matching rules and to give some feedback about 
which fields are really useful for users to use. At the moment we 
can only guess at what people will want to use in practice.

> 
> Section 4.1:
> ------------
> In the BNF for "CertificateListExactAssertion", the "$" after "Time"
> is OPTIONAL, correct?  It should only be needed if
> "DistributionPointName" is specified, I think.

Yes we could change the ABNF to put the  $ inside the DP 
construct.

> 
> Section 5 - ISSUE:
> ------------------
> I am not qualified to provide an opinion on this one.
> 
> Section 5.3.2 - first Editor's note:
> ------------------------------------
> I would like to see attribute type names (not just OIDs) be allowed.

The AC profile specifies that the attribute MUST be identified by its 
OID in the AC. Therefore if the user interface allows attribute 
names to be presented by the user, something has to map this into 
the correct OID, otherwise a wrong AC will be found by the LDAP 
server. If we specify an OID in the matching rule, then it must be 
the user interface that does the mapping. If we allow string names 
in the matching rule, it must be the server that does the mapping.

What do you think?

> 
> Section 5.3.2 - second Editor's note:
> -------------------------------------
> I would find 5.3.9 Time Specification Match to be useful.  I don't
> have experience with the others.
> 

Thanks for that.

David
> 
> Regards,
> Tim Hahn
> 
> Internet: [email-masked]
> Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
> phone: 607.752.6388     tie-line: 8/852.6388
> fax: 607.752.3681

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

Date: Fri, 20 Oct 2000 11:01:11 -0500
From: Dale Gustafson <[email-masked]>
To: Al Arsenault <[email-masked]>
CC: Polar Humenn <[email-masked]>, "Linn, John" <[email-masked]>, [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Al, Polar,

Let me also try to summarize.

I think we've arrived at the current state because the group genuinely perceives
the need for Attribute Certificates.  I think there is a common sense that there
is or will soon be a compelling need for secure applications to distribute and
utilize tamper-resistant, application specific data elements within the global
PKI.  It is envisioned that authoritative entities will deploy Attribute
Authority systems that manage the life cycle of these special certificates.  We
further speculate that each authoritative entity will work with it's various
constituents to define the form, fit, and function of a specific attribute
certificate that will be utilized by a well-defined set of applications.  This
application specific certificate's format and content will be updated from time
to time as the applications evolve, etc. under some management process
controlled by the authoritative entity.

Past experience has strongly suggested what NOT to do but has not necessarily
indicated the most appropriate course of action.

Logically, and assuming the need is real, there are at least three possible
approaches:

1. Embed the Attribute Certificate information in x.509 v3 Identification
Certificates

Each industry or market group (banking, finance, insurance, communications,
government, et. al.) can create a set non-critical extensions that allow their
application-specific information to be carried in a common public key
certificate or certificates.

In the near term (at least) this is the most effective approach because each
design can take a free ride on all of the PKI infrastructure that is being put
in place at great expense.  The downside is that the combined certificate
retains all of the properties of a public key certificate irrespective of
whether that makes sense for the attribute information and the secure
application(s) that will utilize it.

2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate

This has been suggested in the past but was not well received, likely because it
was obvious that significant additional overhead would be added to each
attribute certificate but it could not be shown that such a close coupling of
the attribute certificate and public key certificate would have technical merit
that justifies the cost.  Problems of keeping the ID certificate and attribute
together are eliminated but there are still two certificate chains.  The
infrastructure for and deployment of ID certificates can be utilized "as is".

3. Provide a Link from the Attribute Certificate to the Public Key Certificate

This approach appeared at the outset to be the most elegant and, most
importantly, appeared to be the most flexible.  It has just now become more
apparent that creating a reliable, "dynamic" link between the two certificates
is difficult.  This has been discussed at length recently.

Perhaps others can recall other approaches that have been suggested.

My sense is that the real value of a separate attribute certificate is that it
invites others with specific application expertise to join the process "earlier"
without making everyone's work overly complex -- if (and only if) that's true,
will people be willing to pay some reasonable price to accomplish the necessary
up-front planning.

What appears to be missing is a framework that enables secure application
builders to understand when they can "have at it" knowing they have a reasonably
stable environment around them.  That is, allows and encourages their innovative
work to move forward in  parallel with that of other industry and market
groups.  In order for that to happen, there needs to be a common understanding
that the basic problem is bounded and within range.

A framework for attribute certificates might better define many of the things we
have recently discussed:

 - encode / decode methods supported (ASN.1, XML, other)
 - commonly used data elements
 - encryption methods (selected attributes, full certificate)
 - delivery methods (SSL, S/MIME, directories, other)
 - certificate path creation / signature validation
 - certificate status checking
 - summary:  distinction between ID certificates and attribute certificates
 - other ?

Perhaps this has already been done elsewhere.  I suspect even an all-knowing
expert would have to look long and hard at the overall requirements for
attribute certificates before deciding that a single approach would suffice.

Comments?

Best Regards,

Dale Gustafson

Al Arsenault wrote:

> Polar Humenn wrote:
> >
> > Hi Al,
> >
> > The problem is that an Attribute Certificte Authority must be separate
> > from a Identity Certificate Authority, because it has control over the
> > attribute information. So, if we have the IDentity CA issues a certificate
> > of [IDCA,George,kGeorge] where, kGeorge is the public key of george. If
> > the Attribute Certificate Authority issues a new certificate (effectively
> > cross certifying George) [ACA,George,kGeorge,Attributes] what's the real
> > difference to having a separate data structure?
> >
> > Do you really think the correlation problem of a separate AC at the
> > Relying Party is that easy?
> >
> > Cheers,
> > -Polar
> >
> >
>
> In THAT particular system it was, because everything chained back to
> what was essentially a single trusted Root CA. (It was called a "Policy
> Approving Authority" or PAA, but it was in effect a single
> globally-trusted root.) And, name constraints were enforced throughout
> the system, providing a guarantee that unless some CA screwed up
> somewhere or a trusted human was an active attacker, every DN was indeed
> unique. (And such a screw-up or attacker would ultimately be detectable
> through other means.)
>
> Now, in other scenarios which don't have such a strictly-enforced
> policy, it's a different ballgame.  I've been dealing with it a lot
> lately, though, because my company primarily sells two products, one of
> which is a CA/PKI product and the other which is essentially an
> Attribute Certificate/PMI product. When implemented properly, each
> product is secure, and if they're integrated properly, the combination
> is secure (for whatever values of "secure").  But if some customer wants
> to do something new with them - which happens a lot, because attribute
> certificates are so new in practice - we work carefully with them to
> make sure that they're not doing anything foolish, or that will inhibit
> the desired security level.
>
> The bottom line on all of this is that there are ways to do things
> "securely", and ways to do them "insecurely" for whatever definition of
> "secure" you prefer.  What we need to do in the standards world is (1)
> do the best we can to ensure that "secure" is possible with conformant
> products; and (2) make clear where the risks lie.  I give a talk on
> occasion whose theme is "standards are no substitute for proper system
> engineering."  I really believe that.
>
>                 Al Arsenault
>                 Chief Security Architect
>                 Diversinet Corp.

Date: Fri, 20 Oct 2000 06:38:12 -0700
From: Ed Gerck <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: simply a bad name model?, was Re: Comments on  draft-ietf-pkix-ac509prof-05.txt

[trimming CC list]

Dave:

As we know, PKI DNs are quite arbitrary when compared with IP numbers, which
are constants in routers and are further defined by a physical topology.  PKI DNs are
also quite arbitrary when compared with DNS names, which are in turn also quite
arbitrary when compared with IPs. So, DNS names are fully  independent from the IP
addresses used and PKI DNs have no relationship whatsoever with any of them.

Thus, I find the argument to change DNs not so compelling as with changing  IP
addresses. Any organization can and should be able to change its PKI DNs without
worrying about the needs of the network layer!

We should ask the question whether  this WG is not creating artificial constraints on
names simply because a bad name model is used and not how can we justify the bad
name model used.  It is OK IMO for this WG to use a bad name model but it is not
OK for this WG to raise this choice to the level of a "requirement."

Cheers,

Ed Gerck

"David P. Kemp" wrote:

> It's happened before, when organizations with isolated IP networks
> decided to connect to the Internet.  It was a royal pain to get a block
> of official IP addresses and renumber all your machines, but it was
> necessary, so people did it.  (This was before NAT and masquerading,
> of course.)
>
> At some point, organizations with isolated PKIs might decide to get an
> "official" DN subtree and issue certificates within it.  After an
> organization makes a decision to operate in a coordinated way with
> other organizations, implementation of name constraints in cross certs
> and replacement of user certificates is not particularly daunting.
> Less daunting than IP renumbering, at any rate.
>
> "Compliance" is not the problem.  The problem is understanding that an
> Inter-PKI cannot really work if users pick their own DNs any more than
> the Internet could work if users picked their own IP addresses.

> Dave
>
> > From: Polar Humenn <[email-masked]>
> >

From: Michael Myers <[email-masked]>
To: Polar Humenn <[email-masked]>, Al Arsenault <[email-masked]>
Cc: "Linn, John" <[email-masked]>, Dale Gustafson <[email-masked]>, [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Thu, 19 Oct 2000 18:10:26 -0700

Polar,

Mike

Date: Thu, 19 Oct 2000 17:39:07 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Al Arsenault <[email-masked]>
cc: "Linn, John" <[email-masked]>, Dale Gustafson <[email-masked]>, [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

On Thu, 19 Oct 2000, Al Arsenault wrote:

> Polar Humenn wrote:
> > Do you really think the correlation problem of a separate AC at the
> > Relying Party is that easy?
> 
> In THAT particular system it was, because everything chained back to
> what was essentially a single trusted Root CA. (It was called a "Policy
> Approving Authority" or PAA, but it was in effect a single
> globally-trusted root.) And, name constraints were enforced throughout
> the system, providing a guarantee that unless some CA screwed up
> somewhere or a trusted human was an active attacker, every DN was indeed
> unique. (And such a screw-up or attacker would ultimately be detectable
> through other means.)

True. However, all parties know (or should I say suspect) extactly what
the common trusted root is.

In the general case of PKI, all I really have is a notion of being able to
authenticate a holder of a particular private key. That's it! I have some
"hint" called a certificate which may give him a name in some space. BTW,
He doesn't even have to give me that hint. But if he does, the certificate
he gives me may not mean anything to me. That is, I might not trust the
certificate's CA. However, it might help me find a certificate I have for
him that I do trust, (under the same DN, or a different one?). I guess
this is called path discovery?

Some SSL implementations don't really work like that. The client delivers a
chain to a root, and its compared against a "trusted" root certificate
registered in the servers space. That's not really a
"cross-certification", but is the practical side of things. 

To cross certify, I should really have my bonafide root CA create a
certificate by extracting the public key from the "trusted" root
certificates and giving the new certificate a name. Correct?

This approach I believe is the approach that Carlisle suggests. 

On the cross certify, especially with a ubiquitous directory, I would like
to use the CA name in the "trusted' certificate given to me. That would
make it easy to locate. However, that may violate name constraints of my
own CA because I may not be allowed to issue certificates in that space.
Isn't that right? I would have to use a different name.

I guess that's why I'm skeptical that names actually work at all between
at least three parties. Of course, as you have concluded and determined
still takes a lot of work, you need to initally have all parties *believe*
they are under the same trusted root. (and actually implemented it as
such).

> I give a talk on occasion whose theme is "standards are no substitute
> for proper system engineering."  I really believe that.

I agree. However, when you want to be "interoperable" it would be nice if
the standards could constrain, if not eliminate, the risks where possible.

Cheers,
-Polar

> Now, in other scenarios which don't have such a strictly-enforced
> policy, it's a different ballgame.  I've been dealing with it a lot
> lately, though, because my company primarily sells two products, one of
> which is a CA/PKI product and the other which is essentially an
> Attribute Certificate/PMI product. When implemented properly, each
> product is secure, and if they're integrated properly, the combination
> is secure (for whatever values of "secure").  But if some customer wants
> to do something new with them - which happens a lot, because attribute
> certificates are so new in practice - we work carefully with them to
> make sure that they're not doing anything foolish, or that will inhibit
> the desired security level.
> 
> The bottom line on all of this is that there are ways to do things
> "securely", and ways to do them "insecurely" for whatever definition of
> "secure" you prefer.  What we need to do in the standards world is (1)
> do the best we can to ensure that "secure" is possible with conformant
> products; and (2) make clear where the risks lie.  I give a talk on
> occasion whose theme is "standards are no substitute for proper system
> engineering."  I really believe that.
> 
> 		Al Arsenault
> 		Chief Security Architect
> 		Diversinet Corp.
> 

From: Michael Zolotarev <[email-masked]>
To: Russ Housley <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: RE: TSP. Version 10, Removal of SIA Extension
Date: Fri, 20 Oct 2000 08:14:26 +1000

Sounds like its time to get SIA back to TSS draft, Denis :)

> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, 20 October 2000 6:26
> To: Denis Pinkas
> Cc: [email-masked]
> Subject: Re: TSP. Version 10, Removal of SIA Extension
> 
> 
> Tim and I have already started the addition of 
> subjectInfoAccess in the 
> next son-of-RFC2459 draft.  I assigned the OID for it 
> yesterday.  I posted 
> it to the IMC Web site earlier today.
> 
> Russ
> 
> At 05:15 PM 10/19/2000 +0200, Denis Pinkas wrote:
> >Francois,
> >
> > > Hi Denis,
> > >
> > > I just noticed that in the latest draft you completely 
> remove from Section
> > > 2.3 the text about a TSA's certificate possibly 
> containing a Subject
> > > Information Access (SIA) extension. From the many 
> comments received during
> > > last call against the previous draft, I did not recall 
> anyone asking for
> > > the SIA extension to be removed.
> > >
> > > Did I miss anything or is there a particular reason why 
> the SIA extension
> > > was removed?
> >
> >You read the draft very carefully, congratulations !
> >
> >I forgot to mention this point. At the Barcelona ISSE 
> meeting, I had a
> >discussion with Stephen Kent about the progression of this 
> draft to RFC. We
> >came to the conclusion that this draft should not be delayed 
> any longer.
> >Since the SIA extension is not defined in RFC 2459, we would 
> have had to
> >wait until "son-of-RFC 2459" is published. However, we did 
> not wanted to
> >hold the draft until "son-of-RFC 2459" got its own RFC number.
> >
> >Since the SIA was not mandatory to implement, it has been 
> suppressed. We now
> >have two options:
> >
> >1) either to re-incorporate it when the TSP Proposed 
> Standard will move to
> >Standard,
> >2) or define this extension directly in "son-of-RFC 2459" 
> (Tim can you hear
> >me ???)
> >
> >Regards,
> >
> >Denis
> >
> > > Regards,
> > >
> > > Francois
> > > ___________________________________
> > > Francois Rousseau
> > > Director of Standards and Conformance
> > > Chrysalis-ITS
> > > 1688 Woodward Drive
> > > Ottawa, Ontario, CANADA, K2C 3R7
> > > [email-masked]      Tel. (613) 723-5076 ext. 419
> > > http://www.chrysalis-its.com     Fax. (613) 723-5078
> 

Date: Thu, 19 Oct 2000 16:26:03 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: TSP. Version 10, Removal of SIA Extension
Cc: [email-masked]

Tim and I have already started the addition of subjectInfoAccess in the 
next son-of-RFC2459 draft.  I assigned the OID for it yesterday.  I posted 
it to the IMC Web site earlier today.

Russ

At 05:15 PM 10/19/2000 +0200, Denis Pinkas wrote:
>Francois,
>
> > Hi Denis,
> >
> > I just noticed that in the latest draft you completely remove from Section
> > 2.3 the text about a TSA's certificate possibly containing a Subject
> > Information Access (SIA) extension. From the many comments received during
> > last call against the previous draft, I did not recall anyone asking for
> > the SIA extension to be removed.
> >
> > Did I miss anything or is there a particular reason why the SIA extension
> > was removed?
>
>You read the draft very carefully, congratulations !
>
>I forgot to mention this point. At the Barcelona ISSE meeting, I had a
>discussion with Stephen Kent about the progression of this draft to RFC. We
>came to the conclusion that this draft should not be delayed any longer.
>Since the SIA extension is not defined in RFC 2459, we would have had to
>wait until "son-of-RFC 2459" is published. However, we did not wanted to
>hold the draft until "son-of-RFC 2459" got its own RFC number.
>
>Since the SIA was not mandatory to implement, it has been suppressed. We now
>have two options:
>
>1) either to re-incorporate it when the TSP Proposed Standard will move to
>Standard,
>2) or define this extension directly in "son-of-RFC 2459" (Tim can you hear
>me ???)
>
>Regards,
>
>Denis
>
> > Regards,
> >
> > Francois
> > ___________________________________
> > Francois Rousseau
> > Director of Standards and Conformance
> > Chrysalis-ITS
> > 1688 Woodward Drive
> > Ottawa, Ontario, CANADA, K2C 3R7
> > [email-masked]      Tel. (613) 723-5076 ext. 419
> > http://www.chrysalis-its.com     Fax. (613) 723-5078

Date: Thu, 19 Oct 2000 15:21:40 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Polar Humenn <[email-masked]>
CC: "Linn, John" <[email-masked]>, Dale Gustafson <[email-masked]>, [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Polar Humenn wrote:
> 
> Hi Al,
> 
> The problem is that an Attribute Certificte Authority must be separate
> from a Identity Certificate Authority, because it has control over the
> attribute information. So, if we have the IDentity CA issues a certificate
> of [IDCA,George,kGeorge] where, kGeorge is the public key of george. If
> the Attribute Certificate Authority issues a new certificate (effectively
> cross certifying George) [ACA,George,kGeorge,Attributes] what's the real
> difference to having a separate data structure?
> 
> Do you really think the correlation problem of a separate AC at the
> Relying Party is that easy?
> 
> Cheers,
> -Polar
> 
>

In THAT particular system it was, because everything chained back to
what was essentially a single trusted Root CA. (It was called a "Policy
Approving Authority" or PAA, but it was in effect a single
globally-trusted root.) And, name constraints were enforced throughout
the system, providing a guarantee that unless some CA screwed up
somewhere or a trusted human was an active attacker, every DN was indeed
unique. (And such a screw-up or attacker would ultimately be detectable
through other means.)

Now, in other scenarios which don't have such a strictly-enforced
policy, it's a different ballgame.  I've been dealing with it a lot
lately, though, because my company primarily sells two products, one of
which is a CA/PKI product and the other which is essentially an
Attribute Certificate/PMI product. When implemented properly, each
product is secure, and if they're integrated properly, the combination
is secure (for whatever values of "secure").  But if some customer wants
to do something new with them - which happens a lot, because attribute
certificates are so new in practice - we work carefully with them to
make sure that they're not doing anything foolish, or that will inhibit
the desired security level.

The bottom line on all of this is that there are ways to do things
"securely", and ways to do them "insecurely" for whatever definition of
"secure" you prefer.  What we need to do in the standards world is (1)
do the best we can to ensure that "secure" is possible with conformant
products; and (2) make clear where the risks lie.  I give a talk on
occasion whose theme is "standards are no substitute for proper system
engineering."  I really believe that.

		Al Arsenault
		Chief Security Architect
		Diversinet Corp.

Date: Thu, 19 Oct 2000 14:52:09 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Al Arsenault <[email-masked]>
cc: "Linn, John" <[email-masked]>, Dale Gustafson <[email-masked]>, [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Hi Al,

The problem is that an Attribute Certificte Authority must be separate
from a Identity Certificate Authority, because it has control over the
attribute information. So, if we have the IDentity CA issues a certificate
of [IDCA,George,kGeorge] where, kGeorge is the public key of george. If
the Attribute Certificate Authority issues a new certificate (effectively
cross certifying George) [ACA,George,kGeorge,Attributes] what's the real
difference to having a separate data structure?

Do you really think the correlation problem of a separate AC at the
Relying Party is that easy?

Cheers,
-Polar

On Thu, 19 Oct 2000, Al Arsenault wrote:

> To further expand on John's comments:
> 
> "Linn, John" wrote:
> > 
> > Polar writes, excerpting:
> > 
> > > Quite frankly, I'd like to understand why attribute certificates are
> > > needed at all? Why not just put the attributes in the subject's PKC?
> > >
> > 
> > X.509 allows attributes to be stored in PKCs, specifically within the
> > subjectDirectoryAttributes element, as an alternative to representing them
> > within separate ACs.  Early in the development of the PKIX AC profile, I
> > suggested that PKIX also reflect this option.  This choice was unpopular in
> > discussion and therefore not adopted, partly because of concern (also
> > discussed within the introduction to draft-ietf-pkix-ac509prof-05) that
> > inclusion of attribute data within PKCs would imply a need for more frequent
> > revocation and partly because some environments dictate management of
> > identity vs. attribute data by separate authorities.  
> 
> AWA: It should also be noted that numerous contributors to PKIX
> (including myself, in a former life) have a lot of experience (10 years?
> longer?) with a very large, very expensive operational PKI that did
> exactly this - put all of the attributes - clearances, privileges, etc.
> - in the subjectDirectoryAttributes element of an X.509v3 certificate. 
> (Actually, that was the second iteration.  The first iteration, which
> was built prior to X.509v3 and thus used X.509v1 certificates, put all
> those attributes in the subjectPublicKey field.  My, that was fun!)
> Experience in that system indicated that a lot of those attributes
> changed very frequently - on the order of every few months, if the
> reorganizations were spinning out of control again, and on the order of
> every couple of years as a matter of business. When the system was
> small, this wasn't a major problem - you just revoked the old certs
> every time you reorganized and issued new ones.  But then this led to
> the situation that revocation checking got ugly - big CRLs or lots of
> real-time checking - and the number of certificates in the system at one
> time exploded.  There was a massive groundswell of support for moving to
> a structure whereby the actual PKC had information that was reasonably
> stable, and didn't normally change too often; and to find some other
> structure in which to put the "transient" information.  Attribute Certs
> seemed to fit the bill.
> 
> And, as John points out, there's also the issue of who controls the
> attributes.  As a general rule, the people who are responsible for
> certifying identities and issuing PKCs - often called the "Pass and
> Identification" people - have no jurisdiction over most of the
> attributes under consideration. So it was easier to have the Attribute
> Authority be the entity that actually controlled the attribute, instead
> of some CA doing it on the basis of "well, he said so."
> 
> Now, as John correctly points out, this case is in some ways unique, and
> the circumstances will not be the same in other situations.  I can
> easily conceive of situations in which attribute certificates do not add
> substantial value - several of my customers fit into that category right
> now.  But the structures were advanced and supported by some set of
> people because in actual experience it seemed to be the right answer.
> 
> 
> >These factors are
> > valid, though may apply in greater or lesser degree in different cases and
> > under different operational assumptions.  It's possible, I believe, that
> > representation of attributes in PKCs can be workable and effective in some
> > contexts, particularly if revocation is accomplished via on-line techniques
> > rather than via CRLs.
> > 
> 
> AWA: I agree, although I'm less convinced that OCSP-vice-CRLs is
> important.  I think it's more closely related to how often the attribute
> changes.
> 
> > --jl
> 
> 
> 
> 
> 			Al Arsenault
> 

Date: Thu, 19 Oct 2000 14:40:34 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: "Linn, John" <[email-masked]>
CC: "'Polar Humenn'" <[email-masked]>, Dale Gustafson <[email-masked]>, [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

To further expand on John's comments:

"Linn, John" wrote:
> 
> Polar writes, excerpting:
> 
> > Quite frankly, I'd like to understand why attribute certificates are
> > needed at all? Why not just put the attributes in the subject's PKC?
> >
> 
> X.509 allows attributes to be stored in PKCs, specifically within the
> subjectDirectoryAttributes element, as an alternative to representing them
> within separate ACs.  Early in the development of the PKIX AC profile, I
> suggested that PKIX also reflect this option.  This choice was unpopular in
> discussion and therefore not adopted, partly because of concern (also
> discussed within the introduction to draft-ietf-pkix-ac509prof-05) that
> inclusion of attribute data within PKCs would imply a need for more frequent
> revocation and partly because some environments dictate management of
> identity vs. attribute data by separate authorities.  

AWA: It should also be noted that numerous contributors to PKIX
(including myself, in a former life) have a lot of experience (10 years?
longer?) with a very large, very expensive operational PKI that did
exactly this - put all of the attributes - clearances, privileges, etc.
- in the subjectDirectoryAttributes element of an X.509v3 certificate. 
(Actually, that was the second iteration.  The first iteration, which
was built prior to X.509v3 and thus used X.509v1 certificates, put all
those attributes in the subjectPublicKey field.  My, that was fun!)
Experience in that system indicated that a lot of those attributes
changed very frequently - on the order of every few months, if the
reorganizations were spinning out of control again, and on the order of
every couple of years as a matter of business. When the system was
small, this wasn't a major problem - you just revoked the old certs
every time you reorganized and issued new ones.  But then this led to
the situation that revocation checking got ugly - big CRLs or lots of
real-time checking - and the number of certificates in the system at one
time exploded.  There was a massive groundswell of support for moving to
a structure whereby the actual PKC had information that was reasonably
stable, and didn't normally change too often; and to find some other
structure in which to put the "transient" information.  Attribute Certs
seemed to fit the bill.

And, as John points out, there's also the issue of who controls the
attributes.  As a general rule, the people who are responsible for
certifying identities and issuing PKCs - often called the "Pass and
Identification" people - have no jurisdiction over most of the
attributes under consideration. So it was easier to have the Attribute
Authority be the entity that actually controlled the attribute, instead
of some CA doing it on the basis of "well, he said so."

Now, as John correctly points out, this case is in some ways unique, and
the circumstances will not be the same in other situations.  I can
easily conceive of situations in which attribute certificates do not add
substantial value - several of my customers fit into that category right
now.  But the structures were advanced and supported by some set of
people because in actual experience it seemed to be the right answer.

>These factors are
> valid, though may apply in greater or lesser degree in different cases and
> under different operational assumptions.  It's possible, I believe, that
> representation of attributes in PKCs can be workable and effective in some
> contexts, particularly if revocation is accomplished via on-line techniques
> rather than via CRLs.
> 

AWA: I agree, although I'm less convinced that OCSP-vice-CRLs is
important.  I think it's more closely related to how often the attribute
changes.

> --jl

			Al Arsenault

Date: Thu, 19 Oct 2000 13:57:57 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: "Linn, John" <[email-masked]>
cc: Dale Gustafson <[email-masked]>, [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

On Thu, 19 Oct 2000, Linn, John wrote:

> Polar writes, excerpting: 
> 
> > Quite frankly, I'd like to understand why attribute certificates are
> > needed at all? Why not just put the attributes in the subject's PKC?
> > 
> 
> X.509 allows attributes to be stored in PKCs, specifically within the
> subjectDirectoryAttributes element, as an alternative to representing them
> within separate ACs.  Early in the development of the PKIX AC profile, I
> suggested that PKIX also reflect this option.  This choice was unpopular in
> discussion and therefore not adopted, partly because of concern (also
> discussed within the introduction to draft-ietf-pkix-ac509prof-05) that
> inclusion of attribute data within PKCs would imply a need for more frequent
> revocation and partly because some environments dictate management of
> identity vs. attribute data by separate authorities.  These factors are
> valid, though may apply in greater or lesser degree in different cases and
> under different operational assumptions.  It's possible, I believe, that
> representation of attributes in PKCs can be workable and effective in some
> contexts, particularly if revocation is accomplished via on-line techniques
> rather than via CRLs. 

I see your point. However, since one may have *many* certificates relating
to a public key, or a even a DN, there is no need to revoke the "previous"
certificates.

In the needs for "other" authorities to issue attributes, they can issue
different certificates with the same public key, and quite possibly the
same DN (but let's not get into that :), and not have to revoke the
original certificate.

And in this day in age, I agree with you that revocation should be
accomplished via on-line techniques and NOT CRLs. They just go back to the
day where your credit card was looked up on a book at the cash register.
Still the cashier called in any over $50. My credit card now gets get
checked on-line all the time, even if I spend 64 cents on a cup of coffee.

Cheers,
-Polar

> --jl

From: "Linn, John" <[email-masked]>
To: "'Polar Humenn'" <[email-masked]>, Dale Gustafson <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Thu, 19 Oct 2000 13:27:54 -0400

Polar writes, excerpting: 

> Quite frankly, I'd like to understand why attribute certificates are
> needed at all? Why not just put the attributes in the subject's PKC?
> 

X.509 allows attributes to be stored in PKCs, specifically within the
subjectDirectoryAttributes element, as an alternative to representing them
within separate ACs.  Early in the development of the PKIX AC profile, I
suggested that PKIX also reflect this option.  This choice was unpopular in
discussion and therefore not adopted, partly because of concern (also
discussed within the introduction to draft-ietf-pkix-ac509prof-05) that
inclusion of attribute data within PKCs would imply a need for more frequent
revocation and partly because some environments dictate management of
identity vs. attribute data by separate authorities.  These factors are
valid, though may apply in greater or lesser degree in different cases and
under different operational assumptions.  It's possible, I believe, that
representation of attributes in PKCs can be workable and effective in some
contexts, particularly if revocation is accomplished via on-line techniques
rather than via CRLs. 

--jl

From: "Stephen McConnell" <[email-masked]>
To: "Polar Humenn" <[email-masked]>, "Dale Gustafson" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Electronic Commerce DTF" <[email-masked]>
Subject: Impact on OMG's CSIv2 (was - RE: Comments on draft-ietf-pkix-ac509prof-05.txt)
Date: Thu, 19 Oct 2000 18:10:13 +0200
Importance: Normal

Polar et. al.

Some comments from an OMG/EC perspective:

	- EC has a significant subscribed list of end-user
	  organisations that will end up using this stuff,
	  possibly not in the pure IETF model of data
	  structures, but in terms of the real application
        level problems based on the emerging CSIv2
	  OMG's cross-domain security interoperability spec).

  	- Members of EC are watching closely the CSIv2 process,
	  because we know the CORBA security doesn't work beyond a
	  single enterprise, and the CSIv2 is the silver bullet.
	  Because CSIv2 depends on Attribute Certificates, this
	  means  that the strength of CSIv2 is limited by the
	  strength of X509 (2000).  If there are holes in X509
	  (2000) it means that there are holes in CSIv2.  CSIv2 has
	  been adopted. It will be presumably enter a finalisation
	  phase during the next meeting.  Based on several emails
	  sent out on this thread, my conclusion is that
	  X509 (2000) isn't ready for prime time - adding a
	  "by-the-way there are security holes and there are
	  optional vendor fixes (if they want to) but, ooh,
	  by the way, you, the customer, you should be selecting
	  your provider on the basis your technical due-diligence"
	  (etc.) ... simply sucks. But lets look at what this means
	  in terms of the impact on CSIv2:

	  1. CSIv2 is dependent on the strength of X509 (2000), in
	     particular, the dependence that CSIv2 places on
	     Attribute Certificates

	  2. Holes have been identified by Polar in the Attribute
	     Certificate model and confirmed by several other
	     authorities on this list.

	  3. What I'm missing here is this thread is the distinction
	     between the following:

		   OMG CSIv2 functionality

	            - why CSIv2 needs Attribute Certificates
			  in the first place ?

			- is there any reason why CSIv2 cannot use
			  X509 Classic instead ?

		   OMG PKI Service functionality

			- currently defines mechanisms for
			  certificate issue and verification,

			- is missing an extendable valuetype
			  definition of a certificate to sync X509
			  and CSIv2 with the PKI service

		   Application level functionality

			- getting a clear distinction between
			  application level (which is where I would
		  	  have through Attribute Certificates are
			  relevant) as opposed to CSIv2 service
			  functionality.

Cheers, Steve.

P.S.  Please consider this email as a vote for fully expanded acronyms.  For
myself, AA stands for "Alcoholics Anonymous" and AC stands for "Andersen
Consulting"!

Date: Thu, 19 Oct 2000 17:15:23 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked], Tim Polk <[email-masked]>
CC: [email-masked]
Subject: Re: TSP. Version 10, Removal of SIA Extension

Francois,

> Hi Denis,
> 
> I just noticed that in the latest draft you completely remove from Section
> 2.3 the text about a TSA's certificate possibly containing a Subject
> Information Access (SIA) extension. From the many comments received during
> last call against the previous draft, I did not recall anyone asking for
> the SIA extension to be removed.
> 
> Did I miss anything or is there a particular reason why the SIA extension
> was removed?

You read the draft very carefully, congratulations !

I forgot to mention this point. At the Barcelona ISSE meeting, I had a
discussion with Stephen Kent about the progression of this draft to RFC. We
came to the conclusion that this draft should not be delayed any longer.
Since the SIA extension is not defined in RFC 2459, we would have had to
wait until "son-of-RFC 2459" is published. However, we did not wanted to
hold the draft until "son-of-RFC 2459" got its own RFC number.

Since the SIA was not mandatory to implement, it has been suppressed. We now
have two options:

1) either to re-incorporate it when the TSP Proposed Standard will move to
Standard,
2) or define this extension directly in "son-of-RFC 2459" (Tim can you hear
me ???)

Regards,

Denis

> Regards,
> 
> Francois
> ___________________________________
> Francois Rousseau
> Director of Standards and Conformance
> Chrysalis-ITS
> 1688 Woodward Drive
> Ottawa, Ontario, CANADA, K2C 3R7
> [email-masked]      Tel. (613) 723-5076 ext. 419
> http://www.chrysalis-its.com     Fax. (613) 723-5078

Date: Thu, 19 Oct 2000 11:08:09 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Dale Gustafson <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Hi Doug et al,

BTW, I took OMG Electronic Commerce Group <[email-masked]> off the list,
because Doug Moss complained.

On Thu, 19 Oct 2000, Dale Gustafson wrote:

> Polar,
> 
> To attempt to get at your concern about what happens when the holder needs to
> update their signature key and certificate -- perhaps we could consider adding an
> optional URI pointer to the AC that tells the RP where to find the AA's "key
> update" service.

I don't think it's my concern any longer. I cannot see how an AC can
reference an entity by a DN, because that DN has no hope of being unique
unless there is a ubiquitous TRUSTED directory. That is impossible.

An AC can only reference a public key. If the public key is updated, the
AC must be updated as well.

Quite frankly, I'd like to understand why attribute certificates are
needed at all? Why not just put the attributes in the subject's PKC?

The correlation problem is more complex than certificate verification
itself. The certificate chain verification problem is so complex servers
were invented to do it for us, creating yet another kink in the trust
model. Is there now a need to create server that verifies the PK
certificate chain and AC and its certificate chain together?

I've talked with a couple of vendors so far, and they just create
extensions in their X.509 certificates for various things concerning
access control and auditing. This seems to be much cheaper. Also, that way
they don't have to change anything, like SSL stacks, and other things that
just look at PK certificate particulars. Relying party software that
doesn't pay attention to the new attributes also doesn't have to be
re-engineered. An if it does, it only has to look in the PKC, and not
other information delivered by other protocols, i.e. the AC.

Is the only real reason for the attribute certificate to issue attributes
to identifiers that do not have public/private keys, such as a Kerberos
name, or an email name?

Cheers,
-Polar

> If requested by an RP, the service would be able to, given a particular AC,
> provide a newer PKC (or list of PKCs) that can be used to verify the holder's
> digital signature.  Conceivably, this is one method that would allow an AC to
> reliably reference PKCs that do not exist at the time the AC is issued.
> 
> Questions:
> ----------
> 
> Is this additional capability important enough that a (perhaps not-free) service
> would be a viable solution ?
> 
> Is it almost always better / cheaper / faster to simply reissue the AC(s)
> whenever the holder's PKC is updated / replaced?
> 
> Are there technical reasons why this approach wouldn't work?
> 
> Best Regards,
> 
> Dale Gustafson
> 
> 
> Polar Humenn wrote:
> 
> > Tom,
> >
> > >      Since ObjectDigestInfo is already in the standard, those new syntaxes
> > > I suggested earlier today are redundant, and I hope that I will be forgiven
> > > for them.  IMO the correct thing to do in the profile is to recommend that
> > > with digestedObjectType publicKeyCert.  In those cases where entityName is
> > > used with underlying PKC authentication but it is the AA's intent that only
> > >      Do we need a new extension to permit the listing of multiple PKC's (by
> > > An attribute or extension is the only acceptable approach to me, unless we
> > > > > You are proposing syntax that is no longer compatible with X.509.  I am
> > > >Hmmm. I only went on that taking into account Tom and Denises suggestion.
> > > > > >I still think that this solution doesn't quite solve the problem, but
> > > is a
> > > > > >good start.  In fact Tom Gindin's suggestion just came in and includes
> > > > > >The fact is that the entityName option still contains a DN and the RP
> > > MUST
> > > > > >option, the DN MUST verifiable and uniquely name an entity within the
> > > PKI
> > > > > >AA belongs belongs to behave in its creation of unique DN. Therefore,
> > > > > >Therefore, it would still probably be better to use the Issuer/Serial
> > > and
> > > > > >Of course, when an application authenticates to an RP using PKCs this
> > > ties
> > > > > >the authorization to a particular certificate. Apparently that was not
> > > > > >desirable due to the effect of key rollover and new certificates being
> > > > > >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> > > > > >uniquely name an entity within the PKI of the AC issuer. The PKC named
> > > by
> > > > > >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> > > > > >    the holder's PK certificate MUST be uniquely found under the same
> > > root
> > > > > >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> > > > > >    The entire certificate path starting with the holder's PKC and the
> > > PKC
> > > > > >Note: there is *still* a problem with AC targeting and proxying using
> > > > > >just DNs.
> > > > > >
> > > > > >Cheers,
> > > > > >-Polar
> > > > > >
> > > > > >

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: TSP. Version 10, Removal of SIA Extension
Date: Thu, 19 Oct 2000 10:55:13 -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_01C039DC.962B91C0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Denis,

I just noticed that in the latest draft you completely remove from Section
2.3 the text about a TSA's certificate possibly containing a Subject
Information Access (SIA) extension. From the many comments received during
last call against the previous draft, I did not recall anyone asking for the
SIA extension to be removed.

Did I miss anything or is there a particular reason why the SIA extension
was removed?

Regards,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

------_=_NextPart_001_01C039DC.962B91C0
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.2650.12">
<TITLE>RE: TSP. Version 10, Removal of SIA Extension</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I just noticed that in the latest draft you =
completely remove from Section 2.3 the text about a TSA's certificate =
possibly containing a Subject Information Access (SIA) extension. From =
the many comments received during last call against the previous draft, =
I did not recall anyone asking for the SIA extension to be =
removed.</FONT></P>

<P><FONT SIZE=3D2>Did I miss anything or is there a particular reason =
why the SIA extension was removed?</FONT>
</P>

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

<P><FONT SIZE=3D2>Francois</FONT>
<BR><FONT SIZE=3D2>___________________________________</FONT>
<BR><FONT SIZE=3D2>Francois Rousseau</FONT>
<BR><FONT SIZE=3D2>Director of Standards and Conformance</FONT>
<BR><FONT SIZE=3D2>Chrysalis-ITS</FONT>
<BR><FONT SIZE=3D2>1688 Woodward Drive</FONT>
<BR><FONT SIZE=3D2>Ottawa, Ontario, CANADA, K2C 3R7</FONT>
<BR><FONT =
SIZE=3D2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Tel. =
(613) 723-5076 ext. 419</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.chrysalis-its.com" =
TARGET=3D"_blank">http://www.chrysalis-its.com</A>&nbsp;&nbsp;&nbsp;&nbs=
p; Fax. (613) 723-5078</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C039DC.962B91C0--

Date: Thu, 19 Oct 2000 08:50:10 -0500
From: Dale Gustafson <[email-masked]>
To: Polar Humenn <[email-masked]>
CC: [email-masked], Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Polar,

To attempt to get at your concern about what happens when the holder needs to
update their signature key and certificate -- perhaps we could consider adding an
optional URI pointer to the AC that tells the RP where to find the AA's "key
update" service.

If requested by an RP, the service would be able to, given a particular AC,
provide a newer PKC (or list of PKCs) that can be used to verify the holder's
digital signature.  Conceivably, this is one method that would allow an AC to
reliably reference PKCs that do not exist at the time the AC is issued.

Questions:
----------

Is this additional capability important enough that a (perhaps not-free) service
would be a viable solution ?

Is it almost always better / cheaper / faster to simply reissue the AC(s)
whenever the holder's PKC is updated / replaced?

Are there technical reasons why this approach wouldn't work?

Best Regards,

Dale Gustafson

Polar Humenn wrote:

> >      Since ObjectDigestInfo is already in the standard, those new syntaxes
> > I suggested earlier today are redundant, and I hope that I will be forgiven
> > for them.  IMO the correct thing to do in the profile is to recommend that
> > with digestedObjectType publicKeyCert.  In those cases where entityName is
> > used with underlying PKC authentication but it is the AA's intent that only
> >      Do we need a new extension to permit the listing of multiple PKC's (by
> > An attribute or extension is the only acceptable approach to me, unless we
> > > > You are proposing syntax that is no longer compatible with X.509.  I am
> > >Hmmm. I only went on that taking into account Tom and Denises suggestion.
> > > > >I still think that this solution doesn't quite solve the problem, but
> > is a
> > > > >good start.  In fact Tom Gindin's suggestion just came in and includes
> > > > >The fact is that the entityName option still contains a DN and the RP
> > MUST
> > > > >option, the DN MUST verifiable and uniquely name an entity within the
> > PKI
> > > > >AA belongs belongs to behave in its creation of unique DN. Therefore,
> > > > >Therefore, it would still probably be better to use the Issuer/Serial
> > and
> > > > >Of course, when an application authenticates to an RP using PKCs this
> > ties
> > > > >the authorization to a particular certificate. Apparently that was not
> > > > >desirable due to the effect of key rollover and new certificates being
> > > > >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> > > > >uniquely name an entity within the PKI of the AC issuer. The PKC named
> > by
> > > > >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> > > > >    the holder's PK certificate MUST be uniquely found under the same
> > root
> > > > >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> > > > >    The entire certificate path starting with the holder's PKC and the
> > PKC
> > > > >Note: there is *still* a problem with AC targeting and proxying using
> > > > >just DNs.
> > > > >
> > > > >Cheers,
> > > > >-Polar
> > > > >
> > > > >

Date: Thu, 19 Oct 2000 10:30:04 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Russ Housley <[email-masked]>
CC: Polar Humenn <[email-masked]>, [email-masked], Sharon Boeyen <[email-masked]>, "Hoyt L. Kesterson II" <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Russ,

> An attribute or extension is the only acceptable approach to me, unless we

Since you said ... "unless we coordinate with X.509 agrees to make the same
change to the base syntax", there are two solutions, not a single acceptable
approach. On that basis, I agree with you.

We can certainly attempt to coordinate with ISO, since the Orlando meeting
is coming. I am a member of the ISO defect report team and can certainly
bring the attention of the ISO group on that topic. :-)

Denis

> Russ

From: "Parag Namjoshi" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "IETF-PXIX" <[email-masked]>
Subject: Re: TSP. Version 10
Date: Thu, 19 Oct 2000 12:55:13 +0530

Hi Denis,

A few minor details.

1. The PKIXTSP ASN.1 module does not define/import PKIFreeText.
2. The text on page 8 refers to PolicyInformation, which is no longer used.
I believe text should refer to TSAPolicyId instead. (ASN.1 module imports
PolicyInformation too.)

Parag.

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "IETF-PXIX" <[email-masked]>
Sent: Friday, October 13, 2000 4:32 PM
Subject: TSP. Version 10

>
> A new version of the Time Stamping Protocol has been placed on the web
> server. A URL for this Internet-Draft is:
>
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-10.txt
>
> This version addresses the comments received during the IESG last call
> period.
>
> Besides the changes made to accommodate the 24 comments raised by Russ
> Housley, the abstract and the introduction have been modified, by myself
and
> Steve Kent, in order to address some of the concerns raised by Todd
Glassey.
>
> If there are no major editorial errors, this version should (hopefully) be
> the version to be published as an RFC. Should there be a few minor errors
> left, please tell me, since they can still be corrected directly by myself
> when the RFC editor transforms the document into an RFC (there a 48 hours
> time window to do so).
>
> FYI, the abstract and the introduction are now as follows:
>
> Abstract
>
> A time stamping service allows to prove that a datum existed before
> a particular time. This document describes the format of a request
> sent to a Time Stamping Authority (TSA) and of the response that is
> returned. It also establishes several security-relevant requirements
> for TSA operation, with regards to processing requests to generate
> responses. A TSA may be operated as a Trusted Third Party (TTP)
> service, though other operational models may be appropriate, e.g. an
> organization might require a TSA for internal time stamping purposes.
>
> Non-repudiation services [ISONR] require the ability to establish the
> existence of data before specified times. This protocol may be used as
> a building block to support such services. An example of how to prove
> that a digital signature was generated during the validity period of
> a public key certificate is given in an annex.
>
> (...)
>
> 1.  Introduction
>
> (...)
>
> This standard does not establish overall security requirements for
> TSA operation, just like other PKIX standards do not establish such
> requirements for CA operation. Rather, it is anticipated that a TSA
> will make know to prospective clients the policies it implements to
> ensure accurate time stamp generation, and clients will make use of
> the services of a TSA only if they are satisfied that these policies
> meet their needs.
>
>
> Denis

From: "Hiroyuki Sakakibara" <[email-masked]>
To: "Frank Balluffi" <[email-masked]>, <[email-masked]>
Subject: Re: question about certificate path length
Date: Thu, 19 Oct 2000 13:19:38 +0900

Mr.Frank Balluffi

Thank you very much for your relpy.

I have refered the X.509 document
cited in draft-ietf-pkix-new-part1-02.txt.
In the document, while the relationship between a delegation
path length and the pathLenConstraint component of the basicAttrConstraints
is clear,
but the relationship between a certification path length and the the
pathLenConstraint
component of the basicConstraints seemes to be not clear, I think.

So,  the description of the certification path length in
the 6.1 Basic Path Validation in draft-ietf-pkix-new-part1-02.txt
is clearer to me.

# I mistakenly have described "certification path" as "certificate path" in
# my posted mail. "certification path" is correct.

Hiroyuki Sakakibara.

> Hiroyuki, draft-ietf-pkix-new-part1-02.txt
>
> I believe that your understanding is correct.
>
> Note that draft-ietf-pkix-new-part1-02.txt's definition of the basic
> constraints extension (section 4.2.1.10) clears up ambiguities found in
RFC
> 2459's definition. For example, draft-ietf-pkix-new-part1-02.txt states:
>
> This extension MAY appear as a critical or non-critical extension in end
> entity certificates.
>
> where RFC 2459 says:
>
> This extension SHOULD NOT appear in end entity certificates.
>
> Frank
>
>
> In the case of validating Cert_b as  EE certificate, the
> > certificate path is
> > Cert_a -> Cert_b,
> >
>
> When validating
>
> section 3
>
>    end entity:  user of PKI certificates and/or end user system that
>                 is the subject of a certificate;
>
>
>
> 4.2.1.10
>    This extension MUST appear as a critical extension in all CA
>    certificates.  This extension SHOULD NOT appear in end entity
>    certificates.
>
>
>
>
>    This extension MUST appear as a critical extension in all CA
>    certificates.  This extension SHOULD NOT appear in end entity
>    certificates.
>
>
>
>
>
> > From: Hiroyuki Sakakibara [mailto:[email-masked]]
> > Sent: Tuesday, October 17, 2000 2:55 AM
> > To: [email-masked]
> > Subject: question about certificate path length
> >
> >
> > Hi.
> >
> > I have a question about difference between "certificate path
> > length" and
> > "pathLenConstraint field in the basicConstraint extension".
> >
> > >Internet X.509 Public Key Infrastructure
> > >Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
> > >July 14, 2000
> >
> > >4.2.1.10  Basic Constraints
> > >"The pathLenConstraint field is meaningful only if cA is set to TRUE.
> > >   In this case, it gives the maximum number of CA certificates that
> > >may follow this certificate in a certification path."
> >
> > SNIP
> >
> > >6.1 Basic Path Validation
> >
> > >To meet this goal, the path validation process verifies, among other
> > >things, that a prospective certification path (a sequence of n certi-
> > >ficates) satisfies the following conditions:
> > >      (i) for all x in {1, ..., n-1}, the subject of certificate x is
> > >      the issuer of certificate x+1;
> > >      (ii) certificate 1 is issued by the trust anchor;
> > >      (iii) certificate n is the end entity certificate; and
> > >      (iv) for all x in {1, ..., n}, the certificate was valid at the
> > >      time in question.
> > SNIP
> > >(inputs)
> > >(a) a prospective certification path of length n;
> >
> > >State variable initialization
> > >(l) max_path_length:  this integer is initialized to n, and is
> > >      reset by the path length constraint field within the basic con-
> > >      straints extension of a CA certificate.
> >
> > Referencing "Internet X.509 Public Key Infrastructure
> > Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
> > July 14, 2000"
> >  I will describe my understanding.
> >
> > For example,
> >
> > CAa : trust anchor
> > CAb : subordinate CA of CAa
> > CAc : subordinate CA of CAb
> > CAd : subordinate CA of CAc
> > EE   : subordinate user of CAd
> >
> > Cert_a : CAa's self-signed certificate
> > Cert_b : CAb's certificate issued by CAa
> > Cert_c : CAb's certificate issued by CAb
> > Cert_d : CAb's certificate issued by CAc
> > Cert_user : user's certificate issued by CAd
> >
> > In this case, certificate path is
> >
> > Cert_a -> Cert_b -> Cert_c -> Cert_d -> Cert_user
> >
> > therefore, the length of the certificate path is "5".
> >
> > On the other hand, if CAa restricts the number of subordinates
> > CAs, 3, actually to CAd in this case, the pathLenConstraint value
> > in Cert_a is 3.
> >
> > because
> >
> > >4.2.1.10  Basic Constraints
> > >"The pathLenConstraint field is meaningful only if cA is set to TRUE.
> > >   In this case, it gives the maximum number of CA certificates that
> > >may follow this certificate in a certification path."
> >
> > So, in general, the length of the certificate path means
> > that, the number of
> > chained
> > certificates, from the trust anchor CA's certificate to

> > user or CA)
> > certificate,
> > as shown above
> > ( including BOTH THE TRUST ANCHOR's CERTIFICATE AND EE CERTIFICATE).
> >
> > In the case of validating Cert_b as  EE certificate, the
> > certificate path is
> > Cert_a -> Cert_b,
> > therefore the length of the certificate path is 2.
> >
> > Consequently, if someone handles the Cert_a as the trust anchor CA's
> > certificate,
> > he sees that the maximam path length is 5, because pathLenConstraint
> > in Cert_a is 3, so, he adds "2(CAa and user)" to "3" then
> > gets the length as
> > 5.
> >
> > Am I misunderstanding ?
> >
> > ---------------------------------------
> > Hiroyuki Sakakibara
> > MITSUBISHI ELECTRIC CORPORATION
> > Information Technology R&D Center
> > 5-1-1 Ofuna, Kamakura, Kanagawa, Japan
> > PHONE: +81-467-41-2183
> > FAX:   +81-467-41-2185
> > E-mail : [email-masked]
> >
>

From: [email-masked]
To: Polar Humenn <[email-masked]>
cc: Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 18 Oct 2000 22:45:34 -0400
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

     Polar:

          Tom Gindin

Tom,

Cheers,
-Polar

syntaxes
forgiven
that
is
only
(by
we
am
suggestion.
say
but
includes
RP
the
Therefore,
Issuer/Serial
this
not
being
ObjectDigestInfo
named
issuer
same
PK
the
using

Date: Thu, 19 Oct 2000 03:17:34 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Polar Humenn <[email-masked]>
CC: "Covey, Carlin" <[email-masked]>, Denis Pinkas <[email-masked]>, Al Arsenault <[email-masked]>, Sharon Boeyen <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Regardless of any other text, if you want to change X.509(2000)
then you should contact ISO. PKIX compliant ACs have to be
X.509 compliant. 

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: Thu, 19 Oct 2000 03:13:12 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: Denis Pinkas <[email-masked]>, Al Arsenault <[email-masked]>, Sharon Boeyen <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

I completely agree.

Stephen.

"Phillip H. Griffin" wrote:
> It is a really bad idea to break compatibility
> with an international standard you are attempting
> to profile. Suggesting such a course of action is
> ridiculous.
> 
> No matter how benign they may appear to be, any ASN.1
> changes made to the AC profile in order to attempt to
> force changes into X.509 would not be wise. This would
> likely lead to two different notations for ACs.

-- 
____________________________________________________________
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, 19 Oct 2000 03:10:42 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: Lista IETF <[email-masked]>
Subject: Re: Attribute Certificates II

Pedro,

>         -> In section 4.2.3 it's said that all AC Issuers must be
> identified by non-empty DNs. It's also said that "it means that the AC
> Issuer does not have to know which PKC the verifier will use for it (the
> AC Issuer). Using the baseCertificateID field to reference the AC Issuer
> would mean that the AC verifier would have to trust the PKC that the AC
> Issuer chosed (for itself) at the AC creation time.".
> 
>            If that is so, then how does the relying party know what AC
> Issuer PKC it should use to verify the signature on the AC ?

This is entirely analagous to verifying the signature on a PKC, even
down to the ability to include an AKID in the AC. Just the same, no
different.

>         -> If the holder is identified using the "entityName" field can
> you assure that only the authentic holder can gain access to some
> resource and not another party (with an equal DN) ?
>           As far as I know, presenting the AC isn't enough... You also
> have to present a proof of possesion (usually the signature of a
> challenge) of something that only that identity knows (like the private
> key corresponding to the cert's public key)...
>            Am I wrong ?
>            Or, when you use this field, who presents the AC gets the
> access and that's it ?

No, that isn't it. Protocols using this profile would have to specify how 
theft of ACs is prevented. The security considerations section describes
some of the issues and the proposed additional text adds some more.

Incidentally, what you call proof-of-possession above I would call
authentication.

> 
>         -> Regarding the previous point, if you use the
> "objectDigestInfo" of a public key or cert, you could make that proof of
> possesion right ?

Indirectly. If the authentication is based on the relevant public key or
PKC.

> 
>         -> Are supposing that it's the job of a lower software
> layer/protocol to verify/ensure that the AC is being presented by the
> righteous owner ?
>           If so, do you have any protocol in mind ?

I don't understand the question. In any case, since this is just
a profile, such protocol issues are out of scope.

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, 18 Oct 2000 21:50:23 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: [email-masked]
cc: Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Tom,

Cheers,
-Polar

On Wed, 18 Oct 2000 [email-masked] wrote:

>      Since ObjectDigestInfo is already in the standard, those new syntaxes
> I suggested earlier today are redundant, and I hope that I will be forgiven
> for them.  IMO the correct thing to do in the profile is to recommend that
> with digestedObjectType publicKeyCert.  In those cases where entityName is
> used with underlying PKC authentication but it is the AA's intent that only
>      Do we need a new extension to permit the listing of multiple PKC's (by
> An attribute or extension is the only acceptable approach to me, unless we
> > > You are proposing syntax that is no longer compatible with X.509.  I am
> >Hmmm. I only went on that taking into account Tom and Denises suggestion.
> > > >I still think that this solution doesn't quite solve the problem, but
> is a
> > > >good start.  In fact Tom Gindin's suggestion just came in and includes
> > > >The fact is that the entityName option still contains a DN and the RP
> MUST
> > > >option, the DN MUST verifiable and uniquely name an entity within the
> PKI
> > > >AA belongs belongs to behave in its creation of unique DN. Therefore,
> > > >Therefore, it would still probably be better to use the Issuer/Serial
> and
> > > >Of course, when an application authenticates to an RP using PKCs this
> ties
> > > >the authorization to a particular certificate. Apparently that was not
> > > >desirable due to the effect of key rollover and new certificates being
> > > >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> > > >uniquely name an entity within the PKI of the AC issuer. The PKC named
> by
> > > >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> > > >    the holder's PK certificate MUST be uniquely found under the same
> root
> > > >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> > > >    The entire certificate path starting with the holder's PKC and the
> PKC
> > > >Note: there is *still* a problem with AC targeting and proxying using
> > > >just DNs.
> > > >
> > > >Cheers,
> > > >-Polar
> > > >
> > > >

From: [email-masked]
To: Russ Housley <[email-masked]>
cc: Polar Humenn <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 18 Oct 2000 18:29:28 -0400
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

     Since ObjectDigestInfo is already in the standard, those new syntaxes
I suggested earlier today are redundant, and I hope that I will be forgiven
for them.  IMO the correct thing to do in the profile is to recommend that
all uses of baseCertificateID SHOULD also use the objectDigestInfo field
with digestedObjectType publicKeyCert.  In those cases where entityName is
used with underlying PKC authentication but it is the AA's intent that only
one PKC be permitted, the objectDigestInfo field with digestedObjectType
publicKeyCert SHOULD also be used.
     Do we need a new extension to permit the listing of multiple PKC's (by
cert digest) for the same entityName when it is the AA's intent to allow
the use of such for a single AC and all the intended PKC's already exist?

          Tom Gindin

An attribute or extension is the only acceptable approach to me, unless we
coordinate with X.509 agrees to make the same change to the base syntax.

Russ

At 02:09 PM 10/18/2000 -0400, Polar Humenn wrote:
> > You are proposing syntax that is no longer compatible with X.509.  I am
>Hmmm. I only went on that taking into account Tom and Denises suggestion.
same
> > >I still think that this solution doesn't quite solve the problem, but
is a
> > >good start.  In fact Tom Gindin's suggestion just came in and includes
> > >The fact is that the entityName option still contains a DN and the RP
MUST
accept
some
entityName
> > >option, the DN MUST verifiable and uniquely name an entity within the
PKI
MUST
in
the
> > >AA belongs belongs to behave in its creation of unique DN. Therefore,
PKI
brings up
PKI of
> > >Therefore, it would still probably be better to use the Issuer/Serial
and
> > >Of course, when an application authenticates to an RP using PKCs this
ties
> > >the authorization to a particular certificate. Apparently that was not
> > >desirable due to the effect of key rollover and new certificates being
only
fine.
> > >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
and
> > >uniquely name an entity within the PKI of the AC issuer. The PKC named
by
> > >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
entityName
which
Therefore,
issuer's
1,
> > >    the holder's PK certificate MUST be uniquely found under the same
root
MUST be
> > >3. When the AC holder is named by a baseCertificateId, the issuer's PK
correctly
> > >    The entire certificate path starting with the holder's PKC and the
PKC
> > >Note: there is *still* a problem with AC targeting and proxying using
> > >just DNs.
> > >
> > >Cheers,
> > >-Polar
> > >
> > >

Date: Wed, 18 Oct 2000 18:15:32 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-MD5: p/+/jnaSzfmnbGDqGtuN8g==

It's happened before, when organizations with isolated IP networks
decided to connect to the Internet.  It was a royal pain to get a block
of official IP addresses and renumber all your machines, but it was
necessary, so people did it.  (This was before NAT and masquerading,
of course.)

At some point, organizations with isolated PKIs might decide to get an
"official" DN subtree and issue certificates within it.  After an
organization makes a decision to operate in a coordinated way with
other organizations, implementation of name constraints in cross certs
and replacement of user certificates is not particularly daunting.
Less daunting than IP renumbering, at any rate.

"Compliance" is not the problem.  The problem is understanding that an
Inter-PKI cannot really work if users pick their own DNs any more than
the Internet could work if users picked their own IP addresses.

Dave

> From: Polar Humenn <[email-masked]>
> 

From: "Covey, Carlin" <[email-masked]>
To: "'Polar Humenn'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt (fwd)
Date: Wed, 18 Oct 2000 13:48:02 -0700

Polar,

Evidently the assumption in the "snippet" below is that when the holder of
an AC is identified by a DN, some PKC with the same DN will be used to
authenticate the holder.  Is this actually required?  Couldn't the AC, even
if it identified the holder by a DN, specify some other authentication
criterion, such as a biometric?  The holder of the AC may in fact have zero,
one or more PKC's that may also be used for authentication.

- Carlin Covey
  Cylink Corp.

> From: Polar Humenn [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2000 1:19 PM
> To: Russ Housley
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt (fwd)
> 
> 
> 
<snip> 
> When using an entityName that contains a DN, the DN MUST verifiably and
> uniquely name an entity within the PKI of the AC issuer. 
> The PKC named by the DN MUST verify back to the root CA of the AC issuer.
> The AC issuer MUST ONLY create AttributeCertificates with the Holder as a 
> DN entityName in this fashion. This constraint is subject to the entire
PKI 
> for which the AC issuer belongs to behave in its creation of unique 
> DNs. Therefore, verification is also subject to the trust the RP places in

> the AC issuer's PKI to conform to this behavior.
> 
<snip>

Date: Wed, 18 Oct 2000 16:19:04 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Russ Housley <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt (fwd)

Hi, 

Okay, on Russ's suggestion that only an attribute extension will be
acceptable. 

I think this approach does the following:

1. Addresses Carlisle's points about when using DNs that "everything"
   belongs to one PKI, i.e. under a single trusted root. So using DNs for  
   the Holder, or the Holder's issuer in IssuerSerial are okay.

2. Addresses my points solving name collisions by either impostor or
   coincidence.

3. If everything was previous working in accordance with Carlisle's
   assumptions of a single PKI, it doesn't break anything.

4. Doesn't change X.509.

5. There is no need to put a security consideration in the document 
   refering to DN name collisions. 

6. The sentence appearing in Section 4.2.2 Holder,

	"See the security consideration section which mentions some
        name collision problems that may arise when using the entityName
        option."

   can probably be eliminated. (Since there isn't a section currently
   in the security consideration section mentioning name collision
   problems.)

Here is the entire proposed text:

Section 4.1 Remains:

   Holder ::= SEQUENCE {

When using an entityName that contains a DN, the DN MUST verifiably and
uniquely name an entity within the PKI of the AC issuer. The PKC named by
the DN MUST verify back to the root CA of the AC issuer. The AC issuer
MUST ONLY create AttributeCertificates with the Holder as a DN entityName
in this fashion. This constraint is subject to the entire PKI for which
the AC issuer belongs to behave in its creation of unique DNs. Therefore,
verification is also subject to the trust the RP places in the AC issuer's
PKI to conform to this behavior.

When using the baseCertificateID, if the DN contained in
holder.baseCertificateID.issuer construct does not verifiably and uniquely
name an entity within the PKI of the AC issuer, the
VerifiedBaseCertificateID critical extension, as defined in Section 4.3.?,
MUST be present. The AC issuer MUST only create AttributeCertificates with
the Holder as a baseCertificateID in this fashion.

Add the following subsection to Section 4.3 Extensions:

4.3.? Verifying Base Certificate ID

When the holder is named by the baseCertificateID, if the DN contained in
the holder.baseCertificateID.issuer construct does not verifiably and
uniquely name an entity within the PKI of the AC Issuer, a verifiable link
to that issuer's PKC is required by Section 4.2.2. This extension provides
that link by using a digest of the holder issuer's PK certificate.

The digest contained in this extension MUST be a digest of the PKC of the
entity named by the DN in the holder.baseCertificateID.issuer field.

  name           id-pe-ac-verfiedBaseCertificateID
  OID            { id-pe ??? }
  syntax         ObjectDigestInfo
  criticality    MUST be TRUE

In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
inserting 2, 3, and 4 below, and renumbering accordingly).

2. When the AC holder is named by a DN using the entityName option,
   a PK certificate MUST be found for which the holder's DN is unique
   under the same root CA as the AC issuer. The entire certification path
   of that PKC MUST be verified in accordance with [PKIXPROF].

3. When the AC holder is named by a baseCertificateID, one of the
   following cases MUST hold: 

   (a) If the VerifiedBaseCertificateID critical extension is not present,
       a PK certificate MUST be found for which the DN contained in
       the holder.baseCertificateID.issuer construct is unique under the
       same root CA as the AC issuer. The entire certificate path of that
       PKC MUST be verified in accordance with [PKIXPROF].
   (b) If the VerifiedBaseCertificateID critical extension is present,
       a PK certificate MUST be found for the DN contained in
       the holder.baseCertificateID.issuer construct, and that PKC MUST
       correctly digest to the digest value contained in the
       extension. The entire certificate path beginning with the holder's
       PKC and the PKC of the holder's issuer MUST be verified
       in accordance with [PKIXPROF].

Note: there is still a problem targets and proxies just using DNs.

Cheers,
-Polar

Date: Wed, 18 Oct 2000 12:11:49 -0700
To: Peter Williams <[email-masked]>, IETF-PXIX <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: TSP. Version 10

At 11:00 AM 10/18/00 -0700, Peter Williams wrote:
>Tony,
>
>Or,
>
>The operator of a time stamping service *asserts* (or may *represent*, or
>may *warrant*) that...
>
>
>---------
>
>
>Designating something as either providing evidence or supporting
>proof claims is not something that an Internet Standard can do,
>legitimately, of one takes, as legally authoritative, Michael Baum's
>scorn of X.400's (1988) International Standard's ratified specifications
>of  "proof" and "non-repudiation" security services.

Peter,

Thank you for the admonishment.

   "A time stamping service supports assertions of proof that ..."

___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

Date: Wed, 18 Oct 2000 14:23:10 -0400
To: Polar Humenn <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

An attribute or extension is the only acceptable approach to me, unless we 
coordinate with X.509 agrees to make the same change to the base syntax.

Russ

At 02:09 PM 10/18/2000 -0400, Polar Humenn wrote:
> > You are proposing syntax that is no longer compatible with X.509.  I am
>Hmmm. I only went on that taking into account Tom and Denises suggestion.
> > > > link between the AC and the certificate, even if the CA has the same
> > > name as
> > >I still think that this solution doesn't quite solve the problem, but is a
> > >good start.  In fact Tom Gindin's suggestion just came in and includes
> > >The fact is that the entityName option still contains a DN and the RP MUST
> > >be prepared to accept it. However, on what conditions should the RP accept
> > >the Holder as a DN? (Especially if this verification is offloaded to some
> > >When using an AC that contains the Holder specification as a DN entityName
> > >option, the DN MUST verifiable and uniquely name an entity within the PKI
> > >of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
> > >ONLY create AttributeCertificates with the Holder as a DN entityName in
> > >this fashion. This constraint is subject to the entire PKI for which the
> > >AA belongs belongs to behave in its creation of unique DN. Therefore,
> > >verification is subject to the trust the RP places in the AA and its PKI
> > >[Note: this approach still does not solve the problem that Denis brings up
> > >below as comment 43. A subordinate CA may be compromised within the PKI of
> > >Therefore, it would still probably be better to use the Issuer/Serial and
> > >Of course, when an application authenticates to an RP using PKCs this ties
> > >the authorization to a particular certificate. Apparently that was not
> > >desirable due to the effect of key rollover and new certificates being
> > >However, I think that if as Carlise pointed out, that if the DN is only
> > >used in the case of a single trusted Root, then everything will be fine.
> > >
> > >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> > >When using an entityName that contains a DN, the DN MUST verifiably and
> > >uniquely name an entity within the PKI of the AC issuer. The PKC named by
> > >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> > >MUST ONLY create AttributeCertificates with the Holder as a DN entityName
> > >in this fashion. This constraint is subject to the entire PKI for which
> > >the AC issuer belongs to behave in its creation of unique DNs. Therefore,
> > >verification is also subject to the trust the RP places in the AC issuer's
> > >In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
> > >    the holder's PK certificate MUST be uniquely found under the same root
> > >    CA as the AC issuer. The entire certification path of that PKC MUST be
> > >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> > >    named holder issuer's PKC must be found, and that PKC MUST correctly
> > >    digest to the digest value contained in the verifiedBaseCertificateID.
> > >    The entire certificate path starting with the holder's PKC and the PKC
> > >Note: there is *still* a problem with AC targeting and proxying using
> > >just DNs.
> > >
> > >Cheers,
> > >-Polar
> > >
> > >

Date: Wed, 18 Oct 2000 14:09:59 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Russ Housley <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

On Wed, 18 Oct 2000, Russ Housley wrote:

> Polar:
> 
> You are proposing syntax that is no longer compatible with X.509.  I am 

Hmmm. I only went on that taking into account Tom and Denises suggestion.
Do you feel that an attribute extension would be warranted instead?

Cheers,
-Polar

> > > link between the AC and the certificate, even if the CA has the same 
> > name as
> >I still think that this solution doesn't quite solve the problem, but is a
> >good start.  In fact Tom Gindin's suggestion just came in and includes
> >The fact is that the entityName option still contains a DN and the RP MUST
> >be prepared to accept it. However, on what conditions should the RP accept
> >the Holder as a DN? (Especially if this verification is offloaded to some
> >When using an AC that contains the Holder specification as a DN entityName
> >option, the DN MUST verifiable and uniquely name an entity within the PKI
> >of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
> >ONLY create AttributeCertificates with the Holder as a DN entityName in
> >this fashion. This constraint is subject to the entire PKI for which the
> >AA belongs belongs to behave in its creation of unique DN. Therefore,
> >verification is subject to the trust the RP places in the AA and its PKI
> >[Note: this approach still does not solve the problem that Denis brings up
> >below as comment 43. A subordinate CA may be compromised within the PKI of
> >Therefore, it would still probably be better to use the Issuer/Serial and
> >Of course, when an application authenticates to an RP using PKCs this ties
> >the authorization to a particular certificate. Apparently that was not
> >desirable due to the effect of key rollover and new certificates being
> >However, I think that if as Carlise pointed out, that if the DN is only
> >used in the case of a single trusted Root, then everything will be fine.
> >
> >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> >When using an entityName that contains a DN, the DN MUST verifiably and
> >uniquely name an entity within the PKI of the AC issuer. The PKC named by
> >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> >MUST ONLY create AttributeCertificates with the Holder as a DN entityName
> >in this fashion. This constraint is subject to the entire PKI for which
> >the AC issuer belongs to behave in its creation of unique DNs. Therefore,
> >verification is also subject to the trust the RP places in the AC issuer's
> >In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
> >    the holder's PK certificate MUST be uniquely found under the same root
> >    CA as the AC issuer. The entire certification path of that PKC MUST be
> >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> >    named holder issuer's PKC must be found, and that PKC MUST correctly
> >    digest to the digest value contained in the verifiedBaseCertificateID.
> >    The entire certificate path starting with the holder's PKC and the PKC
> >Note: there is *still* a problem with AC targeting and proxying using
> >just DNs.
> >
> >Cheers,
> >-Polar
> >
> >

Content-return: allowed
Date: Wed, 18 Oct 2000 11:00:50 -0700
From: Peter Williams <[email-masked]>
Subject: RE: TSP. Version 10
To: "'Tony Bartoletti'" <[email-masked]>, IETF-PXIX <[email-masked]>
Deferred-delivery: Wed, 18 Oct 2000 11:04:00 -0700

Tony,

Or,

The operator of a time stamping service *asserts* (or may *represent*, or  
may *warrant*) that...

---------

Designating something as either providing evidence or supporting 
proof claims is not something that an Internet Standard can do,
legitimately, of one takes, as legally authoritative, Michael Baum's 
scorn of X.400's (1988) International Standard's ratified specifications 
of  "proof" and "non-repudiation" security services.

A real actor may assert, with varying degrees of accountability, that
a fact is, or may be, true. It takes someone skilled in and accountable
to scientific method or legal method to take these assertions and claim 
them either as evidence or as proof of another claim.

We should not deviate from the "assertion-centric" design already made in 
the name & certificate registration arena of PKIX. A DN is just a 
collection of assertions about the registration of real-world objects
by the naming authorities. It is not evidence or proof of anything. 
Similarly, certifying a key in a certificate provides per se no evidence,
nor 
does it per se support a proof of any claim. Both name registration, and 
key certification do hold the authority accountable for their management
procedures, however, assuming one can authenticate the 
authority's messages. Time stamping should be no different.

We should remain cognizant of the fact that different Internet communities
have different presumptive arrangements concerning legal evidence and 
legal proof. Unless I am mistaken, there is no citable claim of legal
analysis 
behind PKIX,  and no claim that we are forming or complying with any 
legal standards. Citing compliance to PKIX will provide a legal forum
no more certainty that citing to X.400 1988.

Peter.

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]]
Sent: Wednesday, October 18, 2000 10:38 AM
To: Hal Lockhart; Denis Pinkas; IETF-PXIX
Subject: RE: TSP. Version 10

Or ...

   A time stamping service supports proof that ...

Or ...

   A time stamping service provides evidence that ...

___tony___

At 08:43 PM 10/17/00 -0400, Hal Lockhart wrote:

> > FYI, the abstract and the introduction are now as follows:
> >
> > Abstract
> >
> > A time stamping service allows to prove that a datum existed before
> > a particular time.
>
>I thought you would have fixed the fact that there seemes to be a word
>missing after "allows". What that word should be, ("one", "a party", "a
>user", "someone", "a subscriber")I do not know.
>
>Hal

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

Date: Wed, 18 Oct 2000 13:53:09 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: "Covey, Carlin" <[email-masked]>
cc: Denis Pinkas <[email-masked]>, Al Arsenault <[email-masked]>, Sharon Boeyen <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

On Wed, 18 Oct 2000, Covey, Carlin wrote:

> The wording of 2. below seems a bit misleading.  My understanding is that
> the security issue is a consequence of the fact that the entityName option
> deliberately permits mapping to more than one of the holder's PKC's (hence
> potentially to another user's PKC).  Perhaps instead of "... the holder's PK
> certificate MUST be uniquely found under the same root CA..." the wording
> should be "... a PK certificate MUST be found whose DN is unique under the
> same root CA..."

Hi Carlin,

I agree with your observation, but with the stipulation that we are
talking about the AC's Holder. With that in mind, the new 2:

2. When the AC holder is named by a DN using the entityName option,
   a PK certificate MUST be found for which the holder's DN is unique
   under the same root CA as the AC issuer. The entire certification path
   of that PKC MUST be verified in accordance with [PKIXPROF].

Do you agree?

So, to keep the proposal all together, below is the same as before with
the new 2. and one minor editorial change in 4. I forgot an "of". :(

Cheers,
-Polar

Section 4.1:

   Holder ::= SEQUENCE {

When using an entityName that contains a DN, the DN MUST verifiably and
uniquely name an entity within the PKI of the AC issuer. The PKC named by
the DN MUST verify back to the root CA of the AC issuer. The AC issuer
MUST ONLY create AttributeCertificates with the Holder as a DN entityName
in this fashion. This constraint is subject to the entire PKI for which
the AC issuer belongs to behave in its creation of unique DNs. Therefore,
verification is also subject to the trust the RP places in the AC issuer's
PKI to conform to this behavior.

In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
inserting 2, 3, and 4 below, and renumbering accordingly).

2. When the AC holder is named by a DN using the entityName option,
   a PK certificate MUST be found for which the holder's DN is unique
   under the same root CA as the AC issuer. The entire certification path
   of that PKC MUST be verified in accordance with [PKIXPROF].

3. When the AC holder is named by a baseCertificateID, the issuer's PK
   certificate MUST be uniquely found under the same root CA as
   the AC issuer. The entire certificate path of that PKC MUST
   be verified in accordance with [PKIXPROF].

4. When the AC holder is named by a verifiedBaseCertificateID, the
   named holder issuer's PKC must be found, and that PKC MUST correctly
   digest to the digest value contained in the verifiedBaseCertificateID.
   The entire certificate path starting with the holder's PKC and the PKC
   of the issuer of the holder's PKC MUST be verified in accordance
   with [PKIXPROF].

Note: there is still a problem targets and proxies just using DNs.

Cheers,
-Polar

Date: Wed, 18 Oct 2000 13:48:52 -0400
To: Polar Humenn <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

Polar:

You are proposing syntax that is no longer compatible with X.509.  I am 
very unhappy with such a deviation.

Russ

   At 12:38 PM 10/18/2000 -0400, Polar Humenn wrote:
> > link between the AC and the certificate, even if the CA has the same 
> name as
>I still think that this solution doesn't quite solve the problem, but is a
>good start.  In fact Tom Gindin's suggestion just came in and includes
>The fact is that the entityName option still contains a DN and the RP MUST
>be prepared to accept it. However, on what conditions should the RP accept
>the Holder as a DN? (Especially if this verification is offloaded to some
>When using an AC that contains the Holder specification as a DN entityName
>option, the DN MUST verifiable and uniquely name an entity within the PKI
>of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
>ONLY create AttributeCertificates with the Holder as a DN entityName in
>this fashion. This constraint is subject to the entire PKI for which the
>AA belongs belongs to behave in its creation of unique DN. Therefore,
>verification is subject to the trust the RP places in the AA and its PKI
>[Note: this approach still does not solve the problem that Denis brings up
>below as comment 43. A subordinate CA may be compromised within the PKI of
>Therefore, it would still probably be better to use the Issuer/Serial and
>Of course, when an application authenticates to an RP using PKCs this ties
>the authorization to a particular certificate. Apparently that was not
>desirable due to the effect of key rollover and new certificates being
>However, I think that if as Carlise pointed out, that if the DN is only
>used in the case of a single trusted Root, then everything will be fine.
>
>Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
>When using an entityName that contains a DN, the DN MUST verifiably and
>uniquely name an entity within the PKI of the AC issuer. The PKC named by
>the DN MUST verify back to the root CA of the AC issuer. The AC issuer
>MUST ONLY create AttributeCertificates with the Holder as a DN entityName
>in this fashion. This constraint is subject to the entire PKI for which
>the AC issuer belongs to behave in its creation of unique DNs. Therefore,
>verification is also subject to the trust the RP places in the AC issuer's
>In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
>    the holder's PK certificate MUST be uniquely found under the same root
>    CA as the AC issuer. The entire certification path of that PKC MUST be
>3. When the AC holder is named by a baseCertificateId, the issuer's PK
>    named holder issuer's PKC must be found, and that PKC MUST correctly
>    digest to the digest value contained in the verifiedBaseCertificateID.
>    The entire certificate path starting with the holder's PKC and the PKC
>Note: there is *still* a problem with AC targeting and proxying using
>just DNs.
>
>Cheers,
>-Polar
>
>

Date: Wed, 18 Oct 2000 13:32:42 -0400
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting  
To: Denis Pinkas <[email-masked]>
CC: Al Arsenault <[email-masked]>, Sharon Boeyen <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Denis Pinkas wrote (in part):

snip 

> a defect report to ISO, which is, I think, a real defect: a comment for such

It is a really bad idea to break compatibility 
with an international standard you are attempting
to profile. Suggesting such a course of action is
ridiculous.

No matter how benign they may appear to be, any ASN.1
changes made to the AC profile in order to attempt to
force changes into X.509 would not be wise. This would
likely lead to two different notations for ACs.

Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------

Date: Wed, 18 Oct 2000 10:38:10 -0700
To: Hal Lockhart <[email-masked]>, Denis Pinkas <[email-masked]>, IETF-PXIX <[email-masked]>
From: Tony Bartoletti <[email-masked]>
Subject: RE: TSP. Version 10

Or ...

   A time stamping service supports proof that ...

Or ...

   A time stamping service provides evidence that ...

___tony___

At 08:43 PM 10/17/00 -0400, Hal Lockhart wrote:

> > FYI, the abstract and the introduction are now as follows:
> >
> > Abstract
> >
> > A time stamping service allows to prove that a datum existed before
> > a particular time.
>
>I thought you would have fixed the fact that there seemes to be a word
>missing after "allows". What that word should be, ("one", "a party", "a
>user", "someone", "a subscriber")I do not know.
>
>Hal

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

From: "Covey, Carlin" <[email-masked]>
To: "'Polar Humenn'" <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: Al Arsenault <[email-masked]>, Sharon Boeyen <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Wed, 18 Oct 2000 09:56:09 -0700

The wording of 2. below seems a bit misleading.  My understanding is that
the security issue is a consequence of the fact that the entityName option
deliberately permits mapping to more than one of the holder's PKC's (hence
potentially to another user's PKC).  Perhaps instead of "... the holder's PK
certificate MUST be uniquely found under the same root CA..." the wording
should be "... a PK certificate MUST be found whose DN is unique under the
same root CA..."

- Carlin Covey
  Cylink Corp.

>   the holder's PK certificate MUST be uniquely found under the same root
>   CA as the AC issuer. The entire certification path of that PKC MUST be

-----Original Message-----
From: Polar Humenn [mailto:[email-masked]]
Sent: Wednesday, October 18, 2000 9:39 AM
To: Denis Pinkas
Cc: Al Arsenault; Sharon Boeyen; Russ Housley; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

as

Dennis,

I still think that this solution doesn't quite solve the problem, but is a
good start.  In fact Tom Gindin's suggestion just came in and includes
yours. So I'll sort of work off of that.

The fact is that the entityName option still contains a DN and the RP MUST
be prepared to accept it. However, on what conditions should the RP accept
the Holder as a DN? (Especially if this verification is offloaded to some
remote verification engine).

When using an AC that contains the Holder specification as a DN entityName
option, the DN MUST verifiable and uniquely name an entity within the PKI
of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
ONLY create AttributeCertificates with the Holder as a DN entityName in
this fashion. This constraint is subject to the entire PKI for which the
AA belongs belongs to behave in its creation of unique DN. Therefore,
verification is subject to the trust the RP places in the AA and its PKI
together to conform to this behavior.

[Note: this approach still does not solve the problem that Denis brings up
below as comment 43. A subordinate CA may be compromised within the PKI of
the AA and create impostor certificates, grabbing privileges.]

Therefore, it would still probably be better to use the Issuer/Serial and
a hash of the Issuer's certificate, even if in the same PKI.

Of course, when an application authenticates to an RP using PKCs this ties
the authorization to a particular certificate. Apparently that was not
desirable due to the effect of key rollover and new certificates being
issued to the same subject entity.

However, I think that if as Carlise pointed out, that if the DN is only
used in the case of a single trusted Root, then everything will be fine.

Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
that is already defined in the document for the certificate Hash).

Section 4.1:

   Holder ::= SEQUENCE {

When using an entityName that contains a DN, the DN MUST verifiably and
uniquely name an entity within the PKI of the AC issuer. The PKC named by
the DN MUST verify back to the root CA of the AC issuer. The AC issuer
MUST ONLY create AttributeCertificates with the Holder as a DN entityName
in this fashion. This constraint is subject to the entire PKI for which
the AC issuer belongs to behave in its creation of unique DNs. Therefore,
verification is also subject to the trust the RP places in the AC issuer's
PKI to conform to this behavior.

In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
inserting 2, 3, and 4 below, and renumbering accordingly).

2. When the AC holder is named by a DN using the entityName option,
   the holder's PK certificate MUST be uniquely found under the same root
   CA as the AC issuer. The entire certification path of that PKC MUST be
   verified in accordance with [PKIXPROF].

3. When the AC holder is named by a baseCertificateId, the issuer's PK
   certificate MUST be uniquely found under the same root CA as
   the AC issuer. The entire certificate path of that PKC MUST
   be verified in accordance with [PKIXPROF].

4. When the AC holder is named by a verifiedBaseCertificateID, the
   named holder issuer's PKC must be found, and that PKC MUST correctly
   digest to the digest value contained in the verifiedBaseCertificateID.
   The entire certificate path starting with the holder's PKC and the PKC
   of the issuer the holder's PKC MUST be verified in accordance
   with [PKIXPROF].

.....

Note: there is *still* a problem with AC targeting and proxying using
just DNs.

Cheers,
-Polar

Date: Wed, 18 Oct 2000 12:38:49 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Denis Pinkas <[email-masked]>
cc: Al Arsenault <[email-masked]>, Sharon Boeyen <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

On Wed, 18 Oct 2000, Denis Pinkas wrote:

> link between the AC and the certificate, even if the CA has the same name as

Dennis,

I still think that this solution doesn't quite solve the problem, but is a
good start.  In fact Tom Gindin's suggestion just came in and includes
yours. So I'll sort of work off of that.

The fact is that the entityName option still contains a DN and the RP MUST
be prepared to accept it. However, on what conditions should the RP accept
the Holder as a DN? (Especially if this verification is offloaded to some
remote verification engine).

When using an AC that contains the Holder specification as a DN entityName
option, the DN MUST verifiable and uniquely name an entity within the PKI
of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
ONLY create AttributeCertificates with the Holder as a DN entityName in
this fashion. This constraint is subject to the entire PKI for which the
AA belongs belongs to behave in its creation of unique DN. Therefore,
verification is subject to the trust the RP places in the AA and its PKI
together to conform to this behavior.

[Note: this approach still does not solve the problem that Denis brings up
below as comment 43. A subordinate CA may be compromised within the PKI of
the AA and create impostor certificates, grabbing privileges.]

Therefore, it would still probably be better to use the Issuer/Serial and
a hash of the Issuer's certificate, even if in the same PKI.

Of course, when an application authenticates to an RP using PKCs this ties
the authorization to a particular certificate. Apparently that was not
desirable due to the effect of key rollover and new certificates being
issued to the same subject entity.

However, I think that if as Carlise pointed out, that if the DN is only
used in the case of a single trusted Root, then everything will be fine.

Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
that is already defined in the document for the certificate Hash).

Section 4.1:

   Holder ::= SEQUENCE {

When using an entityName that contains a DN, the DN MUST verifiably and
uniquely name an entity within the PKI of the AC issuer. The PKC named by
the DN MUST verify back to the root CA of the AC issuer. The AC issuer
MUST ONLY create AttributeCertificates with the Holder as a DN entityName
in this fashion. This constraint is subject to the entire PKI for which
the AC issuer belongs to behave in its creation of unique DNs. Therefore,
verification is also subject to the trust the RP places in the AC issuer's
PKI to conform to this behavior.

In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
inserting 2, 3, and 4 below, and renumbering accordingly).

2. When the AC holder is named by a DN using the entityName option,
   the holder's PK certificate MUST be uniquely found under the same root
   CA as the AC issuer. The entire certification path of that PKC MUST be
   verified in accordance with [PKIXPROF].

3. When the AC holder is named by a baseCertificateId, the issuer's PK
   certificate MUST be uniquely found under the same root CA as
   the AC issuer. The entire certificate path of that PKC MUST
   be verified in accordance with [PKIXPROF].

4. When the AC holder is named by a verifiedBaseCertificateID, the
   named holder issuer's PKC must be found, and that PKC MUST correctly
   digest to the digest value contained in the verifiedBaseCertificateID.
   The entire certificate path starting with the holder's PKC and the PKC
   of the issuer the holder's PKC MUST be verified in accordance
   with [PKIXPROF].

.....

Note: there is *still* a problem with AC targeting and proxying using
just DNs.

Cheers,
-Polar

Date: Wed, 18 Oct 2000 16:45:06 +0200
From: Pedro Miguel Pereira Borges <[email-masked]>
Reply-To: [email-masked]
Organization: Sociedade =?iso-8859-1?Q?Interbanc=E1ria?= de  =?iso-8859-1?Q?Servi=E7os?=, S.A.
To: Lista IETF <[email-masked]>
Subject: Attribute Certificates II

This is a cryptographically signed message in MIME format.

--------------ms903D23EB05C54940DE1300E2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

   Hi all :)

   I'm interested in Attribute Certificates and I tried to keep up with
the latest thread but since it was 37 mails long, at some point I was
lost...
   So sorry if this is a re-run :)
   Even so, after reading the latest version, I have some questions that
I hope you can make clearer for me :) :

        -> In section 4.2.3 it's said that all AC Issuers must be
identified by non-empty DNs. It's also said that "it means that the AC
Issuer does not have to know which PKC the verifier will use for it (the
AC Issuer). Using the baseCertificateID field to reference the AC Issuer
would mean that the AC verifier would have to trust the PKC that the AC
Issuer chosed (for itself) at the AC creation time.".
         =

           If that is so, then how does the relying party know what AC
Issuer PKC it should use to verify the signature on the AC ?

        -> If the holder is identified using the "entityName" field can
you assure that only the authentic holder can gain access to some
resource and not another party (with an equal DN) ?
          As far as I know, presenting the AC isn't enough... You also
have to present a proof of possesion (usually the signature of a
challenge) of something that only that identity knows (like the private
key corresponding to the cert's public key)...
           Am I wrong ?
           Or, when you use this field, who presents the AC gets the
access and that's it ?

        -> Regarding the previous point, if you use the
"objectDigestInfo" of a public key or cert, you could make that proof of
possesion right ?

        -> Are supposing that it's the job of a lower software
layer/protocol to verify/ensure that the AC is being presented by the
righteous owner ?
          If so, do you have any protocol in mind ?

   Thanks in advance,

        Pedro Borges   =

-----------------------------------------------------------------------
Pedro Miguel Pereira Borges                            <[email-masked]>
SIBS - Sociedade Interbanc=E1ria de Servi=E7os, S.A.  <http://www.sibs.pt=
/>
Rua Soeiro Pereira Gomes, Lote 1 - 1649-031 Lisboa, Portugal
Tel: + 351 21 791 88 00                         Fax: + 351 21 794 24 40
Certificate Fingerprint 20:A2:77:C5:15:5E:D7:A2:DF:D5:27:53:4A:99:94:37
-----------------------------------------------------------------------
This message was signed with a certificate issued by MULTICERT SIBS.
To validate the signature you must obtain the 'MULTICERT Pilot'
Certification Authority certificate, at http://www.sibs.multicert.com/
-----------------------------------------------------------------------
--------------ms903D23EB05C54940DE1300E2
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

--------------ms903D23EB05C54940DE1300E2--

From: [email-masked]
To: Denis Pinkas <[email-masked]>
cc: Al Arsenault <[email-masked]>, Sharon Boeyen <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 18 Oct 2000 11:28:22 -0400
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

           Holder ::= SEQUENCE {

          Tom Gindin

changes

information

           Holder ::= SEQUENCE {

           Holder ::= SEQUENCE {

with

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,

with:

Denis

> Okay, take your shots at it.

Date: Wed, 18 Oct 2000 16:35:31 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Al Arsenault <[email-masked]>, Sharon Boeyen <[email-masked]>
CC: Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

> Russ Housley wrote:
> >
> > I would like to redirect this thread.  We should be discussing the changes
> > to the document.
> >
> 

> > certification paths must be validated before the authorization information

           Holder ::= SEQUENCE {

if we use ESSCertID (defined in RFC 2634 - CMS) instead of IssuerSerial then
we have:

           Holder ::= SEQUENCE {

with 

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,

In this way, at the time of verification, there is no ambiguity about the
link between the AC and the certificate, even if the CA has the same name as
another CA certified from a different root key.

a defect report to ISO, which is, I think, a real defect: a comment for such

43. Page 30. Section 13.7. Attribute certificate syntax. There is a security
weakness in the linkage of the attribute certificate with a public key
certificate, even when the baseCertificateId is used. 

In such a case an attribute certificate could point to "CA from Delta
company, number 1234567" which is the certificate from Mr Dupont, but if the
CA key is compromised then the attacker could forge a certificate with the
same serial number that would contain the name Mr Durand. The way to counter
that threat is to include the hash of the public key certificate as well.
The ASN1 should be changed to a sequence of both the serial number and the
hash of the certificate and the corresponding explanations should be
adjusted accordingly.

with:

Denis

> Okay, take your shots at it.

Date: Wed, 18 Oct 2000 10:07:26 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Stephen Farrell <[email-masked]>
cc: Al Arsenault <[email-masked]>, Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: AC text changes

On Wed, 18 Oct 2000, Stephen Farrell wrote:

> 
> Hi Al,
> 
> Al Arsenault wrote:
> > 
> > Russ Housley wrote:
> > >
> > > I would like to redirect this thread.  We should be discussing the changes
> > > to the document.
> > >
> > 
> Seconded. (Thirded?)
> > > certification paths must be validated before the authorization information
> I'm nearly ok with this. Minor caveat is that I'd still like that
> the AC profile doesn't mandate PKCs for holder->RP authentication,
> so I'd tweak it to:
>  
> "1.   Where the holder uses a PKC to authenticate to the AC verifier, then 
> the AC holder's PKC MUST be found, and the entire certification path of 
> that PKC MUST be verified in accordance with [PKIXPROF]. As noted in 
> the security considerations section, if some other authentication scheme
> is used, AC verifiers need to be very careful mapping the identities
> (authenticated identity, holder field) involved."
> 
> Similarly, I'd tweak the security considerations section text:
> 
> "         There is a potential security issue when an attribute certificate is
>  PKCs, (one under each of the two roots), belonging to two different holders, might 
>  have the same subject field or even issuer name and serial number, and this 
>  information will be in the AC holder field.  In this case, it may not be possible 
>  to identify which PKC authenticates the AC holder, and thus attributes may 
>  be associated with the wrong holder.
> 
>          One solution to this issue is for AC verifiers to only accept AC/PKC
>  combinations where both the holder's and AC's PKCs chain back to a common root CA, 
>  or to CAs that (1) are cross-certified; and (2) enforce name constraints to ensure 
>  that there are not two issuers with the same names. Failing this, AC verifiers
>  have to establish (using other means) that the potential collisions cannot
>  actually occur, for example, the CPSs of the CAs involved may make it clear that
>  no such name collisions can occur.

I don't know if Stephen saw my previous comment before he wrote this.
So, I'll just reiterate that stating that two issuers that have the same
names are not enough, especially when you must accept an entityName with a
DN in it. I'll propose a rewording of (1) and (2) togther:

Modified:

>          One solution to this issue is for AC verifiers to only accept AC/PKC
>  combinations where both the holder's and AC's PKCs chain back to a common root CA, 

or to CAs that are cross-certified such that name constraints are enforced
to ensure that there MUST NOT be two end entities with the same names.
Failing this, AC verifiers

>  have to establish (using other means) that the potential collisions cannot
>  actually occur, for example, the CPSs of the CAs involved may make it clear that
>  no such name collisions can occur.

I don't really like this last part, but I don't really understand the Law
that applies to CPSs and how it can enforce problems, especially
automatically. All it does do is prevent a ligitimate user from using its
privileges, because the AC verifier couldn't really be sure if there was
another legitmate or illegitimate user with the same name.

I am sad that the technology cannot be introduced to ensure that this
problem doesn't exist and all we can get out of it is a warning label on
the side of the box.

Cheers,
-Polar

> Minor tweaks only:-)
> BTW: There was also the issue raised by Tom Gindin (and supported by
> James Manger) about allowing entityName = subject *or* any subjectAltName
> (it currently only allows entityName = subject for this case). I asked folks 
> to comment, but only James supported it and no one objected. Failing 
> further comments, I'll include this change too.
> 
> 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, 18 Oct 2000 14:31:44 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Al Arsenault <[email-masked]>
CC: Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: AC text changes

Hi Al,

Al Arsenault wrote:
> 
> Russ Housley wrote:
> >
> > I would like to redirect this thread.  We should be discussing the changes
> > to the document.
> >
> 

Seconded. (Thirded?)

> > certification paths must be validated before the authorization information

I'm nearly ok with this. Minor caveat is that I'd still like that
the AC profile doesn't mandate PKCs for holder->RP authentication,
so I'd tweak it to:
 
"1.   Where the holder uses a PKC to authenticate to the AC verifier, then 
the AC holder's PKC MUST be found, and the entire certification path of 
that PKC MUST be verified in accordance with [PKIXPROF]. As noted in 
the security considerations section, if some other authentication scheme
is used, AC verifiers need to be very careful mapping the identities
(authenticated identity, holder field) involved."

Similarly, I'd tweak the security considerations section text:

"         There is a potential security issue when an attribute certificate is
 issued to a holder and the holder's PKC chains back to a root CA that is
 independent from the root CA to which the AC issuer's PKC chains.
 "Independent" means that neither root CA is subordinate to the other,
 and they are not cross-certified.  The security issue is that two
 PKCs, (one under each of the two roots), belonging to two different holders, might 
 have the same subject field or even issuer name and serial number, and this 
 information will be in the AC holder field.  In this case, it may not be possible 
 to identify which PKC authenticates the AC holder, and thus attributes may 
 be associated with the wrong holder.

         One solution to this issue is for AC verifiers to only accept AC/PKC
 combinations where both the holder's and AC's PKCs chain back to a common root CA, 
 or to CAs that (1) are cross-certified; and (2) enforce name constraints to ensure 
 that there are not two issuers with the same names. Failing this, AC verifiers
 have to establish (using other means) that the potential collisions cannot
 actually occur, for example, the CPSs of the CAs involved may make it clear that
 no such name collisions can occur.

> Okay, take your shots at it.

Minor tweaks only:-)

BTW: There was also the issue raised by Tom Gindin (and supported by
James Manger) about allowing entityName = subject *or* any subjectAltName
(it currently only allows entityName = subject for this case). I asked folks 
to comment, but only James supported it and no one objected. Failing 
further comments, I'll include this change too.

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, 17 Oct 2000 22:57:49 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Al Arsenault <[email-masked]>
cc: Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

On Tue, 17 Oct 2000, Al Arsenault wrote:

> 
> 
> Russ Housley wrote:
> > 
> > I would like to redirect this thread.  We should be discussing the changes
> > to the document.
> >
> 
> > certification paths must be validated before the authorization information

Hmmm. I didn't realize that wasn't there, or I thought it was at least
implied by (2).

> 	There is a potential security issue when an attribute certificate is
                 ^^^^^^^^^^^
  There is a security issue

> are not two issuers with the same names.

Oh well, I can't see what techincal merit can be brought forth in the
"Security Concerns" section, especially with no possible means of solving
the problem other than declaring you to have eminate domain over all
parties, AAs,RPs,PKC RootCAs, involved. I wouldn't really need a public
standard in that case.

In addition, the (2) is not good enough. You have to ensure that there are
no two issuers with the same names when using the Issuer-Serial
baseCertificateId option, or no two end entities with the same names.  Of
course, a Relying Party may not know what he's going to get handed to it,
Issuer-Serial or entityName, since he MUST accept both. Correct?
Therefore, all DNs MUST be unique. Of course, that does nothing for
established PKIs that *already* have name collisions, or the possiblity
for creating them.

Anyway, who does the enforcing? The RP or does the cross certification of
CAs have to figure out what name constraints don't issue collisions a
priori? That means they either have to permit all the trees that don't
have collisions, or either deny all the trees that do have collisions.
This is not simple. Especially if you want identities in those collision
spaces to actually do something.

Cheers,
-Polar

From: "Rich Ankney" <[email-masked]>
To: "Al Arsenault" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Tue, 17 Oct 2000 22:32:35 -0400

Regards,
Rich

-----Original Message-----
From: Al Arsenault <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]

changes
information
>Okay, take your shots at it.

Date: Tue, 17 Oct 2000 21:57:22 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Russ Housley <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Russ Housley wrote:
> 
> I would like to redirect this thread.  We should be discussing the changes
> to the document.
>

> certification paths must be validated before the authorization information

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

From: Hal Lockhart <[email-masked]>
To: Denis Pinkas <[email-masked]>, IETF-PXIX <[email-masked]>
Subject: RE: TSP. Version 10
Date: Tue, 17 Oct 2000 20:43:45 -0400

> FYI, the abstract and the introduction are now as follows:
> 
> Abstract
> 
> A time stamping service allows to prove that a datum existed before 
> a particular time.

I thought you would have fixed the fact that there seemes to be a word
missing after "allows". What that word should be, ("one", "a party", "a
user", "someone", "a subscriber")I do not know.

Hal

Date: Tue, 17 Oct 2000 15:46:52 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt
Cc: [email-masked], [email-masked], [email-masked]

I would like to redirect this thread.  We should be discussing the changes 
to the document.

What changes are needed to the base document that make it clear that 
certification paths must be validated before the authorization information 
contained in an attribute certificate can be safely used?

   -- Russ

Date: Tue, 17 Oct 2000 10:05:51 -0700 (PDT)
From: julie whitfield <[email-masked]>
To: [email-masked]

Please unsubscribe from mailing list

=====
Red leader---OUT!!!

J

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

Date: Tue, 17 Oct 2000 09:40:51 -0500
From: Dale Gustafson <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Stephen,
<p>Comments inline.
<p>Best Regards,
<p>--dg
<p>Stephen Farrell wrote:
<blockquote TYPE=CITE>Hi Dale,
<p>> What I mean is a value that maps, cryptographically, to only one certificate.
<p>Ok there are lots of examples of pointing to one certificate all right,
however,
<br>I don't know of any that point to one certificate *path*, which is
what I thought
<br>you meant.
<p>> I think the potential attack described earlier is that a bad guy would
intentionally assume the
<br>> name of a legitimate CA for the express purpose of gaining use of
permissions, etc. provided by
<br>> someone else's AC.&nbsp; So we can't say this is unlikely to occur.
<p>Yes, but that attack applies in all PKI cases - it amounts to
<br>grabbing the root configuration information of the RP, as
<br>discussed in Al's earlier message. If we need new bits on the
<br>wire to protect against this, then that'd affect all PKIX
<br>specifications and probably S/MIME, TLS and IPSec too. Do we
<br>really need to go there? I don't believe so. (And I certainly
<br>don't want to either:-) I can't see any reason why the AC
<br>profile is any different from any of those, in the face of
<br>"stomping on root CA configuration" attacks.
<p>And so I don't see any need to add such new attributes to an AC.</blockquote>
I believe the potential attack consisted of replacing the entire PKC chain.&nbsp;
This could done if the Holder's PKC was identified only by issuer and serial
number within the AC and the attacker was somehow able to get a different
key (and the holder's DN and serial number) certified by any other accepted
CA.
<p>A significant difference in the AC case is that the Holder's public
key is outside of the AC so there needs to be a solid link from the AC
to the holder's PKC.
<p>If referencing the holder's PKC only (rather than a specific PKC chain)
is architecturally more elegant, then I agree that's a better solution.
<br>&nbsp;
<blockquote TYPE=CITE>Stephen.
<p>--
<br>____________________________________________________________
<br>Stephen Farrell
<br>Baltimore Technologies,&nbsp;&nbsp; tel: (direct line) +353 1 647 7406
<br>61 Fitzwilliam Lane,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
fax: +353 1 647 7499
<br>Dublin 2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

<a href="mailto:[email-masked]">mailto:[email-masked]</a>
<br>Ireland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

<a href="http://www.baltimore.com">http://www.baltimore.com</a></blockquote>
</html>

Date: Tue, 17 Oct 2000 09:01:59 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Al Arsenault <[email-masked]>
cc: [email-masked], Carlisle Adams <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

On Mon, 16 Oct 2000, Al Arsenault wrote:

> > [SNIPPED] 
> 
> AWA: Well, those who know me know that I've been called "paranoid" and a
> lot of other things in my 17+ years in this security business, now. 
> (Actually, I can think of at least 4 regular contributors to this list
> who have called me "paranoid" at one point or another. :-) I'm generally
> seen as one unwilling to accept even the tiniest of security holes. 
> However, in this case, I think that it comes down to a tradeoff:
> 
> 	- if the RP trusts two independent Root CAs, then there is a chance
> that the two Roots can have sub-CAs that cause naming collisions.  This
> applies to ACs or PKCs.
> 
> 	- if you don't want to accept that risk, then as Carlisle has
> suggested, you simply operate in an environment in which you don't do
> this.  You make everything be "one PKI", chaining back to the "one true
> Root" that you choose to/have to trust.
> 
> 	- on the other hand, the benefits of accepting two independent Roots
> are that you can work in two different environments, simultaneously,
> without worrying about the relationship of the Roots themselves.  If I
> want to use a DVNT cert issued under a DST root, and a VeriSign cert
> under a VeriSign root, and an Entrust cert issued under an XYZ root, I
> really don't want to care about the relationships among the top levels. 
> If I choose to take the risk, it's my choice.
> 
> So: benefits of "two PKIs" vs. risks of naming collisions. Sounds like a
> trade-off to me. One I think that we ought to allow.

So, Al, Let me guess.
You are still driving your Ford Explorer with the Bridgestone tires on it.
:)

-Polar

Content-return: allowed
Date: Tue, 17 Oct 2000 05:46:58 -0700
From: Frank Balluffi <[email-masked]>
Subject: RE: question about certificate path length
To: "'Hiroyuki Sakakibara'" <[email-masked]>, [email-masked]

Hiroyuki,

I believe that your understanding is correct.

Note that draft-ietf-pkix-new-part1-02.txt's definition of the basic
constraints extension (section 4.2.1.10) clears up ambiguities found in RFC
2459's definition. For example, draft-ietf-pkix-new-part1-02.txt states:

This extension MAY appear as a critical or non-critical extension in end
entity certificates.

where RFC 2459 says:

This extension SHOULD NOT appear in end entity certificates.

Frank

In the case of validating Cert_b as  EE certificate, the 
> certificate path is
> Cert_a -> Cert_b,

When validating

section 3

   end entity:  user of PKI certificates and/or end user system that
                is the subject of a certificate;

4.2.1.10  
   This extension MUST appear as a critical extension in all CA
   certificates.  This extension SHOULD NOT appear in end entity
   certificates.

   This extension MUST appear as a critical extension in all CA
   certificates.  This extension SHOULD NOT appear in end entity
   certificates.

> From: Hiroyuki Sakakibara [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2000 2:55 AM
> To: [email-masked]
> Subject: question about certificate path length
> 
> 
> Hi.
> 
> I have a question about difference between "certificate path 
> length" and
> "pathLenConstraint field in the basicConstraint extension".
> 
> >Internet X.509 Public Key Infrastructure
> >Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
> >July 14, 2000
> 
> >4.2.1.10  Basic Constraints
> >"The pathLenConstraint field is meaningful only if cA is set to TRUE.
> >   In this case, it gives the maximum number of CA certificates that
> >may follow this certificate in a certification path."
> 
> SNIP
> 
> >6.1 Basic Path Validation
> 
> >To meet this goal, the path validation process verifies, among other
> >things, that a prospective certification path (a sequence of n certi-
> >ficates) satisfies the following conditions:
> >      (i) for all x in {1, ..., n-1}, the subject of certificate x is
> >      the issuer of certificate x+1;
> >      (ii) certificate 1 is issued by the trust anchor;
> >      (iii) certificate n is the end entity certificate; and
> >      (iv) for all x in {1, ..., n}, the certificate was valid at the
> >      time in question.
> SNIP
> >(inputs)
> >(a) a prospective certification path of length n;
> 
> >State variable initialization
> >(l) max_path_length:  this integer is initialized to n, and is
> >      reset by the path length constraint field within the basic con-
> >      straints extension of a CA certificate.
> 
> Referencing "Internet X.509 Public Key Infrastructure
> Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
> July 14, 2000"
>  I will describe my understanding.
> 
> For example,
> 
> CAa : trust anchor
> CAb : subordinate CA of CAa
> CAc : subordinate CA of CAb
> CAd : subordinate CA of CAc
> EE   : subordinate user of CAd
> 
> Cert_a : CAa's self-signed certificate
> Cert_b : CAb's certificate issued by CAa
> Cert_c : CAb's certificate issued by CAb
> Cert_d : CAb's certificate issued by CAc
> Cert_user : user's certificate issued by CAd
> 
> In this case, certificate path is
> 
> Cert_a -> Cert_b -> Cert_c -> Cert_d -> Cert_user
> 
> therefore, the length of the certificate path is "5".
> 
> On the other hand, if CAa restricts the number of subordinates
> CAs, 3, actually to CAd in this case, the pathLenConstraint value
> in Cert_a is 3.
> 
> because
> 
> >4.2.1.10  Basic Constraints
> >"The pathLenConstraint field is meaningful only if cA is set to TRUE.
> >   In this case, it gives the maximum number of CA certificates that
> >may follow this certificate in a certification path."
> 
> So, in general, the length of the certificate path means 
> that, the number of
> chained
> certificates, from the trust anchor CA's certificate to EE( 
> user or CA)
> certificate,
> as shown above
> ( including BOTH THE TRUST ANCHOR's CERTIFICATE AND EE CERTIFICATE).
> 
> In the case of validating Cert_b as  EE certificate, the 
> certificate path is
> Cert_a -> Cert_b,
> therefore the length of the certificate path is 2.
> 
> Consequently, if someone handles the Cert_a as the trust anchor CA's
> certificate,
> he sees that the maximam path length is 5, because pathLenConstraint
> in Cert_a is 3, so, he adds "2(CAa and user)" to "3" then 
> gets the length as
> 5.
> 
> Am I misunderstanding ?
> 
> ---------------------------------------
> Hiroyuki Sakakibara
> MITSUBISHI ELECTRIC CORPORATION
> Information Technology R&D Center
> 5-1-1 Ofuna, Kamakura, Kanagawa, Japan
> PHONE: +81-467-41-2183
> FAX:   +81-467-41-2185
> E-mail : [email-masked]
> 

From: "Hiroyuki Sakakibara" <[email-masked]>
To: <[email-masked]>
Subject: Re: question about certificate path length
Date: Tue, 17 Oct 2000 20:35:57 +0900

Hi

There was misdescription in the posted mail.

[WRONG]
> Cert_a : CAa's self-signed certificate
> Cert_b : CAb's certificate issued by CAa
> Cert_c : CAb's certificate issued by CAb
> Cert_d : CAb's certificate issued by CAc
> Cert_user : user's certificate issued by CAd

[CORRECT]
Cert_a : CAa's self-signed certificate
Cert_b : CAb's certificate issued by CAa
Cert_c : CAc's certificate issued by CAb
Cert_d : CAd's certificate issued by CAc
Cert_user : user's certificate issued by CAd

I'm sorry.

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: +81-467-41-2183
FAX:   +81-467-41-2185
E-mail : [email-masked]

From: "Hiroyuki Sakakibara" <[email-masked]>
To: <[email-masked]>
Subject: question about certificate path length
Date: Tue, 17 Oct 2000 15:55:21 +0900

Hi.

I have a question about difference between "certificate path length" and
"pathLenConstraint field in the basicConstraint extension".

>Internet X.509 Public Key Infrastructure
>Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
>July 14, 2000

>4.2.1.10  Basic Constraints
>"The pathLenConstraint field is meaningful only if cA is set to TRUE.
>   In this case, it gives the maximum number of CA certificates that
>may follow this certificate in a certification path."

SNIP

>6.1 Basic Path Validation

>To meet this goal, the path validation process verifies, among other
>things, that a prospective certification path (a sequence of n certi-
>ficates) satisfies the following conditions:
>      (i) for all x in {1, ..., n-1}, the subject of certificate x is
>      the issuer of certificate x+1;
>      (ii) certificate 1 is issued by the trust anchor;
>      (iii) certificate n is the end entity certificate; and
>      (iv) for all x in {1, ..., n}, the certificate was valid at the
>      time in question.
SNIP
>(inputs)
>(a) a prospective certification path of length n;

>State variable initialization
>(l) max_path_length:  this integer is initialized to n, and is
>      reset by the path length constraint field within the basic con-
>      straints extension of a CA certificate.

Referencing "Internet X.509 Public Key Infrastructure
Certificate and CRL Profile   <draft-ietf-pkix-new-part1-02.txt>
July 14, 2000"
 I will describe my understanding.

For example,

CAa : trust anchor
CAb : subordinate CA of CAa
CAc : subordinate CA of CAb
CAd : subordinate CA of CAc
EE   : subordinate user of CAd

Cert_a : CAa's self-signed certificate
Cert_b : CAb's certificate issued by CAa
Cert_c : CAb's certificate issued by CAb
Cert_d : CAb's certificate issued by CAc
Cert_user : user's certificate issued by CAd

In this case, certificate path is

Cert_a -> Cert_b -> Cert_c -> Cert_d -> Cert_user

therefore, the length of the certificate path is "5".

On the other hand, if CAa restricts the number of subordinates
CAs, 3, actually to CAd in this case, the pathLenConstraint value
in Cert_a is 3.

because

>4.2.1.10  Basic Constraints
>"The pathLenConstraint field is meaningful only if cA is set to TRUE.
>   In this case, it gives the maximum number of CA certificates that
>may follow this certificate in a certification path."

So, in general, the length of the certificate path means that, the number of
chained
certificates, from the trust anchor CA's certificate to EE( user or CA)
certificate,
as shown above
( including BOTH THE TRUST ANCHOR's CERTIFICATE AND EE CERTIFICATE).

In the case of validating Cert_b as  EE certificate, the certificate path is
Cert_a -> Cert_b,
therefore the length of the certificate path is 2.

Consequently, if someone handles the Cert_a as the trust anchor CA's
certificate,
he sees that the maximam path length is 5, because pathLenConstraint
in Cert_a is 3, so, he adds "2(CAa and user)" to "3" then gets the length as
5.

Am I misunderstanding ?

---------------------------------------
Hiroyuki Sakakibara
MITSUBISHI ELECTRIC CORPORATION
Information Technology R&D Center
5-1-1 Ofuna, Kamakura, Kanagawa, Japan
PHONE: +81-467-41-2183
FAX:   +81-467-41-2185
E-mail : [email-masked]

From: Michael Zolotarev <[email-masked]>
To: Frank Balluffi <[email-masked]>, Michael Myers <[email-masked]>, [email-masked]
Subject: RE: Delegated Path Validation draft.
Date: Tue, 17 Oct 2000 13:43:41 +1000

Frank,

The path discovery algorithm is [meant to be] deterministic. Theoretically,
two different DPD boxes, regardless if they execute the same or different
path building algorithms, should come up with the same path for the same
certificate, provided that the input conditions are identical. The order of
components in the path may vary, though, but it doesn't change a lot.

Therefore it should be reasonable to expect that a path generated/obtained
by the DPV will be identical to a path generated by any compliant
path-discovery engine.

Michael

> From: Frank Balluffi [mailto:[email-masked]]
> Sent: Tuesday, 17 October 2000 12:10
> To: 'Michael Zolotarev'; Frank Balluffi; Michael Myers;
> [email-masked]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> Michael Zolotarev said:
> 
> > To find out why 'No', a client can use DPD to get the path, 
> > and then ask DPV
> > for each component in the path.
> 
> I agree that a client should be able to request the path used 
> during DPV,
> but I do not see any guarantee that a DPD response will 
> contain the path
> used to generate a previous DPV response. Is my understanding correct?
> 
> Frank
> 

Content-return: allowed
Date: Mon, 16 Oct 2000 19:17:11 -0700
From: Frank Balluffi <[email-masked]>
Subject: RE: Delegated Path Validation draft.
To: "'Michael Zolotarev'" <[email-masked]>, Michael Myers <[email-masked]>, Frank Balluffi <[email-masked]>, [email-masked]

Michael Zolotarev said:

> Frank - I'm still standing on attention to hear why do you 
> think a client
> may want to know 'why Yes'. No jokes. That'd be one of the 
> major requirement
> for audit performed on DPV, if there is for example a legal reason, or
> something...

If a server were to apply a policy not requested by a client, returning this
information to the client might be valuable. Obviously, this assumes that
the protocol allows such behavior.

Frank

Content-return: allowed
Date: Mon, 16 Oct 2000 19:09:55 -0700
From: Frank Balluffi <[email-masked]>
Subject: RE: Delegated Path Validation draft.
To: "'Michael Zolotarev'" <[email-masked]>, Frank Balluffi <[email-masked]>, Michael Myers <[email-masked]>, [email-masked]

Michael Zolotarev said:

> To find out why 'No', a client can use DPD to get the path, 
> and then ask DPV
> for each component in the path.

I agree that a client should be able to request the path used during DPV,
but I do not see any guarantee that a DPD response will contain the path
used to generate a previous DPV response. Is my understanding correct?

Frank

Date: Mon, 16 Oct 2000 17:10:24 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Stephen Farrell <[email-masked]>
cc: Dale Gustafson <[email-masked]>, [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Hi, 

comments below.

On Mon, 16 Oct 2000, Stephen Farrell wrote:

> 
> Hi Dale,
> 
> > What I mean is a value that maps, cryptographically, to only one certificate.  
> 
> Ok there are lots of examples of pointing to one certificate all right, however,
> I don't know of any that point to one certificate *path*, which is what I thought
> you meant.
> 
> > I think the potential attack described earlier is that a bad guy would intentionally assume the
> > name of a legitimate CA for the express purpose of gaining use of permissions, etc. provided by
> > someone else's AC.  So we can't say this is unlikely to occur.
> 
> Yes, but that attack applies in all PKI cases - it amounts to 
> grabbing the root configuration information of the RP, as 
> discussed in Al's earlier message. If we need new bits on the
> wire to protect against this, then that'd affect all PKIX
> specifications and probably S/MIME, TLS and IPSec too. Do we 
> really need to go there? I don't believe so. (And I certainly 
> don't want to either:-) I can't see any reason why the AC 
> profile is any different from any of those, in the face of 
> "stomping on root CA configuration" attacks.

I will not deny that if you grab root configuration information of any RP
that you have a problem in the PKI space. However, this attack doesn't
require you to grab the root configuration. It merely relies on a name
collision whether it is malicious or coincidental.

With AC's you have an indirection problem because you are "naming" a
holder with a DN. You are not doing ANY verification on anything common
between the RP and the AA with respect to the holder.

In TLS you are not naming anything. You present the certificate chain. The
chain has all the evidence you need to do verification of the subject of
the certificate chain. It verifies the authentication signature.

In applications of S/MIME, you are looking to verify a signature of the
subject. You can send the subject's certificate chain if you wish, which
reduces the problem to TLS above. In the advent that you don't send the
certificates, you can name the subject's certificate, but you still have
something, a signature that needs to be verified. So, if you don't get the
correct certificate verification of that signature CANNOT happen.

If in AC's you only name the Holder using its DN you have the following
problem. If you have the possibility of having [CA1,Holder] and
[CA2,Holder] (i.e. a name collision between the CA1 and CA2 spaces) where
[x,y] means x certifies y, in your believable world, there is nothing the
RP can do with just the AC to verify that the AC is certifying CA1's
Holder as opposed to CA2's Holder.

I don't have to grab anybody's root configuration information.

Cheers,
-Polar

> And so I don't see any need to add such new attributes to an
> AC.
> 
> 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: Mon, 16 Oct 2000 17:14:31 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Polar Humenn <[email-masked]>
CC: [email-masked], Carlisle Adams <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Comments in-line, prefaced by my initials, again.

Polar Humenn wrote:
> 
> On Mon, 16 Oct 2000, Al Arsenault wrote:
> 
> <snip>
> I thought it was the case as well, that the AC can really bridge three
> PKIs. That means the holder, the AA, and the RP all can have their own
> different PKIs with the possibility of cross-certification of all three. I
> don't even see a need for cross certification in the model. My browser
> "trusts" 137 root certificates without cross-certification, and nobody
> seems to care all that much.

AWA:  Actually, I think that that's a *really band thing*.  Antime I get
a new browser installed, one of the first things I do is go delete all
the default CA certs, and then add 'em back one at a time as I need to. 
Among other things, it lets you see which certs are really being used.

> 
> > In my opinion, the "security hole" pointed out by Polar can in fact
> > occur, either maliciously or by "accident". (e.g., if the holder's PKC
> > chains back to root_CA_1, and the AA's PKC chains back to root_CA_2,
> > then there can be a cert under root_CA_2 with the same DN,
> > subjectAltName, serial number, ... as the holder's PKC. If the RP trusts
> > both root_CA_1 and root_CA_2, then it may be the case that the RP can't
> > tell which holder PKC to use. And it gets even more interesting if the
> > RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
> > right cert is the one under root_CA_2, and thus everything validates; or
> > does the RP think that the right holder PKC is the one under root_CA_1,
> > and thus reject the AC?)
> >
> > However, I do not believe that the right thing to do is either mandate
> > the objectDigest form in the AC, or kill the AC draft.  And I don't
> > think it's to insert the requirement that the holder's PKC and the AA's
> > PKC chain back to the same root. Rather, I think that the best approach
> > is to acknowledge that this risk exists, and live with it. Put in an
> > explanation (in Security Considerations, in some other section - in the
> > Roadmap, too, in all likelihood - that says that if you trust two
> > independent Root CAs, then this is a risk you run.
> 
> This brush off seems to be a hard call for a group that worried so much
> about the security and trust relationships of PKI to begin with.
> 
> Well, at the very least, I'm glad that some people in the group actually
> see the problem. Whether it amounts to anything significant, I can only
> hope.
> 
> I cannot recommend the use of such products and services, except in
> tightly controlled environments, which rules out e-commerce on the
> internet, or even business-to-business on the internet, or anything on the
> internet. Call me paranoid, but I am a security person, not an issurance
> salesman. Unfortunately, I'd probably make a lot more money if I were the
> latter. :)
> 

AWA: Well, those who know me know that I've been called "paranoid" and a
lot of other things in my 17+ years in this security business, now. 
(Actually, I can think of at least 4 regular contributors to this list
who have called me "paranoid" at one point or another. :-) I'm generally
seen as one unwilling to accept even the tiniest of security holes. 
However, in this case, I think that it comes down to a tradeoff:

	- if the RP trusts two independent Root CAs, then there is a chance
that the two Roots can have sub-CAs that cause naming collisions.  This
applies to ACs or PKCs.

	- if you don't want to accept that risk, then as Carlisle has
suggested, you simply operate in an environment in which you don't do
this.  You make everything be "one PKI", chaining back to the "one true
Root" that you choose to/have to trust.

	- on the other hand, the benefits of accepting two independent Roots
are that you can work in two different environments, simultaneously,
without worrying about the relationship of the Roots themselves.  If I
want to use a DVNT cert issued under a DST root, and a VeriSign cert
under a VeriSign root, and an Entrust cert issued under an XYZ root, I
really don't want to care about the relationships among the top levels. 
If I choose to take the risk, it's my choice.

So: benefits of "two PKIs" vs. risks of naming collisions. Sounds like a
trade-off to me. One I think that we ought to allow.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

Date: Mon, 16 Oct 2000 16:22:08 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Hi,

I do not agree with Carlisle that the AC must verify to the same root CAs
and cross-certifications of root CAs. Nor do I think that
cross-certification eliminates name clashes in the DN space. Nor do I
think that cross-certification is actually required for it to work.

I think all naming schemes follow the basic structure of a name and an
ubiquitous identifiable scope.

Likewise, the AC Holder should have the same thing. If you end up naming
the Holder with a DN you must have a scope in which that name is defined.

Naming the Holder's Root CA (DN) and a hash of its certificate, and maybe
a path length, would probably close the door on this security hole. This
approach names the Holder and its PKI, i.e. name and scope. The scope for
the Holder can be implemented as a standard optional critical attribute.
It isn't a hint, it needs to be verified.

That way AAs and RPs have a way to make sure this door on this security
hole doesn't open. Without it you are forced to accept a risk in using
this technology.

I still have to remind the group that the same exact problems exist with
naming of Proxies and Targets of the AC. Maybe new attributes should be
invented that replace the current ProxyInfo and TargetInfo that names the
proxy or target and the scope of each.

Cheers,
-Polar

Date: Mon, 16 Oct 2000 20:51:32 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Dale Gustafson <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Hi Dale,

> What I mean is a value that maps, cryptographically, to only one certificate.  

Ok there are lots of examples of pointing to one certificate all right, however,
I don't know of any that point to one certificate *path*, which is what I thought
you meant.

> I think the potential attack described earlier is that a bad guy would intentionally assume the
> name of a legitimate CA for the express purpose of gaining use of permissions, etc. provided by
> someone else's AC.  So we can't say this is unlikely to occur.

Yes, but that attack applies in all PKI cases - it amounts to 
grabbing the root configuration information of the RP, as 
discussed in Al's earlier message. If we need new bits on the
wire to protect against this, then that'd affect all PKIX
specifications and probably S/MIME, TLS and IPSec too. Do we 
really need to go there? I don't believe so. (And I certainly 
don't want to either:-) I can't see any reason why the AC 
profile is any different from any of those, in the face of 
"stomping on root CA configuration" attacks.

And so I don't see any need to add such new attributes to an
AC.

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: Mon, 16 Oct 2000 13:48:11 -0500
From: Dale Gustafson <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Stephen,
<p>Comments inline.
<p>Best Regards,
<p>Dale Gustafson
<br>&nbsp;
<p>Stephen Farrell wrote:
<blockquote TYPE=CITE>Dale,
<p>> I think Polar is saying that an AC should be able to (optionally)
contain a
<br>> pointer to "one and only one" PKC chain.&nbsp; This seems like a
reasonable
<br>> requirement given that this same concept has already been defined
in several
<br>> forms for a single PKC within RFC-2459, RFC-2560, et. al.
<p>I'm not sure what you mean here, AFAIK neither RFC contains such a
<br>structure or requirement.</blockquote>
What I mean is a value that maps, cryptographically, to only one certificate.&nbsp;
For example if you create a pointer structure that includes a hash of the
target certificate then you can be pointing to only one certificate (since
two different certificates cannot produce the same hash value).
<p>So a pointer to a single certificate might be something like:
<p><tt>&nbsp;&nbsp; CertPTR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
::=&nbsp;&nbsp;&nbsp;&nbsp; SEQUENCE {</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; issuerName&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Name, -- Issuer's DN</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; serialNumber&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CertificateSerialNumber,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hashAlgorithm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AlgorithmIdentifier,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certHash&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OCTET STRING -- hash of certificate including issuer's signature }</tt>
<p>PKIX RFCs and drafts have used several variations of this technique
to create a pointer to a specific certificate.&nbsp; For example, RFC-2560,
page 7, defines "CertID" which includes a hash of the issuer name and a
hash of the issuer's public key value.
<br>&nbsp;
<blockquote TYPE=CITE>> PKI providers could still follow their preferred
architectural approach
<br>> (cross-certify .vs. trust-points).&nbsp; The "PKC chain pointer"
structure would
<br>> probably be useful in other specifications.
<br>>
<br>> Such a structure might contain a pointer to the first and last certificates
in
<br>> the chain {issuer DN, serial number, cert hash} and a hash of the
entire,
<br>> ordered PKC chain.&nbsp; This chain pointer would map to only one
PKC chain.&nbsp; There
<br>> may be other representations that are more elegant yet equally effective.
<p>In general, I don't believe this would be useful, e.g. imagine an
<br>originator (say an AA or an originating mail UA) including such
<br>an attribute in a signed data structure (an AC or s/mime message).
<br>Now the originator has no way to know what path(s) will be ok for the
<br>relying party, so this attribute can at best be a hint unless you
<br>effectively force the originator to "know" about the relying party's
<br>PKI settings.</blockquote>
The described pointer is a shorthand representation of the full PKC chain,
all or part of which is currently included in a typical signed S/MIME message.&nbsp;
This should be equally useful.
<blockquote TYPE=CITE>So, either:
<p>- its a hint (why bother if it can be ignored?), or,
<br>- the originator has to know the RP's settings (and we've just made
<br>&nbsp; general interop *much* harder if not impossible)
<p>I also think folks are getting carried away here - when has any
<br>real CA service been vulnerable to the types of (particularly
<br>CA!) name collisions that are being claimed here? If it were, how
<br>much confidence should you have in anything else it claims to
<br>offer? I think this is just another case where the certificate
<br>syntax itself cannot fully represent the underlying (PKI or
<br>PMI) policy settings.</blockquote>
I think the potential attack described earlier is that a bad guy would
intentionally assume the name of a legitimate CA for the express purpose
of gaining use of permissions, etc. provided by someone else's AC.&nbsp;
So we can't say this is unlikely to occur.
<blockquote TYPE=CITE>Regards,
<br>Stephen.
<p>--
<br>____________________________________________________________
<br>Stephen Farrell
<br>Baltimore Technologies,&nbsp;&nbsp; tel: (direct line) +353 1 647 7406
<br>61 Fitzwilliam Lane,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
fax: +353 1 647 7499
<br>Dublin 2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="mailto:[email-masked]">mailto:[email-masked]</a>
<br>Ireland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="http://www.baltimore.com">http://www.baltimore.com</a></blockquote>
</html>

Date: Mon, 16 Oct 2000 19:20:43 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Carlisle Adams <[email-masked]>
CC: [email-masked]
Subject: One or many PKIs (was: Re: Comments on draft-ietf-pkix-ac509prof-05.txt)

Carlisle,

The text again:-)

     "The signature on every certificate in the path must be verified. Procedures 
      related to validating signatures and public-key certificates are not repeated 
      in this clause. The privilege verifier must verify the identity of every entity 
      in the path, using the procedures of clause 10. Note that checking the signature 
      on an attribute certificate necessarily involves checking the referenced public-key 
      certificate for its validity. Where privileges are assigned using attribute 
      certificates, path processing engines will need to consider elements of both the 
      PMI and the PKI in the course of determining the ultimate validity of a 
      privilege asserter's attribute certificate." 

> Now, does the text above mean that we take EACH of those entities above and use the procedures of
> clause 10 to verify them, which may lead to multiple PKIs?  Or does it mean that the whole
> collection of entities in the list above all pertain to a single path (with respect to the
> authorization decision), and so are all evaluated *collectively* according to clause 10, which
> leads to a single PKI?

That's the question all right. I read it as the former on the basis that it
doesn't say "collectively" or anything like it. If it did, you'd be right,
but it doesn't.

> [snip]...having a single PKI for all the entities involved in this authorization path
> can eliminate the security hole, whereas having multiple PKIs absolutely cannot eliminate this
> hole.  

Again, I disagree - I don't see how the existence of a cross certificate (compared
to the RP having two trustpoints) eliminates anything (not that there was anything 
to be eliminated in the first place:-). The cross-certificate *might* provide the RP 
with some better recourse in the event of a problem arising, but that's not a 
run-time issue, which is what we're discussing.

> What exactly is the argument in favour of supporting multiple PKIs for this purpose?  What problem
> does it solve?  What benefit does it bring?

It decreases the dependence between the PKI(s) and the PMI, which I
think is useful in practice, e.g. the "single" PKI model would mean that
certain RPs could not validate ACs without first getting the RP's
"local" PKI to issue cross certificates for the AA's and holder's PKI(s).
The issuance of such certificates is neither simple (procedurally), nor 
required, if the RP can safely configure in the relevant trustpoints.

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: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Mon, 16 Oct 2000 13:51:16 -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_01C03799.AEDB5E70
Content-Type: text/plain

Hi Stephen,

> ----------
> From: 	Stephen Farrell[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Monday, October 16, 2000 1:03 PM
> To: 	[email-masked]
> Looks like we disagree on this. This is the X.509 quote (I hope:-):
> 
>      "The signature on every certificate in the path must be verified.
> Procedures 
>      related to validating signatures and public-key certificates are not
> repeated 
>      in this clause. The privilege verifier must verify the identity of
> every entity 
>      in the path, using the procedures of clause 10. Note that checking
> the signature 
>      on an attribute certificate necessarily involves checking the
> referenced public-key 
>      certificate for its validity. Where privileges are assigned using
> attribute 
>      certificates, path processing engines will need to consider elements
> of both the 
>      PMI and the PKI in the course of determining the ultimate validity of
> a
>      privilege asserter's attribute certificate."
> 
> To me, that's prettly clearly saying: "check all PKC's involved" and
> nothing 
> about relationships between the different roots involved.
 
What it says is "verify the identity of every entity in the path, using the
procedures of clause 10."  The identities involved in the path are
represented by the holder's PKC (and all the CAs, if any, up to the root),
the AA's PKC (and those of all the AAs, if any, up to the SOA), and perhaps
the AA that signed the role certificate, if there is one (and all PKCs of
those AAs, if any, up to the SOA).

Now, does the text above mean that we take EACH of those entities above and
use the procedures of clause 10 to verify them, which may lead to multiple
PKIs?  Or does it mean that the whole collection of entities in the list
above all pertain to a single path (with respect to the authorization
decision), and so are all evaluated *collectively* according to clause 10,
which leads to a single PKI?

I suppose that, on its own, the text could be read either way.  However, all
the other places in the PMI text which talk only about "THE PKI" suggest to
me that only a single PKI is assumed.  Add to this the fact that having a
single PKI for all the entities involved in this authorization path can
eliminate the security hole, whereas having multiple PKIs absolutely cannot
eliminate this hole.  Add further the idea that it seems unreasonable for an
AA to issue certificates when it has no way of knowing whether any RPs will
be able to verify certificates in the particular set of multiple PKIs the AA
has chosen.  All of this, taken together, says to me that if the X.509 text
assumed anything at all on this issue, it assumed a single PKI.

Sure, the ACprof I-D can take no stance here, or can explicitly state that
multiple PKIs is the underlying model.  But why open up a potential security
hole when we don't need to (and then have to patch it using the sort of
extension that Polar suggested)?  The single-PKI (for all entities involved
in a given authorization path) model is not fundamentally any more limiting
than the multi-PKI model, but it is more secure, and it seems (to me) to be
more reasonable in terms of what an AA can expect RPs to know.  And (as I
keep saying) given that entities in two PKIs can't authenticate anyway
unless these PKIs are tied into one, I don't see what the objection is.

What exactly is the argument in favour of supporting multiple PKIs for this
purpose?  What problem does it solve?  What benefit does it bring?

Carlisle.

------_=_NextPart_001_01C03799.AEDB5E70
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Stephen,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Stephen =
Farrell[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Reply To:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, October 16, 2000 1:03 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Looks like we disagree on this. This =
is the X.509 quote (I hope:-):</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; &quot;The =
signature on every certificate in the path must be verified. Procedures =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; related to =
validating signatures and public-key certificates are not repeated =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; in this =
clause. The privilege verifier must verify the identity of every entity =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; in the path, =
using the procedures of clause 10. Note that checking the signature =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; on an =
attribute certificate necessarily involves checking the referenced =
public-key </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; certificate =
for its validity. Where privileges are assigned using attribute </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; =
certificates, path processing engines will need to consider elements of =
both the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; PMI and the =
PKI in the course of determining the ultimate validity of a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; privilege =
asserter's attribute certificate.&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">To me, that's prettly clearly saying: =
&quot;check all PKC's involved&quot; and nothing </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">about relationships between the =
different roots involved.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">What it =
says is &quot;verify the identity of every entity in the path, using =
the procedures of clause 10.&quot;&nbsp; The identities involved in the =
path are represented by the holder's PKC (and all the CAs, if any, up =
to the root), the AA's PKC (and those of all the AAs, if any, up to the =
SOA), and perhaps the AA that signed the role certificate, if there is =
one (and all PKCs of those AAs, if any, up to the SOA).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Now, does =
the text above mean that we take EACH of those entities above and use =
the procedures of clause 10 to verify them, which may lead to multiple =
PKIs?&nbsp; Or does it mean that the whole collection of entities in =
the list above all pertain to a single path (with respect to the =
authorization decision), and so are all evaluated *collectively* =
according to clause 10, which leads to a single PKI?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I suppose =
that, on its own, the text could be read either way.&nbsp; However, all =
the other places in the PMI text which talk only about &quot;THE =
PKI&quot; suggest to me that only a single PKI is assumed.&nbsp; Add to =
this the fact that having a single PKI for all the entities involved in =
this authorization path can eliminate the security hole, whereas having =
multiple PKIs absolutely cannot eliminate this hole.&nbsp; Add further =
the idea that it seems unreasonable for an AA to issue certificates =
when it has no way of knowing whether any RPs will be able to verify =
certificates in the particular set of multiple PKIs the AA has =
chosen.&nbsp; All of this, taken together, says to me that if the X.509 =
text assumed anything at all on this issue, it assumed a single =
PKI.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Sure, the =
ACprof I-D can take no stance here, or can explicitly state that =
multiple PKIs is the underlying model.&nbsp; But why open up a =
potential security hole when we don't need to (and then have to patch =
it using the sort of extension that Polar suggested)?&nbsp; The =
single-PKI (for all entities involved in a given authorization path) =
model is not fundamentally any more limiting than the multi-PKI model, =
but it is more secure, and it seems (to me) to be more reasonable in =
terms of what an AA can expect RPs to know.&nbsp; And (as I keep =
saying) given that entities in two PKIs can't authenticate anyway =
unless these PKIs are tied into one, I don't see what the objection =
is.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">What =
exactly is the argument in favour of supporting multiple PKIs for this =
purpose?&nbsp; What problem does it solve?&nbsp; What benefit does it =
bring?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03799.AEDB5E70--

From: Carlisle Adams <[email-masked]>
To: "'Polar Humenn'" <[email-masked]>
Cc: Al Arsenault <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Mon, 16 Oct 2000 13:15:13 -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_01C03794.A5384630
Content-Type: text/plain

Hi Polar,

 
Yes.

Carlisle.

------_=_NextPart_001_01C03794.A5384630
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Polar =
Humenn[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, October 16, 2000 12:25 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Al Arsenault; =
[email-masked]; [email-masked]; [email-masked]; =
[email-masked]; [email-masked]; Stephen McConnell; Kent Salmond; Ken =
Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Carlisle,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">On Mon, 16 Oct 2000, Carlisle Adams =
wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Well, at the very least, I'm =
glad that some people in the group actually</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; see the problem. Whether it =
amounts to anything significant, I can only</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; hope.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Yes, I think people see the =
problem.&nbsp; Furthermore, I've outlined the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; conditions under which it is not =
a problem.&nbsp; These conditions (a single PKI,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; formed through responsible =
cross-certification) are not overly restrictive</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and make perfect sense for =
interoperation between domains that care about</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; security, especially since they =
need to do this anyway in order to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; authenticate each other.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">But this condition of operation for =
the AA still hinges on the fact that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the DN space MUST be unique after =
cross certifying PKI's.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Not =
quite.&nbsp; It hinges on the fact that whatever name space will be =
used, MUST be unique.&nbsp; Name constraints do not have to be applied =
to DNs; they can be applied to e-mail domains, or Kerberos realms, or =
whatever is used within the subject AND subjectAltNames fields (and, in =
fact, can be applied to multiple name spaces simultaneously, if this is =
deemed to be appropriate).&nbsp; The idea is similar to PEM's name =
subordination, but is much more general and flexible.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Can you really see that =
happening?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Yes.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I cannot see that happening in the =
real world. Especially with many</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">players, and especally when you need =
to do things quickly. Forcing one</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">organization or both to comply with =
the other, is a lot of work, and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">figuring out name constraints for =
both could be a daunting effort, not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">mentioning getting it correct.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As one =
example, company A has the e-mail domain A.com and company B has the =
domain B.com.&nbsp; When they cross-certify, the cross-cert that A =
issues says that entities in B's space must be in the B.com domain, and =
the cross-cert that B issues says that entities in A's space must be in =
the A.com domain.&nbsp; This seems quite straightforward and =
intuitive.&nbsp; AND, as I keep saying, they need to do this anyway in =
order to authenticate (this is not some special situation that needs to =
be artificially put in place just so that authorization can =
work).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Other =
example name constraints could equally well have been chosen.&nbsp; I =
don't see the difficulty.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03794.A5384630--

Date: Mon, 16 Oct 2000 18:13:12 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Dale,

> I think Polar is saying that an AC should be able to (optionally) contain a
> pointer to "one and only one" PKC chain.  This seems like a reasonable
> requirement given that this same concept has already been defined in several
> forms for a single PKC within RFC-2459, RFC-2560, et. al.

I'm not sure what you mean here, AFAIK neither RFC contains such a 
structure or requirement.
 
> PKI providers could still follow their preferred architectural approach
> (cross-certify .vs. trust-points).  The "PKC chain pointer" structure would
> probably be useful in other specifications.
> 
> Such a structure might contain a pointer to the first and last certificates in
> the chain {issuer DN, serial number, cert hash} and a hash of the entire,
> ordered PKC chain.  This chain pointer would map to only one PKC chain.  There
> may be other representations that are more elegant yet equally effective.

In general, I don't believe this would be useful, e.g. imagine an 
originator (say an AA or an originating mail UA) including such 
an attribute in a signed data structure (an AC or s/mime message). 
Now the originator has no way to know what path(s) will be ok for the 
relying party, so this attribute can at best be a hint unless you 
effectively force the originator to "know" about the relying party's 
PKI settings. 

So, either:

- its a hint (why bother if it can be ignored?), or,
- the originator has to know the RP's settings (and we've just made
  general interop *much* harder if not impossible)

I also think folks are getting carried away here - when has any
real CA service been vulnerable to the types of (particularly
CA!) name collisions that are being claimed here? If it were, how 
much confidence should you have in anything else it claims to 
offer? I think this is just another case where the certificate
syntax itself cannot fully represent the underlying (PKI or
PMI) policy settings.

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: Mon, 16 Oct 2000 13:05:03 -0400
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting 
To: [email-masked]
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate  authentication draft

Michael Str�der wrote:
> 
> Anders Rundgren wrote:
> >
> > Are you the slightest familiar with XML parsers and schemas?
> 
> There's no doubt that it would be interesting to use XML for the
> presentation layer because of automatic validation against DTD
> retrieved by URL etc.

Yes, XML has great potential for data display. 
But if the data transfer has been performed using
an efficient binary method, such as provided by
any of the ASN.1 encoding rules, there is no need
or benefit for performing further validation of 
the data using either XML DTDs or any of their 
many (relax, etc.) XML schema. 

Simply decoding ASN.1 encoded data validates the 
gross structure of the information, and assures that
the data conforms to the schema specified by the 
ASN.1 notation - decoding guarantees that the data
values are valid members of the distinct set of 
values indicated by the their tag type. 

> But there would be still a need to define the semantics of the
> attributes (name space in XML) to make different applications from
> different vendors interoperable. Or did I get you totally wrong?
> 
> > There is AFAIK not any standardized way to verify that an ASN.1
> > document corresponds to its definition.

This is exactly the opposite of true. Each ASN.1 value is
a member of an ASN.1 type. An ASN.1 type is a class of
distinct values. Given the tag for the type, the validity
of every value can be easily determined. 

In ASN.1 the schema is built into and underlies the actual
notation. There is just one schema in ASN.1, but there are
many encoding rules (soon to include one for XML). One schema
seems to be more than enough for most folks.

> I leave this question open to the ASN.1 compiler experts.
> 
> Ciao, Michael.

-- 
Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------

Date: Mon, 16 Oct 2000 18:03:49 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Carlisle,

Where in X.509(2000) is there an assertion that a "single" PKI is good, bad
or indifferent w.r.t. AC validity? I certainly don't recall one. (Maybe Hoyt 
or Sharon can clarify this?)

> The text that I quoted in my previous message is from X.509 (2000), not from the AC I-D. I have
> not checked, but I strongly suspect that the I-D says nothing about this, which is probably why
> you cannot find it.  

You won't find it since its not there, nor (IMO) should it be.

> I think that the X.509 text implies this pretty clearly, but I don't think
> this is stated explicitly.

Looks like we disagree on this. This is the X.509 quote (I hope:-):

     "The signature on every certificate in the path must be verified. Procedures 
     related to validating signatures and public-key certificates are not repeated 
     in this clause. The privilege verifier must verify the identity of every entity 
     in the path, using the procedures of clause 10. Note that checking the signature 
     on an attribute certificate necessarily involves checking the referenced public-key 
     certificate for its validity. Where privileges are assigned using attribute 
     certificates, path processing engines will need to consider elements of both the 
     PMI and the PKI in the course of determining the ultimate validity of a
     privilege asserter's attribute certificate."

To me, that's prettly clearly saying: "check all PKC's involved" and nothing 
about relationships between the different roots involved.

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

From: "Anders Rundgren" <[email-masked]>
To: "=?iso-8859-1?Q?Michael_Str=F6der?=" <[email-masked]>, <[email-masked]>
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 18:51:39 +0200

<snip>

>But there would be still a need to define the semantics of the
>attributes (name space in XML) to make different applications from
>different vendors interoperable. Or did I get you totally wrong?

Well you *could* do that but I think it is the wrong way to go.
An AC XML attribute schema is the application IMO.  You would typically
find that the health-care sector would define their own schemas (with their own
syntax and semantics only limted by XML itself).  And so would every other sector
or single application do.  I.e. IETF should not have to
bother about semantics for attributes. In the same way as Microsoft does not
care how many BizTalk purchase order schemas are created and how they are to
be interpreted.  It is up to every community.

Anders

Date: Mon, 16 Oct 2000 12:25:56 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Carlisle Adams <[email-masked]>
cc: Al Arsenault <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

Hi Carlisle,

On Mon, 16 Oct 2000, Carlisle Adams wrote:

> > Well, at the very least, I'm glad that some people in the group actually
> > see the problem. Whether it amounts to anything significant, I can only
> > hope.
>  
> conditions under which it is not a problem.  These conditions (a single PKI,
> formed through responsible cross-certification) are not overly restrictive
> and make perfect sense for interoperation between domains that care about

Cheers,
-Polar

From: "Stephen McConnell" <[email-masked]>
To: "Dale Gustafson" <[email-masked]>, "Carlisle Adams" <[email-masked]>
Cc: <[email-masked]>, "'Al Arsenault'" <[email-masked]>, "'Polar Humenn'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Kent Salmond" <[email-masked]>, "Ken Mccoy" <[email-masked]>, "Thumrongsak Kosiyatrakul" <[email-masked]>, "Susan Older" <[email-masked]>, "Shiu-Kai Chin" <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Mon, 16 Oct 2000 18:26:18 +0200
Importance: Normal

Seems to me that Dale's comment seems to properly address the issue here.

Cheers, Steve.

> From: Dale Gustafson [mailto:[email-masked]]
> Sent: Monday, 16 October, 2000 17:41
> To: Carlisle Adams
> Cc: [email-masked]; 'Al Arsenault'; 'Polar Humenn';
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> Stephen McConnell; Kent Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul;
> Susan Older; Shiu-Kai Chin
> I think Polar is saying that an AC should be able to (optionally)
> contain a pointer to "one and only one" PKC chain.  This seems
> like a reasonable requirement given that this same concept has
> already been defined in several forms for a single PKC within
> RFC-2459, RFC-2560, et. al.
>
> PKI providers could still follow their preferred architectural
> approach (cross-certify .vs. trust-points).  The "PKC chain
> pointer" structure would probably be useful in other
> specifications.
>
> Such a structure might contain a pointer to the first and last
> certificates in the chain {issuer DN, serial number, cert hash}
> and a hash of the entire, ordered PKC chain.  This chain pointer
> would map to only one PKC chain.  There may be other
> representations that are more elegant yet equally effective.
>
> Best Regards,
>
> Dale Gustafson
>
>
>
>
> Carlisle Adams wrote:
>
> >
> >
> > Hi Al, Stephen,
> >
> >      ----------
> >      From:   Al Arsenault[SMTP:[email-masked]]
> >      Sent:   Monday, October 16, 2000 9:37 AM
> >      To:     [email-masked]
> >      Cc:     Carlisle Adams; 'Polar Humenn'; [email-masked];
> >      Stephen Farrell wrote:
> >      > Carlisle,
> >      > You're overstating the requirements for an AC to be
> valid. There is
> >      > no need for the AA and holder to belong to the "same"
> PKI - the only
> >      > requirement, in general, is that the RP be able to
> valiate the AA's PKC
> >
> >      > and the holder's PKC and that the AC contents be
> consistent with those
> >      > two PKCs. That's what X.509(2000) says (ignoring "hints" whose
> >      significance
> >      > we'll never know:-) and also what the PKIX AC profile
> says. If there is
> >
> >      > text somewhere clearly to the contrary please point it out.
> >      >
> >      ><rest snipped>
> >
> >      I agree with Stephen - I can find nothing in the AC I-D
> that says that
> >      the AA's PKC and the holder's PKC have to trace back to
> the same Root
> >      CA.  And it was my understanding that that was decided to not be a
> >      requirement.
> >      As always, I'm willing to be shown where I screwed up, and this is
> >      actually required - I've been publicly shown to be wrong
> so many times
> >      that it doesn't bother me at all.  :-)
> >
> >
> > The text that I quoted in my previous message is from X.509
> (2000), not from
> > the AC I-D.  I have not checked, but I strongly suspect that
> the I-D says
> > nothing about this, which is probably why you cannot find it.
> I think that
> > the X.509 text implies this pretty clearly, but I don't think
> this is stated
> > explicitly.
> >
> >      In my opinion, the "security hole" pointed out by Polar can in fact
> >      occur, either maliciously or by "accident". (e.g., if the
> holder's PKC
> >      chains back to root_CA_1, and the AA's PKC chains back to
> root_CA_2,
> >      then there can be a cert under root_CA_2 with the same DN,
> >      subjectAltName, serial number, ... as the holder's PKC. If
> the RP trusts
> >      both root_CA_1 and root_CA_2, then it may be the case that
> the RP can't
> >      tell which holder PKC to use. And it gets even more
> interesting if the
> >      RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
> >      right cert is the one under root_CA_2, and thus everything
> validates; or
> >      does the RP think that the right holder PKC is the one
> under root_CA_1,
> >      and thus reject the AC?)
> >
> >
> > Yes, I agree that the "security hole" can occur if multiple
> PKIs are involved,
> > which is why I believe that the underlying assumption in X.509
> (2000) is that
> > there is one PKI and that it is managed in such a way as to
> avoid identity
> > collisions through proper use of name constraints.  This eliminates the
> > security hole (which, ultimately should be the goal of a security
> > infrastructure).
> >
> > Even aside from security, however, I think that allowing for
> multiple PKIs
> > here is unreasonable in practice.  As Stephen said, what is
> required is that
> > the RP can validate the AA's PKC and the holder's PKC and that
> the AC contents
> > are consistent with those two PKCs.  But in general the AA
> (particularly the
> > SOA) does not know who the relying parties will be, especially
> if delegation
> > is involved so that there are intermediate AAs (this is
> identical to a root CA
> > not knowing who its relying parties are in general when there
> are subordinate
> > CAs in between).  So why would it make sense for the SOA to create
> > certificates that only RPs with trust anchors in these two PKIs
> can validate?
> > It has no way of knowing if such RPs even exist (they
> *probably* do, but the
> > SOA doesn't know who they are, or where they are, or what their
> > needs/assumptions will be with respect to authorization)!  I
> just can't see
> > much value in this level of generalization.  I'm not saying
> that this can't be
> > done, or that we should necessarily do anything to prohibit it,
> but I don't
> > see the value of it and I wonder if it actually would be used.
> >
> > So, I suggest that security and simplicity both lean toward the
> single PKI
> > model.
> >
> >      However, I do not believe that the right thing to do is
> either mandate
> >      the objectDigest form in the AC, or kill the AC draft.  And I don't
> >      think it's to insert the requirement that the holder's PKC
> and the AA's
> >      PKC chain back to the same root. Rather, I think that the
> best approach
> >      is to acknowledge that this risk exists, and live with it.
> Put in an
> >      explanation (in Security Considerations, in some other
> section - in the
> >      Roadmap, too, in all likelihood - that says that if you trust two
> >      independent Root CAs, then this is a risk you run.
> >
> >
> > Fair enough.  That way, those that are serious about security
> can "do the
> > right thing" and those for whom security is less important can
> "hope that bad
> > things don't happen"...  :-)
> >
> >      That's my .02 worth.  And if I'm wrong and missed the part
> in the I-D
> >      that says the two certs do have to chain back to the same
> root, then I
> >      retract the last two paragraphs.
> >
> >
> > As mentioned above, I doubt that you missed anything in the
> I-D.  But look at
> > .509 again with fresh eyes and let me know if I'm just imagining this
> > underlying assumption in the text.
> >
> > Carlisle.
>

Date: Mon, 16 Oct 2000 10:40:38 -0500
From: Dale Gustafson <[email-masked]>
To: Carlisle Adams <[email-masked]>
CC: [email-masked], "'Al Arsenault'" <[email-masked]>, "'Polar Humenn'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Hi Carlisle,

I think Polar is saying that an AC should be able to (optionally) contain a
pointer to "one and only one" PKC chain.  This seems like a reasonable
requirement given that this same concept has already been defined in several
forms for a single PKC within RFC-2459, RFC-2560, et. al.

PKI providers could still follow their preferred architectural approach
(cross-certify .vs. trust-points).  The "PKC chain pointer" structure would
probably be useful in other specifications.

Such a structure might contain a pointer to the first and last certificates in
the chain {issuer DN, serial number, cert hash} and a hash of the entire,
ordered PKC chain.  This chain pointer would map to only one PKC chain.  There
may be other representations that are more elegant yet equally effective.

Best Regards,

Dale Gustafson

Carlisle Adams wrote:

>
>
> Hi Al, Stephen,
>
>      ----------
>      From:   Al Arsenault[SMTP:[email-masked]]
>      Sent:   Monday, October 16, 2000 9:37 AM
>      To:     [email-masked]
>      Cc:     Carlisle Adams; 'Polar Humenn'; [email-masked];
>      Stephen Farrell wrote:
>      > Carlisle,
>      > You're overstating the requirements for an AC to be valid. There is
>      > no need for the AA and holder to belong to the "same" PKI - the only
>      > requirement, in general, is that the RP be able to valiate the AA's PKC
>
>      > and the holder's PKC and that the AC contents be consistent with those
>      > two PKCs. That's what X.509(2000) says (ignoring "hints" whose
>      significance
>      > we'll never know:-) and also what the PKIX AC profile says. If there is
>
>      > text somewhere clearly to the contrary please point it out.
>      >
>      ><rest snipped>
>
>      I agree with Stephen - I can find nothing in the AC I-D that says that
>      the AA's PKC and the holder's PKC have to trace back to the same Root
>      CA.  And it was my understanding that that was decided to not be a
>      requirement.
>      As always, I'm willing to be shown where I screwed up, and this is
>      actually required - I've been publicly shown to be wrong so many times
>      that it doesn't bother me at all.  :-)
>
>
> The text that I quoted in my previous message is from X.509 (2000), not from
> the AC I-D.  I have not checked, but I strongly suspect that the I-D says
> nothing about this, which is probably why you cannot find it.  I think that
> the X.509 text implies this pretty clearly, but I don't think this is stated
> explicitly.
>
>      In my opinion, the "security hole" pointed out by Polar can in fact
>      occur, either maliciously or by "accident". (e.g., if the holder's PKC
>      chains back to root_CA_1, and the AA's PKC chains back to root_CA_2,
>      then there can be a cert under root_CA_2 with the same DN,
>      subjectAltName, serial number, ... as the holder's PKC. If the RP trusts
>      both root_CA_1 and root_CA_2, then it may be the case that the RP can't
>      tell which holder PKC to use. And it gets even more interesting if the
>      RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
>      right cert is the one under root_CA_2, and thus everything validates; or
>      does the RP think that the right holder PKC is the one under root_CA_1,
>      and thus reject the AC?)
>
>
> Yes, I agree that the "security hole" can occur if multiple PKIs are involved,
> which is why I believe that the underlying assumption in X.509 (2000) is that
> there is one PKI and that it is managed in such a way as to avoid identity
> collisions through proper use of name constraints.  This eliminates the
> security hole (which, ultimately should be the goal of a security
> infrastructure).
>
> Even aside from security, however, I think that allowing for multiple PKIs
> here is unreasonable in practice.  As Stephen said, what is required is that
> the RP can validate the AA's PKC and the holder's PKC and that the AC contents
> are consistent with those two PKCs.  But in general the AA (particularly the
> SOA) does not know who the relying parties will be, especially if delegation
> is involved so that there are intermediate AAs (this is identical to a root CA
> not knowing who its relying parties are in general when there are subordinate
> CAs in between).  So why would it make sense for the SOA to create
> certificates that only RPs with trust anchors in these two PKIs can validate?
> It has no way of knowing if such RPs even exist (they *probably* do, but the
> SOA doesn't know who they are, or where they are, or what their
> needs/assumptions will be with respect to authorization)!  I just can't see
> much value in this level of generalization.  I'm not saying that this can't be
> done, or that we should necessarily do anything to prohibit it, but I don't
> see the value of it and I wonder if it actually would be used.
>
> So, I suggest that security and simplicity both lean toward the single PKI
> model.
>
>      However, I do not believe that the right thing to do is either mandate
>      the objectDigest form in the AC, or kill the AC draft.  And I don't
>      think it's to insert the requirement that the holder's PKC and the AA's
>      PKC chain back to the same root. Rather, I think that the best approach
>      is to acknowledge that this risk exists, and live with it. Put in an
>      explanation (in Security Considerations, in some other section - in the
>      Roadmap, too, in all likelihood - that says that if you trust two
>      independent Root CAs, then this is a risk you run.
>
>
> Fair enough.  That way, those that are serious about security can "do the
> right thing" and those for whom security is less important can "hope that bad
> things don't happen"...  :-)
>
>      That's my .02 worth.  And if I'm wrong and missed the part in the I-D
>      that says the two certs do have to chain back to the same root, then I
>      retract the last two paragraphs.
>
>
> As mentioned above, I doubt that you missed anything in the I-D.  But look at
> .509 again with fresh eyes and let me know if I'm just imagining this
> underlying assumption in the text.
>
> Carlisle.

From: [email-masked]
Subject: UNSUBSCRIBE
To: [email-masked]
Date: Mon, 16 Oct 2000 16:38:12 +0100

From: Carlisle Adams <[email-masked]>
To: Al Arsenault <[email-masked]>, "'Polar Humenn'" <[email-masked]>
Cc: [email-masked], Carlisle Adams <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Mon, 16 Oct 2000 11:21:22 -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_01C03784.BDDCF880
Content-Type: text/plain

Hi Polar,

> Sent: 	Monday, October 16, 2000 10:48 AM
> To: 	Al Arsenault
> Cc: 	[email-masked]; Carlisle Adams; [email-masked];
> I thought it was the case as well, that the AC can really bridge three
> PKIs. That means the holder, the AA, and the RP all can have their own
> different PKIs with the possibility of cross-certification of all three. 
 
As I mentioned before, as soon as you allow (proper) cross-certification of
all three, you no longer have three, but one.  This is what makes the model
work.

> I don't even see a need for cross certification in the model. My browser
> "trusts" 137 root certificates without cross-certification, and nobody
> seems to care all that much.
 
A number of people have been saying for a long time now that the Web model
(with dozens of "trust anchors" in your software that you've never even
heard about) is NOT a good model for security.  I wouldn't quite say that
"nobody seems to care all that much".  If you look at the organizations
operating PKIs today that care a lot about security (governments and
financial institutions, in particular, but others as well), most of them do
not rely solely upon the browser software for security in their
authentication decisions.

> Well, at the very least, I'm glad that some people in the group actually
> see the problem. Whether it amounts to anything significant, I can only
> hope.
 
Yes, I think people see the problem.  Furthermore, I've outlined the
conditions under which it is not a problem.  These conditions (a single PKI,
formed through responsible cross-certification) are not overly restrictive
and make perfect sense for interoperation between domains that care about
security, especially since they need to do this anyway in order to
authenticate each other.

Carlisle.

------_=_NextPart_001_01C03784.BDDCF880
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Polar =
Humenn[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, October 16, 2000 10:48 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Al =
Arsenault</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]; Carlisle Adams; [email-masked]; =
[email-masked]; [email-masked]; [email-masked]; Stephen McConnell; Kent =
Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai =
Chin</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I thought it was the case as well, =
that the AC can really bridge three</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PKIs. That means the holder, the AA, =
and the RP all can have their own</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">different PKIs with the possibility =
of cross-certification of all three. </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As I =
mentioned before, as soon as you allow (proper) cross-certification of =
all three, you no longer have three, but one.&nbsp; This is what makes =
the model work.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I</FONT><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Times New Roman"></FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">don't even see a need for cross certification in the =
model. My browser</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;trusts&quot; 137 root =
certificates without cross-certification, and nobody</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">seems to care all that much.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">A number =
of people have been saying for a long time now that the Web model (with =
dozens of &quot;trust anchors&quot; in your software that you've never =
even heard about) is NOT a good model for security.&nbsp; I wouldn't =
quite say that &quot;nobody seems to care all that much&quot;.&nbsp; If =
you look at the organizations operating PKIs today that care a lot =
about security (governments and financial institutions, in particular, =
but others as well), most of them do not rely solely upon the browser =
software for security in their authentication decisions.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Well, at the very least, I'm glad that =
some people in the group actually</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">see the problem. Whether it amounts =
to anything significant, I can only</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">hope.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Yes, I =
think people see the problem.&nbsp; Furthermore, I've outlined the =
conditions under which it is not a problem.&nbsp; These conditions (a =
single PKI, formed through responsible cross-certification) are not =
overly restrictive and make perfect sense for interoperation between =
domains that care about security, especially since they need to do this =
anyway in order to authenticate each other.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03784.BDDCF880--

From: Carlisle Adams <[email-masked]>
To: [email-masked], [email-masked], "'Bob Jueneman'" <[email-masked]>
Cc: [email-masked], [email-masked], "<Ed Reed" <[email-masked]>
Subject: RE: Objections to advancing the attribute certificate authenticat ion draft
Date: Mon, 16 Oct 2000 11:06:10 -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_01C03782.9E2ADFE0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Bob,

Just a couple of quick responses to specific points below...

> ----------
> From: 	Bob Jueneman[SMTP:[email-masked]]
> Sent: 	Friday, October 13, 2000 6:56 PM
> To: 	[email-masked]; [email-masked]
> Cc: 	[email-masked]; [email-masked]; <Ed Reed
> Subject: 	Objections to advancing the attribute certificate
> authentication draft
> 
> Secondly, I tend to disagree with the assertion that the PKC issuer is not
> usually authoritative for the authorization information.  This assumes a
> separation of function of identity confirmation vs. authorization which I
> simply haven't seen demonstrated in practice, except arguably in some
> European systems where the State is issuing high-grade identity
> certificates to their citizens.
> 
> Within the US, at least, I would claim that 99.9% all of the identity
> certificates that  have been issued were either created by or vouched for
> by an organizational RA, or were issued by the organization itself. And
> inevitably it is that organization that is authoritative for the
> authorization information.  
 
Yes, the identity certificates were issued by the organization, and it is
the organization that is authoritative for the authorization information.
No argument.  BUT, is it the same department within the organization?  Is it
exactly the same people within the organization that administer both
identity and privilege?  Not that I've seen (or heard about).  Whoever it
was in Novell that assigned you an employee ID number is almost certainly
not the same person that decides whether or not you can sign a cheque for
$10,000. to buy some office equipment or some new software for your machine.

Maybe we just work in different circles, but this separation of function
(identity versus authorization) is about the ONLY thing I've ever seen in
actual practice.

> Finally, I also disagree with the third assumption, i.e., that
> authorization needs to be bound to an identity.  It often is, of course,
> but it need not be, and there are plenty of examples such as extranet
> access control where identity may be relevant to audit, but not to access
> control.  
 
Yes, often identity is relevant to audit but not to access control.
However, audit is extremely important to many organizations (at least for
some types of transactions), so being able to bind these things together,
especially in a persistent way, can be valuable.

> In addition, in some cases it is highly desirable that authorization NOT
> be tied to identity, or at least that the identity be anonymous. An
> example might be a teen-aged girl that wants to log in to get the results
> of her pregnancy test, but without revealing her name.  In that case a
> standard X.509 certificate could be used that contained a security label
> attribute and nothing more than a serial number, with no DN.
 
Sure, a PKC with no DN that includes a security label attribute, or a PKC
with no DN and a corresponding AC that contains a security label attribute.
Either will work and both have their advantages and disadvantages.
Depending on the adv. and disadv. you pick one or the other for some
particular application.

> Because attribute certificates are presently tied to a distinguished NAME
> that is presumably contained in an identity certificate, but not
> necessarily to any particular public/private key or certificate, path
> validation up the chain to two different CAs would seem to be a nightmare,
> and revocation  even worse.
 
ACs MAY be tied to a DN, but are preferably tied to the certificate itself
via issuer/serial.

> In an offline note to me, Ed Reed recently made another cogent
> observation.  Whereas incorporating a security/clearance/rights label in
> an identity certificate binds that label inextricably to the public key
> (and to the identity, if that matters), the same is not true of an
> attribute certificate.  
> 
> In particular, if the function of the security label is to DENY the
> delegation of some particular capability or default to an entity, then all
> that entity has to do is to conveniently "lose" the attribute certificate
> and he is back in business.  This may not be obvious, but without negative
> delegation I really have no way to definitive way to control what CAs I
> trust to control what functions, except by the very ponderous mechanisms
> of closed user groups and policy OID constraints. Yuch.
 
If you want to set up your security architecture in such a way that everyone
gets to do something unless there's a certificate saying "don't let me do
this thing", and you rely upon the entity to volunteer this certificate
whenever they feel like doing this thing, then I can't help but feel that
this is a flawed architecture...  :-)

No, if you want to operate in this manner (i.e., with "negative"
privileges), then the relying party must be responsible for acquiring this
information independent of the requesting entity.  There are multiple ways
to do this securely.  This doesn't argue against ACs.

> In summary, I am afraid I have to object to advancing the proposed draft
> at this time.
 
X.509 (2000) is, of course, already a standard.  I don't see what purpose
objecting to advancing a profile of this standard will serve.  If there are
specific technical flaws, that's one thing.  But objecting on the grounds
that you think the business case for ACs is suspect doesn't make sense.
That would be like trying to hold up RFC 2459 because you don't think
public-key certificates will work.  Trying to hold up a profile because you
really object to the base standard seems to be of little value.

Carlisle.

------_=_NextPart_001_01C03782.9E2ADFE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: Objections to advancing the attribute certificate =
authentication draft</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Bob,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Just a =
couple of quick responses to specific points below...</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Bob =
Jueneman[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Friday, October 13, 2000 6:56 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]; [email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]; [email-masked]; &lt;Ed Reed</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Objections to advancing the attribute certificate authentication =
draft</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Secondly, I tend to disagree with the =
assertion that the PKC issuer is not usually authoritative for the =
authorization information.&nbsp; This assumes a separation of function =
of identity confirmation vs. authorization which I simply haven't seen =
demonstrated in practice, except arguably in some European systems =
where the State is issuing high-grade identity certificates to their =
citizens.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Within the US, at least, I would claim =
that 99.9% all of the identity certificates that&nbsp; have been issued =
were either created by or vouched for by an organizational RA, or were =
issued by the organization itself. And inevitably it is that =
organization that is authoritative for the authorization =
information.&nbsp; </FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Yes, the =
identity certificates were issued by the organization, and it is the =
organization that is authoritative for the authorization =
information.&nbsp; No argument.&nbsp; BUT, is it the same department =
within the organization?&nbsp; Is it exactly the same people within the =
organization that administer both identity and privilege?&nbsp; Not =
that I've seen (or heard about).&nbsp; Whoever it was in Novell that =
assigned you an employee ID number is almost certainly not the same =
person that decides whether or not you can sign a cheque for $10,000. =
to buy some office equipment or some new software for your =
machine.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Maybe we =
just work in different circles, but this separation of function =
(identity versus authorization) is about the ONLY thing I've ever seen =
in actual practice.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Finally, I also disagree with the =
third assumption, i.e., that authorization needs to be bound to an =
identity.&nbsp; It often is, of course, but it need not be, and there =
are plenty of examples such as extranet access control where identity =
may be relevant to audit, but not to access control.&nbsp; </FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Yes, =
often identity is relevant to audit but not to access control.&nbsp; =
However, audit is extremely important to many organizations (at least =
for some types of transactions), so being able to bind these things =
together, especially in a persistent way, can be valuable.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In addition, in some cases it is =
highly desirable that authorization NOT be tied to identity, or at =
least that the identity be anonymous. An example might be a teen-aged =
girl that wants to log in to get the results of her pregnancy test, but =
without revealing her name.&nbsp; In that case a standard X.509 =
certificate could be used that contained a security label attribute and =
nothing more than a serial number, with no DN.</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Sure, a =
PKC with no DN that includes a security label attribute, or a PKC with =
no DN and a corresponding AC that contains a security label =
attribute.&nbsp; Either will work and both have their advantages and =
disadvantages.&nbsp; Depending on the adv. and disadv. you pick one or =
the other for some particular application.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Because attribute certificates are =
presently tied to a distinguished NAME that is presumably contained in =
an identity certificate, but not necessarily to any particular =
public/private key or certificate, path validation up the chain to two =
different CAs would seem to be a nightmare, and revocation&nbsp; even =
worse.</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">ACs MAY =
be tied to a DN, but are preferably tied to the certificate itself via =
issuer/serial.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In an offline note to me, Ed Reed =
recently made another cogent observation.&nbsp; Whereas incorporating a =
security/clearance/rights label in an identity certificate binds that =
label inextricably to the public key (and to the identity, if that =
matters), the same is not true of an attribute certificate.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In particular, if the function of the =
security label is to DENY the delegation of some particular capability =
or default to an entity, then all that entity has to do is to =
conveniently &quot;lose&quot; the attribute certificate and he is back =
in business.&nbsp; This may not be obvious, but without negative =
delegation I really have no way to definitive way to control what CAs I =
trust to control what functions, except by the very ponderous =
mechanisms of closed user groups and policy OID constraints. =
Yuch.</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">If you =
want to set up your security architecture in such a way that everyone =
gets to do something unless there's a certificate saying &quot;don't =
let me do this thing&quot;, and you rely upon the entity to volunteer =
this certificate whenever they feel like doing this thing, then I can't =
help but feel that this is a flawed architecture...&nbsp; =
:-)</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">No, if you =
want to operate in this manner (i.e., with &quot;negative&quot; =
privileges), then the relying party must be responsible for acquiring =
this information independent of the requesting entity.&nbsp; There are =
multiple ways to do this securely.&nbsp; This doesn't argue against =
ACs.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In summary, I am afraid I have to =
object to advancing the proposed draft at this time.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">X.509 =
(2000) is, of course, already a standard.&nbsp; I don't see what =
purpose objecting to advancing a profile of this standard will =
serve.&nbsp; If there are specific technical flaws, that's one =
thing.&nbsp; But objecting on the grounds that you think the business =
case for ACs is suspect doesn't make sense.&nbsp; That would be like =
trying to hold up RFC 2459 because you don't think public-key =
certificates will work.&nbsp; Trying to hold up a profile because you =
really object to the base standard seems to be of little =
value.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03782.9E2ADFE0--

Sender: [email-masked]
Date: Mon, 16 Oct 2000 16:57:06 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Organization: stroeder.com
To: [email-masked]
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate  authentication draft

Anders Rundgren wrote:
> 
> Are you the slightest familiar with XML parsers and schemas?

There's no doubt that it would be interesting to use XML for the
presentation layer because of automatic validation against DTD
retrieved by URL etc. 

But there would be still a need to define the semantics of the
attributes (name space in XML) to make different applications from
different vendors interoperable. Or did I get you totally wrong?

> There is AFAIK not any standardized way to verify that an ASN.1
> document corresponds to its definition.

I leave this question open to the ASN.1 compiler experts.

Ciao, Michael.

From: =?iso-8859-1?Q?Fran=E7ois-Fr=E9d=E9ric_Ozog?= <[email-masked]>
To: "Anders Rundgren" <[email-masked]>, "Bob Jueneman" <[email-masked]>, <[email-masked]>, "Polar Humenn" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 17:04:22 +0200

Anders,

Since January I was trying to solve a business problem then I came to a
conclusion to the need of a new concept. Investigated it and found something
closse to AC. In fact I can use AC as a building block. Checking IDs and
signing e-mails are a nice to have: that's why PKIs haven't yet been really
deployed.What you can build with AC will become a must have and I expect it
to drive PKI implementations.

Stephen, Polar

I think that Polar addressed a number of valid points but we are looping in
circles to get them fixed: I am not sure I make a list of all of them to
address them one by one. I creates a climate of uncertainty that raises
doubts in Bob's mind.
Can you help better structure the resolution of those issues.

>From my perspective, I see two main objections:

1) How holder is identified ?
Certificate, DN, ...

2) Can you trust DN way to assign attributes ?

3) How trust can be built in PKI ?
a) From a business standpoint
b) From a technical standpoint

Clearly points number 3a and 3b are a very interesting general PKI problem
but should not impact AC.

FFO

> Tim,
>
> >Bob - One of the main reasons for favouring a collection of attribute
certificates over
> >a collection of public-key certificates for asserting privilege is that
one of the main
> >costs associated with public-key certificates is that related to the
management of the
> >corresponding private key.  The private key has to be secured for
confidentiality
>
> You are right but I felt that the core of Bob's criticism of ACs is not
based on security
> issues but rather on the business case (applications if you prefer) for
ACs.
>
> I wholeheartedly agree with Bob that the use of ACs between organizations
is highly dubious
> but if ACs become an RFC or not is something I care less about.  I.e. a
standard that
> no one uses is IMO "harmless".
>
> ACs are though redundant as:
> - ACs have no support in the commercial world including browsers.  Never
will.
> - ACs are in the "wrong" format: ASN.1.  XML is what's counts in
e-business
> - ACs are like PKCs originally thought of replacing paper credentials in
an off-line world. In
> an on-line world authority can be delivered directly from the source which
make issuing,
> distribution, validity, and revocation essentially "no-issues".
>
> Internally there are other solutions such as Kerberos, Externally ACs
complicate things
> more than they solve.
>
> An AC RFC cannot change these basic facts!
>
> BTW, are ACs also anticipated to be used in conjunction with digital
signatures?
> Anyone written a paper on that?
>
> Anders Rundgren
> Senior Internet e-commerce Architect
> X-OBI AB
>

Date: Mon, 16 Oct 2000 10:48:07 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Al Arsenault <[email-masked]>
cc: [email-masked], Carlisle Adams <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

On Mon, 16 Oct 2000, Al Arsenault wrote:

> Stephen Farrell wrote:
> > 
> > Carlisle,
> > 
> > You're overstating the requirements for an AC to be valid. There is
> > no need for the AA and holder to belong to the "same" PKI - the only
> > requirement, in general, is that the RP be able to valiate the AA's PKC
> > and the holder's PKC and that the AC contents be consistent with those
> > two PKCs. That's what X.509(2000) says (ignoring "hints" whose significance
> > we'll never know:-) and also what the PKIX AC profile says. If there is
> > text somewhere clearly to the contrary please point it out.
> > 
> ><rest snipped>
> 
> I agree with Stephen - I can find nothing in the AC I-D that says that
> the AA's PKC and the holder's PKC have to trace back to the same Root
> CA.  And it was my understanding that that was decided to not be a
> requirement.
> As always, I'm willing to be shown where I screwed up, and this is
> actually required - I've been publicly shown to be wrong so many times
> that it doesn't bother me at all.  :-)

I thought it was the case as well, that the AC can really bridge three
PKIs. That means the holder, the AA, and the RP all can have their own
different PKIs with the possibility of cross-certification of all three. I
don't even see a need for cross certification in the model. My browser
"trusts" 137 root certificates without cross-certification, and nobody
seems to care all that much.

> In my opinion, the "security hole" pointed out by Polar can in fact
> occur, either maliciously or by "accident". (e.g., if the holder's PKC
> chains back to root_CA_1, and the AA's PKC chains back to root_CA_2,
> then there can be a cert under root_CA_2 with the same DN,
> subjectAltName, serial number, ... as the holder's PKC. If the RP trusts
> both root_CA_1 and root_CA_2, then it may be the case that the RP can't
> tell which holder PKC to use. And it gets even more interesting if the
> RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
> right cert is the one under root_CA_2, and thus everything validates; or
> does the RP think that the right holder PKC is the one under root_CA_1,
> and thus reject the AC?)
> 
> However, I do not believe that the right thing to do is either mandate
> the objectDigest form in the AC, or kill the AC draft.  And I don't
> think it's to insert the requirement that the holder's PKC and the AA's
> PKC chain back to the same root. Rather, I think that the best approach
> is to acknowledge that this risk exists, and live with it. Put in an
> explanation (in Security Considerations, in some other section - in the
> Roadmap, too, in all likelihood - that says that if you trust two
> independent Root CAs, then this is a risk you run.  

This brush off seems to be a hard call for a group that worried so much
about the security and trust relationships of PKI to begin with. 

Well, at the very least, I'm glad that some people in the group actually
see the problem. Whether it amounts to anything significant, I can only
hope.

I cannot recommend the use of such products and services, except in
tightly controlled environments, which rules out e-commerce on the
internet, or even business-to-business on the internet, or anything on the
internet. Call me paranoid, but I am a security person, not an issurance
salesman. Unfortunately, I'd probably make a lot more money if I were the
latter. :)

Cheers,
-Polar

> That's my .02 worth.  And if I'm wrong and missed the part in the I-D
> that says the two certs do have to chain back to the same root, then I
> retract the last two paragraphs.
> 
> 			Al Arsenault
> 			Chief Security Architect
> 			Diversinet Corp.
> 

From: Carlisle Adams <[email-masked]>
To: [email-masked], "'Al Arsenault'" <[email-masked]>
Cc: "'Polar Humenn'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Mon, 16 Oct 2000 10:17:36 -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_01C0377B.D54EA4E0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Al, Stephen,

> ----------
> From: 	Al Arsenault[SMTP:[email-masked]]
> Sent: 	Monday, October 16, 2000 9:37 AM
> To: 	[email-masked]
> Cc: 	Carlisle Adams; 'Polar Humenn'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Stephen McConnell; Kent Salmond; Ken Mccoy;
> Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
> Stephen Farrell wrote:
> > Carlisle,
> > You're overstating the requirements for an AC to be valid. There is
> > no need for the AA and holder to belong to the "same" PKI - the only
> > requirement, in general, is that the RP be able to valiate the AA's PKC
> > and the holder's PKC and that the AC contents be consistent with those
> > two PKCs. That's what X.509(2000) says (ignoring "hints" whose
> significance
> > we'll never know:-) and also what the PKIX AC profile says. If there is
> > text somewhere clearly to the contrary please point it out.
> > 
> ><rest snipped>
> 
> I agree with Stephen - I can find nothing in the AC I-D that says that
> the AA's PKC and the holder's PKC have to trace back to the same Root
> CA.  And it was my understanding that that was decided to not be a
> requirement.
> As always, I'm willing to be shown where I screwed up, and this is
> actually required - I've been publicly shown to be wrong so many times
> that it doesn't bother me at all.  :-)
 
The text that I quoted in my previous message is from X.509 (2000), not from
the AC I-D.  I have not checked, but I strongly suspect that the I-D says
nothing about this, which is probably why you cannot find it.  I think that
the X.509 text implies this pretty clearly, but I don't think this is stated
explicitly.

> In my opinion, the "security hole" pointed out by Polar can in fact
> occur, either maliciously or by "accident". (e.g., if the holder's PKC
> chains back to root_CA_1, and the AA's PKC chains back to root_CA_2,
> then there can be a cert under root_CA_2 with the same DN,
> subjectAltName, serial number, ... as the holder's PKC. If the RP trusts
> both root_CA_1 and root_CA_2, then it may be the case that the RP can't
> tell which holder PKC to use. And it gets even more interesting if the
> RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
> right cert is the one under root_CA_2, and thus everything validates; or
> does the RP think that the right holder PKC is the one under root_CA_1,
> and thus reject the AC?)
 
Yes, I agree that the "security hole" can occur if multiple PKIs are
involved, which is why I believe that the underlying assumption in X.509
(2000) is that there is one PKI and that it is managed in such a way as to
avoid identity collisions through proper use of name constraints.  This
eliminates the security hole (which, ultimately should be the goal of a
security infrastructure).

Even aside from security, however, I think that allowing for multiple PKIs
here is unreasonable in practice.  As Stephen said, what is required is that
the RP can validate the AA's PKC and the holder's PKC and that the AC
contents are consistent with those two PKCs.  But in general the AA
(particularly the SOA) does not know who the relying parties will be,
especially if delegation is involved so that there are intermediate AAs
(this is identical to a root CA not knowing who its relying parties are in
general when there are subordinate CAs in between).  So why would it make
sense for the SOA to create certificates that only RPs with trust anchors in
these two PKIs can validate?  It has no way of knowing if such RPs even
exist (they *probably* do, but the SOA doesn't know who they are, or where
they are, or what their needs/assumptions will be with respect to
authorization)!  I just can't see much value in this level of
generalization.  I'm not saying that this can't be done, or that we should
necessarily do anything to prohibit it, but I don't see the value of it and
I wonder if it actually would be used.

So, I suggest that security and simplicity both lean toward the single PKI
model.

> However, I do not believe that the right thing to do is either mandate
> the objectDigest form in the AC, or kill the AC draft.  And I don't
> think it's to insert the requirement that the holder's PKC and the AA's
> PKC chain back to the same root. Rather, I think that the best approach
> is to acknowledge that this risk exists, and live with it. Put in an
> explanation (in Security Considerations, in some other section - in the
> Roadmap, too, in all likelihood - that says that if you trust two
> independent Root CAs, then this is a risk you run.  
 
Fair enough.  That way, those that are serious about security can "do the
right thing" and those for whom security is less important can "hope that
bad things don't happen"...  :-)

> That's my .02 worth.  And if I'm wrong and missed the part in the I-D
> that says the two certs do have to chain back to the same root, then I
> retract the last two paragraphs.
 
As mentioned above, I doubt that you missed anything in the I-D.  But look
at .509 again with fresh eyes and let me know if I'm just imagining this
underlying assumption in the text.

Carlisle.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi Al, =
Stephen,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Al =
Arsenault[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Monday, October 16, 2000 9:37 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams; 'Polar Humenn'; [email-masked]; [email-masked]; =
[email-masked]; [email-masked]; Stephen McConnell; Kent Salmond; Ken =
Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Stephen Farrell wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Carlisle,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; You're overstating the =
requirements for an AC to be valid. There is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; no need for the AA and holder to =
belong to the &quot;same&quot; PKI - the only</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; requirement, in general, is that =
the RP be able to valiate the AA's PKC</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and the holder's PKC and that =
the AC contents be consistent with those</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; two PKCs. That's what =
X.509(2000) says (ignoring &quot;hints&quot; whose significance</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; we'll never know:-) and also =
what the PKIX AC profile says. If there is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; text somewhere clearly to the =
contrary please point it out.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&lt;rest snipped&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree with Stephen - I can find =
nothing in the AC I-D that says that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the AA's PKC and the holder's PKC =
have to trace back to the same Root</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">CA.&nbsp; And it was my understanding =
that that was decided to not be a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">requirement.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">As always, I'm willing to be shown =
where I screwed up, and this is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">actually required - I've been =
publicly shown to be wrong so many times</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that it doesn't bother me at =
all.&nbsp; :-)</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The text =
that I quoted in my previous message is from X.509 (2000), not from the =
AC I-D.&nbsp; I have not checked, but I strongly suspect that the I-D =
says nothing about this, which is probably why you cannot find =
it.&nbsp; I think that the X.509 text implies this pretty clearly, but =
I don't think this is stated explicitly.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In my opinion, the &quot;security =
hole&quot; pointed out by Polar can in fact</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">occur, either maliciously or by =
&quot;accident&quot;. (e.g., if the holder's PKC</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">chains back to root_CA_1, and the =
AA's PKC chains back to root_CA_2,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">then there can be a cert under =
root_CA_2 with the same DN,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">subjectAltName, serial number, ... as =
the holder's PKC. If the RP trusts</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">both root_CA_1 and root_CA_2, then it =
may be the case that the RP can't</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">tell which holder PKC to use. And it =
gets even more interesting if the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">RP trusts root_CA_2 but not root_CA_1 =
- does the RP assume that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">right cert is the one under =
root_CA_2, and thus everything validates; or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">does the RP think that the right =
holder PKC is the one under root_CA_1,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and thus reject the AC?)</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Yes, I =
agree that the &quot;security hole&quot; can occur if multiple PKIs are =
involved, which is why I believe that the underlying assumption in =
X.509 (2000) is that there is one PKI and that it is managed in such a =
way as to avoid identity collisions through proper use of name =
constraints.&nbsp; This eliminates the security hole (which, ultimately =
should be the goal of a security infrastructure).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Even aside =
from security, however, I think that allowing for multiple PKIs here is =
unreasonable in practice.&nbsp; As Stephen said, what is required is =
that the RP can validate the AA's PKC and the holder's PKC and that the =
AC contents are consistent with those two PKCs.&nbsp; But in general =
the AA (particularly the SOA) does not know who the relying parties =
will be, especially if delegation is involved so that there are =
intermediate AAs (this is identical to a root CA not knowing who its =
relying parties are in general when there are subordinate CAs in =
between).&nbsp; So why would it make sense for the SOA to create =
certificates that only RPs with trust anchors in these two PKIs can =
validate?&nbsp; It has no way of knowing if such RPs even exist (they =
*probably* do, but the SOA doesn't know who they are, or where they =
are, or what their needs/assumptions will be with respect to =
authorization)!&nbsp; I just can't see much value in this level of =
generalization.&nbsp; I'm not saying that this can't be done, or that =
we should necessarily do anything to prohibit it, but I don't see the =
value of it and I wonder if it actually would be used.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">So, I =
suggest that security and simplicity both lean toward the single PKI =
model.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">However, I do not believe that the =
right thing to do is either mandate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the objectDigest form in the AC, or =
kill the AC draft.&nbsp; And I don't</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">think it's to insert the requirement =
that the holder's PKC and the AA's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PKC chain back to the same root. =
Rather, I think that the best approach</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is to acknowledge that this risk =
exists, and live with it. Put in an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">explanation (in Security =
Considerations, in some other section - in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Roadmap, too, in all likelihood - =
that says that if you trust two</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">independent Root CAs, then this is a =
risk you run.&nbsp; </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Fair =
enough.&nbsp; That way, those that are serious about security can =
&quot;do the right thing&quot; and those for whom security is less =
important can &quot;hope that bad things don't happen&quot;...&nbsp; =
:-)</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">That's my .02 worth.&nbsp; And if I'm =
wrong and missed the part in the I-D</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that says the two certs do have to =
chain back to the same root, then I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">retract the last two =
paragraphs.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As =
mentioned above, I doubt that you missed anything in the I-D.&nbsp; But =
look at .509 again with fresh eyes and let me know if I'm just =
imagining this underlying assumption in the text.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0377B.D54EA4E0--

From: "Sergio Tabanelli" <[email-masked]>
To: <[email-masked]>
Subject: RE: Objections to advancing the attribute certificateauthentication draft
Date: Mon, 16 Oct 2000 16:18:27 +0200
Importance: Normal

Hi all

I know that my knowledges on PKI dosen't stand comparison with those owned
by people participant to this open forum, so please forgive me if the
following comments will seems to you semplicistics and conceited.
I think that one of the problems of the actual use of PKCs is that all of
the Public Administrations, Finantial Institutes and private companies that
use this technology are self issuing their certificates, the risk I am
seeing is that everyone will have dozens of Smart cards or crypto devices in
his pocket or purse, everyone containing a key binded with a PKC issued
under its specific policy and with its specific extensions and keyusage. I
know that the universal CA solution is not a good answer, but I think that
milions of CAs everyone crosscertifing each other is not the right solution
too. IMHO a possible solution is few country based CAs that focus their
activity on certification of individual identities with different levels of
recognitions. Identity certs without any usage reference (keyusage,
extkeyusage, extensions and policy multiplications, ...) and standard
application protocols can help to reduce CA proliferation, semplify policies
and clarify responsabilities assignment. What I am saying is that we don't
need PKC with lots of attributes and extensions but different application
protocols and objects (AC is one example) for different purbose, everyone
based on an identity object, the PKC. Maybe this can be considered banal and
semplicistic but for analogy if "x" is the PKC, and we need y as y=f(x) i
think is better to work on f rather then on x. In conclusion IMHO things
like ACs or new signature protocol like signature policies, signature
request and so on can do the job and help people using this technology,
things like keyusage, non repudiation bit, big PKCs with all in, not.

P.S.
I think that two parties with two distinct rules, authorization issuer and
authorization verifier, can agree to use PKCS7 or CMS with signed attributes
to reach same results as with ACs, I consider ACs as a standard and more
suited way (flawed or not) to do this useful thing.

Sergio Tabanelli

From: "Anders Rundgren" <[email-masked]>
To: "=?iso-8859-1?Q?Michael_Str=F6der?=" <[email-masked]>, <[email-masked]>
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 16:03:28 +0200

Michael,

>> Using XML, an AC draft specification would not have to
>> define a single attribute or attribute syntax!
>
>Well, you would have to define a commonly used XML name space to let
>different applications from different vendors work together. Same
>thing as the ASN.1 type definitions used now.

Are you the slightest familiar with XML parsers and schemas?  There
is AFAIK not any standardized way to verify that an ASN.1 document
corresponds to its definition.
And if there is such a feature it is certainly not a part of the standard itself. 
And it is definitely not a part of current operating systems!
Unlike XML which has DOM and SAX APIs.  Regarding the name-space it is
fairly simple using BizTalk as an example.  You publish the XML schema on
a web-site and the name is essentially the URL.  No magic whatsoever.
AC XML schemas (like most XML schemas) would be specialized for different
purposes and geographic regions and must be agreed upon before used. 

Anders

Date: Mon, 16 Oct 2000 09:37:12 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: [email-masked]
CC: Carlisle Adams <[email-masked]>, "'Polar Humenn'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Stephen Farrell wrote:
> 
> Carlisle,
> 
> You're overstating the requirements for an AC to be valid. There is
> no need for the AA and holder to belong to the "same" PKI - the only
> requirement, in general, is that the RP be able to valiate the AA's PKC
> and the holder's PKC and that the AC contents be consistent with those
> two PKCs. That's what X.509(2000) says (ignoring "hints" whose significance
> we'll never know:-) and also what the PKIX AC profile says. If there is
> text somewhere clearly to the contrary please point it out.
> 
><rest snipped>

I agree with Stephen - I can find nothing in the AC I-D that says that
the AA's PKC and the holder's PKC have to trace back to the same Root
CA.  And it was my understanding that that was decided to not be a
requirement.
As always, I'm willing to be shown where I screwed up, and this is
actually required - I've been publicly shown to be wrong so many times
that it doesn't bother me at all.  :-)

In my opinion, the "security hole" pointed out by Polar can in fact
occur, either maliciously or by "accident". (e.g., if the holder's PKC
chains back to root_CA_1, and the AA's PKC chains back to root_CA_2,
then there can be a cert under root_CA_2 with the same DN,
subjectAltName, serial number, ... as the holder's PKC. If the RP trusts
both root_CA_1 and root_CA_2, then it may be the case that the RP can't
tell which holder PKC to use. And it gets even more interesting if the
RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
right cert is the one under root_CA_2, and thus everything validates; or
does the RP think that the right holder PKC is the one under root_CA_1,
and thus reject the AC?)

However, I do not believe that the right thing to do is either mandate
the objectDigest form in the AC, or kill the AC draft.  And I don't
think it's to insert the requirement that the holder's PKC and the AA's
PKC chain back to the same root. Rather, I think that the best approach
is to acknowledge that this risk exists, and live with it. Put in an
explanation (in Security Considerations, in some other section - in the
Roadmap, too, in all likelihood - that says that if you trust two
independent Root CAs, then this is a risk you run.  

That's my .02 worth.  And if I'm wrong and missed the part in the I-D
that says the two certs do have to chain back to the same root, then I
retract the last two paragraphs.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

Sender: [email-masked]
Date: Mon, 16 Oct 2000 15:24:38 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Organization: stroeder.com
To: [email-masked]
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate  authentication draft

Anders Rundgren wrote:
> 
> Using XML, an AC draft specification would not have to
> define a single attribute or attribute syntax!

Well, you would have to define a commonly used XML name space to let
different applications from different vendors work together. Same
thing as the ASN.1 type definitions used now.

Ciao, Michael.

Date: Mon, 16 Oct 2000 09:23:15 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Michael Zolotarev <[email-masked]>
CC: Michael Myers <[email-masked]>, "'Frank Balluffi'" <[email-masked]>, [email-masked]
Subject: Re: Delegated Path Validation draft.

Comments in-line, prefaced by my initials.

Michael Zolotarev wrote:
> 
> On the same tune:
> 
> I expect that receiving 'No' answer will be rather an exception than a
> common case of using DVP. 

AWA: I tend to agree with this part. At least I *hope* that it will be
the case.

>If you keep receiving 'No's, it most likely
> indicates that either your trust/policy settings are wrong, or you are under
> attack. Significance of it is that each 'No' case will require human
> intervention, at least at the initial stage of system's operations. With the
> amount of data required to perform adequate 'why No' analysis being larger
> than a single response message can reasonably communicate.
>

AWA: This part I disagree with. Suppose that I'm trying to access some
popular website from my wireless device, so I choose to use DPV.  Say
for the sake of argument that the site I'm accessing is my brokerage
account on "AlTrade".  Now, I get the result that "AlTrade's certificate
does not validate."  While it's true that during initial system testing
(and maybe during the initial operational stages) I'm going to have my
designers/testers go trace back to the problem, I do not believe that
steady-state operation will need or even want human intervention.  One
of the biggest drawbacks to this whole PKI thing in the eyes of many
people is the cost in terms of people needed to make it work.  If you're
going to staff a help-desk to respond to human phone calls saying "I was
trying to buy stock in XYZ; I got a message that the certificate didn't
validate, and no I have no clue what else was involved", you'd better be
ready to shell out some money for people.

Much more efficient would be "AlTrade's certificate does not validate
because the information is not available at this time; please try later
or call 123-456 for help" or "AlTrade's certificate appears to have
expired, please call 987-5432 to update it" or ...  That way, if you do
have to get the human help desk involved, at least you have a clue what
happened.

> However, once the system went through the initial tuning up stage, and the
> client has acquaired reasonable trust into quality of decisions by  the DPV
> server, receiving 'No' answer should be just 'flagged' by the client, but
> not investigated.
>

AWA: "Not investigated" is only acceptable if what you really want is
for all of your users to answer "yes" to the question "AlTrade's
certificate did not validate, would you like to continue anyway?" It's
not often that they're just going to give up - and I'm not really sure
that that's what you want your customers to do, anyway.

> In short, communicating 'Why No' data to the client is rather a 'roll-out
> stage trace/debug' feature, then normal operation mode feature. Therefore
> making it a part of the core(!) protocol is not very justified, to me.
>

AWA: For the reasons stated above, I disagree.
 
> However, every DPV vendor may of course decide on a special way of ensuring
> that the clients have access to the DPV decision making context. As a
> minimum, I'd expect a server to make its verification procedure logic
> publically known and auditable.
> 
> Frank - I'm still standing on attention to hear why do you think a client
> may want to know 'why Yes'. No jokes. That'd be one of the major requirement
> for audit performed on DPV, if there is for example a legal reason, or
> something...
> 

AWA: I can't think of any reasons to mandate that justification always
be passed with a "yes" answer, but I know of some circumstances where it
would be better to provide "yes, and here's the cert path I validated"
than just "yes". So I'd see "why YES" as more optional than mandatory.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

Sender: [email-masked]
Date: Mon, 16 Oct 2000 13:55:44 +0200
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Organization: stroeder.com
To: PKIX-List <[email-masked]>
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate  authentication draft

Anders Rundgren wrote:
> 
> I.e. instead of
> the misery we have today trying to find out where e-mail addresses in PKCs are
> stored, you either a priori know a certain attribute schema or you just reject it.

Disclaimer: Anders, maybe I totally misunderstood you.

So what's the difference in using ASN.1 or XML? I mean that's what
standards are all about. Defining non-proprietary a-priori knowledge
for applications.

The misery today with RFC822 email adresses is that they were not
present in those old X.500 (especially X.521) days.

Ciao, Michael.

From: "Anders Rundgren" <[email-masked]>
To: "David P. Kemp" <[email-masked]>, <[email-masked]>
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 14:53:31 +0200

David,

> <chuckle>
> 
>I've heard some good arguments for using XML in various contexts, but
>"rigor of schema definition" has never been one of them!

Rigor or rigor.  The thing with XML schemas is that they have a "unique" name that the actual
documents must also contain.  Which a parser can use to automatically verify that
received documents follows the schema definition.  Or a sender can verify that it is sending
a proper document.  There is AFAIK no corresponding feature in X509 certificates
or EDI.  And for clearances and authorizations you'd better understand the message
or reject it.

Using XML, an AC draft specification would not have to define a single attribute or attribute syntax!
Just the container document and its signature part.  The attribute schema may be more or less strict
but that is up to the each AC application implementer to define.

That is indeed something to "chuckle" about compared to having in advance know
("guess" I would say),  how roles, clearances etc. could or should be cast in a digital format!

Anders

Date: Mon, 16 Oct 2000 08:10:02 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: XML ACs Was Re: Objections to advancing the attribute certificate authentication draft
To: [email-masked]
Content-MD5: CUKe8un2tP7gQ1M1loDGBA==

> From: "Anders Rundgren" <[email-masked]>
> 
> Hi,
> Not that I believe that ACs have any value but an XML solution would be simlar
> to BizTalk.  I.e. a generic header format holding an arbitrary XML 
shema-defined
> document holding the actual attributes.  In that way you achieve the 
flexibility to let every
> type of digital relationship define a unique (and from other definitions 
clearly
> separable) set of attributes and corresponding interpretation.  I.e. instead 
of
> the misery we have today trying to find out where e-mail addresses in PKCs are
> stored, you either a priori know a certain attribute schema or you just reject 
it. 
> An AC XML draft could though suggest suitable formats for encrypted items etc.
> 
> Anders

 <chuckle>
 
I've heard some good arguments for using XML in various contexts, but
"rigor of schema definition" has never been one of them!

From: "Anders Rundgren" <[email-masked]>
To: "PKIX-List" <[email-masked]>
Subject: XML ACs Was Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 13:18:16 +0200

Hi,
Not that I believe that ACs have any value but an XML solution would be simlar
to BizTalk.  I.e. a generic header format holding an arbitrary XML shema-defined
document holding the actual attributes.  In that way you achieve the flexibility to let every
type of digital relationship define a unique (and from other definitions clearly
separable) set of attributes and corresponding interpretation.  I.e. instead of
the misery we have today trying to find out where e-mail addresses in PKCs are
stored, you either a priori know a certain attribute schema or you just reject it. 
An AC XML draft could though suggest suitable formats for encrypted items etc.

Anders

From: "Anders Rundgren" <[email-masked]>
To: "Michael Zolotarev" <[email-masked]>, "Bob Jueneman" <[email-masked]>, <[email-masked]>, "Tim Moses" <[email-masked]>
Subject: Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 11:21:14 +0200

Michael,

>> - ACs are in the "wrong" format: ASN.1.  XML is what's counts 
>> in e-business
>
>Rather, XML is what's *hot* in e-business. I'm not saying 'No' to XML. But I
>do not accept it as an argument. The encoding format doesn't affect the
>concept. There is a lot of things that can be blamed for being non-XML,
>however widely accepted for more than historical reasons.

That the concept is not affected by format is true.  Market acceptance is another thing.
That PKCs are in ASN.1 is less of a problem as they are essentially only used as a
an mechanism to bind a named entity to a public key.  ACs are more subject to "interpretation".
And more, it is a *new* thing which may call for a *new* format.   Note: I personally do not suggest
changing anything in the AC specification as it is pretty useless anyway.

<snip>

>> Externally ACs complicate things
>> more than they solve.
>I'd like to hear more *meaty* arguments for it :)

I believe that Bob's initial message had plenty of "beef"!

Anders

From: Michael Zolotarev <[email-masked]>
To: Anders Rundgren <[email-masked]>, Bob Jueneman <[email-masked]>, [email-masked], Tim Moses <[email-masked]>
Subject: RE: Objections to advancing the attribute certificate authenticat ion draft
Date: Mon, 16 Oct 2000 19:26:14 +1000

Anders,

> ACs are though redundant as:
> - ACs have no support in the commercial world

It is easy to claim that something that has just been formally defined has
no support in commercial world. 

> including browsers.  Never will. 

Probably. However we can see how it CAN be used, and some certain advantages
of it. So the time may change current (yet still very much questionable)
attitude.

> - ACs are in the "wrong" format: ASN.1.  XML is what's counts 
> in e-business

Rather, XML is what's *hot* in e-business. I'm not saying 'No' to XML. But I
do not accept it as an argument. The encoding format doesn't affect the
concept. There is a lot of things that can be blamed for being non-XML,
however widely accepted for more than historical reasons.

> - ACs are like PKCs originally thought of replacing paper 
> credentials in an off-line world. In
> an on-line world authority can be delivered directly from the 
> source which make issuing,
> distribution, validity, and revocation essentially "no-issues".

This is a 'pull' model, which is one of defined by the draft.

> 
> Internally there are other solutions such as Kerberos, 
The same argument applies to using PKC in general.

> Externally ACs complicate things
> more than they solve.
I'd like to hear more *meaty* arguments for it :)

Regards
Michael

From: "Anders Rundgren" <[email-masked]>
To: "Bob Jueneman" <[email-masked]>, <[email-masked]>, "Tim Moses" <[email-masked]>
Subject: Re: Objections to advancing the attribute certificate authentication draft
Date: Mon, 16 Oct 2000 09:59:44 +0200

Tim,

>Bob - One of the main reasons for favouring a collection of attribute certificates over
>a collection of public-key certificates for asserting privilege is that one of the main 
>costs associated with public-key certificates is that related to the management of the
>corresponding private key.  The private key has to be secured for confidentiality 

You are right but I felt that the core of Bob's criticism of ACs is not based on security
issues but rather on the business case (applications if you prefer) for ACs.

I wholeheartedly agree with Bob that the use of ACs between organizations is highly dubious
but if ACs become an RFC or not is something I care less about.  I.e. a standard that
no one uses is IMO "harmless".

ACs are though redundant as:
- ACs have no support in the commercial world including browsers.  Never will.
- ACs are in the "wrong" format: ASN.1.  XML is what's counts in e-business
- ACs are like PKCs originally thought of replacing paper credentials in an off-line world. In
an on-line world authority can be delivered directly from the source which make issuing,
distribution, validity, and revocation essentially "no-issues".

Internally there are other solutions such as Kerberos, Externally ACs complicate things
more than they solve.

An AC RFC cannot change these basic facts!

BTW, are ACs also anticipated to be used in conjunction with digital signatures?
Anyone written a paper on that?

Anders Rundgren
Senior Internet e-commerce Architect
X-OBI AB

From: Tim Moses <[email-masked]>
To: [email-masked]
Subject: RE: Objections to advancing the attribute certificate authenticat ion draft
Date: Sun, 15 Oct 2000 21:21:03 -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_01C0370F.599FDCE0
Content-Type: text/plain;
	charset="iso-8859-1"

Bob - One of the main reasons for favouring a collection of attribute
certificates over a collection of public-key certificates for asserting
privilege is that one of the main costs associated with public-key
certificates is that related to the management of the corresponding private
key.  The private key has to be secured for confidentiality and it has to be
activated, rolled-over and revoked.  

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Friday, October 13, 2000 6:57 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; <Ed Reed
Subject: Objections to advancing the attribute certificate
authentication draft

>
>PKCs bind a public key to an identity.
>
>ACs bind attributes to an identity.
>
>Authentication, which includes validating the PKC certification path and 
>having the remote party perform some operation that involves the private 
>key associated with the identity.  Without authentication of the identity, 
>who cares what attributes are associated with it?
>
>Russ

The more I read and think about the issues Polar has brought up the more I
am convinced that the very notion of attribute certificates is potentially
flawed, and the business case highly suspect.  They may have had some
validity back in the X.509 v1 time frame, before more general extensions
were allowed, but I am far from convinced that they are necessary, and may
not even be workable.

Let me begin with a few paragraphs from the draft RFC:

   First, authorization information often does not have the
   same lifetime as the binding of the identity and the public key.
   When authorization information is placed in a PKC extension, the
   general result is the shortening of the PKC useful lifetime. Second,
   the PKC issuer is not usually authoritative for the authorization
   information. This results in additional steps for the PKC issuer to
   obtain authorization information from the authoritative source.

   For these reasons, it is often better to separate authorization
   information from the PKC. Yet, authorization information also needs
   to be bound to an identity. An AC provides this binding; it is
   simply a digitally signed (or certified) identity and set of
   attributes.

Although it is certainly true that clearances or rights may not have the
same lifetime as an identity per se, in general those clearances or rights
are quite likely to last LONGER than any reasonable public key/certificate
validity period. An exception might be a short-lived right or capability,
similar to that granted by a Kerberos ticket, but in that case the right is
generally not tied directly to an identity per se, but is better conveyed by
demonstrating that the user possesses a private key that is tied to that
right via the public key.  In any case, certificates are cheap -- they're
just a bag of bits -- and such rights could more easily be conveyed by a
standard X.509 cert that does contain a public key.  

Secondly, I tend to disagree with the assertion that the PKC issuer is not
usually authoritative for the authorization information.  This assumes a
separation of function of identity confirmation vs. authorization which I
simply haven't seen demonstrated in practice, except arguably in some
European systems where the State is issuing high-grade identity certificates
to their citizens.

Within the US, at least, I would claim that 99.9% all of the identity
certificates that  have been issued were either created by or vouched for by
an organizational RA, or were issued by the organization itself. And
inevitably it is that organization that is authoritative for the
authorization information.  The exception to this might be e-mail address
certificates (the equivalent of the VeriSign class 1 certificates) which are
low due-diligence and arguably not identity certificates at all.  It seems
unlikely that such certs would ever be used to authenticate an attribute
cert.

Finally, I also disagree with the third assumption, i.e., that authorization
needs to be bound to an identity.  It often is, of course, but it need not
be, and there are plenty of examples such as extranet access control where
identity may be relevant to audit, but not to access control.  Knowing the
identity in advance might be a management impossibility -- it is just too
hard fro one organization to keep up with everything going on in another
organization, even if they wanted to.  All that is necessary is to know
whether the entity which controls a given private key has the authority to
perform certain functions.

In addition, in some cases it is highly desirable that authorization NOT be
tied to identity, or at least that the identity be anonymous. An example
might be a teen-aged girl that wants to log in to get the results of her
pregnancy test, but without revealing her name.  In that case a standard
X.509 certificate could be used that contained a security label attribute
and nothing more than a serial number, with no DN.

Because attribute certificates are presently tied to a distinguished NAME
that is presumably contained in an identity certificate, but not necessarily
to any particular public/private key or certificate, path validation up the
chain to two different CAs would seem to be a nightmare, and revocation
even worse.

Finally, even the authors of the attribute certificate draft didn't know how
to control a chain of authorization certificates, and in particular how to
control delegation of rights, and so they only allow a one-deep attribute
certificate chain.  They also don't seem to know how to control the
interpretation of the semantics of a particular security label.  So they
throw up their hands and invoke a deus ex machina type of solution, saying
that the relying parties have to "trust the attribute authority root."  This
is no solution at all.

In an offline note to me, Ed Reed recently made another cogent observation.
Whereas incorporating a security/clearance/rights label in an identity
certificate binds that label inextricably to the public key (and to the
identity, if that matters), the same is not true of an attribute
certificate.  

In particular, if the function of the security label is to DENY the
delegation of some particular capability or default to an entity, then all
that entity has to do is to conveniently "lose" the attribute certificate
and he is back in business.  This may not be obvious, but without negative
delegation I really have no way to definitive way to control what CAs I
trust to control what functions, except by the very ponderous mechanisms of
closed user groups and policy OID constraints. Yuch.

The current situation, with dozens or perhaps hundreds of "trusted" roots in
the various relying party software is a mess that is about to become a
disaster, because enterprises have no convenient way of controlling what
roots are really to be trusted, and for what.  I am increasingly convinced
that adding attribute certificates to this already fragile structure will
cause the entire house of cards to collapse.

We have already seen in the E-sign legislation that a number of opponents
(well-intentioned or not so well intentioned) have pushed for an won the
right to use "technology-neutral" alternatives to PKI.  If we continue to
add more and more complexity with less and less justification, as I believe
we are doing over and over again, I predict that we will see a
counter-revolution, and "press one to confirm nonrepudiation" will become
the norm.

In summary, I am afraid I have to object to advancing the proposed draft at
this time.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.

------_=_NextPart_001_01C0370F.599FDCE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Objections to advancing the attribute certificate =
authentication draft</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Bob - One of the main reasons for favouring a =
collection of attribute certificates over a collection of public-key =
certificates for asserting privilege is that one of the main costs =
associated with public-key certificates is that related to the =
management of the corresponding private key.&nbsp; The private key has =
to be secured for confidentiality and it has to be activated, =
rolled-over and revoked.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Bob Jueneman [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Friday, October 13, 2000 6:57 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; [email-masked]; =
&lt;Ed Reed</FONT>
<BR><FONT SIZE=3D2>Subject: Objections to advancing the attribute =
certificate</FONT>
<BR><FONT SIZE=3D2>authentication draft</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;PKCs bind a public key to an identity.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;ACs bind attributes to an identity.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Authentication, which includes validating the =
PKC certification path and </FONT>
<BR><FONT SIZE=3D2>&gt;having the remote party perform some operation =
that involves the private </FONT>
<BR><FONT SIZE=3D2>&gt;key associated with the identity.&nbsp; Without =
authentication of the identity, </FONT>
<BR><FONT SIZE=3D2>&gt;who cares what attributes are associated with =
it?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Russ</FONT>
</P>

<P><FONT SIZE=3D2>The more I read and think about the issues Polar has =
brought up the more I am convinced that the very notion of attribute =
certificates is potentially flawed, and the business case highly =
suspect.&nbsp; They may have had some validity back in the X.509 v1 =
time frame, before more general extensions were allowed, but I am far =
from convinced that they are necessary, and may not even be =
workable.</FONT></P>

<P><FONT SIZE=3D2>Let me begin with a few paragraphs from the draft =
RFC:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; First, authorization information often =
does not have the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; same lifetime as the binding of the =
identity and the public key.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; When authorization information is =
placed in a PKC extension, the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; general result is the shortening of the =
PKC useful lifetime. Second,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the PKC issuer is not usually =
authoritative for the authorization</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; information. This results in additional =
steps for the PKC issuer to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; obtain authorization information from =
the authoritative source.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; For these reasons, it is often better to =
separate authorization</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; information from the PKC. Yet, =
authorization information also needs</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; to be bound to an identity. An AC =
provides this binding; it is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; simply a digitally signed (or =
certified) identity and set of</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; attributes.</FONT>
</P>

<P><FONT SIZE=3D2>Although it is certainly true that clearances or =
rights may not have the same lifetime as an identity per se, in general =
those clearances or rights are quite likely to last LONGER than any =
reasonable public key/certificate validity period. An exception might =
be a short-lived right or capability, similar to that granted by a =
Kerberos ticket, but in that case the right is generally not tied direct=
ly to an identity per se, but is better conveyed by demonstrating that =
the user possesses a private key that is tied to that right via the =
public key.&nbsp; In any case, certificates are cheap -- they're just a =
bag of bits -- and such rights could more easily be conveyed by a =
standard X.509 cert that does contain a public key.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Secondly, I tend to disagree with the assertion that =
the PKC issuer is not usually authoritative for the authorization =
information.&nbsp; This assumes a separation of function of identity =
confirmation vs. authorization which I simply haven't seen demonstrated =
in practice, except arguably in some European systems where the State =
is issuing high-grade identity certificates to their =
citizens.</FONT></P>

<P><FONT SIZE=3D2>Within the US, at least, I would claim that 99.9% all =
of the identity certificates that&nbsp; have been issued were either =
created by or vouched for by an organizational RA, or were issued by =
the organization itself. And inevitably it is that organization that is =
authoritative for the authorization information.&nbsp; The exception to =
this might be e-mail address certificates (the equivalent of the =
VeriSign class 1 certificates) which are low due-diligence and arguably =
not identity certificates at all.&nbsp; It seems unlikely that such =
certs would ever be used to authenticate an attribute cert.</FONT></P>

<P><FONT SIZE=3D2>Finally, I also disagree with the third assumption, =
i.e., that authorization needs to be bound to an identity.&nbsp; It =
often is, of course, but it need not be, and there are plenty of =
examples such as extranet access control where identity may be relevant =
to audit, but not to access control.&nbsp; Knowing the identity in =
advance might be a management impossibility -- it is just too hard fro =
one organization to keep up with everything going on in another =
organization, even if they wanted to.&nbsp; All that is necessary is to =
know whether the entity which controls a given private key has the =
authority to perform certain functions.</FONT></P>

<P><FONT SIZE=3D2>In addition, in some cases it is highly desirable =
that authorization NOT be tied to identity, or at least that the =
identity be anonymous. An example might be a teen-aged girl that wants =
to log in to get the results of her pregnancy test, but without =
revealing her name.&nbsp; In that case a standard X.509 certificate =
could be used that contained a security label attribute and nothing =
more than a serial number, with no DN.</FONT></P>

<P><FONT SIZE=3D2>Because attribute certificates are presently tied to =
a distinguished NAME that is presumably contained in an identity =
certificate, but not necessarily to any particular public/private key =
or certificate, path validation up the chain to two different CAs would =
seem to be a nightmare, and revocation&nbsp; even worse.</FONT></P>

<P><FONT SIZE=3D2>Finally, even the authors of the attribute =
certificate draft didn't know how to control a chain of authorization =
certificates, and in particular how to control delegation of rights, =
and so they only allow a one-deep attribute certificate chain.&nbsp; =
They also don't seem to know how to control the interpretation of the =
semantics of a particular security label.&nbsp; So they throw up their =
hands and invoke a deus ex machina type of solution, saying that the =
relying parties have to &quot;trust the attribute authority =
root.&quot;&nbsp; This is no solution at all.</FONT></P>

<P><FONT SIZE=3D2>In an offline note to me, Ed Reed recently made =
another cogent observation.&nbsp; Whereas incorporating a =
security/clearance/rights label in an identity certificate binds that =
label inextricably to the public key (and to the identity, if that =
matters), the same is not true of an attribute certificate.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>In particular, if the function of the security label =
is to DENY the delegation of some particular capability or default to =
an entity, then all that entity has to do is to conveniently =
&quot;lose&quot; the attribute certificate and he is back in =
business.&nbsp; This may not be obvious, but without negative =
delegation I really have no way to definitive way to control what CAs I =
trust to control what functions, except by the very ponderous =
mechanisms of closed user groups and policy OID constraints. =
Yuch.</FONT></P>

<P><FONT SIZE=3D2>The current situation, with dozens or perhaps =
hundreds of &quot;trusted&quot; roots in the various relying party =
software is a mess that is about to become a disaster, because =
enterprises have no convenient way of controlling what roots are really =
to be trusted, and for what.&nbsp; I am increasingly convinced that =
adding attribute certificates to this already fragile structure will =
cause the entire house of cards to collapse.</FONT></P>

<P><FONT SIZE=3D2>We have already seen in the E-sign legislation that a =
number of opponents (well-intentioned or not so well intentioned) have =
pushed for an won the right to use &quot;technology-neutral&quot; =
alternatives to PKI.&nbsp; If we continue to add more and more =
complexity with less and less justification, as I believe we are doing =
over and over again, I predict that we will see a counter-revolution, =
and &quot;press one to confirm nonrepudiation&quot; will become the =
norm.</FONT></P>

<P><FONT SIZE=3D2>In summary, I am afraid I have to object to advancing =
the proposed draft at this time.</FONT>
</P>

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

<P><FONT SIZE=3D2>Bob</FONT>
</P>

<P><FONT SIZE=3D2>Robert R. Jueneman</FONT>
<BR><FONT SIZE=3D2>Security Architect</FONT>
<BR><FONT SIZE=3D2>Novell, Inc. -- the leading provider of Net services =
software.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0370F.599FDCE0--

From: Michael Zolotarev <[email-masked]>
To: Michael Myers <[email-masked]>, Michael Zolotarev <[email-masked]>, "'Frank Balluffi'" <[email-masked]>, [email-masked]
Subject: RE: Delegated Path Validation draft.
Date: Mon, 16 Oct 2000 10:24:09 +1000

On the same tune: 

I expect that receiving 'No' answer will be rather an exception than a
common case of using DVP. If you keep receiving 'No's, it most likely
indicates that either your trust/policy settings are wrong, or you are under
attack. Significance of it is that each 'No' case will require human
intervention, at least at the initial stage of system's operations. With the
amount of data required to perform adequate 'why No' analysis being larger
than a single response message can reasonably communicate.

However, once the system went through the initial tuning up stage, and the
client has acquaired reasonable trust into quality of decisions by  the DPV
server, receiving 'No' answer should be just 'flagged' by the client, but
not investigated.

In short, communicating 'Why No' data to the client is rather a 'roll-out
stage trace/debug' feature, then normal operation mode feature. Therefore
making it a part of the core(!) protocol is not very justified, to me.

However, every DPV vendor may of course decide on a special way of ensuring
that the clients have access to the DPV decision making context. As a
minimum, I'd expect a server to make its verification procedure logic
publically known and auditable.

Frank - I'm still standing on attention to hear why do you think a client
may want to know 'why Yes'. No jokes. That'd be one of the major requirement
for audit performed on DPV, if there is for example a legal reason, or
something...

Michael

> From: Michael Myers [mailto:[email-masked]]
> Sent: Saturday, 14 October 2000 7:50
> To: Michael Zolotarev; 'Frank Balluffi'; Michael Myers;
> [email-masked]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> 
> I generally agree.  I'm doing all I can to advocate for a 
> principle that
> "simpler is better until compelling proven otherwise." 
> However, it was a
> criticism of 2560 that there exists more easily predictable 
> error status
> values than 2560 currently recognizes.  I propose that we 
> take a look at
> that, building on Frank's suggestions and perhaps those of 
> others, but that
> we do not create a sub-protocol for error cause discovery.
> 
> Mike
> 
> > From: Michael Zolotarev [mailto:[email-masked]]
> > Sent: Friday, October 13, 2000 8:19 AM
> > To: 'Frank Balluffi'; Michael Zolotarev; Michael Myers;
> > [email-masked]
> > Subject: RE: Delegated Path Validation draft.
> > 
> > 
> > Frank,
> > 
> > please, do not go this way. Keep it simple. 
> > Realistically speaking, a client only needs a simple 'yes' or 
> > 'now'. The
> > whole purpose of defining a TTP for path validation was to 
> > simplify things.
> > 
> > If a client is not satisfied by the 'yes' or 'now', there are 
> > other options
> > (other then been shot, of course). Mind you I fail undestand 
> > why a client
> > would ever ask 'why yes?' - would like to hear from you on this one,
> > frankly. 
> > 
> > To find out why 'No', a client can use DPD to get the path, 
> > and then ask DPV
> > for each component in the path.
> > 
> > Otherwise we'll end up with a hugely blown-up service, which 
> > wasn't the
> > purpose of the exercise.
> > 
> > M
> 

Date: Sun, 15 Oct 2000 17:52:17 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Bob Jueneman <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], "<Ed Reed" <[email-masked]>
Subject: Re: Objections to advancing the attribute certificateauthentication  draft

Bob,

I don't think your objection should be entertained for the following
reasons:

Profiling of ACs is in the PKIX charter. This document has been discussed
on the PKIX list for more than 18 months now. You have not objected to
it before, though you have discussed it before on the list. Your mail
contains no specific technical issues with the document but rather just
some indication of your "feelings" towards it (phrases like: "I tend to 
disagree...",  "It seems unlikely that..." etc.)

The only point where you directly quote the draft is the discussion
on the "lifetime" of attributes in PKCs and ACs. This was discussed
at length on the PKIX list a long time back (not sure if you were
part of that or not?), but in any case it did get WG discussion.
The consensus was against the position you express in your mail.

And lastly:

> Finally, even the authors of the attribute certificate draft didn't know 
> how to control a chain of authorization certificates, and in particular 
> how to control delegation of rights, and so they only allow a one-deep 
> attribute certificate chain.  

I quote this directly since I'd love to know how you know what I know 
and what I don't know. In fact, the main reason for omitting AC chains 
is relative simplicity. I do have some doubts that the X.509(2000) model 
for delegation can be made to work well, but that is quite different 
from not knowing "how to control a chain". 

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: Sun, 15 Oct 2000 17:31:15 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Carlisle Adams <[email-masked]>
CC: "'Polar Humenn'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Carlisle,

You're overstating the requirements for an AC to be valid. There is 
no need for the AA and holder to belong to the "same" PKI - the only 
requirement, in general, is that the RP be able to valiate the AA's PKC 
and the holder's PKC and that the AC contents be consistent with those 
two PKCs. That's what X.509(2000) says (ignoring "hints" whose significance 
we'll never know:-) and also what the PKIX AC profile says. If there is
text somewhere clearly to the contrary please point it out.

Of course, if anyone chooses to implement their RP s/w in the way you've
described then that's just fine, but irrelevant for AC profile.

Stephen.

> Carlisle Adams wrote:
>      Sent:   Friday, October 13, 2000 1:14 PM
>      To:     Carlisle Adams
>      Cc:     Stephen Farrell; [email-masked]; [email-masked]; [email-masked]; [email-masked];
>      Stephen McConnell; Kent Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai
>      Chin
> 
>      Carlisle,
>      Thank you for your very learned and well formed response.
> 
>      You do draw an important conclusion that the AA and the Holder must belong
>      to the same "well-behaved" PKI in order for this scheme to work correctly.
>      (I wonder how many PKI's are actually really well-behaved? :).
> 
> 
> Good question.  On the other hand, why would anyone expect to get security from a system that was
> not "well-behaved"?  If security is important to you, the onus is on you to choose (buy,
> implement, deploy, whatever) your PKI carefully...
> 
>      In any case, I do not see anywhere in the ac509 profile that specifies
>      that AA must belong to the same PKI (under the same rootCA?) as the
>      Holder's it authorizes? Can you point me to some text stating this
>      requirement, or some text that somehow implies this requirement?
> 
> 
> Ed Barkmeyer also asked for this.  I haven't had a chance to skim quickly through the profile
> document, so I can't comment on that one at the moment, but this implication is definitely there
> in X.509 (2000).  As one example, all through the sections on attribute certificates it talks
> about "the" PKI, so it seems that the AC-based PMI is to be tied to only a single PKI.  Slightly
> more explicitly, however, Clause 16.1 ("Basic processing procedure"), begins as follows:
> 
>      "The signature on every certificate in the path must be verified. Procedures related to
>      validating signatures and public-key certificates are not repeated in this clause. The
>      privilege verifier must verify the identity of every entity in the path, using the procedures
>      of clause 10. Note that checking the signature on an attribute certificate necessarily
>      involves checking the referenced public-key certificate for its validity. Where privileges
>      are assigned using attribute certificates, path processing engines will need to consider
>      elements of both the PMI and the PKI in the course of determining the ultimate validity of a
>      privilege asserter's attribute certificate."
> 
> ACs and PKCs are talked about "in the same breath" with respect to validity checking and identity
> verification.  The referenced Clause 10 ("Certification path processing procedure") lists the
> inputs to the procedure in Section 10.1.  One of the inputs is "a trusted public key value or key
> identifier (if the key is stored internally to the certification path processing module), for use
> in verifying the first certificate in the certification path".  This strongly implies to me that
> there is a single trusted root key that forms the starting point for all the path processing
> (which includes the AC path as well as the PKC path).
> 
>      I also see this requirement to be a crippling constraint.
> 
>      The requirement for the AA and the Holder's it certificate to belong to the
>      same PKI means that I will be able to authorize certain subject entities
>      from HisCarCompany to have access to resources in MyCarCompany, unless I
>      do one of the following:
> 
>      1. Create a new identity at MyCarCompany for subject entity X in
>         HisCarCompany.
>           This is undesirable for many reasons. For example,
>           if Person X from HisCarCompany gets fired. Also, it to generate
>           new keys, new certificates, new names, new password, new
>           token card, etc. Now, causes a single-sign-on scenario.
> 
>      2. Create an entirely new PKI for the interested parties and an AA.
>           Out of the question for most. It's Way too much work with new keys,
>           new names, new passwords, new tokens cards, etc.
> 
> 
> This is not a crippling constraint because neither of the above undesirable actions need to be
> taken.  If these two companies want to work together, they need to issue cross-certificates
> between their root CAs anyway so that authentication can take place.  Cross-certification ties
> these previously-independent PKIs together, so that there is only a single PKI.  Appropriate name
> constraints in the cross-certificates ensure that identity clashes will be ruled out of the
> picture, and authorization based upon attribute certificates can proceed securely.
> 
>      It would be nice if PKI and AA combined could solve the single-sign-on
>      problem.
> 
> 
> If the companies follow what is outlined above, single sign-on is preserved.
> 
>      Of course, this problem would go away, if there is only one RootCA for all
>      organzations, and therefore on PKI. For example, HisCarCompany, and
>      MyCarCompany must get our CA certificates signed by the Verisign RootCA.
>      And we and everybody that Verisign signs, must be well behaved, and the DN
>      space is consequently unique.
> 
> 
> I'm sure you can imagine that Entrust and Baltimore and many other PKI providers would not be
> content with the scenario you paint...  :-)
> 
> But seriously, people recognized a long time ago that a single root for the whole world will not
> work.  This is why cross-certification was invented -- so that independently-deployed PKIs can be
> joined to form a single, workable PKI.  This is why the term "PKI networking" is sometimes used
> instead of "cross-certification" (it seems slightly more descriptive).
> 
>      Is this approach realistic and practical?
> 
> 
> What I described above, I believe, has the qualities of both realism and practicality.
> Cross-certification is what allows you to grow your PKI to include other environments, but in a
> very controlled and reasoned manner.  Attribute certificates take the power of this secure, yet
> flexible, authentication technology and overlays the power of secure, yet flexible,
> authorization.  It's a very strong combination!
> 
> Carlisle.

-- 
____________________________________________________________
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: Fri, 13 Oct 2000 17:10:59 -0700
From: Ed Gerck <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Objections to advancing the attribute certificateauthentication  draft

IMO, attribute certificates as defined in the draft can be seen as a �patch� type
of solution that may introduce a series of inconsistencies (e.g., revocation
lists for either type of certificate, cross dependencies, etc.) that will only
highlight the broken model of trust being used.

On the other hand, attribute certificates with more attributes will tend to
have a shorter lifetime than attribute certificates with a lesser number of
attributes. The formula I calculated under very general assumptions which
I believe hold for the majority of cases is that the lifetime of the certificate
is inversely proportional to the sum of the inverse of each independent
attribute's lifetime (see PKIX archives, 99).

This means that it is indeed advantageous to divide information in attribute
certificates so that expiration of one short-lived attribute will not invalidate
an entire certificate with otherwise long-lived data. The analogy (due to Tony
Bartoletti at the time) is a box with dynamite sticks where upon the explosion
of one stick the entire box explodes � which sets a limit for the number of dynamite
sticks that one can safely store in one place. Placing too many attributes in one
certificate is generally not a good idea and this may be the only justification I
would find for PKIX to advance the draft, in spite of my first comment above.

Cheers,

Ed Gerck

Date: Fri, 13 Oct 2000 16:56:33 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "<Ed Reed" <[email-masked]>
Subject: Objections to advancing the attribute certificate authentication draft

>
>PKCs bind a public key to an identity.
>
>ACs bind attributes to an identity.
>
>Authentication, which includes validating the PKC certification path and 
>having the remote party perform some operation that involves the private 
>key associated with the identity.  Without authentication of the identity, 
>who cares what attributes are associated with it?
>
>Russ

The more I read and think about the issues Polar has brought up the more I am convinced that the very notion of attribute certificates is potentially flawed, and the business case highly suspect.  They may have had some validity back in the X.509 v1 time frame, before more general extensions were allowed, but I am far from convinced that they are necessary, and may not even be workable.

Let me begin with a few paragraphs from the draft RFC:

   First, authorization information often does not have the
   same lifetime as the binding of the identity and the public key.
   When authorization information is placed in a PKC extension, the
   general result is the shortening of the PKC useful lifetime. Second,
   the PKC issuer is not usually authoritative for the authorization
   information. This results in additional steps for the PKC issuer to
   obtain authorization information from the authoritative source.

   For these reasons, it is often better to separate authorization
   information from the PKC. Yet, authorization information also needs
   to be bound to an identity. An AC provides this binding; it is
   simply a digitally signed (or certified) identity and set of
   attributes.

Although it is certainly true that clearances or rights may not have the same lifetime as an identity per se, in general those clearances or rights are quite likely to last LONGER than any reasonable public key/certificate validity period. An exception might be a short-lived right or capability, similar to that granted by a Kerberos ticket, but in that case the right is generally not tied directly to an identity per se, but is better conveyed by demonstrating that the user possesses a private key that is tied to that right via the public key.  In any case, certificates are cheap -- they're just a bag of bits -- and such rights could more easily be conveyed by a standard X.509 cert that does contain a public key.  

Secondly, I tend to disagree with the assertion that the PKC issuer is not usually authoritative for the authorization information.  This assumes a separation of function of identity confirmation vs. authorization which I simply haven't seen demonstrated in practice, except arguably in some European systems where the State is issuing high-grade identity certificates to their citizens.

Within the US, at least, I would claim that 99.9% all of the identity certificates that  have been issued were either created by or vouched for by an organizational RA, or were issued by the organization itself. And inevitably it is that organization that is authoritative for the authorization information.  The exception to this might be e-mail address certificates (the equivalent of the VeriSign class 1 certificates) which are low due-diligence and arguably not identity certificates at all.  It seems unlikely that such certs would ever be used to authenticate an attribute cert.

Finally, I also disagree with the third assumption, i.e., that authorization needs to be bound to an identity.  It often is, of course, but it need not be, and there are plenty of examples such as extranet access control where identity may be relevant to audit, but not to access control.  Knowing the identity in advance might be a management impossibility -- it is just too hard fro one organization to keep up with everything going on in another organization, even if they wanted to.  All that is necessary is to know whether the entity which controls a given private key has the authority to perform certain functions.

In addition, in some cases it is highly desirable that authorization NOT be tied to identity, or at least that the identity be anonymous. An example might be a teen-aged girl that wants to log in to get the results of her pregnancy test, but without revealing her name.  In that case a standard X.509 certificate could be used that contained a security label attribute and nothing more than a serial number, with no DN.

Because attribute certificates are presently tied to a distinguished NAME that is presumably contained in an identity certificate, but not necessarily to any particular public/private key or certificate, path validation up the chain to two different CAs would seem to be a nightmare, and revocation  even worse.

Finally, even the authors of the attribute certificate draft didn't know how to control a chain of authorization certificates, and in particular how to control delegation of rights, and so they only allow a one-deep attribute certificate chain.  They also don't seem to know how to control the interpretation of the semantics of a particular security label.  So they throw up their hands and invoke a deus ex machina type of solution, saying that the relying parties have to "trust the attribute authority root."  This is no solution at all.

In an offline note to me, Ed Reed recently made another cogent observation.  Whereas incorporating a security/clearance/rights label in an identity certificate binds that label inextricably to the public key (and to the identity, if that matters), the same is not true of an attribute certificate.  

In particular, if the function of the security label is to DENY the delegation of some particular capability or default to an entity, then all that entity has to do is to conveniently "lose" the attribute certificate and he is back in business.  This may not be obvious, but without negative delegation I really have no way to definitive way to control what CAs I trust to control what functions, except by the very ponderous mechanisms of closed user groups and policy OID constraints. Yuch.

The current situation, with dozens or perhaps hundreds of "trusted" roots in the various relying party software is a mess that is about to become a disaster, because enterprises have no convenient way of controlling what roots are really to be trusted, and for what.  I am increasingly convinced that adding attribute certificates to this already fragile structure will cause the entire house of cards to collapse.

We have already seen in the E-sign legislation that a number of opponents (well-intentioned or not so well intentioned) have pushed for an won the right to use "technology-neutral" alternatives to PKI.  If we continue to add more and more complexity with less and less justification, as I believe we are doing over and over again, I predict that we will see a counter-revolution, and "press one to confirm nonrepudiation" will become the norm.

In summary, I am afraid I have to object to advancing the proposed draft at this time.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.

Date: Fri, 13 Oct 2000 17:54:49 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Carlisle Adams <[email-masked]>
cc: Stephen Farrell <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

Hi Carlise,

On Fri, 13 Oct 2000, Carlisle Adams wrote:

> Good question.  On the other hand, why would anyone expect to get security
> from a system that was not "well-behaved"?  If security is important to you,
> the onus is on you to choose (buy, implement, deploy, whatever) your PKI
> carefully...

I don't want a closed world. I want to interoperate. This leads me to
the next point you bring up, which is about cross certification. Sorry I
snipped all the text to make this note somewhat shorter.

You say that there WILL be name constraints on CAs and they will be placed
on the cross certificates.

So, that means that the CA's when they cross certify each other have to
make sure that their name constraints (if they have any at all) are
consistent with each other.

Without doing all the set theoretic mathematics, this tells me, that if
naming constraints exist, the permitted subtrees MUST be distinct to
comprise a unique DN space for the two of them together. Otherwise, name
collisions may already exist.

I cannot figure out if the permitted subtree specification only describes
one hop from each CA certificate, or for all certificates underneath.

There is no mandate in RFC2459, that the permitted subtrees and excluded
subtrees from that CA relate to the CA's certificate DN in any way. In
fact, its explicitly called out that constraint DOES NOT exist, referring
in contrast to the PEM stringent CA and DN hierarchy.

Page 12:

      (b)  Name constraints may be imposed through explicit inclusion of
      a name constraints extension in a certificate, but are not
      required.

Therefore, while cross certifying a CA, I must chase down all the CA's and
their permitted and excluded subtrees, in general. Also, I must check the
other CA as well to make sure, which is information I don't think I have
access to.

The only place I have seen anything that looks like it will work in this
regard is in the PEM specification RFC1422, where there is a ridged
subordinate subject DN creation scheme for CAs. That is, a CA named "C=US,
O=Adiron" must generate subject DN's with "C=US, O=Adiron" in them, i.e.
"C=US, O=Adiron, OU=Research", etc. (I don't know how unwieldy that can
get at, for example, 5 or six levels of CAs deep). There is supposed to be
an Email based registry, IPRA, to make sure that the PEM root certificates
contain distinct DN's.

That document makes special dispensation for cross-certificates, or
certificates out of the application of PEM. I haven't really thought about
that.

There is a obvious reason these stringent requirements exist for the PEM
application of PKI. It is that you need unique names over this application
space because applications other than X.509 certificates reference DNs for
their purposes, i.e. other than for validation.

And, that is the case with the AA. It references DNs. They really need to
be unique, but it seems that they are not guaranteed to be.

So, why isn't there a ridged structure placed on X.509 RootCA's that the
subject names should be subordinate to the issuer DN's? There is a
definition of superior and subordinate DNs, all roots have distinct DNs,
and then make special dispensation for Cross Certificates?

Also, when RFC2459 states in the Path Validation algorithm with respect to 
the constrained subtrees state variable:

      (b)  constrained subtrees:  A set of root names defining a set of
      subtrees within which all subject names in subsequent certificates
      in the certification path shall fall. The initial value is
      "unbounded".

And processing each CA certificate:

      (j)  If permittedSubtrees is present in the certificate, set the
      constrained subtrees state variable to the intersection of its
      previous value and the value indicated in the extension field.

What does the "intersection" mean? It is not explicitly defined.

Does it mean, just the intersection of the root names named in the
constrained subtrees by explicit equality? Or does it more involved? Say
for each TYPE (DN, DNS, email, etc)  of each name in the constrained
subtress, N, if N is "superior" to at least one P of the same TYPE in the
permitted Subtrees, then replace N with P in constrained subtrees,
otherwise drop N from the constrained subtrees. If this is the case, I
would imagine then also, that an absence of a name with the same type as N
would also constitue dropping N.

If this is the case, then name constraints on the CAs would do it, and
before two companies wanted to cross certify each other their Namespaces
would have to be distinct. However, I don't think that is the case. Is it?

Cheers,
-Polar

From: Michael Myers <[email-masked]>
To: Michael Zolotarev <[email-masked]>, "'Frank Balluffi'" <[email-masked]>, Michael Myers <[email-masked]>, [email-masked]
Subject: RE: Delegated Path Validation draft.
Date: Fri, 13 Oct 2000 14:50:04 -0700

I generally agree.  I'm doing all I can to advocate for a principle that
"simpler is better until compelling proven otherwise." However, it was a
criticism of 2560 that there exists more easily predictable error status
values than 2560 currently recognizes.  I propose that we take a look at
that, building on Frank's suggestions and perhaps those of others, but that
we do not create a sub-protocol for error cause discovery.

Mike

> From: Michael Zolotarev [mailto:[email-masked]]
> Sent: Friday, October 13, 2000 8:19 AM
> To: 'Frank Balluffi'; Michael Zolotarev; Michael Myers;
> [email-masked]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> Frank,
> 
> please, do not go this way. Keep it simple. 
> Realistically speaking, a client only needs a simple 'yes' or 
> 'now'. The
> whole purpose of defining a TTP for path validation was to 
> simplify things.
> 
> If a client is not satisfied by the 'yes' or 'now', there are 
> other options
> (other then been shot, of course). Mind you I fail undestand 
> why a client
> would ever ask 'why yes?' - would like to hear from you on this one,
> frankly. 
> 
> To find out why 'No', a client can use DPD to get the path, 
> and then ask DPV
> for each component in the path.
> 
> Otherwise we'll end up with a hugely blown-up service, which 
> wasn't the
> purpose of the exercise.
> 
> M

Date: Fri, 13 Oct 2000 16:09:14 -0400
From: John Marsh <[email-masked]>
Organization: Concept Five Technologies, Inc.
To: Polar Humenn <[email-masked]>
CC: Carlisle Adams <[email-masked]>, Stephen Farrell <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

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

Polar -
A modification to your suggestion of "one" -

I'd suggest world that looks more like the financial services world.  In the
financial services world, there's differentiation in what one has to do to get
varying levels of services and varying levels of universal acceptance.

Other than cash (which looks like no authentication unless the transaction gets very
high value), there's a couple levels of authentication & associated authorizations -

There's near universal acceptance of "certificates" from a very small number of
trusted "standard roots" - VISA, Discover, Mastercard, Diners, American Express.
Merchants handle cards from some subset of these (in the US - VISA & MC always, some
greater differentiation with AMEX & Discover, & Diners is much less accepted, but
exists essentially to be used by corporations to keep their employees from spending
money on anything that's not travel related.  In travel, it's fairly well
accepted.). There is some variation in both services to the card holder and
merchants, but as long as one of the "standard" cards is presented it's sufficient
up to the holder's credit limits.    Note that at this level, there are no
cross-certifications - there are individual "authorizations" but against universally
accepted certificates.

In addition, some merchants also offer their own "certificates" to the general
public - cards -  that are good at their place of business for special privileges
but are not intended for use at any other location (though they are some times
accepted for other purposes at other locations - e.g. Safeway stealing customers
from A&P by giving a discount to A&P card presenters).  Users aren't willing to hold
too many of these, but if it's a service that is highly valued to them, they will
allow them to show up in their wallet.

In the above cases, the level of potential damage on both sides for significant
breach is fairly low given the comparatively low dollar financial transactions
occuring.  At the same time, there's a relatively low level of authentication
evidence presented prior to receiving the card & there is typically a large number
of holders of the "certificate" type.

However, for very high valued services or internal users or representations for
purchase authority at other organizations - say for large purchases, purchases
dependent on acceptance, ... other arrangements end up getting created that may have
higher associated transaction costs, different levels of certification required,
stronger revocation list support, etc. It is also at this level that Carlisle's
cross-certifications really occur.

So the likely long term arrangements look like:

1)  No authentication required.
2)  Some small (always prime (-:) number of nearly univerally accepted root CAs
where no cross-certifications occur but where the acceptance risks are low.
3)  <this level may not exist in the long run> merchant's "own" CAs intended for the
general public.
4)  Specialized roots for much higher level of authentication when the transaction
involved is high risk and where cross-certifications may occur.

John

Polar Humenn wrote:

> My apologies,
>
> I missed stating a negative in a paragraph below.  Sorry!
>
> -Polar
>
> On Fri, 13 Oct 2000, Polar Humenn wrote:
>
> >
> > Carlisle,
> >
> > Thank you for your very learned and well formed response.
> >
> > You do draw an important conclusion that the AA and the Holder must belong
> > to the same "well-behaved" PKI in order for this scheme to work correctly.
> > (I wonder how many PKI's are actually really well-behaved? :).
> >
> > In any case, I do not see anywhere in the ac509 profile that specifies
> > that AA must belong to the same PKI (under the same rootCA?) as the
> > Holder's it authorizes? Can you point me to some text stating this
> > requirement, or some text that somehow implies this requirement?
> >
> > I also see this requirement to be a crippling constraint.
> >
> > The requirement for the AA and the Holder's it certificate to belong to the
> > same PKI means that I will be able to authorize certain subject entities
> > from HisCarCompany to have access to resources in MyCarCompany, unless I
> > do one of the following:
> ^^^^^^^^^^^^^^^^^^^^^^^^Scratch that  paragraph!^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> The requirement that the AA and the Holders it certifies must belong to
> the same PKI means that I will NOT be able to authorize certain subject
> entities from HisCarCompany to have access to resources in MyCarCompany,
> unless I do one of the following:
>
> > 1. Create a new identity at MyCarCompany for subject entity X in
> >    HisCarCompany.
> >      This is undesirable for many reasons. For example,
> >      if Person X from HisCarCompany gets fired. Also, it to generate
> >      new keys, new certificates, new names, new password, new
> >      token card, etc. Now, causes a single-sign-on scenario.
> >
> > 2. Create an entirely new PKI for the interested parties and an AA.
> >      Out of the question for most. It's Way too much work with new keys,
> >      new names, new passwords, new tokens cards, etc.
> >
> > It would be nice if PKI and AA combined could solve the single-sign-on
> > problem.
> >
> > Of course, this problem would go away, if there is only one RootCA for all
> > organizations, and therefore on PKI. For example, HisCarCompany, and
> > MyCarCompany must get our CA certificates signed by the Verisign RootCA.
> > And we and everybody that Verisign signs, must be well behaved, and the DN
> > space is consequently unique.
> >
> > Is this approach realistic and practical?
> >
> > Cheers,
> > -Polar
> >
> > On Fri, 13 Oct 2000, Carlisle Adams wrote:
> >
> > > Hi Polar,
> > >
> > > I think that as this thread has progressed we've all come to a better
> > > understanding of what you perceive the problem to be.  However, I suspect
> > > you may be missing an important foundational premise which so many of us
> > > take for granted that it may not be stated explicitly in the various
> > > standards documents.
> > >
> > > In PKI, a number of security implications rest upon the underlying trust
> > > model.  If I have a particular root CA (i.e., I received it's public-key
> > > out-of-band in a secure fashion, etc. -- all the usual conditions), then
> > > that root CA defines for me a PKI.  That is, it is the starting (or ending)
> > > point in my certificate path validation processing; any path that does not
> > > validly end up at this root is rejected by my software.  Therefore, this
> > > root CA defines for me a universe of PKI entities.  Such entities are
> > > identified in some way, perhaps by DN in the subject field, or by some other
> > > value(s) in subjectAltNames field, or by a combination of the two fields.
> > >
> > > Now if, for some reason (my deliberate choice, or as a result of the browser
> > > I downloaded, or whatever) I happen to have a second root CA, then this root
> > > CA defines for me a second PKI, another universe of entities.  Is it
> > > possible that a given entity could have an identity in each of these
> > > universes?  Of course.  But my path validation software will trace a path
> > > down to one root or the other, depending on which certificate it began with.
> > > Is it possible that two different entities could have (accidentally or
> > > maliciously) the same identity in each of these universes?  Again, of
> > > course.  But, again, my path validation software will trace a path down to
> > > one root or the other, depending on which certificate it began with.  The
> > > point is that these two universes of PKI entities are always distinguishable
> > > because they trace to one root or the other.  (Extend this to any number of
> > > roots with corresponding universes and this remains true.)
> > >
> > > Now, what about authorization via attribute certificates, which is where
> > > this thread began?  The AC may be bound to a PKI entity only through
> > > identity (DN, or issuer/serial), but this "identity" may appear in several
> > > different PKIs.  Your question is, "how can the AC verifier know which PKI
> > > was intended unless the AC issuer includes in the AC the full path of DNs
> > > (identities) all the way to the root?"  The answer is that this new
> > > extension is not at all necessary because this AC issuer (i.e., this AA)
> > > itself has an identity, and *its* issuer has an identity, all the way up to
> > > the SOA, which also has an identity.  All these identities must belong to
> > > the same universe, from the perspective of the relying party (the verifier),
> > > otherwise the AC is rejected.
> > >
> > > X.509 (2000) is fairly clear about the idea that AAs do not create
> > > identities; they rely upon the PKI to do this function and then simply point
> > > to those identities in the ACs they issue (see, for example, Section 13).
> > > Therefore, the AA must not simply have an awareness of the identities it can
> > > point to; it must itself be able to verify these identities in order to
> > > assign privileges to them.  In other words, the AA and the proposed AC
> > > holder MUST BELONG TO THE SAME PKI.  This relationship must necessarily hold
> > > recursively all the way up the chain to the SOA and the first AA in the
> > > path.  Logically, this makes sense as well:  why would it be reasonable for
> > > an AA in one universe to be able to assign privileges to some entity in an
> > > arbitrary, different universe?  No, all entities involved must be part of
> > > the same PKI because the AA is only making use of the identities defined in
> > > the PKI of which it is a part and from which it has its own identity.
> > >
> > > The extension you propose would not hurt, but would not help either.  It
> > > would be a fairly sizable piece of extraneous, unnecessary information
> > > carried in each and every attribute certificate.
> > >
> > > Carlisle.
> > >
> > > P.S., It seems to me that thinking about this one-to-one mapping between
> > > root CAs and PKIs alleviates all the name clashing concerns.  Yes there can
> > > be name (identity) clashes between universes of entities, but this doesn't
> > > matter:  any certificate can be resolved to one and only one universe by
> > > following its path of signatures to the root.  Furthermore, it is easy to
> > > ensure that identity clashes will not be a concern within a single PKI:
> > > this is why name constraints were invented.  A root CA that does its job
> > > correctly will put name constraints in the certificates it issues to its
> > > subordinate CAs, and will put name constraints in the cross-certificates it
> > > issues to other CAs.  Any of these CAs can, of course, ignore these
> > > constraints and (again, accidentally or maliciously) create name clashes,
> > > but such certificates will not validate in proper path validation software
> > > and so are of no consequence.  Any environment for which secure
> > > authentication and authorization is important will use a root CA that
> > > imposes proper name constraints in order to eliminate the possibility of
> > > identity clashes within that PKI.  Clashes with entities in another PKI will
> > > not lead to faulty authentication or authorization decisions because all
> > > certificates being validated for a single purported entity must exist within
> > > the same universe.
> > >
> > > P.P.S., Stephen asked that we trim the Cc: list back to PKIX, and I agree
> > > that we should probably do this.  However, I kept all the copied lists and
> > > people on this response because I don't know how many of you currently
> > > subscribe to PKIX and I felt it was important to address the concern being
> > > raised so widely that name clashing was somehow a serious security problem
> > > for attribute certificates and for PKI more generally.  This is not the
> > > case, as I hope I have shown above.
> > >
> > >
> >

--------------5DDD41D0EFE0702ACF2773E0
Content-Type: text/x-vcard; charset=us-ascii;
 name="jmarsh.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Marsh
Content-Disposition: attachment;
 filename="jmarsh.vcf"

begin:vcard 
n:Marsh;John
tel;cell:(703)371-8470
tel;fax:(703)639-2605
tel;work:(703)639-2451
x-mozilla-html:FALSE
url:www.concept5.com
org:Concept Five Technologies, Inc;Financial Services
version:2.1
email;internet:[email-masked]
title:Architect
adr;quoted-printable:;;1595 Spring Hill Rd, Suite 600=0D=0A;Vienna;VA;22182;USA
fn:John Marsh
end:vcard

--------------5DDD41D0EFE0702ACF2773E0--

Date: Fri, 13 Oct 2000 15:37:12 -0400
From: Sean Turner <[email-masked]>
Organization: IECA, Inc.
To: Carlisle Adams <[email-masked]>
CC: "'Polar Humenn'" <[email-masked]>, Stephen Farrell <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Carlisle,

This should probably go in the roadmap too.

spt

Carlisle Adams wrote:

>      Sent:   Friday, October 13, 2000 1:14 PM
>      To:     Carlisle Adams
>      Cc:     Stephen Farrell; [email-masked]; [email-masked];
>      [email-masked]; [email-masked]; Stephen McConnell; Kent Salmond;
>      Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
>
>      Carlisle,
>      Thank you for your very learned and well formed response.
>
>      You do draw an important conclusion that the AA and the Holder
>      must belong
>      to the same "well-behaved" PKI in order for this scheme to work
>      correctly.
>      (I wonder how many PKI's are actually really well-behaved? :).
>
>
> Good question.  On the other hand, why would anyone expect to get
> security from a system that was not "well-behaved"?  If security is
> important to you, the onus is on you to choose (buy, implement,
> deploy, whatever) your PKI carefully...
>
>      In any case, I do not see anywhere in the ac509 profile that
>      specifies
>      that AA must belong to the same PKI (under the same rootCA?) as
>      the
>      Holder's it authorizes? Can you point me to some text stating
>      this
>      requirement, or some text that somehow implies this requirement?
>

From: Carlisle Adams <[email-masked]>
To: "'Polar Humenn'" <[email-masked]>
Cc: Stephen Farrell <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 13 Oct 2000 15:17:29 -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_01C0354A.3AA5A480
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Polar,

> Sent: 	Friday, October 13, 2000 1:14 PM
> To: 	Carlisle Adams
> Cc: 	Stephen Farrell; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Stephen McConnell; Kent Salmond; Ken Mccoy;
> Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
> Carlisle,
> Thank you for your very learned and well formed response.
> 
> You do draw an important conclusion that the AA and the Holder must belong
> to the same "well-behaved" PKI in order for this scheme to work correctly.
> (I wonder how many PKI's are actually really well-behaved? :). 
 
Good question.  On the other hand, why would anyone expect to get security
from a system that was not "well-behaved"?  If security is important to you,
the onus is on you to choose (buy, implement, deploy, whatever) your PKI
carefully...

> In any case, I do not see anywhere in the ac509 profile that specifies
> that AA must belong to the same PKI (under the same rootCA?) as the
> Holder's it authorizes? Can you point me to some text stating this
> requirement, or some text that somehow implies this requirement?
 
Ed Barkmeyer also asked for this.  I haven't had a chance to skim quickly
through the profile document, so I can't comment on that one at the moment,
but this implication is definitely there in X.509 (2000).  As one example,
all through the sections on attribute certificates it talks about "the" PKI,
so it seems that the AC-based PMI is to be tied to only a single PKI.
Slightly more explicitly, however, Clause 16.1 ("Basic processing
procedure"), begins as follows:

	"The signature on every certificate in the path must be verified.
Procedures related to validating signatures and public-key certificates are
not repeated in this clause. The privilege verifier must verify the identity
of every entity in the path, using the procedures of clause 10. Note that
checking the signature on an attribute certificate necessarily involves
checking the referenced public-key certificate for its validity. Where
privileges are assigned using attribute certificates, path processing
engines will need to consider elements of both the PMI and the PKI in the
course of determining the ultimate validity of a privilege asserter's
attribute certificate."

ACs and PKCs are talked about "in the same breath" with respect to validity
checking and identity verification.  The referenced Clause 10
("Certification path processing procedure") lists the inputs to the
procedure in Section 10.1.  One of the inputs is "a trusted public key value
or key identifier (if the key is stored internally to the certification path
processing module), for use in verifying the first certificate in the
certification path".  This strongly implies to me that there is a single
trusted root key that forms the starting point for all the path processing
(which includes the AC path as well as the PKC path).

> I also see this requirement to be a crippling constraint.
> 
> The requirement for the AA and the Holder's it certificate to belong to
> the
> same PKI means that I will be able to authorize certain subject entities
> from HisCarCompany to have access to resources in MyCarCompany, unless I
> do one of the following:
> 
> 1. Create a new identity at MyCarCompany for subject entity X in 
>    HisCarCompany.
>      This is undesirable for many reasons. For example,
>      if Person X from HisCarCompany gets fired. Also, it to generate
>      new keys, new certificates, new names, new password, new
>      token card, etc. Now, causes a single-sign-on scenario.
>      
> 2. Create an entirely new PKI for the interested parties and an AA. 
>      Out of the question for most. It's Way too much work with new keys,
>      new names, new passwords, new tokens cards, etc.
 
This is not a crippling constraint because neither of the above undesirable
actions need to be taken.  If these two companies want to work together,
they need to issue cross-certificates between their root CAs anyway so that
authentication can take place.  Cross-certification ties these
previously-independent PKIs together, so that there is only a single PKI.
Appropriate name constraints in the cross-certificates ensure that identity
clashes will be ruled out of the picture, and authorization based upon
attribute certificates can proceed securely.

> It would be nice if PKI and AA combined could solve the single-sign-on
> problem.
 
If the companies follow what is outlined above, single sign-on is preserved.

> Of course, this problem would go away, if there is only one RootCA for all
> organzations, and therefore on PKI. For example, HisCarCompany, and
> MyCarCompany must get our CA certificates signed by the Verisign RootCA.
> And we and everybody that Verisign signs, must be well behaved, and the DN
> space is consequently unique.
 
I'm sure you can imagine that Entrust and Baltimore and many other PKI
providers would not be content with the scenario you paint...  :-)

But seriously, people recognized a long time ago that a single root for the
whole world will not work.  This is why cross-certification was invented --
so that independently-deployed PKIs can be joined to form a single, workable
PKI.  This is why the term "PKI networking" is sometimes used instead of
"cross-certification" (it seems slightly more descriptive).

> Is this approach realistic and practical?
 
What I described above, I believe, has the qualities of both realism and
practicality.  Cross-certification is what allows you to grow your PKI to
include other environments, but in a very controlled and reasoned manner.
Attribute certificates take the power of this secure, yet flexible,
authentication technology and overlays the power of secure, yet flexible,
authorization.  It's a very strong combination!

Carlisle.

------_=_NextPart_001_01C0354A.3AA5A480
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Polar =
Humenn[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Friday, October 13, 2000 1:14 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Stephen =
Farrell; [email-masked]; [email-masked]; [email-masked]; =
[email-masked]; Stephen McConnell; Kent Salmond; Ken Mccoy; Thumrongsak =
Kosiyatrakul; Susan Older; Shiu-Kai Chin</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: Comments on draft-ietf-pkix-ac509prof-05.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carlisle,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thank you for your very learned and =
well formed response.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">You do draw an important conclusion =
that the AA and the Holder must belong</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to the same &quot;well-behaved&quot; =
PKI in order for this scheme to work correctly.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(I wonder how many PKI's are actually =
really well-behaved? :). </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Good =
question.&nbsp; On the other hand, why would anyone expect to get =
security from a system that was not &quot;well-behaved&quot;?&nbsp; If =
security is important to you, the onus is on you to choose (buy, =
implement, deploy, whatever) your PKI carefully...</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">In any case, I do not see anywhere in =
the ac509 profile that specifies</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that AA must belong to the same PKI =
(under the same rootCA?) as the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Holder's it authorizes? Can you point =
me to some text stating this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">requirement, or some text that =
somehow implies this requirement?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Ed =
Barkmeyer also asked for this.&nbsp; I haven't had a chance to skim =
quickly through the profile document, so I can't comment on that one at =
the moment, but this implication is definitely there in X.509 =
(2000).&nbsp; As one example, all through the sections on attribute =
certificates it talks about &quot;the&quot; PKI, so it seems that the =
AC-based PMI is to be tied to only a single PKI.&nbsp; Slightly more =
explicitly, however, Clause 16.1 (&quot;Basic processing =
procedure&quot;), begins as follows:</FONT></P>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"TIMES">&quot;The signature =
on every certificate in the path must be verified. Procedures related =
to validating signatures and public-key certificates are not repeated =
in this clause. The privilege verifier must verify the identity of =
every entity in the path, using the procedures of clause 10. Note that =
checking the signature on an attribute certificate necessarily involves =
checking the referenced public-key certificate for its validity. Where =
privileges are assigned using attribute certificates, path processing =
engines will need to consider elements of both the PMI and the PKI in =
the course of determining the ultimate validity of a privilege =
asserter's attribute certificate.&quot;</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">ACs and =
PKCs are talked about &quot;in the same breath&quot; with respect to =
validity checking and identity verification.&nbsp; The referenced =
Clause 10 (&quot;Certification path processing procedure&quot;) lists =
the inputs to the procedure in Section 10.1.&nbsp; One of the inputs is =
&quot;</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"TIMES">a trusted =
public key value or key identifier (if the key is stored internally to =
the certification path processing module), for use in verifying the =
first certificate in the certification path</FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">&quot;.&nbsp; This =
strongly implies to me that there is a single trusted root key that =
forms the starting point for all the path processing (which includes =
the AC path as well as the PKC path).</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I also see this requirement to be a =
crippling constraint.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The requirement for the AA and the =
Holder's it certificate to belong to the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">same PKI means that I will be able to =
authorize certain subject entities</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">from HisCarCompany to have access to =
resources in MyCarCompany, unless I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">do one of the following:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. Create a new identity at =
MyCarCompany for subject entity X in </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; HisCarCompany.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; This is =
undesirable for many reasons. For example,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; if Person X =
from HisCarCompany gets fired. Also, it to generate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; new keys, =
new certificates, new names, new password, new</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; token card, =
etc. Now, causes a single-sign-on scenario.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">2. Create an entirely new PKI for the =
interested parties and an AA. </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; Out of the =
question for most. It's Way too much work with new keys,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; new names, =
new passwords, new tokens cards, etc.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">This is =
not a crippling constraint because neither of the above undesirable =
actions need to be taken.&nbsp; If these two companies want to work =
together, they need to issue cross-certificates between their root CAs =
anyway so that authentication can take place.&nbsp; Cross-certification =
ties these previously-independent PKIs together, so that there is only =
a single PKI.&nbsp; Appropriate name constraints in the =
cross-certificates ensure that identity clashes will be ruled out of =
the picture, and authorization based upon attribute certificates can =
proceed securely.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">It would be nice if PKI and AA =
combined could solve the single-sign-on</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">problem.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">If the =
companies follow what is outlined above, single sign-on is =
preserved.</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Of course, this problem would go away, =
if there is only one RootCA for all</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">organzations, and therefore on PKI. =
For example, HisCarCompany, and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MyCarCompany must get our CA =
certificates signed by the Verisign RootCA.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">And we and everybody that Verisign =
signs, must be well behaved, and the DN</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">space is consequently unique.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I'm sure =
you can imagine that Entrust and Baltimore and many other PKI providers =
would not be content with the scenario you paint...&nbsp; =
:-)</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">But =
seriously, people recognized a long time ago that a single root for the =
whole world will not work.&nbsp; This is why cross-certification was =
invented -- so that independently-deployed PKIs can be joined to form a =
single, workable PKI.&nbsp; This is why the term &quot;PKI =
networking&quot; is sometimes used instead of =
&quot;cross-certification&quot; (it seems slightly more =
descriptive).</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Is this approach realistic and =
practical?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">What I =
described above, I believe, has the qualities of both realism and =
practicality.&nbsp; Cross-certification is what allows you to grow your =
PKI to include other environments, but in a very controlled and =
reasoned manner.&nbsp; Attribute certificates take the power of this =
secure, yet flexible, authentication technology and overlays the power =
of secure, yet flexible, authorization.&nbsp; It's a very strong =
combination!</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0354A.3AA5A480--

Date: Fri, 13 Oct 2000 14:02:46 -0400
From: Ed Barkmeyer <[email-masked]>
Reply-To: [email-masked]
Organization: NIST
To: Carlisle Adams <[email-masked]>
CC: Stephen Farrell <[email-masked]>, "'Polar Humenn'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Carlisle,

Thanks for taking the trouble to copy your tutorial to us unwashed outliers who
happen to be on peripheral exploders (in my case, OMG ec).

One question:  Is the model you describe documented somewhere in the IETF or PKI
space?

(That is to say:  Before I read your tutorial, I never understood the "implicit
CA scoping rules", and while it may be common knowledge in the PKI standards
development community, it may not be common knowledge to the "new kid on the
block" who may be charged with implementing an AA.  And I can tell you from
experience that there are a lot of idiots like me who think they can read a
standard and understand it, whilst stupidly having failed to read an important
background document that defines the playing rules for the context in which that
standard was intended to be used.  In this case, I am exactly the kind of idiot
savant you needed to educate.  The tutorial was great, but what document should
I have read?  Next week's idiot will not have been on this collection of email
exploders.)

Thanks,
-Ed

P.S. Any OMG person will tell you that I am one of those people who took the
elementary school teacher's advice to heart:  "If you have a question, don't be
afraid to ask, because lots of people probably have the same question!"

-- 
Edward J. Barkmeyer                           Email: [email-masked]
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Mail Stop 8260              Tel: +1 301-975-3528
Gaithersburg, MD 20899-8260                   FAX: +1 301-975-4482

Date: Fri, 13 Oct 2000 13:22:19 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Carlisle Adams <[email-masked]>
cc: Stephen Farrell <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

My apologies,

I missed stating a negative in a paragraph below.  Sorry!

-Polar

On Fri, 13 Oct 2000, Polar Humenn wrote:

> 
> Carlisle,
> 
> Thank you for your very learned and well formed response.
> 
> You do draw an important conclusion that the AA and the Holder must belong
> to the same "well-behaved" PKI in order for this scheme to work correctly.
> (I wonder how many PKI's are actually really well-behaved? :). 
> 
> In any case, I do not see anywhere in the ac509 profile that specifies
> that AA must belong to the same PKI (under the same rootCA?) as the
> Holder's it authorizes? Can you point me to some text stating this
> requirement, or some text that somehow implies this requirement?
> 
> I also see this requirement to be a crippling constraint.
> 
> The requirement for the AA and the Holder's it certificate to belong to the
> same PKI means that I will be able to authorize certain subject entities
> from HisCarCompany to have access to resources in MyCarCompany, unless I
> do one of the following:
^^^^^^^^^^^^^^^^^^^^^^^^Scratch that  paragraph!^^^^^^^^^^^^^^^^^^^^^^^^^^^

The requirement that the AA and the Holders it certifies must belong to
the same PKI means that I will NOT be able to authorize certain subject
entities from HisCarCompany to have access to resources in MyCarCompany,
unless I do one of the following:

> 1. Create a new identity at MyCarCompany for subject entity X in 
>    HisCarCompany.
>      This is undesirable for many reasons. For example,
>      if Person X from HisCarCompany gets fired. Also, it to generate
>      new keys, new certificates, new names, new password, new
>      token card, etc. Now, causes a single-sign-on scenario.
>      
> 2. Create an entirely new PKI for the interested parties and an AA. 
>      Out of the question for most. It's Way too much work with new keys,
>      new names, new passwords, new tokens cards, etc.
> 
> It would be nice if PKI and AA combined could solve the single-sign-on
> problem.
> 
> Of course, this problem would go away, if there is only one RootCA for all
> organizations, and therefore on PKI. For example, HisCarCompany, and
> MyCarCompany must get our CA certificates signed by the Verisign RootCA.
> And we and everybody that Verisign signs, must be well behaved, and the DN
> space is consequently unique.
> 
> Is this approach realistic and practical?
> 
> Cheers,
> -Polar
>  
> On Fri, 13 Oct 2000, Carlisle Adams wrote:
> 
> > Hi Polar,
> > 
> > I think that as this thread has progressed we've all come to a better
> > understanding of what you perceive the problem to be.  However, I suspect
> > you may be missing an important foundational premise which so many of us
> > take for granted that it may not be stated explicitly in the various
> > standards documents.
> > 
> > In PKI, a number of security implications rest upon the underlying trust
> > model.  If I have a particular root CA (i.e., I received it's public-key
> > out-of-band in a secure fashion, etc. -- all the usual conditions), then
> > that root CA defines for me a PKI.  That is, it is the starting (or ending)
> > point in my certificate path validation processing; any path that does not
> > validly end up at this root is rejected by my software.  Therefore, this
> > root CA defines for me a universe of PKI entities.  Such entities are
> > identified in some way, perhaps by DN in the subject field, or by some other
> > value(s) in subjectAltNames field, or by a combination of the two fields.
> > 
> > Now if, for some reason (my deliberate choice, or as a result of the browser
> > I downloaded, or whatever) I happen to have a second root CA, then this root
> > CA defines for me a second PKI, another universe of entities.  Is it
> > possible that a given entity could have an identity in each of these
> > universes?  Of course.  But my path validation software will trace a path
> > down to one root or the other, depending on which certificate it began with.
> > Is it possible that two different entities could have (accidentally or
> > maliciously) the same identity in each of these universes?  Again, of
> > course.  But, again, my path validation software will trace a path down to
> > one root or the other, depending on which certificate it began with.  The
> > point is that these two universes of PKI entities are always distinguishable
> > because they trace to one root or the other.  (Extend this to any number of
> > roots with corresponding universes and this remains true.)
> > 
> > Now, what about authorization via attribute certificates, which is where
> > this thread began?  The AC may be bound to a PKI entity only through
> > identity (DN, or issuer/serial), but this "identity" may appear in several
> > different PKIs.  Your question is, "how can the AC verifier know which PKI
> > was intended unless the AC issuer includes in the AC the full path of DNs
> > (identities) all the way to the root?"  The answer is that this new
> > extension is not at all necessary because this AC issuer (i.e., this AA)
> > itself has an identity, and *its* issuer has an identity, all the way up to
> > the SOA, which also has an identity.  All these identities must belong to
> > the same universe, from the perspective of the relying party (the verifier),
> > otherwise the AC is rejected.
> > 
> > X.509 (2000) is fairly clear about the idea that AAs do not create
> > identities; they rely upon the PKI to do this function and then simply point
> > to those identities in the ACs they issue (see, for example, Section 13).
> > Therefore, the AA must not simply have an awareness of the identities it can
> > point to; it must itself be able to verify these identities in order to
> > assign privileges to them.  In other words, the AA and the proposed AC
> > holder MUST BELONG TO THE SAME PKI.  This relationship must necessarily hold
> > recursively all the way up the chain to the SOA and the first AA in the
> > path.  Logically, this makes sense as well:  why would it be reasonable for
> > an AA in one universe to be able to assign privileges to some entity in an
> > arbitrary, different universe?  No, all entities involved must be part of
> > the same PKI because the AA is only making use of the identities defined in
> > the PKI of which it is a part and from which it has its own identity.
> > 
> > The extension you propose would not hurt, but would not help either.  It
> > would be a fairly sizable piece of extraneous, unnecessary information
> > carried in each and every attribute certificate.
> > 
> > Carlisle.
> > 
> > P.S., It seems to me that thinking about this one-to-one mapping between
> > root CAs and PKIs alleviates all the name clashing concerns.  Yes there can
> > be name (identity) clashes between universes of entities, but this doesn't
> > matter:  any certificate can be resolved to one and only one universe by
> > following its path of signatures to the root.  Furthermore, it is easy to
> > ensure that identity clashes will not be a concern within a single PKI:
> > this is why name constraints were invented.  A root CA that does its job
> > correctly will put name constraints in the certificates it issues to its
> > subordinate CAs, and will put name constraints in the cross-certificates it
> > issues to other CAs.  Any of these CAs can, of course, ignore these
> > constraints and (again, accidentally or maliciously) create name clashes,
> > but such certificates will not validate in proper path validation software
> > and so are of no consequence.  Any environment for which secure
> > authentication and authorization is important will use a root CA that
> > imposes proper name constraints in order to eliminate the possibility of
> > identity clashes within that PKI.  Clashes with entities in another PKI will
> > not lead to faulty authentication or authorization decisions because all
> > certificates being validated for a single purported entity must exist within
> > the same universe.
> > 
> > P.P.S., Stephen asked that we trim the Cc: list back to PKIX, and I agree
> > that we should probably do this.  However, I kept all the copied lists and
> > people on this response because I don't know how many of you currently
> > subscribe to PKIX and I felt it was important to address the concern being
> > raised so widely that name clashing was somehow a serious security problem
> > for attribute certificates and for PKI more generally.  This is not the
> > case, as I hope I have shown above.
> > 
> > 
> 

Date: Fri, 13 Oct 2000 13:14:11 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Carlisle Adams <[email-masked]>
cc: Stephen Farrell <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

Carlisle,

Thank you for your very learned and well formed response.

You do draw an important conclusion that the AA and the Holder must belong
to the same "well-behaved" PKI in order for this scheme to work correctly.
(I wonder how many PKI's are actually really well-behaved? :). 

In any case, I do not see anywhere in the ac509 profile that specifies
that AA must belong to the same PKI (under the same rootCA?) as the
Holder's it authorizes? Can you point me to some text stating this
requirement, or some text that somehow implies this requirement?

I also see this requirement to be a crippling constraint.

The requirement for the AA and the Holder's it certificate to belong to the
same PKI means that I will be able to authorize certain subject entities
from HisCarCompany to have access to resources in MyCarCompany, unless I
do one of the following:

1. Create a new identity at MyCarCompany for subject entity X in 
   HisCarCompany.
     This is undesirable for many reasons. For example,
     if Person X from HisCarCompany gets fired. Also, it to generate
     new keys, new certificates, new names, new password, new
     token card, etc. Now, causes a single-sign-on scenario.
     
2. Create an entirely new PKI for the interested parties and an AA. 
     Out of the question for most. It's Way too much work with new keys,
     new names, new passwords, new tokens cards, etc.

It would be nice if PKI and AA combined could solve the single-sign-on
problem.

Of course, this problem would go away, if there is only one RootCA for all
organzations, and therefore on PKI. For example, HisCarCompany, and
MyCarCompany must get our CA certificates signed by the Verisign RootCA.
And we and everybody that Verisign signs, must be well behaved, and the DN
space is consequently unique.

Is this approach realistic and practical?

Cheers,
-Polar
 
On Fri, 13 Oct 2000, Carlisle Adams wrote:

> Hi Polar,
> 
> I think that as this thread has progressed we've all come to a better
> understanding of what you perceive the problem to be.  However, I suspect
> you may be missing an important foundational premise which so many of us
> take for granted that it may not be stated explicitly in the various
> standards documents.
> 
> In PKI, a number of security implications rest upon the underlying trust
> model.  If I have a particular root CA (i.e., I received it's public-key
> out-of-band in a secure fashion, etc. -- all the usual conditions), then
> that root CA defines for me a PKI.  That is, it is the starting (or ending)
> point in my certificate path validation processing; any path that does not
> validly end up at this root is rejected by my software.  Therefore, this
> root CA defines for me a universe of PKI entities.  Such entities are
> identified in some way, perhaps by DN in the subject field, or by some other
> value(s) in subjectAltNames field, or by a combination of the two fields.
> 
> Now if, for some reason (my deliberate choice, or as a result of the browser
> I downloaded, or whatever) I happen to have a second root CA, then this root
> CA defines for me a second PKI, another universe of entities.  Is it
> possible that a given entity could have an identity in each of these
> universes?  Of course.  But my path validation software will trace a path
> down to one root or the other, depending on which certificate it began with.
> Is it possible that two different entities could have (accidentally or
> maliciously) the same identity in each of these universes?  Again, of
> course.  But, again, my path validation software will trace a path down to
> one root or the other, depending on which certificate it began with.  The
> point is that these two universes of PKI entities are always distinguishable
> because they trace to one root or the other.  (Extend this to any number of
> roots with corresponding universes and this remains true.)
> 
> Now, what about authorization via attribute certificates, which is where
> this thread began?  The AC may be bound to a PKI entity only through
> identity (DN, or issuer/serial), but this "identity" may appear in several
> different PKIs.  Your question is, "how can the AC verifier know which PKI
> was intended unless the AC issuer includes in the AC the full path of DNs
> (identities) all the way to the root?"  The answer is that this new
> extension is not at all necessary because this AC issuer (i.e., this AA)
> itself has an identity, and *its* issuer has an identity, all the way up to
> the SOA, which also has an identity.  All these identities must belong to
> the same universe, from the perspective of the relying party (the verifier),
> otherwise the AC is rejected.
> 
> X.509 (2000) is fairly clear about the idea that AAs do not create
> identities; they rely upon the PKI to do this function and then simply point
> to those identities in the ACs they issue (see, for example, Section 13).
> Therefore, the AA must not simply have an awareness of the identities it can
> point to; it must itself be able to verify these identities in order to
> assign privileges to them.  In other words, the AA and the proposed AC
> holder MUST BELONG TO THE SAME PKI.  This relationship must necessarily hold
> recursively all the way up the chain to the SOA and the first AA in the
> path.  Logically, this makes sense as well:  why would it be reasonable for
> an AA in one universe to be able to assign privileges to some entity in an
> arbitrary, different universe?  No, all entities involved must be part of
> the same PKI because the AA is only making use of the identities defined in
> the PKI of which it is a part and from which it has its own identity.
> 
> The extension you propose would not hurt, but would not help either.  It
> would be a fairly sizable piece of extraneous, unnecessary information
> carried in each and every attribute certificate.
> 
> Carlisle.
> 
> P.S., It seems to me that thinking about this one-to-one mapping between
> root CAs and PKIs alleviates all the name clashing concerns.  Yes there can
> be name (identity) clashes between universes of entities, but this doesn't
> matter:  any certificate can be resolved to one and only one universe by
> following its path of signatures to the root.  Furthermore, it is easy to
> ensure that identity clashes will not be a concern within a single PKI:
> this is why name constraints were invented.  A root CA that does its job
> correctly will put name constraints in the certificates it issues to its
> subordinate CAs, and will put name constraints in the cross-certificates it
> issues to other CAs.  Any of these CAs can, of course, ignore these
> constraints and (again, accidentally or maliciously) create name clashes,
> but such certificates will not validate in proper path validation software
> and so are of no consequence.  Any environment for which secure
> authentication and authorization is important will use a root CA that
> imposes proper name constraints in order to eliminate the possibility of
> identity clashes within that PKI.  Clashes with entities in another PKI will
> not lead to faulty authentication or authorization decisions because all
> certificates being validated for a single purported entity must exist within
> the same universe.
> 
> P.P.S., Stephen asked that we trim the Cc: list back to PKIX, and I agree
> that we should probably do this.  However, I kept all the copied lists and
> people on this response because I don't know how many of you currently
> subscribe to PKIX and I felt it was important to address the concern being
> raised so widely that name clashing was somehow a serious security problem
> for attribute certificates and for PKI more generally.  This is not the
> case, as I hope I have shown above.
> 
> 

From: Carlisle Adams <[email-masked]>
To: Stephen Farrell <[email-masked]>, "'Polar Humenn'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt
Date: Fri, 13 Oct 2000 12:44:56 -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_01C03534.EAEF3290
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Polar,

I think that as this thread has progressed we've all come to a better
understanding of what you perceive the problem to be.  However, I suspect
you may be missing an important foundational premise which so many of us
take for granted that it may not be stated explicitly in the various
standards documents.

In PKI, a number of security implications rest upon the underlying trust
model.  If I have a particular root CA (i.e., I received it's public-key
out-of-band in a secure fashion, etc. -- all the usual conditions), then
that root CA defines for me a PKI.  That is, it is the starting (or ending)
point in my certificate path validation processing; any path that does not
validly end up at this root is rejected by my software.  Therefore, this
root CA defines for me a universe of PKI entities.  Such entities are
identified in some way, perhaps by DN in the subject field, or by some other
value(s) in subjectAltNames field, or by a combination of the two fields.

Now if, for some reason (my deliberate choice, or as a result of the browser
I downloaded, or whatever) I happen to have a second root CA, then this root
CA defines for me a second PKI, another universe of entities.  Is it
possible that a given entity could have an identity in each of these
universes?  Of course.  But my path validation software will trace a path
down to one root or the other, depending on which certificate it began with.
Is it possible that two different entities could have (accidentally or
maliciously) the same identity in each of these universes?  Again, of
course.  But, again, my path validation software will trace a path down to
one root or the other, depending on which certificate it began with.  The
point is that these two universes of PKI entities are always distinguishable
because they trace to one root or the other.  (Extend this to any number of
roots with corresponding universes and this remains true.)

Now, what about authorization via attribute certificates, which is where
this thread began?  The AC may be bound to a PKI entity only through
identity (DN, or issuer/serial), but this "identity" may appear in several
different PKIs.  Your question is, "how can the AC verifier know which PKI
was intended unless the AC issuer includes in the AC the full path of DNs
(identities) all the way to the root?"  The answer is that this new
extension is not at all necessary because this AC issuer (i.e., this AA)
itself has an identity, and *its* issuer has an identity, all the way up to
the SOA, which also has an identity.  All these identities must belong to
the same universe, from the perspective of the relying party (the verifier),
otherwise the AC is rejected.

X.509 (2000) is fairly clear about the idea that AAs do not create
identities; they rely upon the PKI to do this function and then simply point
to those identities in the ACs they issue (see, for example, Section 13).
Therefore, the AA must not simply have an awareness of the identities it can
point to; it must itself be able to verify these identities in order to
assign privileges to them.  In other words, the AA and the proposed AC
holder MUST BELONG TO THE SAME PKI.  This relationship must necessarily hold
recursively all the way up the chain to the SOA and the first AA in the
path.  Logically, this makes sense as well:  why would it be reasonable for
an AA in one universe to be able to assign privileges to some entity in an
arbitrary, different universe?  No, all entities involved must be part of
the same PKI because the AA is only making use of the identities defined in
the PKI of which it is a part and from which it has its own identity.

The extension you propose would not hurt, but would not help either.  It
would be a fairly sizable piece of extraneous, unnecessary information
carried in each and every attribute certificate.

Carlisle.

P.S., It seems to me that thinking about this one-to-one mapping between
root CAs and PKIs alleviates all the name clashing concerns.  Yes there can
be name (identity) clashes between universes of entities, but this doesn't
matter:  any certificate can be resolved to one and only one universe by
following its path of signatures to the root.  Furthermore, it is easy to
ensure that identity clashes will not be a concern within a single PKI:
this is why name constraints were invented.  A root CA that does its job
correctly will put name constraints in the certificates it issues to its
subordinate CAs, and will put name constraints in the cross-certificates it
issues to other CAs.  Any of these CAs can, of course, ignore these
constraints and (again, accidentally or maliciously) create name clashes,
but such certificates will not validate in proper path validation software
and so are of no consequence.  Any environment for which secure
authentication and authorization is important will use a root CA that
imposes proper name constraints in order to eliminate the possibility of
identity clashes within that PKI.  Clashes with entities in another PKI will
not lead to faulty authentication or authorization decisions because all
certificates being validated for a single purported entity must exist within
the same universe.

P.P.S., Stephen asked that we trim the Cc: list back to PKIX, and I agree
that we should probably do this.  However, I kept all the copied lists and
people on this response because I don't know how many of you currently
subscribe to PKIX and I felt it was important to address the concern being
raised so widely that name clashing was somehow a serious security problem
for attribute certificates and for PKI more generally.  This is not the
case, as I hope I have shown above.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: Comments on draft-ietf-pkix-ac509prof-05.txt</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">I think =
that as this thread has progressed we've all come to a better =
understanding of what you perceive the problem to be.&nbsp; However, I =
suspect you may be missing an important foundational premise which so =
many of us take for granted that it may not be stated explicitly in the =
various standards documents.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">In PKI, a =
number of security implications rest upon the underlying trust =
model.&nbsp; If I have a particular root CA (i.e., I received it's =
public-key out-of-band in a secure fashion, etc. -- all the usual =
conditions), then that root CA defines for me a PKI.&nbsp; That is, it =
is the starting (or ending) point in my certificate path validation =
processing; any path that does not validly end up at this root is =
rejected by my software.&nbsp; Therefore, this root CA defines for me a =
universe of PKI entities.&nbsp; Such entities are identified in some =
way, perhaps by DN in the subject field, or by some other value(s) in =
subjectAltNames field, or by a combination of the two =
fields.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Now if, =
for some reason (my deliberate choice, or as a result of the browser I =
downloaded, or whatever) I happen to have a second root CA, then this =
root CA defines for me a second PKI, another universe of =
entities.&nbsp; Is it possible that a given entity could have an =
identity in each of these universes?&nbsp; Of course.&nbsp; But my path =
validation software will trace a path down to one root or the other, =
depending on which certificate it began with.&nbsp; Is it possible that =
two different entities could have (accidentally or maliciously) the =
same identity in each of these universes?&nbsp; Again, of course.&nbsp; =
But, again, my path validation software will trace a path down to one =
root or the other, depending on which certificate it began with.&nbsp; =
The point is that these two universes of PKI entities are always =
distinguishable because they trace to one root or the other.&nbsp; =
(Extend this to any number of roots with corresponding universes and =
this remains true.)</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Now, what =
about authorization via attribute certificates, which is where this =
thread began?&nbsp; The AC may be bound to a PKI entity only through =
identity (DN, or issuer/serial), but this &quot;identity&quot; may =
appear in several different PKIs.&nbsp; Your question is, &quot;how can =
the AC verifier know which PKI was intended unless the AC issuer =
includes in the AC the full path of DNs (identities) all the way to the =
root?&quot;&nbsp; The answer is that this new extension is not at all =
necessary because this AC issuer (i.e., this AA) itself has an =
identity, and *its* issuer has an identity, all the way up to the SOA, =
which also has an identity.&nbsp; All these identities must belong to =
the same universe, from the perspective of the relying party (the =
verifier), otherwise the AC is rejected.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">X.509 =
(2000) is fairly clear about the idea that AAs do not create =
identities; they rely upon the PKI to do this function and then simply =
point to those identities in the ACs they issue (see, for example, =
Section 13).&nbsp; Therefore, the AA must not simply have an awareness =
of the identities it can point to; it must itself be able to verify =
these identities in order to assign privileges to them.&nbsp; In other =
words, the AA and the proposed AC holder MUST BELONG TO THE SAME =
PKI.&nbsp; This relationship must necessarily hold recursively all the =
way up the chain to the SOA and the first AA in the path.&nbsp; =
Logically, this makes sense as well:&nbsp; why would it be reasonable =
for an AA in one universe to be able to assign privileges to some =
entity in an arbitrary, different universe?&nbsp; No, all entities =
involved must be part of the same PKI because the AA is only making use =
of the identities defined in the PKI of which it is a part and from =
which it has its own identity.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The =
extension you propose would not hurt, but would not help either.&nbsp; =
It would be a fairly sizable piece of extraneous, unnecessary =
information carried in each and every attribute certificate.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">P.S., It =
seems to me that thinking about this one-to-one mapping between root =
CAs and PKIs alleviates all the name clashing concerns.&nbsp; Yes there =
can be name (identity) clashes between universes of entities, but this =
doesn't matter:&nbsp; any certificate can be resolved to one and only =
one universe by following its path of signatures to the root.&nbsp; =
Furthermore, it is easy to ensure that identity clashes will not be a =
concern within a single PKI:&nbsp; this is why name constraints were =
invented.&nbsp; A root CA that does its job correctly will put name =
constraints in the certificates it issues to its subordinate CAs, and =
will put name constraints in the cross-certificates it issues to other =
CAs.&nbsp; Any of these CAs can, of course, ignore these constraints =
and (again, accidentally or maliciously) create name clashes, but such =
certificates will not validate in proper path validation software and =
so are of no consequence.&nbsp; Any environment for which secure =
authentication and authorization is important will use a root CA that =
imposes proper name constraints in order to eliminate the possibility =
of identity clashes within that PKI.&nbsp; Clashes with entities in =
another PKI will not lead to faulty authentication or authorization =
decisions because all certificates being validated for a single =
purported entity must exist within the same universe.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">P.P.S., =
Stephen asked that we trim the Cc: list back to PKIX, and I agree that =
we should probably do this.&nbsp; However, I kept all the copied lists =
and people on this response because I don't know how many of you =
currently subscribe to PKIX and I felt it was important to address the =
concern being raised so widely that name clashing was somehow a serious =
security problem for attribute certificates and for PKI more =
generally.&nbsp; This is not the case, as I hope I have shown =
above.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C03534.EAEF3290--

Content-return: allowed
Date: Fri, 13 Oct 2000 07:35:06 -0700
From: Frank Balluffi <[email-masked]>
Subject: RE: Delegated Path Validation draft.
To: "'Michael Zolotarev'" <[email-masked]>, Frank Balluffi <[email-masked]>, Michael Myers <[email-masked]>, [email-masked]

Michael,

I strongly agree with your desire to keep it simple. Unfortunately, I am
learning as I go and do not know all of the answers to how this stuff will
be used. For example, I recently learned that there are many certificates in
the real world that do pass RFC 2459, section 6.1 (e.g., illegal criticality
flags, improper policy identifier values, etc.). I have no idea how the
world will choose to deal with these certificates. Also, what is a client?
An end-user device (e.g., an internet-enabled phone)? A gateway? Perhaps a
gateway will want more detailed information than an end-user device. I don't
know. As long as we can find a simple way to deal with complexity, I am
happy (e.g., by just saying no).

Frank

> From: Michael Zolotarev [mailto:[email-masked]]
> Sent: Friday, October 13, 2000 11:19 AM
> To: 'Frank Balluffi'; Michael Zolotarev; Michael Myers;
> [email-masked]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> Frank,
> 
> please, do not go this way. Keep it simple. 
> Realistically speaking, a client only needs a simple 'yes' or 
> 'now'. The
> whole purpose of defining a TTP for path validation was to 
> simplify things.
> 
> If a client is not satisfied by the 'yes' or 'now', there are 
> other options
> (other then been shot, of course). Mind you I fail undestand 
> why a client
> would ever ask 'why yes?' - would like to hear from you on this one,
> frankly. 
> 
> To find out why 'No', a client can use DPD to get the path, 
> and then ask DPV
> for each component in the path.
> 
> Otherwise we'll end up with a hugely blown-up service, which 
> wasn't the
> purpose of the exercise.
> 
> M
> 
> 
> From: Frank Balluffi [mailto:[email-masked]]
> Sent: Saturday, October 14, 2000 12:04 AM
> To: 'Michael Zolotarev'; Michael Myers; [email-masked]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> Michael Zolotarev wrote:
> 
> > However, my original question was what does the server do if 
> > both Policy and
> > Trust components aren't there. I'd assume that the server has 
> > two options:
> > 1. Check revocation status and then apply some 'default' 
> > implicit policy and
> > trust points. This would be an option for a pre-configured (i.e.
> > enterprise-wide) responder.
> > 2. Check revocation status and then discard the request on 
> > the basis that
> > there is no 'implicit' verification context which the server 
> > can apply (at
> > all, or for that particular certificate). In this case the 
> > error code can be
> > either 'invalid', if the cert is revoked, or 'unknown', 
> > indicating that the
> > cert is not revoked, but validation couldn't be executed due 
> > to lack of
> > input conditions.
> 
> Considering that validating a path includes more steps than 
> checking the
> revocation status of each certificate (in the path), and that 
> at least one
> of these steps should not "check out" under normal operations 
> (or at least
> until there are no adversaries), I expect that clients will 
> want to know why
> a path was not valid, and possibly why a path was valid. For example:
> 
> 1. the server did not possess the necessary information to 
> validate each
> certificate
> 2. the server applied some default policy
> 3. a certificate's basic information (e.g., its signature, 
> validity period,
> revocation status or subject name) did not "check out" (i.e., 
> adhere to RFC
> 2459, section 6.1)
> 4. a certificate extension did not "check out"
> 
> RFC 2560 addresses some failure paths (e.g., malformed 
> request, internal
> error). So my answer to your question is that the protocol needs to:
> 
> a. provide a mechanism for the server to return detailed 
> information about
> why the server deemed the path valid or not valid (e.g., it 
> applied some
> default policy, it encountered a "bad" extension, etc.)
> b. define a set of cases and each's expected behavior
> 
> Frank
> 

From: Michael Zolotarev <[email-masked]>
To: "'Frank Balluffi'" <[email-masked]>, Michael Zolotarev <[email-masked]>, Michael Myers <[email-masked]>, [email-masked]
Subject: RE: Delegated Path Validation draft.
Date: Sat, 14 Oct 2000 01:19:07 +1000

Frank,

please, do not go this way. Keep it simple. 
Realistically speaking, a client only needs a simple 'yes' or 'now'. The
whole purpose of defining a TTP for path validation was to simplify things.

If a client is not satisfied by the 'yes' or 'now', there are other options
(other then been shot, of course). Mind you I fail undestand why a client
would ever ask 'why yes?' - would like to hear from you on this one,
frankly. 

To find out why 'No', a client can use DPD to get the path, and then ask DPV
for each component in the path.

Otherwise we'll end up with a hugely blown-up service, which wasn't the
purpose of the exercise.

M

-----Original Message-----
From: Frank Balluffi [mailto:[email-masked]]
Sent: Saturday, October 14, 2000 12:04 AM
To: 'Michael Zolotarev'; Michael Myers; [email-masked]
Subject: RE: Delegated Path Validation draft.

Michael Zolotarev wrote:

> However, my original question was what does the server do if 
> both Policy and
> Trust components aren't there. I'd assume that the server has 
> two options:
> 1. Check revocation status and then apply some 'default' 
> implicit policy and
> trust points. This would be an option for a pre-configured (i.e.
> enterprise-wide) responder.
> 2. Check revocation status and then discard the request on 
> the basis that
> there is no 'implicit' verification context which the server 
> can apply (at
> all, or for that particular certificate). In this case the 
> error code can be
> either 'invalid', if the cert is revoked, or 'unknown', 
> indicating that the
> cert is not revoked, but validation couldn't be executed due 
> to lack of
> input conditions.

Considering that validating a path includes more steps than checking the
revocation status of each certificate (in the path), and that at least one
of these steps should not "check out" under normal operations (or at least
until there are no adversaries), I expect that clients will want to know why
a path was not valid, and possibly why a path was valid. For example:

1. the server did not possess the necessary information to validate each
certificate
2. the server applied some default policy
3. a certificate's basic information (e.g., its signature, validity period,
revocation status or subject name) did not "check out" (i.e., adhere to RFC
2459, section 6.1)
4. a certificate extension did not "check out"

RFC 2560 addresses some failure paths (e.g., malformed request, internal
error). So my answer to your question is that the protocol needs to:

a. provide a mechanism for the server to return detailed information about
why the server deemed the path valid or not valid (e.g., it applied some
default policy, it encountered a "bad" extension, etc.)
b. define a set of cases and each's expected behavior

Frank

Content-return: allowed
Date: Fri, 13 Oct 2000 07:04:16 -0700
From: Frank Balluffi <[email-masked]>
Subject: RE: Delegated Path Validation draft.
To: "'Michael Zolotarev'" <[email-masked]>, Michael Myers <[email-masked]>, [email-masked]

Michael Zolotarev wrote:

> However, my original question was what does the server do if 
> both Policy and
> Trust components aren't there. I'd assume that the server has 
> two options:
> 1. Check revocation status and then apply some 'default' 
> implicit policy and
> trust points. This would be an option for a pre-configured (i.e.
> enterprise-wide) responder.
> 2. Check revocation status and then discard the request on 
> the basis that
> there is no 'implicit' verification context which the server 
> can apply (at
> all, or for that particular certificate). In this case the 
> error code can be
> either 'invalid', if the cert is revoked, or 'unknown', 
> indicating that the
> cert is not revoked, but validation couldn't be executed due 
> to lack of
> input conditions.

Considering that validating a path includes more steps than checking the
revocation status of each certificate (in the path), and that at least one
of these steps should not "check out" under normal operations (or at least
until there are no adversaries), I expect that clients will want to know why
a path was not valid, and possibly why a path was valid. For example:

1. the server did not possess the necessary information to validate each
certificate
2. the server applied some default policy
3. a certificate's basic information (e.g., its signature, validity period,
revocation status or subject name) did not "check out" (i.e., adhere to RFC
2459, section 6.1)
4. a certificate extension did not "check out"

RFC 2560 addresses some failure paths (e.g., malformed request, internal
error). So my answer to your question is that the protocol needs to:

a. provide a mechanism for the server to return detailed information about
why the server deemed the path valid or not valid (e.g., it applied some
default policy, it encountered a "bad" extension, etc.)
b. define a set of cases and each's expected behavior

Frank

Reply-To: =?UTF-8?B?6rmA7ISx642V?= <[email-masked]>
From: =?UTF-8?B?6rmA7ISx642V?= <[email-masked]>
To: <[email-masked]>
Subject: id-smime-ct-TSTInfo
Date: Fri, 13 Oct 2000 21:17:48 +0900
Organization: =?UTF-8?B?7KCE7J6Q7J247Kad7IKs7JeF67aA?=

I think that  id-smime-ct-TSTInfo in Appendix D of new TSP draft should be replaced by id-ct-TSTInfo .

TSP version 10
2.4.2 Response Format
id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2) 
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

 Appendix D 
TimeStampToken ::= ContentInfo
     -- contentType is id-signedData as defined in [CMS]
     -- content is SignedData as defined in([CMS])
     -- eContentType within SignedData is id-ct-TSTInfo 
     -- eContent within SignedData is TSTInfo

-- eContentType for a time stamping token

id-smime-ct-TSTInfo  OBJECT IDENTIFIER ::= { id-smime-ct 4 }
id-smime-ct          OBJECT IDENTIFIER ::= { id-smime 1 }
id-smime             OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 

Date: Fri, 13 Oct 2000 13:02:02 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>
Subject: TSP. Version 10

A new version of the Time Stamping Protocol has been placed on the web
server. A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-10.txt

This version addresses the comments received during the IESG last call
period.

Besides the changes made to accommodate the 24 comments raised by Russ
Housley, the abstract and the introduction have been modified, by myself and
Steve Kent, in order to address some of the concerns raised by Todd Glassey.

If there are no major editorial errors, this version should (hopefully) be
the version to be published as an RFC. Should there be a few minor errors
left, please tell me, since they can still be corrected directly by myself
when the RFC editor transforms the document into an RFC (there a 48 hours
time window to do so).

FYI, the abstract and the introduction are now as follows:

Abstract

A time stamping service allows to prove that a datum existed before 
a particular time. This document describes the format of a request 
sent to a Time Stamping Authority (TSA) and of the response that is 
returned. It also establishes several security-relevant requirements 
for TSA operation, with regards to processing requests to generate 
responses. A TSA may be operated as a Trusted Third Party (TTP) 
service, though other operational models may be appropriate, e.g. an 
organization might require a TSA for internal time stamping purposes. 

Non-repudiation services [ISONR] require the ability to establish the 
existence of data before specified times. This protocol may be used as 
a building block to support such services. An example of how to prove 
that a digital signature was generated during the validity period of 
a public key certificate is given in an annex.

(...)

1.  Introduction

(...)

This standard does not establish overall security requirements for 
TSA operation, just like other PKIX standards do not establish such 
requirements for CA operation. Rather, it is anticipated that a TSA 
will make know to prospective clients the policies it implements to 
ensure accurate time stamp generation, and clients will make use of 
the services of a TSA only if they are satisfied that these policies 
meet their needs.

Denis

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-time-stamp-10.txt
Date: Fri, 13 Oct 2000 06:34: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 
                          Time Stamp Protocols (TSP)
	Author(s)	: C. Adams, P. Cain, D. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-10.txt
	Pages		: 24
	Date		: 12-Oct-00
	
A time stamping service allows to prove that a datum existed before 
a particular time. This document describes the format of a request 
sent to a Time Stamping Authority (TSA) and of the response that is 
returned. It also establishes several security-relevant requirements 
for TSA operation, with regards to processing requests to generate 
responses. A TSA may be operated as a Trusted Third Party (TTP) 
service, though other operational models may be appropriate, e.g. an 
organization might require a TSA for internal time stamping purposes. 

Non-repudiation services [ISONR] require the ability to establish the 
existence of data before specified times. This protocol may be used as 
a building block to support such services. An example of how to prove 
that a digital signature was generated during the validity period of 
a 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-10.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-10.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-10.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-10.txt

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

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

--OtherAccess--

--NextPart--

From: Peter Sylvester <[email-masked]>
Date: Fri, 13 Oct 2000 12:22:26 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Experimental TSA

> 
> Therefore it's more constructive to see if there's a way to work around these problems, and
> what should be the best way for that, than to simply complain.
> 

I may have been misunderstood, the first part of your statement is the
exact purpose of this discussion of early experiemnts. First, it
helps to identify certain problems, then we can find a way to 
handle this in whatever way. 

As I said, the problem is not in the server: In any case, at least
one message and answer get through. It may be a problem for a client,
if the client first wait for the connection to end before treating
a response, or client must not assume that the connection will
be closed by the server. That's all what I think needs to be 
understood.  

Date: Fri, 13 Oct 2000 12:00:46 +0200
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: ietf-pkix <[email-masked]>
Subject: Re: Experimental TSA

Peter Sylvester wrote:

>   Section 5 of the [RFC2510] spec specifies sending the DER-encoded
>   CMP message directly over various protocols. However, implementors,
>   during various interoperability workshops, found the protocol
>   lacking in the following respects:
>
>   1.    No clear definition on when the connection is to be closed
>         and by whom.
>   2.    No version number specified to allow for extensions.

You can define new values for the request flag, etc...
But it's not very sure how the server that doesn't understand it, will react (close the
connection, send an error message with flag 6 and leave the connection open, etc...)

>   3.    Error messages cannot be processed by applications.

Answer with flag value "6" is an error message.
The error message can be also in the status.

>   At least we have the SAME situation as in 1. here in this discussion.

About the same. A separate RFC for that would be better of course.

> > The client just has to check if the connexion is still open before sending the second
> > message.
> This is normal error handling.

That's my point.

Most of the "problems" that occurs in that case are things that _could_ also happen if the
protocol did define whether there will be several messages or not.

The only actual difference is that the server has to wait a time-out interval after sending
the answer, so some ressources are used a little more than necessary.
Under normal circumstances , I think this time-out interval could be something around 10 or
20 seconds.
I don't believe this is the performance bottle-neck of the server, if it's properly
configured with a large number of sockets.

I'm not saying the protocol is perfect.

I just think that from the previous discussion it is clear there will be no major chance in
the draft anymore.

Therefore it's more constructive to see if there's a way to work around these problems, and
what should be the best way for that, than to simply complain.

Date: Fri, 13 Oct 2000 10:07:27 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: The future of DVCS...

Carlisle,

My comments are along the lines.

> Hi Denis,
 
 (...some text deleted...)

>> I agree that more clearly-defined subsets of the DVCS functionality
>> should be handled by these other protocols (TSP, OCSP, etc.) .. 
>> but this also means that this subset is not the right direction for 
>> the long run and thus should be deprecated. For that reason, this 
>> subset should *not* be placed in an experimental RFC.

> Actually, this is a very good reason why this subset *should* be placed in
> an Experimental RFC.  

Sorry, I do not see any argument for supporting your assertion.

> These other protocols, which differ in some details
> with what is in DVCS, go on to become standards, whereas our early
> "experimental" work on this same functionality is archived as something
> that was tried but not standardized.

(text deleted) 
 
> Actually, this again *is* a good argument for saving this material in an
> Experimental RFC.  DVCS represents something that was conceived,
> discussed, and implemented, but all in quite limited circles.  When it
> comes time to discuss this sort of topic more broadly, this early
> "experimental" work can perhaps serve as a reasonable starting point for
> that discussion.

(text deleted)
 
> Within the IETF environment, what alternatives are there for preserving
> this work?  As you well know, the only archival documents in IETF are
> RFCs, so if we all agree that DVCS is not appropriate for the standards
> track at this time, we are left with Experimental, Informational,
> Historic, and Best Current Practice.  The description for Experimental is
> given in RFC 2026 as follows:
> 
>    The "Experimental" designation typically denotes a specification that
>    is part of some research or development effort.  Such a specification
>    is published for the general information of the Internet technical
>    community and as an archival record of the work, subject only to
>    editorial considerations and to verification that there has been
>    adequate coordination with the standards process (see below).  An
>    Experimental specification may be the output of an organized Internet
>    research effort (e.g., a Research Group of the IRTF), an IETF Working
>    Group, or it may be an individual contribution.
> 
> DVCS was certainly the result of some early research work centering on the
> possible uses of a notarization-type server, and did undergo some limited
> development (i.e., implementation) effort.  It may be useful as a source
> of information on this topic to at least the Internet technical community,
> if not the broader Internet community.  It makes sense to have an archival
> record of this work, especially if this topic may arise again in the
> future.  I see pretty-much an exact fit between DVCS and the stated
> purpose of the Experimental RFC category.

Let me provide a copy of the text in the next following section of RFC 2026:

   To ensure that the non-standards track Experimental and Informational
   designations are not misused to circumvent the Internet Standards
   Process, the IESG and the RFC Editor have agreed that the RFC Editor
   will refer to the IESG any document submitted for Experimental or
   Informational publication which, in the opinion of the RFC Editor,
   may be related to work being done, or expected to be done, within the
   IETF community.  The IESG shall review such a referred document
   within a reasonable period of time, and recommend either that it be
   published as originally submitted or referred to the IETF as a
   contribution to the Internet Standards Process.

   If (a) the IESG recommends that the document be brought within the
   IETF and progressed within the IETF context, but the author declines
   to do so, or (b) the IESG considers that the document proposes
   something that conflicts with, or is actually inimical to, an
   established IETF effort, the document may still be published as an
   Experimental or Informational RFC.  In these cases, however, the IESG
   may insert appropriate "disclaimer" text into the RFC either in or
   immediately following the "Status of this Memo" section in order to
   make the circumstances of its publication clear to readers.

   Documents proposed for Experimental and Informational RFCs by IETF
   Working Groups go through IESG review.  The review is initiated using
   the process described in section 6.1.1.

So the first question is whether this document is proposed for Experimental
and Informational RFCs by some individuals or by the PKIX Working Groups. I
am not supportive of presenting this document as a PKIX WG proposal.

The next point, as far as I understand, is that in any case it will go
through IESG review. Should the document be proposed as an Experimental RFC,
the concerns I have might then be brought to the attention of the IESG.

> Perhaps, however, you are suggested that this document should be preserved
> outside the IETF process.  This can certainly be done, but I must confess
> to having a hard time seeing what value that would serve to the Internet
> community.

All drafts which are submitted do not need to become RFCs (even Experimental
or Informational). There are numerous examples for this. Since it is very
likely that some of the authors of DVCS are going to remain present in the
PKIX working group, parts of this document might be brought up, when
necessary, by one of the authors and alternatively by someone else who saved
the document. Once again, preserving the document does not mandate the
issuance of an Experimental RFC.

> (...substantial and valuable comments deleted for the sake of brevity...)
> 
> Thank you once again for your careful consideration of this document and
> for your thoughtful input.  

:-)

> I skimmed quickly through Peter's responses
> and am in agreement with what I saw there.  But ultimately the question is
> this:  "Is it worth revising this document further, given that it is not
> targeted for the standards track?"  Why don't we simply freeze it as-is
> and call it a day.  I suspect we all have other things we could be working
> on...

I agree we have other things todo. However, pushing the document to
Experimental RFC would *not* save our time. :-)

Denis

> Carlisle.

From: [email-masked]
Date: Fri, 13 Oct 2000 00:08:29 -0400
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Delegated Path Validation draft.

I'm a bit removed from OCSP details these days.  Can an OCSP repsonder
indicate which extensions in the request it didn't like?

Even if this is not possible, I see no reason to remove the CRITICALITY
feature.  A client can always resend without that bit if it decides
the semantics are optional after all.

From: "Manger, James H" <[email-masked]>
To: pkix <[email-masked]>
Subject: RE: AttributeCertificates: Why is the holder DN preferred?
Date: Fri, 13 Oct 2000 10:53:57 +1100

I support making the change.

The separation of names between the 'subject' and 'subjectAltName' fields is
for historical reasons.  These two fields should not be distinguished for
future processing - i.e. together they provide the certificate holder's
names.

----------
From: Stephen Farrell [mailto:[email-masked]]

. if there were consensus that they were important then I'd be ok 
with changing the draft to allow AC.holder.entityName to be compared against

either the PKC.subject or any of the PKC.subjectAltName values.

So, if a bunch of folks want this change, I'd agree to it.

PS: If we made the change, I wouldn't agree to distinguish some types of alt
name
from others (e.g. disallowing ip-address as you suggested), but would treat
all 
equally since that's what the CA put in the PKC.

From: Michael Zolotarev <[email-masked]>
To: Michael Myers <[email-masked]>, [email-masked]
Subject: RE: Delegated Path Validation draft.
Date: Fri, 13 Oct 2000 10:51:47 +1000

> From: Michael Myers [mailto:[email-masked]]
> Sent: Friday, 13 October 2000 6:48
> To: Michael Zolotarev; [email-masked]
> Subject: RE: Delegated Path Validation draft.
> 
> 
> Michael,
> 
> Regarding the criticality flag, in fact I'd rather change 
> 2560's current
> "Support for any specific extension is OPTIONAL. The critical 
> flag SHOULD
> NOT be set for any of them." to SHALL NOT set the criticality flag.  I
> believe this will improve interoperability and reduce 
> confusion with no loss
> of security assurances.  Are there are any criticality flag 
> advocates out
> there who would wish to argue a contrary position?
> 

In my opinion the extentions defined for DPV (and DPD as a matter of fact)
must be marked as critical. The client adds those extensions as an indicator
of the type of service it expects. Leaving those extension non-critical
would be just wrong, equivalent to say "the client wants DPV (not basic
OCSP), but the responder may ingore it". It obviously defeats the purpose.

> I propose to clarify the "omit both fields" requirement to 
> read "If neither
> initialPolicySet nor trustPoints are included in the request, 
> the DPVOptions
> structure SHALL be encoded as an SEQUENCE of zero length 
> (that is, an empty
> sequence)."
> 

Agree.

> And I will give some thought to the instance when a relying 
> party includes
> both initialPolicySet and trustPoints.  In fact, we had 
> talked at length
> about these kind of combinatorics in blocking out the draft, 
> but I wanted
> first to get a sounding from the WG on the overall approach 
> before drilling
> down too deeply.  Minimally, we need an "invalid" response value in
> BasicOCSPResponse to distinguish the case when a certificate 
> isn't revoked
> but fails to validate against OCSP request extension content.
> 

I agree. The client asks the question "Can this cert be validated given that
policy and trust critirea, provided that the cert is NOT 
revoked". Therefore, if any of the conditions fail, the response must be
'invalid'.

However, my original question was what does the server do if both Policy and
Trust components aren't there. I'd assume that the server has two options:
1. Check revocation status and then apply some 'default' implicit policy and
trust points. This would be an option for a pre-configured (i.e.
enterprise-wide) responder.
2. Check revocation status and then discard the request on the basis that
there is no 'implicit' verification context which the server can apply (at
all, or for that particular certificate). In this case the error code can be
either 'invalid', if the cert is revoked, or 'unknown', indicating that the
cert is not revoked, but validation couldn't be executed due to lack of
input conditions.

Michael

Date: Thu, 12 Oct 2000 19:09:46 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Stephen Farrell <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Stephen,

Comments below:

On Thu, 12 Oct 2000, Stephen Farrell wrote:

> 
> Polar,
> 
> Since you choose to quote from that off-list mail, let me complete the
> quote somewhat:
> 
> You wrote:
> 
> > > Help me out here. This one I don't understand? How can another path exist?
> > > The PKIXPROF mandates that the Issuer field of a PKC MUST match a subject
> > > field of the certificate containing the public key that verifies it. That
> > > really mandates just one path up to the RootCA for the holder's identity.
> > > How can a different path exist?
> 
> And I responded:
>  
> > CA1 certifies holder.
> > CA2 certifies CA1.
> > AA trusts CA2 as a "root"
> > CA3 also certifies CA1.
> > RP trusts CA3 as a "root"
> > 
> > Both [CA2,CA2],[CA2,CA1],[CA1,holder] and [CA3,CA3],[CA3,CA1],[CA1,holder]
> > are potentially valid paths, where [x,y] means "x certifies y". Based on their 
> > respective configurations the first path is usable by the AA, the second by 
> > the RP.

Yes, and thank you for clearing up my confusion. And from your response, I
should note, that I concluded the problem was worse than I had originally
imagined. :)

> The bottom line seems to be that you have a different concept of "identity" 
> to that which has been understood in PKIX for the last five years. Your 
> concept of "identity" is the entire sequence of DNs from the end-entity 
> PKC subject field, up to a "root" CA, including all CA names in between. 
> PKIX treats the end entity PKC subject field by itself as an identity

Which means that the DN MUST be globally unique? Is the fact that a single
DN is just NOT empahtiacally guaranteed to point to a unique subject
entity just specifically avoided in arguments for the sake of
functionality, which in this case is *security functionality*?

> (and no, I don't want to start another of those interesting discussions
> about whether this is good or bad!).

Right. We should not be concerned about about the integrity of such an
infrastructure. We should just use what is given to us, whether it is good
or bad. ;^)

And I guess, why not? I have a machine (of which I only use when forced
to) on my desk with an operating system made by a popular software company
that just can't get out of its own way and stop crashing, getting
diseases, etc. I have to use it sometimes because everybody else uses the
same thing and sends me stuff only it can understand. Oh well. I should
just accept this. Okay. It's a market. It's a standard. :)

> I can only guess that this is ultimately why you perceive there to be such 
> a problem, where others don't. 

Your "guess" is correct! At least you recognize my problem with the entire
thing.

What I would like is an answer to the verifiability problem all the way up
the identity chain of the Holder. The PKIXPROF tells you how to verify a
PKC chain. Why does it even bother walking up a chain? All PKIX identities
and public keys should be signed by Verisign and be done with it. :^)

But seriously, the AC draft says nothing other than that when using the
baseCertificateID it must match that of the components of the
authenticated entity's certificate. It's just not enough in the cases of
PKC chains greater than 2. Even the an Issuer UID can be forged in the
holder's PKC along with the DN and the serial number, especially if I am
allowed to have two CA's certify the same certificate as you have pointed
out above.

I don't mind if a single certificate subject field points to one and only
one unique subject entity.  But I cannot ignore, skip, or gloss over the
fact that the DN is just NOT unique in the PKIX space.

I do like Tom's suggestion of being able to use the subjectAltName in
places where uniqueness is a factor, ignoring the subject DN. The problem
is being able to force vendors of AAs to use it. In some cases, where
authentication services are provided by widely disparate CA services and
vendors, mandating such things from AA service vendors may be impossible.

> So, can we leave it there and agree to disagree as to what constitutes
> an "identity"? (I'd *much* rather that than to have to parse & respond 
> to all of your "treatise":-)

Okay. Okay. I wrote something you won't read? I'm defenseless against that
approach.

I just have to tell my customers they can't use such standards and
standard products (at least not without proprietary extensions) and they
will have to use something else for widely scaled e-commerce solutions in
the PKI space.

I guess there is a market for a workable, but inadequate, solution now
with really expensive upgrades later on that fix the problems, albeit
after the attacks, or the screw ups.

"How come I can't get my pizza?" 
"I'm sorry Mr. Smith, you already picked it up!"

> Stephen.
> 
> PS: Can we also drop the huge cc list if there are any more mails on 
> this topic? The AC profile is a PKIX draft - whoever is interested can
> discuss it there.

Surely, now that you've seen my point and my problem with it, let's take
it back to PKIX and the OMG lists. The CC list is for the people I know
are interested and aren't on the lists. I took the iesg off the list.
Hopefully, the concerned parties there are subscribed to the pkix list.

Cheers,
-Polar

> ____________________________________________________________
> 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: [email-masked]
To: [email-masked]
cc: Russ Housley <[email-masked]>, pkix <[email-masked]>
Date: Thu, 12 Oct 2000 18:25:48 -0400
Subject: Re: AttributeCertificates: Why is the holder DN preferred?

     The reason I think that using SubjectAltName might sometimes be
preferred is related to Polar's concern about the adequacy of identities.
IMHO, both e-mail addresses and permanent identifiers are less likely to
have identity conflicts than DN's, while IP addresses and DNS names are
usually adequate identifiers only for devices.  There is also little reason
to prefer a secondary directoryName or x400Name to a subject DN.  I would
not be sure where to put ediPartyName, registeredID, or URI in such an
ordering - the last two are pretty immune from naming conflicts but they
don't usually indicate individuals.
     Using SubjectAltName fields would allow an AA to specify a user by
e-mail address or by PI and let that user use any of his PKC's with that
AC.  The only potential drawback I see is whether that allows an attacker
to get a PKC with a false value in that field from a legitimate CA, but I
hope that if there are others they will be pointed out.
     If this suggestion comes too late in the cycle, so be it.

          Tom Gindin

Stephen Farrell <[email-masked]> on 10/12/2000 05:33:25 PM

Please respond to [email-masked]

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   Russ Housley <[email-masked]>, pkix <[email-masked]>, xme
      <[email-masked]>
Subject:  Re: AttributeCertificates: Why is the holder DN preferred?

Tom,

Sorry, I misinterpreted your mail a bit (being mixed up with figuring out
how
many identities could dance on the subject field of a certificate:-).
You're right
in what you said below, but I think its ok anyway on the following basis:

If a PKC is used to authenticate the holder to the relying party, and that
PKC
contains a non-null subject field, and the AA chose to put the entityName
in on
the basis of that PKC, then there's no reason not to just stick with
AC.holder.entityName being compared to PKC.subject.

I guess the (now explicit) assumption in there is that the same PKC (well
at least
the same PKC.subject value) is the basis on which the AA issued the AC and
is also
used for holder to relying party authentication - in which case the subject
field
is available to both, so why not just use it?

I suppose a circumstance where this wouldn't hold would be e.g. where the
holder
uses Keberos to authenticate to the AA, which then produces an AC
containing
the holder's KerberosName in AC.holder.entityName.OTHER-NAME and where the
holder
then uses her PKC to authenticate to the relying party when using the
AC, and where the KerberosName is in PKC.subjectAltName.OTHER-NAME, but
PKC.subject is not empty. I hadn't really considered such "mixed"
authentication
schemes, but if there were consensus that they were important then I'd be
ok
with changing the draft to allow AC.holder.entityName to be compared
against
either the PKC.subject or any of the PKC.subjectAltName values.

So, if a bunch of folks want this change, I'd agree to it. If its not
important
enough right now (which is what I think) then we're ok as is (Russ?).

Stephen

PS: If we made the change, I wouldn't agree to distinguish some types of
alt name
from others (e.g. disallowing ip-address as you suggested), but would treat
all
equally since that's what the CA put in the PKC.

[email-masked] wrote:
>
>      I am not misquoting the draft in any important way.  The third
> paragraph (excluding the note) of section 4.2.2 of your current draft
> begins as follows: "If the holder field uses the entityName option and
the
> underlying authentication is based on a PKC, then the entityName MUST be
> the same as the PKC subject field, unless the PKC subject field contains
an
> empty distinguished name. If the PKC subject field contains an empty
> distinguished name, then the entityName field MUST be identical to one of
> the values of the PKC subjectAltName field extension."  This forbids the
> use of a value from subjectAltName, whether e-mail or PI, as an
entityName
> if the subject DN is present.  The preference for baseCertificateID makes
> the issue somewhat less important, but does not eliminate it.
>      As for PI's (whose draft is -01 rather than -00), I cited them as
one
> of two reasonable global identifiers for a user in SubjectAltName.  I
> understand that you would not want to hold up this draft for that one,
but
> I'm looking for re-wording of this statement to allow SubjectAltName
> components including e-mail, but excluding IP address, DNS name, and
> probably some others.  It might be appropriate to state that the use of
> "OTHER-NAME components specifying the identity of the subject as an
> individual" may be supported as well.
>
>           Tom Gindin
>
> Stephen Farrell <[email-masked]> on 10/12/2000 05:30:30 AM
>
> Please respond to [email-masked]
>
> cc:   Russ Housley <[email-masked]>, pkix <[email-masked]>
> Subject:  Re: AttributeCertificates: Why is the holder DN preferred?
>
> Tom,
>
> I think you're misquoting the draft. basdCertificateID is the SHOULD for
> holder
> when PKCs are used for authentiation. When entityName is used, the text
> tells
> you how it should compare to the subject and/or subjectAltName from the
> PKC. It
> does not say that the PKC must use any particular form of subject naming.
>
> There is no reference to PI since right now that's a -00 draft with who
> know
> what future (bright, I'm sure:-) and the AC profile is in IETF wide last
> call.
>
> Stephen.
>
> [email-masked] wrote:
> >
> >      Russ:
> >
> >      On one subject which is connected to what Polar brought up, I am
> > inclined to think that he is right.  In the AC509Prof draft, section
> 4.2.2
> > states that for PKC-based authentication the entityName MUST be the
same
> as
> > the PKC subject field unless that field is empty.  Why should it be
> > mandatory to prefer the subject DN to either permanent ID's or e-mail
> > addresses, both of which identify individuals in a globally unique way?
> > Name collisions are more likely in the DN space than in either of the
> other
> > two, except for PI's with a default assignment authority, and PI's of
> that
> > sort should be forbidden as entityName's.  This does not imply that
most
> of
> > the options within GeneralName are appropriate as entityName's, as I
> don't
> > think they are.
> >
> >           Tom Gindin
> >
> > Russ Housley <[email-masked]> on 10/11/2000 01:50:42 PM
> >
> > cc:   Al Arsenault <[email-masked]>, Stephen Farrell
> >       <[email-masked]>, Patrik F�ltstr�m <[email-masked]>,
> >       [email-masked], [email-masked], Thumrongsak Kosiyatrakul
> >       <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan
> >       Older <[email-masked]>
> > Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> Targets
> >       andProxies
> >
> > Polar:
> >
> > > > Okay, I think I finally figured out what Polar is getting at here,
> but
> > > > I'm not sure what the fix is.  Let me try to illustrate with an
> > example.
> > > >
> > > > (We'll be picking on Stephen a little bit in this; nothing personal
> > > > intended; apologies for any offense.  :-)
> > > >
> > > > Suppose that there's a legitimate root CA with DN "C=IE,
O=Baltimore
> > > > Technologies, OU=Public CAs, CN=The CA".
> > > > That CA has a self signed certificate with subject and issuer both
> > equal
> > > > to the DN above.
> > > >
> > > > Now, there is an end-user certificate issued under that CA.  The
> issuer
> > > > field of that certificate will be the DN above; the subject field
is
> > > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > > > CN=Stephen".
> > > >
> > > > The serial number field will be something like "4434".
> > > >
> > > > Now, an attribute authority has issued our friend Stephen an AC
> > > > consistent with the proposed profile.  The "Holder" field in that
AC
> > can
> > > > be one of three things, according to the proposed profile:
> > > >
> > > >       - it can be the issuer and serial number of the base PKC;
that
> is
> > > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> > > >
> > > >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> > > >
> > > >       - it can be an ObjectDigest - for which the I-D does not
> require
> > > > support.
> > >
> > >I think the ObjectDigest is truly the only way to go. However, it
still
> > >has problems. The object that is talked about must be able to be
> recalled
> > >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
> > >delivered with the Holder's Public Key Certificate.
> > >
> > >I don't believe that requiring the delivery of the Holders certificate
> is
> > >unreasonable. Can something like this be mandated in this profile? I
> don't
> > >see how. I only see that in specific protocols. Or am I wrong?
> >
> > PKCs bind a public key to an identity.
> >
> > ACs bind attributes to an identity.
> >
> > Authentication, which includes validating the PKC certification path
and
> > having the remote party perform some operation that involves the
private
> > key associated with the identity.  Without authentication of the
> identity,
> > who cares what attributes are associated with it?
> >
> > Russ
>
> --
> ____________________________________________________________
> 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

--
____________________________________________________________
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, 12 Oct 2000 22:33:25 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: Russ Housley <[email-masked]>, pkix <[email-masked]>, xme <[email-masked]>
Subject: Re: AttributeCertificates: Why is the holder DN preferred?

Tom,

Sorry, I misinterpreted your mail a bit (being mixed up with figuring out how 
many identities could dance on the subject field of a certificate:-). You're right 
in what you said below, but I think its ok anyway on the following basis:

If a PKC is used to authenticate the holder to the relying party, and that PKC 
contains a non-null subject field, and the AA chose to put the entityName in on 
the basis of that PKC, then there's no reason not to just stick with 
AC.holder.entityName being compared to PKC.subject.

I guess the (now explicit) assumption in there is that the same PKC (well at least
the same PKC.subject value) is the basis on which the AA issued the AC and is also
used for holder to relying party authentication - in which case the subject field 
is available to both, so why not just use it? 

I suppose a circumstance where this wouldn't hold would be e.g. where the holder
uses Keberos to authenticate to the AA, which then produces an AC containing 
the holder's KerberosName in AC.holder.entityName.OTHER-NAME and where the holder
then uses her PKC to authenticate to the relying party when using the
AC, and where the KerberosName is in PKC.subjectAltName.OTHER-NAME, but 
PKC.subject is not empty. I hadn't really considered such "mixed" authentication 
schemes, but if there were consensus that they were important then I'd be ok 
with changing the draft to allow AC.holder.entityName to be compared against 
either the PKC.subject or any of the PKC.subjectAltName values.

So, if a bunch of folks want this change, I'd agree to it. If its not important 
enough right now (which is what I think) then we're ok as is (Russ?).

Stephen

PS: If we made the change, I wouldn't agree to distinguish some types of alt name
from others (e.g. disallowing ip-address as you suggested), but would treat all 
equally since that's what the CA put in the PKC.

[email-masked] wrote:
> 
>      I am not misquoting the draft in any important way.  The third
> paragraph (excluding the note) of section 4.2.2 of your current draft
> begins as follows: "If the holder field uses the entityName option and the
> underlying authentication is based on a PKC, then the entityName MUST be
> the same as the PKC subject field, unless the PKC subject field contains an
> empty distinguished name. If the PKC subject field contains an empty
> distinguished name, then the entityName field MUST be identical to one of
> the values of the PKC subjectAltName field extension."  This forbids the
> use of a value from subjectAltName, whether e-mail or PI, as an entityName
> if the subject DN is present.  The preference for baseCertificateID makes
> the issue somewhat less important, but does not eliminate it.
>      As for PI's (whose draft is -01 rather than -00), I cited them as one
> of two reasonable global identifiers for a user in SubjectAltName.  I
> understand that you would not want to hold up this draft for that one, but
> I'm looking for re-wording of this statement to allow SubjectAltName
> components including e-mail, but excluding IP address, DNS name, and
> probably some others.  It might be appropriate to state that the use of
> "OTHER-NAME components specifying the identity of the subject as an
> individual" may be supported as well.
> 
>           Tom Gindin
> 
> Stephen Farrell <[email-masked]> on 10/12/2000 05:30:30 AM
> 
> Please respond to [email-masked]
> 
> cc:   Russ Housley <[email-masked]>, pkix <[email-masked]>
> Subject:  Re: AttributeCertificates: Why is the holder DN preferred?
> 
> Tom,
> 
> I think you're misquoting the draft. basdCertificateID is the SHOULD for
> holder
> when PKCs are used for authentiation. When entityName is used, the text
> tells
> you how it should compare to the subject and/or subjectAltName from the
> PKC. It
> does not say that the PKC must use any particular form of subject naming.
> 
> There is no reference to PI since right now that's a -00 draft with who
> know
> what future (bright, I'm sure:-) and the AC profile is in IETF wide last
> call.
> 
> Stephen.
> 
> [email-masked] wrote:
> >
> >      Russ:
> >
> >      On one subject which is connected to what Polar brought up, I am
> > inclined to think that he is right.  In the AC509Prof draft, section
> 4.2.2
> > states that for PKC-based authentication the entityName MUST be the same
> as
> > the PKC subject field unless that field is empty.  Why should it be
> > mandatory to prefer the subject DN to either permanent ID's or e-mail
> > addresses, both of which identify individuals in a globally unique way?
> > Name collisions are more likely in the DN space than in either of the
> other
> > two, except for PI's with a default assignment authority, and PI's of
> that
> > sort should be forbidden as entityName's.  This does not imply that most
> of
> > the options within GeneralName are appropriate as entityName's, as I
> don't
> > think they are.
> >
> >           Tom Gindin
> >
> > Russ Housley <[email-masked]> on 10/11/2000 01:50:42 PM
> >
> > cc:   Al Arsenault <[email-masked]>, Stephen Farrell
> >       <[email-masked]>, Patrik F�ltstr�m <[email-masked]>,
> >       [email-masked], [email-masked], Thumrongsak Kosiyatrakul
> >       <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan
> >       Older <[email-masked]>
> > Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> Targets
> >       andProxies
> >
> > Polar:
> >
> > > > Okay, I think I finally figured out what Polar is getting at here,
> but
> > > > I'm not sure what the fix is.  Let me try to illustrate with an
> > example.
> > > >
> > > > (We'll be picking on Stephen a little bit in this; nothing personal
> > > > intended; apologies for any offense.  :-)
> > > >
> > > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > > > Technologies, OU=Public CAs, CN=The CA".
> > > > That CA has a self signed certificate with subject and issuer both
> > equal
> > > > to the DN above.
> > > >
> > > > Now, there is an end-user certificate issued under that CA.  The
> issuer
> > > > field of that certificate will be the DN above; the subject field is
> > > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > > > CN=Stephen".
> > > >
> > > > The serial number field will be something like "4434".
> > > >
> > > > Now, an attribute authority has issued our friend Stephen an AC
> > > > consistent with the proposed profile.  The "Holder" field in that AC
> > can
> > > > be one of three things, according to the proposed profile:
> > > >
> > > >       - it can be the issuer and serial number of the base PKC; that
> is
> > > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> > > >
> > > >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> > > >
> > > >       - it can be an ObjectDigest - for which the I-D does not
> require
> > > > support.
> > >
> > >I think the ObjectDigest is truly the only way to go. However, it still
> > >has problems. The object that is talked about must be able to be
> recalled
> > >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
> > >delivered with the Holder's Public Key Certificate.
> > >
> > >I don't believe that requiring the delivery of the Holders certificate
> is
> > >unreasonable. Can something like this be mandated in this profile? I
> don't
> > >see how. I only see that in specific protocols. Or am I wrong?
> >
> > PKCs bind a public key to an identity.
> >
> > ACs bind attributes to an identity.
> >
> > Authentication, which includes validating the PKC certification path and
> > having the remote party perform some operation that involves the private
> > key associated with the identity.  Without authentication of the
> identity,
> > who cares what attributes are associated with it?
> >
> > Russ
> 
> --
> ____________________________________________________________
> 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

-- 
____________________________________________________________
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, 12 Oct 2000 22:12:32 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Polar Humenn <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, John Propper <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>, xme <[email-masked]>
Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

Polar,

Since you choose to quote from that off-list mail, let me complete the
quote somewhat:

You wrote:

> > Help me out here. This one I don't understand? How can another path exist?
> > The PKIXPROF mandates that the Issuer field of a PKC MUST match a subject
> > field of the certificate containing the public key that verifies it. That
> > really mandates just one path up to the RootCA for the holder's identity.
> > How can a different path exist?

And I responded:
 
> CA1 certifies holder.
> CA2 certifies CA1.
> AA trusts CA2 as a "root"
> CA3 also certifies CA1.
> RP trusts CA3 as a "root"
> 
> Both [CA2,CA2],[CA2,CA1],[CA1,holder] and [CA3,CA3],[CA3,CA1],[CA1,holder]
> are potentially valid paths, where [x,y] means "x certifies y". Based on their 
> respective configurations the first path is usable by the AA, the second by 
> the RP.

The bottom line seems to be that you have a different concept of "identity" 
to that which has been understood in PKIX for the last five years. Your 
concept of "identity" is the entire sequence of DNs from the end-entity 
PKC subject field, up to a "root" CA, including all CA names in between. 
PKIX treats the end entity PKC subject field by itself as an identity
(and no, I don't want to start another of those interesting discussions
about whether this is good or bad!).

I can only guess that this is ultimately why you percieve there to be such 
a problem, where others don't. 

So, can we leave it there and agree to disagree as to what consitutes
an "identity"? (I'd *much* rather that than to have to parse & respond 
to all of your "treatise":-)

Stephen.

PS: Can we also drop the huge cc list if there are any more mails on 
this topic? The AC profile is a PKIX draft - whoever's interested can
discuss it there.

-- 
____________________________________________________________
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: Michael Myers <[email-masked]>
To: Michael Zolotarev <[email-masked]>, [email-masked]
Subject: RE: Delegated Path Validation draft.
Date: Thu, 12 Oct 2000 13:47:45 -0700

Michael,

Regarding the criticality flag, in fact I'd rather change 2560's current
"Support for any specific extension is OPTIONAL. The critical flag SHOULD
NOT be set for any of them." to SHALL NOT set the criticality flag.  I
believe this will improve interoperability and reduce confusion with no loss
of security assurances.  Are there are any criticality flag advocates out
there who would wish to argue a contrary position?

I propose to clarify the "omit both fields" requirement to read "If neither
initialPolicySet nor trustPoints are included in the request, the DPVOptions
structure SHALL be encoded as an SEQUENCE of zero length (that is, an empty
sequence)."

And I will give some thought to the instance when a relying party includes
both initialPolicySet and trustPoints.  In fact, we had talked at length
about these kind of combinatorics in blocking out the draft, but I wanted
first to get a sounding from the WG on the overall approach before drilling
down too deeply.  Minimally, we need an "invalid" response value in
BasicOCSPResponse to distinguish the case when a certificate isn't revoked
but fails to validate against OCSP request extension content.

Mike

Date: Thu, 12 Oct 2000 16:14:57 -0400
To: "pkix" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: FYI: SHA-2, AES

FYI,

NIST has just posted a white paper that specifies hashing algorithms 
(SHA-256, SHA-384, and SHA-512) that are intended to provide security 
similar to that of the three AES key sizes. Information can be found at 
<http://www.nist.gov/sha/>.

These algorithms "will be proposed in a draft Federal Information 
Processing Standard (FIPS) in 2001. These algorithms are being made 
available for information purposes prior to the publication of the draft 
FIPS. SHA-256 is a 256-bit hash function that is intended to provide 128 
bits of security against collision attacks, and SHA-512 is a 512-bit hash 
function that is intended to provide 256 bits of security. A 384-bit hash 
may be obtained by truncating the SHA-512 output."

The web site has the NIST contact points.

One side note about AES: http://csrc.nist.gov/csor/algorithms.htm contains 
the object identifiers and ASN.1 type definitions for AES parameters for 
protocols built on ASN.1.  The OIDs for the new hash algorithms will follow 
next week.

Thanks,

Tim Polk

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, "pkix" <[email-masked]>
Subject: Re: AttributeCertificates: Why is the holder DN preferred?
Date: Thu, 12 Oct 2000 23:01:27 +0200

Tom,
I think you addressed  a somewhat bigger issue:
The relationship between Subject DN and SubjectAltName.
I.e. where should the poor RP look for identity information?
Unfortunately PIs and the PKIX-recommended place to put e-mail addresses
makes this even mory fuzzy.

/Anders

-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Russ Housley <[email-masked]>; pkix <[email-masked]>
Date: Thursday, October 12, 2000 20:31
Subject: Re: AttributeCertificates: Why is the holder DN preferred?

>     I am not misquoting the draft in any important way.  The third
>paragraph (excluding the note) of section 4.2.2 of your current draft
>begins as follows: "If the holder field uses the entityName option and the
>underlying authentication is based on a PKC, then the entityName MUST be
>the same as the PKC subject field, unless the PKC subject field contains an
>empty distinguished name. If the PKC subject field contains an empty
>distinguished name, then the entityName field MUST be identical to one of
>the values of the PKC subjectAltName field extension."  This forbids the
>use of a value from subjectAltName, whether e-mail or PI, as an entityName
>if the subject DN is present.  The preference for baseCertificateID makes
>the issue somewhat less important, but does not eliminate it.
>     As for PI's (whose draft is -01 rather than -00), I cited them as one
>of two reasonable global identifiers for a user in SubjectAltName.  I
>understand that you would not want to hold up this draft for that one, but
>I'm looking for re-wording of this statement to allow SubjectAltName
>components including e-mail, but excluding IP address, DNS name, and
>probably some others.  It might be appropriate to state that the use of
>"OTHER-NAME components specifying the identity of the subject as an
>individual" may be supported as well.
>
>          Tom Gindin
>
>Stephen Farrell <[email-masked]> on 10/12/2000 05:30:30 AM
>
>Please respond to [email-masked]
>
>cc:   Russ Housley <[email-masked]>, pkix <[email-masked]>
>Subject:  Re: AttributeCertificates: Why is the holder DN preferred?
>
>
>
>
>Tom,
>
>I think you're misquoting the draft. basdCertificateID is the SHOULD for
>holder
>when PKCs are used for authentiation. When entityName is used, the text
>tells
>you how it should compare to the subject and/or subjectAltName from the
>PKC. It
>does not say that the PKC must use any particular form of subject naming.
>
>There is no reference to PI since right now that's a -00 draft with who
>know
>what future (bright, I'm sure:-) and the AC profile is in IETF wide last
>call.
>
>Stephen.
>
>[email-masked] wrote:
>>
>>      Russ:
>>
>>      On one subject which is connected to what Polar brought up, I am
>> inclined to think that he is right.  In the AC509Prof draft, section
>4.2.2
>> states that for PKC-based authentication the entityName MUST be the same
>as
>> the PKC subject field unless that field is empty.  Why should it be
>> mandatory to prefer the subject DN to either permanent ID's or e-mail
>> addresses, both of which identify individuals in a globally unique way?
>> Name collisions are more likely in the DN space than in either of the
>other
>> two, except for PI's with a default assignment authority, and PI's of
>that
>> sort should be forbidden as entityName's.  This does not imply that most
>of
>> the options within GeneralName are appropriate as entityName's, as I
>don't
>> think they are.
>>
>>           Tom Gindin
>>
>> Russ Housley <[email-masked]> on 10/11/2000 01:50:42 PM
>>
>> cc:   Al Arsenault <[email-masked]>, Stephen Farrell
>>       <[email-masked]>, Patrik F�ltstr�m <[email-masked]>,
>>       [email-masked], [email-masked], Thumrongsak Kosiyatrakul
>>       <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan
>>       Older <[email-masked]>
>> Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders,
>Targets
>>       andProxies
>>
>> Polar:
>>
>> > > Okay, I think I finally figured out what Polar is getting at here,
>but
>> > > I'm not sure what the fix is.  Let me try to illustrate with an
>> example.
>> > >
>> > > (We'll be picking on Stephen a little bit in this; nothing personal
>> > > intended; apologies for any offense.  :-)
>> > >
>> > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
>> > > Technologies, OU=Public CAs, CN=The CA".
>> > > That CA has a self signed certificate with subject and issuer both
>> equal
>> > > to the DN above.
>> > >
>> > > Now, there is an end-user certificate issued under that CA.  The
>issuer
>> > > field of that certificate will be the DN above; the subject field is
>> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
>> > > CN=Stephen".
>> > >
>> > > The serial number field will be something like "4434".
>> > >
>> > > Now, an attribute authority has issued our friend Stephen an AC
>> > > consistent with the proposed profile.  The "Holder" field in that AC
>> can
>> > > be one of three things, according to the proposed profile:
>> > >
>> > >       - it can be the issuer and serial number of the base PKC; that
>is
>> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
>> > >
>> > >       - it can be the entity name, which by the I-D MUST be "C=IE,
>> > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
>> > >
>> > >       - it can be an ObjectDigest - for which the I-D does not
>require
>> > > support.
>> >
>> >I think the ObjectDigest is truly the only way to go. However, it still
>> >has problems. The object that is talked about must be able to be
>recalled
>> >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
>> >delivered with the Holder's Public Key Certificate.
>> >
>> >I don't believe that requiring the delivery of the Holders certificate
>is
>> >unreasonable. Can something like this be mandated in this profile? I
>don't
>> >see how. I only see that in specific protocols. Or am I wrong?
>>
>> PKCs bind a public key to an identity.
>>
>> ACs bind attributes to an identity.
>>
>> Authentication, which includes validating the PKC certification path and
>> having the remote party perform some operation that involves the private
>> key associated with the identity.  Without authentication of the
>identity,
>> who cares what attributes are associated with it?
>>
>> Russ
>
>--
>____________________________________________________________
>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, 12 Oct 2000 15:21:55 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
cc: Stephen McConnell <[email-masked]>, Kent Salmond <[email-masked]>, Ken Mccoy <[email-masked]>, John Propper <[email-masked]>, Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Comments on draft-ietf-pkix-ac509prof-05.txt

This message is from Polar Humenn from Adiron, LLC; Syracuse University;
and the Object Management Group(OMG) Security SIG.

Greetings IETF, PKIX WG, OMG Security SIG, and OMG E-Commerce DTF:

I have analyzed the X.509 Attribute Certificate Draft Specification and
have come to the conclusion that a glaring problem exists. The problem
relates to the verification that the Relying Party(RP) carries out on the
Attribute Certificate(AC) issued by an Attribute Authority(AA) for a
particular subject entity. This problem exists in the case when the
subject entity is represented by a chain of Public Key Certificates (PKC),
such as in, but not limited to, SSL or TLS.

I also state a recommendation of the creation and use of the AC's in their
current form, draft-ietf-pkix-ac509prof-05.txt, for systems in which
verification of that AC belongs to particular subject entity is paramount.

The Problem:

Only the least significant part of the AC's Holder's Identity is present
in the AC.

This anomally is a problem, because it allows impostors or coincidental
bystanders to reap the privileges certified in the AC.

Several Certificate Authorities(CA) may create subject entities with any
DN they choose. An ATTACK may be levied against an RP by virtue of knowing
(or sniffing) the fact that an AC was issued in a particular Holder's DN.
The only prevention against such an attack is that the AA and the RP agree
on common trust points (trusted CA) for verification of the PKCs used to
reference the Holder at the AA, and authenticate the Holder at the RP.
Also the Holder's certificate chain length MUST be no greater than 2 and
that the DN spaces underneath each trusted CA the AA and RP agree on MUST
be distinct.

On The Distinctness of DN space:

In the following treatise, DN's are represented by single words, such as
CA1 and DN1. A DN path from most significant to least significant is
represented as DNs separated by colons (:), such as CA1:DN1. 

In the case where CA1 and CA2 are Certificate Authorities and they certify
names in a common DN space, name collisions can exist. [Note: There is no
mandate that either CA1 or CA2 know anything about each others name
spaces]. 

The problem is that if the AA certifies privileges for CA1:DN1, only DN1
goes in the AC. If the RP gets an authentication from CA2:DN1 (which is a
different subject entity). The AC WRONGFULLY applies. The AA did NOT issue
CA2:DN1 the privileges, it issued them to CA1:DN1.

The structure of DN's will NOT solve this problem, since there is no
mandated relationship between an Issuer's DN and a Subject's DN in a
Public Key Certificate. i.e. there is no relationship between the internal
structure of CA1 and the internal structure of DN1. Therefore, no
implication can be made as to the Holder's Issuer's name from the Holder's
DN alone.

This problem is tantamount considering 1234 and 3214 equal numbers. This
problem is also tantamount to ordering and paying for a pizza under credit
card 2132 2323 3343 3433 and letting anybody with a credit card xxxx xxxx
xxxx 3433 pick it up.

This situation DOES NOT lend itself to a GOOD E-commerce model.

It is also said that the following scenario is desirable and should be
supported:

The following scenario is attributed to Stephen Farrell from an email I
received from him:

> CA1 certifies holder.
> CA2 certifies CA1.
> AA trusts CA2 as a "root"
> CA3 also certifies CA1.
> RP trusts CA3 as a "root"

> Both [CA2,CA2],[CA2,CA1],[CA1,holder] and
> [CA3,CA3],[CA3,CA1],[CA1,holder] are potentially valid paths, where
> [x,y] means "x certifies y". Based on their respective configurations
> the first path is usable by the AA, the second by the RP.

In this case, the RP has no idea what the AA certified. Does
CA2:CA1:Holder really the same as CA3:CA1:Holder?

The RP would have to know that some cross certification is possible, i.e.
that actually AA was using CA2:CA1 for referencing Holder. This is
impossible and cannot be verified unless the RP has intimate knowledge of
the AA.

Using the baseCertificateID IssuerSerial form of the Holder in the AC:

Using the baseCertificateID IssuerSerial form of the AC Holder just pushes
the problem up one level because the Issuer is only named by a single DN,
and not a path from its root CA. If it is NOT the case that the Issuer is
a common trust point for the AA and the RP and they agree that the DN
references the same certificate, verification of the AC with respect to
the Holder's certificate serial number cannot even be performed.

If the Holder is defined by a CA that is two levels deep, verification of
the AC with respect to the Holder certificate serial number cannot be
performed. Attacks can now be enumerated by creating certificate chains
with bogus PKCs with serial numbers and the Issuer's DN.

Widely Scaled E-COMMERCE Model:

This model for E-COMMERCE should be able to be supported by an AA and RP.

The RP sells Pizza. 
A user labeled by a PKC chain of RootCA1:CA2:Batman wants to buy a pizza.
He contacts the RP's AA, pays for the pizza, and the AA creates an AC with
attributes telling the RP that a pizza has been purchased.

Note that this can be an pseudo anonymous process. In this process, the AA
authenticates Batman all the way up to the RootCA1. It is not the job of
the AA to care if the RootCA1 is a trusted entity of the AA. The AA for
the purposes of collecting money trusts all Root CA's only for the purpose
of authentication. There is just an agreement between the AA and the RP
that whatever identity certificate chain is presented to the AA, verifies
to a root. The AA and RP don't care who it is or who certified it, just
that the entity paid for a pizza, AND that the same entity that paid for
the pizza walks out with the pizza.

Unfortunately, the standard X.509 AC only contains the Holder as "Batman".

RootCA1:CA2:Batman authenticates to the RP to pick up a pizza. The AC
(either delivered by Batman, or gotten from some directory) verifies in
this case and Batman gets his pizza.

ALSO: 

If RootCA2:CA43:CA33:Batman authenticates to the RP and orders a pizza,
without going to the AA first. The AC verifies and he, THE WRONG BATMAN,
gets a pizza.

This is tantamount to a standard college prank, of which this Attribute
Certificate Model as it stands, cannot prevent.

For this scenario to work without common trusted CA certificates between
the AA and RP, the AC needs to contain the entire DN path from the RootCA
to the Holder, AND it MUST contain a hash of the Holder's RootCA
certificate to prove that the same certificate chain presented to the AA
was presented to the RP.

Recommendation for Verifiability of the X.509 AC:

Aside from HIGHLY CONSTRAINED environments, where agreements between AAs
and RPs go down into intimate details, there is only one Profile that can
breed VERIFIABLE trust that the AA actually certified the subject entity
the RP is dealing with:

Verifiable Profile;
1. The AA MUST use the baseCertificateID IssuerSerial form of the Holder.
2. The AA and RP must agree that ANY Issuer Name in the 
   baseCertificateID field resolves to the SAME certificate 
   in their respective repositories,i.e. Common Trust Points. 
   That is, any verification chain of a Holder's PKC cannot
   be greater than 1 from any trust point common to both the AA and the
   RP.
3. The RP MUST reject any AC for which the AA and RP have not 
   emphatically agreed on to be a common trust point, even if
   the RP can locate the Issuer's certificate via the DN in the
   baseCertificateID field of the AC.

This solution does not scale well. The AA and RP must communicate
agreements on common trust points.

Requirement 1 is unfortunate because that may require a lookup at the RP
and keep and it definitely ties the AC to the subject entity's
certificate. This effect is undesirable especially in the case of key
rollover, where a new PKC with a different serial number is issued.

The reliance on common trust points severely limits the use of the AC in
widely scaled environments.

Recommendation to the OMG, Security SIG, and E-Commerce Groups;

The OMG Security Protocol (CSIv2) has stated that the IETF AC X.509
Profile be used for it's delivery of privilege information. I only can
recommend that the above Recommendation for Verifiability be followed for
CORBA and EJB systems that use X.509AC, or that the OMG Security Group
fashions its own X.509 Profile with new attribute extensions solving the
problem of verification of X.509 AC, or it creates a new privilege
certificate altogether.

Sincerely,
Polar Humenn

From: [email-masked]
To: [email-masked]
cc: Russ Housley <[email-masked]>, pkix <[email-masked]>
Date: Thu, 12 Oct 2000 14:30:46 -0400
Subject: Re: AttributeCertificates: Why is the holder DN preferred?

     I am not misquoting the draft in any important way.  The third
paragraph (excluding the note) of section 4.2.2 of your current draft
begins as follows: "If the holder field uses the entityName option and the
underlying authentication is based on a PKC, then the entityName MUST be
the same as the PKC subject field, unless the PKC subject field contains an
empty distinguished name. If the PKC subject field contains an empty
distinguished name, then the entityName field MUST be identical to one of
the values of the PKC subjectAltName field extension."  This forbids the
use of a value from subjectAltName, whether e-mail or PI, as an entityName
if the subject DN is present.  The preference for baseCertificateID makes
the issue somewhat less important, but does not eliminate it.
     As for PI's (whose draft is -01 rather than -00), I cited them as one
of two reasonable global identifiers for a user in SubjectAltName.  I
understand that you would not want to hold up this draft for that one, but
I'm looking for re-wording of this statement to allow SubjectAltName
components including e-mail, but excluding IP address, DNS name, and
probably some others.  It might be appropriate to state that the use of
"OTHER-NAME components specifying the identity of the subject as an
individual" may be supported as well.

          Tom Gindin

Stephen Farrell <[email-masked]> on 10/12/2000 05:30:30 AM

Please respond to [email-masked]

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   Russ Housley <[email-masked]>, pkix <[email-masked]>
Subject:  Re: AttributeCertificates: Why is the holder DN preferred?

Tom,

I think you're misquoting the draft. basdCertificateID is the SHOULD for
holder
when PKCs are used for authentiation. When entityName is used, the text
tells
you how it should compare to the subject and/or subjectAltName from the
PKC. It
does not say that the PKC must use any particular form of subject naming.

There is no reference to PI since right now that's a -00 draft with who
know
what future (bright, I'm sure:-) and the AC profile is in IETF wide last
call.

Stephen.

[email-masked] wrote:
>
>      Russ:
>
>      On one subject which is connected to what Polar brought up, I am
> inclined to think that he is right.  In the AC509Prof draft, section
4.2.2
> states that for PKC-based authentication the entityName MUST be the same
as
> the PKC subject field unless that field is empty.  Why should it be
> mandatory to prefer the subject DN to either permanent ID's or e-mail
> addresses, both of which identify individuals in a globally unique way?
> Name collisions are more likely in the DN space than in either of the
other
> two, except for PI's with a default assignment authority, and PI's of
that
> sort should be forbidden as entityName's.  This does not imply that most
of
> the options within GeneralName are appropriate as entityName's, as I
don't
> think they are.
>
>           Tom Gindin
>
> Russ Housley <[email-masked]> on 10/11/2000 01:50:42 PM
>
> cc:   Al Arsenault <[email-masked]>, Stephen Farrell
>       <[email-masked]>, Patrik F�ltstr�m <[email-masked]>,
>       [email-masked], [email-masked], Thumrongsak Kosiyatrakul
>       <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan
>       Older <[email-masked]>
> Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders,
Targets
>       andProxies
>
> Polar:
>
> > > Okay, I think I finally figured out what Polar is getting at here,
but
> > > I'm not sure what the fix is.  Let me try to illustrate with an
> example.
> > >
> > > (We'll be picking on Stephen a little bit in this; nothing personal
> > > intended; apologies for any offense.  :-)
> > >
> > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > > Technologies, OU=Public CAs, CN=The CA".
> > > That CA has a self signed certificate with subject and issuer both
> equal
> > > to the DN above.
> > >
> > > Now, there is an end-user certificate issued under that CA.  The
issuer
> > > field of that certificate will be the DN above; the subject field is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > > CN=Stephen".
> > >
> > > The serial number field will be something like "4434".
> > >
> > > Now, an attribute authority has issued our friend Stephen an AC
> > > consistent with the proposed profile.  The "Holder" field in that AC
> can
> > > be one of three things, according to the proposed profile:
> > >
> > >       - it can be the issuer and serial number of the base PKC; that
is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> > >
> > >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> > >
> > >       - it can be an ObjectDigest - for which the I-D does not
require
> > > support.
> >
> >I think the ObjectDigest is truly the only way to go. However, it still
> >has problems. The object that is talked about must be able to be
recalled
> >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
> >delivered with the Holder's Public Key Certificate.
> >
> >I don't believe that requiring the delivery of the Holders certificate
is
> >unreasonable. Can something like this be mandated in this profile? I
don't
> >see how. I only see that in specific protocols. Or am I wrong?
>
> PKCs bind a public key to an identity.
>
> ACs bind attributes to an identity.
>
> Authentication, which includes validating the PKC certification path and
> having the remote party perform some operation that involves the private
> key associated with the identity.  Without authentication of the
identity,
> who cares what attributes are associated with it?
>
> Russ

--
____________________________________________________________
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, 12 Oct 2000 13:39:44 -0400
To: Carlisle Adams <[email-masked]>, "'Denis Pinkas'" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: RE: The future of DVCS...
Cc: "[email-masked]'" <[email-masked]>, [email-masked]

Carlisle & Denis,

Like Steve, I am comfortable with moving this to Experimental.  I think 
DVCS has run its course, but I don't want to lose the ideas that were 
incorporated into the document.  This strategy permits us to document the 
good ideas in DVCS in more permanent fashion than periodically resubmitting 
the Internet-Draft.

In my opinion, duplication of functionality with standards track documents 
is not an issue.  I assume a "successful" experimental protocol *should* be 
the precursor to standards track RFCs that implement those experimental 
concepts in  a solid and interoperable fashion.   I realize this has 
already occurred to some extent, but there is no need to remove this overlap.

Let's move DVCS to experimental and free up the DVCS editors' time to 
contribute to the standards track documents that will follow.

Tim Polk

From: Peter Sylvester <[email-masked]>
Date: Thu, 12 Oct 2000 19:37:01 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Experimental TSA
Cc: [email-masked]

> 
> Jean-Marc,
> the proposed protocol could be fine but you know
> that the Time Stamp Authority is one for many different clients
> so the protocol is usually decided by the TSA.

> Is very difficult to serve different clients with different protocol ideas.
Indeed. That's why it necessary to discuss possible ambiguities
in protocols. 

> We need more explicit formalization for this kind of extensions.
> 
> And also what about the "denial of service" problems arised from a client which
> doesn't close the connection and let the server waiting indefinitely or in
> the better for a timeout?
This problem is not much different from those that any web server is
faced today. 

You have the same problem when the client opens a connection and doesn't send
data. Does your server has a time out for that? At least it is pretty long >1h,
as far as I can say. :-) 

> Our TSA implementation close the connection after a Token is sent back to
> the client.
It is a simple solution that works. Anyway, it is good to have something
to experiment with. 

Have fun
Peter

From: "Pawling, John" <[email-masked]>
To: "Pawling, John" <[email-masked]>
Subject: v1.8 Certificate Management Library Now Available
Date: Thu, 12 Oct 2000 13:22:51 -0400

All,

Getronics Government Solutions (GGS) (formerly Wang Government Services) has
delivered the Version 1.8 Certificate Management Library (CML).  The v1.8
CML is freely available to everyone from the Fortezza Developers CML Page
<http://www.armadillo.huntsville.al.us/software/certmgmt/index.html>.  

The v1.8 CML is described in the v1.8 CML Application Programming Interface
(API) document.  It implements the 1997 X.509 certification path processing
rules and SDN.706.  It meets the majority of the IETF PKIX RFC 2459
Certificate/CRL Profile requirements.  It (optionally) provides local cache
management functions and (optionally) obtains data objects using the
Lightweight Directory Access Protocol (LDAP).  It can (optionally) be used
in conjunction with the v1.31 Certificate Path Development Library (CPDL)
developed by CygnaCom Solutions, an Entrust Technologies company, to provide
robust certification path building capabilities such as using cross
certificates. The CML has been used to validate X.509 Certificates and
Certificate Revocation Lists (CRL) signed using the Digital Signature
Algorithm (DSA) and RSA.   Further enhancements, ports and testing of the
CML are still in process.  Further releases of the CML will be provided as
significant capabilities are added. 

The following v1.8 CML files are available:
CMLv18win.zip: MS Windows Dynamically Linked Libraries (DLL) 
CML18so.tar.Z: Sun Solaris Libraries 
CML18li.tar.Z: Linux Libraries
CML18sr.tar.Z: Source, including Windows project files 

The aforementioned files and the v1.8 CML API document (CMv1_8api.doc,
CMv1_8api.pdf), test certs (CML18data.zip) and readme.txt files are stored
on the Fortezza Developers CML Page.

The v1.8 CML includes the following enhancements (compared with the v1.71
CML release):

1) Fixed all bugs reported by customers.

2) Tested for MS Windows, Solaris 2.7 and Linux.  On Linux and MS Windows,
we tested the CML with the following crypto capabilities: internal calls to
the internal SHA-1/DSA code; internal calls to RSAREF library; and using the
Crypto++ Crypto Token Interface Libraries (CTIL) with the Crypto++ v3.2
library.  

3) Tested using common v1.3 R4 Enhanced SNACC ASN.1 C Library, v1.8 CTILs
and LIBCERT libraries shared with the v1.8 S/MIME Freeware Library (SFL) and
v1.4 Access Control Library (ACL).  The common, shared libraries are
available from the Fortezza Developer's S/MIME Page
<http://www.armadillo.huntsville.al.us/software/smime>.

4) Enhanced to process all recognized certificate and CRL extensions,
regardless of criticality.

5) Implemented SDN.706 sigOrKMPrivileges and commPrivileges subordination
checks.

6) Corrected processing of v2 subject and issuer unique identifiers.  v1.71
CML incorrectly processed them as if they were key identifiers instead of
distinguished name (DN) qualifiers.

7) Corrected cache/database code so that it stores distribution point CRLs
under a separate entry in the cache/database that is identical to entry from
which the CRL was retrieved.

8) Added name constraints processing for name forms specified in RFC 2459:
rfc822Names, DNS Names and Uniform Resource Identifiers (URI).
directoryName is already supported.  

9) Added support for NULL subject DNs.  (NOTE: Certs with a NULL subject DN
will not be stored in the CML database.)

10) Added support for the RFC 2459 Authority Information Access (AIA)
extension. This includes enhancing the CML to retrieve and check a CRL
identified in an AIA extension by an LDAP address in the URI field.

11) Enhanced CRL retrieval processing.  This includes identification of
Authority Revocation List (ARL) vice CRLs and using the application-provided
distribution points information in the CM_RequestCRLs function.  This
includes enhancing the CML to automatically search the directory for a
current CRL when the current date is later than the nextUpdate field in a
local CRL.  This also includes enhancing the CML to retrieve and check a CRL
identified in a CRLDistributionPoint (CRLDP) extension by an LDAP address in
the URI field.  This also includes the ability to process multiple URI
fields in the CRLDP (especially to handle the case in which the initial URI
field indicates a null server name (LDAP:///...)). 

12) Added support for certificate policy qualifiers as described in RFC
2459.

13) Removal of the C++ SNACC conversion shared library (cmdec_cpp) (the v1.8
CML makes use of the C SNACC ASN.1 Library, but not the C++ SNACC ASN.1
Library).

14) Add CTIL interface shared library (cmctil).

15) Incorporated calls (IFDEFed) to BSAFE v5 library submitted by Secure
Computing Corporation.
  
16) Enhanced CMTool to execute performance testing and memory leak testing.

17) Performed regression testing to ensure that aforementioned enhancements
did not break existing CML functionality.

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

All source code for the CML is being provided at no cost and with no
financial limitations regarding its use and distribution. Organizations can
use the CML without paying any royalties or licensing fees.  The CML was
originally developed by the U.S. Government.  GGS is enhancing and
supporting the CML under contract to the U.S. Government.  The U.S.
Government is furnishing the CML software at no cost to the vendor subject
to the conditions of the CML Public License provided with the CML software.
The CML software is not subject to U.S. Government encryption export
regulations, so it is freely available to everyone.

The v1.8 CML uses the GGS v1.3 R4 Enhanced SNACC ASN.1 Library to
encode/decode objects.  GGS has successfully tested the v1.8 CML with the
SNACC and CTIL DLLs delivered in conjunction with the v1.8 SFL.  Source code
for the GGS-developed CTILs is available from the Fortezza Developer's
S/MIME Page.  The actual crypto libraries are not provided with the CML or
SFL.  They must be independently obtained from the appropriate source.  

The v1.8 CML can be used in conjunction with the v1.31 CPDL to successfully
meet all of the requirements of the Bridge Certification Authority
Demonstration effort which includes cross-certified Entrust, Spyrus and
Motorola v3 certificate domains.  The CML18sr.tar.Z file includes the CPDL
source code and public license.  <http://www.cygnacom.com/cpl> provides more
information regarding the CPDL.

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

All comments regarding the CML source code and documents are welcome. This
CML release announcement was sent to several mail lists, but please send all
messages regarding the CML to the imc-cml mail list ONLY.  Please do not
send messages regarding the CML to any of the IETF mail lists.  We will
respond to all messages sent to the imc-cml mail list.

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

From: Carlisle Adams <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: The future of DVCS...
Date: Thu, 12 Oct 2000 12:18:25 -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_01C03468.0C5257A0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Denis,

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	Thursday, October 12, 2000 3:25 AM
> To: 	Carlisle Adams
> Cc: 	[email-masked]'; [email-masked]'; [email-masked]
> Subject: 	Re: The future of DVCS...
> 
> Carlisle,
> 
> Thank you for posting this E-mail. As explained hereafter, while I agree
> with many of your arguments, I do not share your conclusion.
 
(...some text deleted...)

> > In discussing this protocol with the other authors and with various
> > members of the community, I sense "rough consensus" on two things.
> > Firstly, it makes sense to allow the more clearly-defined subsets of the
> > DVCS functionality to be handled by these other protocols (TSP, OCSP,
> > etc.) since they are relatively well-understood and implementations are
> > already either completed or underway.  
> 
> I agree that more clearly-defined subsets of the DVCS functionality should
> be handled by these other protocols (TSP, OCSP, etc.) .. but this also
> means
> that this subset is not the right direction for the long run and thus
> should
> be deprecated. For that reason, this subset should *not* be placed in an
> experimental RFC.  
 
Actually, this is a very good reason why this subset *should* be placed in
an Experimental RFC.  These other protocols, which differ in some details
with what is in DVCS, go on to become standards, whereas our early
"experimental" work on this same functionality is archived as something that
was tried but not standardized.

> > Secondly, most real-world
> > environments are not yet ready to incorporate notarization functions for
> > other data formats.  This higher-layer purpose of DVCS is perhaps too
> > early as a concept to engage serious review and debate within the wider
> > PKIX group right now.
> 
> I also agree. However, this is not an argument for saving this material in
> an experimental RFC either.
 
Actually, this again *is* a good argument for saving this material in an
Experimental RFC.  DVCS represents something that was conceived, discussed,
and implemented, but all in quite limited circles.  When it comes time to
discuss this sort of topic more broadly, this early "experimental" work can
perhaps serve as a reasonable starting point for that discussion.

> > Furthermore,
> > we are aware of only a single implementation at this time, so any
> > interoperability testing is out of the question, at least at the moment.
> > But enough work has gone into this protocol that letting it expire as an
> > Internet Draft and disappear completely seems inappropriate, especially
> if
> > (as we suspect) this higher-layer functionality will begin to be
> required
> > in PKI environments in the one- to three-year time frame.  
> 
> The specification can certainly be saved without being transformed as an
> experimental RFC.
 
Within the IETF environment, what alternatives are there for preserving this
work?  As you well know, the only archival documents in IETF are RFCs, so if
we all agree that DVCS is not appropriate for the standards track at this
time, we are left with Experimental, Informational, Historic, and Best
Current Practice.  The description for Experimental is given in RFC 2026 as
follows:

   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  An
   Experimental specification may be the output of an organized Internet
   research effort (e.g., a Research Group of the IRTF), an IETF Working
   Group, or it may be an individual contribution.

DVCS was certainly the result of some early research work centering on the
possible uses of a notarization-type server, and did undergo some limited
development (i.e., implementation) effort.  It may be useful as a source of
information on this topic to at least the Internet technical community, if
not the broader Internet community.  It makes sense to have an archival
record of this work, especially if this topic may arise again in the future.
I see pretty-much an exact fit between DVCS and the stated purpose of the
Experimental RFC category.

Perhaps, however, you are suggested that this document should be preserved
outside the IETF process.  This can certainly be done, but I must confess to
having a hard time seeing what value that would serve to the Internet
community.

> Hereafter are some more technical comments which related to version 06 (I
> have not read the recently posted version 07)
 
(...substantial and valuable comments deleted for the sake of brevity...)

Thank you once again for your careful consideration of this document and for
your thoughtful input.  I skimmed quickly through Peter's responses and am
in agreement with what I saw there.  But ultimately the question is this:
"Is it worth revising this document further, given that it is not targeted
for the standards track?"  Why don't we simply freeze it as-is and call it a
day.  I suspect we all have other things we could be working on...

Carlisle.

------_=_NextPart_001_01C03468.0C5257A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: The future of DVCS...</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Denis,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Denis =
Pinkas[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Thursday, October 12, 2000 3:25 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Carlisle =
Adams</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]'; [email-masked]'; [email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: The future of DVCS...</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carlisle,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thank you for posting this E-mail. As =
explained hereafter, while I agree</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">with many of your arguments, I do not =
share your conclusion.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; In discussing this protocol with =
the other authors and with various</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; members of the community, I =
sense &quot;rough consensus&quot; on two things.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Firstly, it makes sense to allow =
the more clearly-defined subsets of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; DVCS functionality to be handled =
by these other protocols (TSP, OCSP,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; etc.) since they are relatively =
well-understood and implementations are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; already either completed or =
underway.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree that more clearly-defined =
subsets of the DVCS functionality should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be handled by these other protocols =
(TSP, OCSP, etc.) .. but this also means</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that this subset is not the right =
direction for the long run and thus should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be deprecated. For that reason, this =
subset should *not* be placed in an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">experimental RFC.&nbsp; </FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Actually, =
this is a very good reason why this subset *should* be placed in an =
Experimental RFC.&nbsp; These other protocols, which differ in some =
details with what is in DVCS, go on to become standards, whereas our =
early &quot;experimental&quot; work on this same functionality is =
archived as something that was tried but not standardized.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Secondly, most real-world</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; environments are not yet ready =
to incorporate notarization functions for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; other data formats.&nbsp; This =
higher-layer purpose of DVCS is perhaps too</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; early as a concept to engage =
serious review and debate within the wider</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; PKIX group right now.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I also agree. However, this is not an =
argument for saving this material in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">an experimental RFC either.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Actually, =
this again *is* a good argument for saving this material in an =
Experimental RFC.&nbsp; DVCS represents something that was conceived, =
discussed, and implemented, but all in quite limited circles.&nbsp; =
When it comes time to discuss this sort of topic more broadly, this =
early &quot;experimental&quot; work can perhaps serve as a reasonable =
starting point for that discussion.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Furthermore,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; we are aware of only a single =
implementation at this time, so any</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; interoperability testing is out =
of the question, at least at the moment.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; But enough work has gone into =
this protocol that letting it expire as an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Internet Draft and disappear =
completely seems inappropriate, especially if</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; (as we suspect) this =
higher-layer functionality will begin to be required</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; in PKI environments in the one- =
to three-year time frame.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The specification can certainly be =
saved without being transformed as an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">experimental RFC.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Within =
the IETF environment, what alternatives are there for preserving this =
work?&nbsp; As you well know, the only archival documents in IETF are =
RFCs, so if we all agree that DVCS is not appropriate for the standards =
track at this time, we are left with Experimental, Informational, =
Historic, and Best Current Practice.&nbsp; The description for =
Experimental is given in RFC 2026 as follows:</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; The &quot;Experimental&quot; designation typically =
denotes a specification that</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; is part of some research or development =
effort.&nbsp; Such a specification</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; is published for the general information of the =
Internet technical</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; community and as an archival record of the work, =
subject only to</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; editorial considerations and to verification that =
there has been</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; adequate coordination with the standards process =
(see below).&nbsp; An</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; Experimental specification may be the output of an =
organized Internet</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; research effort (e.g., a Research Group of the =
IRTF), an IETF Working</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;&nbsp; Group, or it may be an individual =
contribution.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">DVCS was =
certainly the result of some early research work centering on the =
possible uses of a notarization-type server, and did undergo some =
limited development (i.e., implementation) effort.&nbsp; It may be =
useful as a source of information on this topic to at least the =
Internet technical community, if not the broader Internet =
community.&nbsp; It makes sense to have an archival record of this =
work, especially if this topic may arise again in the future.&nbsp; I =
see pretty-much an exact fit between DVCS and the stated purpose of the =
Experimental RFC category.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Perhaps, =
however, you are suggested that this document should be preserved =
outside the IETF process.&nbsp; This can certainly be done, but I must =
confess to having a hard time seeing what value that would serve to the =
Internet community.</FONT></P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Hereafter are some more technical =
comments which related to version 06 (I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">have not read the recently posted =
version 07)</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">(...substantial and valuable comments deleted for the sake of =
brevity...)</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Thank you =
once again for your careful consideration of this document and for your =
thoughtful input.&nbsp; I skimmed quickly through Peter's responses and =
am in agreement with what I saw there.&nbsp; But ultimately the =
question is this:&nbsp; &quot;Is it worth revising this document =
further, given that it is not targeted for the standards =
track?&quot;&nbsp; Why don't we simply freeze it as-is and call it a =
day.&nbsp; I suspect we all have other things we could be working =
on...</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03468.0C5257A0--

Date: Thu, 12 Oct 2000 17:50:13 +0200
From: Bernd Matthes <[email-masked]>
Reply-To: [email-masked]
Organization: Celo Communications GmbH http://www.celocom.de
To: Kevin White <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: UNSUBSCRIBE

This is a cryptographically signed message in MIME format.

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

> Kevin White wrote:
> 
> I have been looking for messages with unsubscribe instructions, but I
> don't see the instructions on any of the many messages per day that I
> receive.  How do I unsubscribe?
> 
> Thanks,
> 
> Kevin

Hi Kevin!

Try the follow:

Look in a mail header from the list and search for 
"List-Unsubscribe: " and then click on this link.

mailto:[email-masked]?body=unsubscribe

Example:

      List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
           List-ID: <ietf-pkix.imc.org>
  List-Unsubscribe: mailto:[email-masked]?body=unsubscribe

Regards

-- 
Mors certa, hora incerta. In dubio pro mille.
--------------------------------------------------------------------
Bernd Matthes                   Celo Communications GmbH
Senior Software Engineer    	Weissenfelser Strasse 46a   
Nachrichtentechniker            D 06217 Merseburg           
Dipl.-Ing.(FH)                  http://www.celocom.com      
  f. technische Informatik      mailto:[email-masked]   
http://www.worldbug.de          Tel.: +49 3461/3318-0       
mailto:[email-masked]      Fax:  +49 3461/415072
--------------------------------------------------------------------
"When in doubt, use brute force." (Ken Thompson)
--------------ms0B3C5D5CA60D1F31B1B4026C
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

--------------ms0B3C5D5CA60D1F31B1B4026C--

Content-return: allowed
Date: Thu, 12 Oct 2000 08:36:29 -0700
From: Boulos Dib <[email-masked]>
Subject: RE: UNSUBSCRIBE
To: "'Kevin White'" <[email-masked]>, "[email-masked]'" <[email-masked]>

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

--Boundary_(ID_o1Ju8JUl17JURu49bB2/cA)
Content-type: text/plain; charset="iso-8859-1"

Try the "Mailing lists" (  <http://www.ietf.org/maillist.html>
http://www.ietf.org/maillist.html) link on the ietf main page (
<http://www.ietf.org)> http://www.ietf.org)
 
Boulos.

-----Original Message-----
From: Kevin White [mailto:[email-masked]]
Sent: Thursday, October 12, 2000 10:46 AM
To: [email-masked]'
Subject: UNSUBSCRIBE

I have been looking for messages with unsubscribe instructions, but I don't
see the instructions on any of the many messages per day that I receive.
How do I unsubscribe?
 
Thanks,
 
Kevin

--Boundary_(ID_o1Ju8JUl17JURu49bB2/cA)
Content-type: text/html; charset="iso-8859-1"

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

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=936583615-12102000>Try 
the "Mailing lists"&nbsp;(<A href="http://www.ietf.org/maillist.html"><FONT 
size=2><FONT face=Arial>http://www.ietf.org/maillist.html</FONT></FONT></A>) 
link on the ietf main page (<A href="http://www.ietf.org)"><FONT size=2><FONT 
face=Arial>http://www.ietf.org</FONT></FONT>)</A></SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=936583615-12102000>Boulos.</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Kevin White 
  [mailto:[email-masked]]<BR><B>Sent:</B> Thursday, October 12, 2000 10:46 
  AM<BR><B>To:</B> [email-masked]'<BR><B>Subject:</B> 
  UNSUBSCRIBE<BR><BR></DIV></FONT>
  <DIV><SPAN class=550425314-12102000><FONT face=Arial size=2>I have been 
  looking for messages with unsubscribe instructions, but I don't see the 
  instructions on any of the many messages per day that I receive.&nbsp; How do 
  I unsubscribe?</FONT></SPAN></DIV>
  <DIV><SPAN class=550425314-12102000><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=550425314-12102000><FONT face=Arial 
  size=2>Thanks,</FONT></SPAN></DIV>
  <DIV><SPAN class=550425314-12102000><FONT face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=550425314-12102000><FONT face=Arial 
  size=2>Kevin</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_o1Ju8JUl17JURu49bB2/cA)--

From: Peter Sylvester <[email-masked]>
Date: Thu, 12 Oct 2000 16:56:30 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Experimental TSA

> > The TimeStamp protocol  doesn't require to leave the connection open for
> > other possible requests after the first has been processed.

We are not talking about the time stamp protocol, but about transport
protocols that are used to exchange queries and replies. 

> 
> Doesn't require, but doesn't restrain either.
Right.

The question is what happens in clients that have been developped by
the same group that always close a connection. Do these clients just
read the n octects returned and process and then finish, or will they
block, in trying to read data, or?  

> What's more :
>   There is no mandatory transport mechanism for TSA messages in this
>   document.  The mechanisms described below are optional; additional
>   optional mechanisms may be defined in the future.
> 
> > So if you want to send many requests at the time you need to do many connections.
> >
> > We could provide some extension payload to the socket based  protocol
> > to support multiple requests in a single packet (modifying the actual draft, but I
> > do not think this is the right time to do that).
> 
> Nothing restrains the client and the authority to have an agreement to exchange
> several messages in a row in the current proposal.
> The problem is that with the current protocol, the client and the TSA need to agree on
> that out of band.
> 
> This said if we take HTTP 1.1 as an exemple, the server might decide to answer in HTTP
> 1.0 to an HTTP 1.1 request and close the connexion.
> 
> The only difference here is that the client has no way to tell explicitly the TSA that
> he wishes to keep the connexion open after the first message.

Note what had been said in 

      draft-ietf-pkix-cmp-transport-protocols-00.txt

1. Motivation

  Section 5 of the [RFC2510] spec specifies sending the DER-encoded
  CMP message directly over various protocols. However, implementors,
  during various interoperability workshops, found the protocol
  lacking in the following respects:

  1.	No clear definition on when the connection is to be closed
	and by whom.
  2.	No version number specified to allow for extensions.
  3.	Error messages cannot be processed by applications.

  Realizing that this could not be achieved in a backward compatible
  way, and acknowledging the changes being made to [RFC2510], the
  decision was made to enhance the protocol now to avoid
  interoperability conflicts later and to pull the transport section
  out in a separate draft. This enhancement tries to keep as much of
  the older protocol as possible, while ensuring that implementations
  using the old protocol will not mistake a new message for a valid
  message in the [RFC2510] format.

At least we have the SAME situation as in 1. here in this discussion. 

> That means a TSA that's able to handle another request on the same connexion, has to
> leave the connexion open after sending the answer and watch if the client decides to
> close it.
It could leave the connexion open for a certain time, just as in a http
keep alive, or actualy one could implement the technique proposed in the
draft mentioned above. 

It was an error anyway not just simply reference 2510. That's history.
 
> The client just has to check if the connexion is still open before sending the second
> message.
This is normal error handling.

> This seems to me to work quite well, even if it's not as elegant as explicitly telling
> whether there will be several messages or not.

This is similar to the question whether for example pipelining would be allowed
in some way or another. Actually a client can also simply open several channels. 

From: Kevin White <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: UNSUBSCRIBE
Date: Thu, 12 Oct 2000 08:45:57 -0600

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

I have been looking for messages with unsubscribe instructions, but I don't
see the instructions on any of the many messages per day that I receive.
How do I unsubscribe?
 
Thanks,
 
Kevin

------_=_NextPart_001_01C0345C.5E2EACB0
Content-Type: text/html;
	charset="iso-8859-1"

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

<META content="MSHTML 5.50.4207.2601" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=550425314-12102000><FONT face=Arial size=2>I have been looking 
for messages with unsubscribe instructions, but I don't see the instructions on 
any of the many messages per day that I receive.&nbsp; How do I 
unsubscribe?</FONT></SPAN></DIV>
<DIV><SPAN class=550425314-12102000><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=550425314-12102000><FONT face=Arial 
size=2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=550425314-12102000><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=550425314-12102000><FONT face=Arial 
size=2>Kevin</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C0345C.5E2EACB0--

Date: Thu, 12 Oct 2000 16:50:53 +0200
From: Raffaello <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>
CC: [email-masked]
Subject: Re: Experimental TSA

This is a cryptographically signed message in MIME format.

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

Jean-Marc,
the proposed protocol could be fine but you know
that the Time Stamp Authority is one for many different clients
so the protocol is usually decided by the TSA.
Is very difficult to serve different clients with different protocol ideas.

We need more explicit formalization for this kind of extensions.

And also what about the "denial of service" problems arised from a client which
doesn't close the connection and let the server waiting indefinitely or in
the better for a timeout?

Our TSA implementation close the connection after a Token is sent back to
the client.

Raffaello

Jean-Marc Desperrier wrote:

> Raffaello wrote:
>
> > The TimeStamp protocol  doesn't require to leave the connection open for
> > other possible requests after the first has been processed.
>
> Doesn't require, but doesn't restrain either.
>
> What's more :
>   There is no mandatory transport mechanism for TSA messages in this
>   document.  The mechanisms described below are optional; additional
>   optional mechanisms may be defined in the future.
>
> > So if you want to send many requests at the time you need to do many connections.
> >
> > We could provide some extension payload to the socket based  protocol
> > to support multiple requests in a single packet (modifying the actual draft, but I
> > do not think this is the right time to do that).
>
> Nothing restrains the client and the authority to have an agreement to exchange
> several messages in a row in the current proposal.
> The problem is that with the current protocol, the client and the TSA need to agree on
> that out of band.
>
> This said if we take HTTP 1.1 as an exemple, the server might decide to answer in HTTP
> 1.0 to an HTTP 1.1 request and close the connexion.
>
> The only difference here is that the client has no way to tell explicitly the TSA that
> he wishes to keep the connexion open after the first message.
>
> That means a TSA that's able to handle another request on the same connexion, has to
> leave the connexion open after sending the answer and watch if the client decides to
> close it.
>
> The client just has to check if the connexion is still open before sending the second
> message.
>
> This seems to me to work quite well, even if it's not as elegant as explicitly telling
> whether there will be several messages or not.

--------------msE65B2EB52F82D672637224A1
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

--------------msE65B2EB52F82D672637224A1--

Date: Thu, 12 Oct 2000 15:49:26 +0100
From: Pedro Miguel Pereira Borges <[email-masked]>
Reply-To: [email-masked]
Organization: Sociedade =?iso-8859-1?Q?Interbanc=E1ria?= de  =?iso-8859-1?Q?Servi=E7os?=, S.A.
To: [email-masked]
Subject: Attribute Certificates

This is a cryptographically signed message in MIME format.

--------------ms7BBB10FA0D2430FA75F77B56
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

   Hi all :)

   I'm interested in Attribute Certificates and I tried to keep up with
the latest thread but since it was 37 mails long, at some point I was
lost...
   So sorry if this is a re-run :)
   Even so, after reading the latest version, I have some questions that
I hope you can make clearer for me :) :

	-> In section 4.2.3 it's said that all AC Issuers must be identified by
non-empty DNs. It's also said that "it means that the AC Issuer does not
have to know which PKC the verifier will use for it (the AC Issuer).
Using the baseCertificateID field to reference the AC Issuer would mean
that the AC verifier would have to trust the PKC that the AC Issuer
chosed (for itself) at the AC creation time.".
	 =

	   If that is so, then how does the relying party know what AC Issuer
PKC it should use to verify the signature on the AC ?

	-> If the holder is identified using the "entityName" field can you
assure that only the authentic holder can gain access to some resource
and not another party (with an equal DN) ?
	  As far as I know, presenting the AC isn't enough... You also have to
present a proof of possesion (usually the signature of a challenge) of
something that only that identity knows (like the private key
corresponding to the cert's public key)...
	   Am I wrong ?
	   Or, when you use this field, who presents the AC gets the access and
that's it ?

	-> Regarding the previous point, if you use the "objectDigestInfo" of a
public key or cert, you could make that proof of possesion right ?

	-> Are supposing that it's the job of a lower software layer/protocol
to verify/ensure that the AC is being presented by the righteous owner ?
	  If so, do you have any protocol in mind ?

   Thanks in advance,

	Pedro Borges   =

-----------------------------------------------------------------------
Pedro Miguel Pereira Borges                            <[email-masked]>
SIBS - Sociedade Interbanc=E1ria de Servi=E7os, S.A.  <http://www.sibs.pt=
/>
Rua Soeiro Pereira Gomes, Lote 1 - 1649-031 Lisboa, Portugal
Tel: + 351 21 791 88 00                         Fax: + 351 21 794 24 40
Certificate Fingerprint 20:A2:77:C5:15:5E:D7:A2:DF:D5:27:53:4A:99:94:37
-----------------------------------------------------------------------
This message was signed with a certificate issued by MULTICERT SIBS.
To validate the signature you must obtain the 'MULTICERT Pilot'
Certification Authority certificate, at http://www.sibs.multicert.com/
-----------------------------------------------------------------------
--------------ms7BBB10FA0D2430FA75F77B56
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

--------------ms7BBB10FA0D2430FA75F77B56--

Date: Thu, 12 Oct 2000 15:05:41 +0200
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: Re: Experimental TSA

Raffaello wrote:

> The TimeStamp protocol  doesn't require to leave the connection open for
> other possible requests after the first has been processed.

Doesn't require, but doesn't restrain either.

What's more :
  There is no mandatory transport mechanism for TSA messages in this
  document.  The mechanisms described below are optional; additional
  optional mechanisms may be defined in the future.

> So if you want to send many requests at the time you need to do many connections.
>
> We could provide some extension payload to the socket based  protocol
> to support multiple requests in a single packet (modifying the actual draft, but I
> do not think this is the right time to do that).

Nothing restrains the client and the authority to have an agreement to exchange
several messages in a row in the current proposal.
The problem is that with the current protocol, the client and the TSA need to agree on
that out of band.

This said if we take HTTP 1.1 as an exemple, the server might decide to answer in HTTP
1.0 to an HTTP 1.1 request and close the connexion.

The only difference here is that the client has no way to tell explicitly the TSA that
he wishes to keep the connexion open after the first message.

That means a TSA that's able to handle another request on the same connexion, has to
leave the connexion open after sending the answer and watch if the client decides to
close it.

The client just has to check if the connexion is still open before sending the second
message.

This seems to me to work quite well, even if it's not as elegant as explicitly telling
whether there will be several messages or not.

Date: Thu, 12 Oct 2000 14:29:16 +0200
From: Raffaello <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: Experimental TSA

This is a cryptographically signed message in MIME format.

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

Peter,

The TimeStamp protocol  doesn't require to leave the connection open for
other possible requests after the first has been processed.

So if you want to send many requests at the time you need to do many connections.

We could provide some extension payload to the socket based  protocol
to support multiple requests in a single packet (modifying the actual draft, but I
do not
think this is the right time to do that).

Raffaello

Peter Sylvester wrote:

> > Rigth now the only interface available is the socket based protocol defined in
> > the
> > draft-ietf-pkix-time-stamp-09.
> >
>
> Furthermore both implementions close the connection after sending the response.
> This is unfriendly and pretty inefficien if you want to send many requests,
> I am not sure whether this had been intended by the protocol.
>
> The length field at the beginning indicate to the client and to
> the server how many data are transmitted in an exchange.
>
> it seems that the same problem occured in the CMP interoperability tests,
> and this has already resulted in a draft.

--------------msE945F83946DEE6CBEC8DDBDD
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

--------------msE945F83946DEE6CBEC8DDBDD--

From: Peter Sylvester <[email-masked]>
Date: Thu, 12 Oct 2000 12:34:32 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: The future of DVCS...
Cc: [email-masked], [email-masked], [email-masked]

> 
> Carlisle,
> 
> Thank you for posting this E-mail. As explained hereafter, while I agree
> with many of your arguments, I do not share your conclusion.
> 
> > Hi,
> > 
> > Over the past year or more, the question has arisen in various contexts as
> > to the status and role of the DVCS draft, especially with respect to TSP,
> > OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated in
> > the future.
> > 
> > DVCS precedes and, at some level, encompasses all of these other
> > protocols.  However, these protocols -- many of them targeted for the
> > standards track -- have been defined for the twin purposes of simplicity
> > and rapid implementation.  They are small and clearly defined; each one
> > tries to solve essentially one problem.  DVCS, on the other hand, is
> > intended to be general, embracing the sometimes abstract notion of the
> > validation and certification of arbitrary data.  The actual content of the
> > data (the payload) in a sense defines the function of the server (i.e., if
> > the data is a hash of something, then the server is providing a time stamp
> > function; if the data is a certificate, then the server is providing an
> > OCSP or SCVP/DPV function; if the data is a contract or legal document,
> > then the server is providing what (at least in North America) might be
> > called a notarization function; etc.).  It's not quite as loose as that,
> > but that's the basic idea.
> > 
> > In discussing this protocol with the other authors and with various
> > members of the community, I sense "rough consensus" on two things.
> > Firstly, it makes sense to allow the more clearly-defined subsets of the
> > DVCS functionality to be handled by these other protocols (TSP, OCSP,
> > etc.) since they are relatively well-understood and implementations are
> > already either completed or underway.  
> 
> I agree that more clearly-defined subsets of the DVCS functionality should
> be handled by these other protocols (TSP, OCSP, etc.) .. but this also means
> that this subset is not the right direction for the long run and thus should
> be deprecated. For that reason, this subset should *not* be placed in an
> experimental RFC. 

I think you are misunderstanding something: We are talking about putting DVCS
as experimental, and we leave it open to take subsets of functionality of
it into other protocols, i.e. to provide some additional building blocks.
 
> 
> > Secondly, most real-world
> > environments are not yet ready to incorporate notarization functions for
> > other data formats.  This higher-layer purpose of DVCS is perhaps too
> > early as a concept to engage serious review and debate within the wider
> > PKIX group right now.
> 
> I also agree. However, this is not an argument for saving this material in
> an experimental RFC either.
> 
> > Consequently, the authors of DVCS are recommending to the chairs that this
> > specification be preserved as an Experimental RFC.  It has received some
> > discussion (both public and private) over the years, but probably not
> > sufficient to warrant progression along the standards track.  
> 
> I certainly agree that this specification has not received sufficient
> discussion to warrant progression along the standards track.

Thank you for your contributions in the past. Also for thse in this message.

> 
> > Furthermore,
> > we are aware of only a single implementation at this time, so any
> > interoperability testing is out of the question, at least at the moment.
> > But enough work has gone into this protocol that letting it expire as an
> > Internet Draft and disappear completely seems inappropriate, especially if
> > (as we suspect) this higher-layer functionality will begin to be required
> > in PKI environments in the one- to three-year time frame.  
> 
> The specification can certainly be saved without being transformed as an
> experimental RFC.

Yes, one could write a book. why are you against an RFC? 

> 
> > We would like
> > to see the specification frozen and preserved for now; it can always be
> > re-visited later (and even re-targeted for the standards track) if the
> > need arises.
> > 
> > In light of this recommendation, further revisions to this document seem
> > unnecessary; the authors are satisfied with the text in this -07 version
> > going to "Experimental" status.
> 
> Hereafter are some more technical comments which related to version 06 (I
> have not read the recently posted version 07)
There are essentially just a few spelling changes. 
 
> The document covers four different services:
> 
> 1. Certification of possession of data,
> 2. Certification of claim possession of identity,
> 3. Validation of a Digitally signed document,
> 4. Validation of a public key certificate.

Have you really read the text, it says:

   - Certification of Possession of Data (cpd),
   - Certification of Claim of Possession of Data (ccpd),
   - Validation of Digitally Signed Document (vsd), and
   - Validation of Public Key Certificates (vpkc).
> 
> Note that, in the following comments, this services are NOT addressed in the
> same order as they are listed above.

> The second service (Certification of claim possession of identity) can
> simply be obtained using directly a Time Stamping server using the TSP
> protocol, by defining the structure of the whole message that must be hashed
> before it is presented to the TSA. So there is no need to define a new
> protocol, but instead to define a data format, which will basically be
> formed by the concatenation of some information that relates to the entity
> claiming the possession of the data (like first name, family name, home
> address, date of birth, place of birth, and any information able to identify
> unambiguously the entity claiming the possession of the data) and the data
> for which the possession is claimed. Note that there is no need to use any
> ASN.1 construct to do this. While it is recognized that this definition
> would be useful, it may be questioned whether this work should be done in
> the PKIX WG or another group.

There is no such thing as 'claim possession of identity'. It's claim
of possession of data.  

Anyway, you are defining something different. 

The difference of the defined service to time stamping is small,
what is provided is a common way to include in the dvc a reference to
the requestor and a reference to the location of the data, and this is visible in the timestamp.

The time stamp essentially becomes a statement like: 

  "We, the DVCS certify that the person identified as requestor is claiming
  to have a document available under the following URL for we he showed
  a hash at date J."

You can obviously achieve this by adding extensions to time stamping.

You are free to define any format describing 'data to be time stamped'
but this is something else IMHO.

> The first service (Certification of possession of data) is defined as being
> similar to the previous one, except that the full message (e.g. Megabytes)
> is transferred instead of a hash. This is not a desirable feature since the
> performance of such a service would be quite low and because the server
> would be able to know the content of the message, which is not desirable for
> several reasons: privacy reasons or when the content is related to IPR.

On the contrary. The server is a notary, archive server, legal depository or
whatever you want to call it. This is a desirable service, there is a trust
relationship between the notary and the client, the transaction is
be protected by ssl or other means.

> 
> The last (fourth) service (Validation of a public key certificate) is
> closely related to remote path processing, a topic that is being addressed
> by two other specifications. There is still the need to have a single
> protocol to cover that functionality since the PKIX WG cannot afford
> multiple protocols for the same purpose.

DVCS is a different protocol than the OCSP++. I refer to a comment from
Michael Myers, who gave a good caracteristics. The protocols are complementary.  

> 
> The third service (Validation of a Digitally Signed Document) is more
> ambitious than the previous service, since every detail of the format of the
> signature itself will have to be known by the server. This goes behind the
> mathematical correctness of all digital signatures, since it is necessary to
> unambiguously know both which certificate has been used to sign the document
> and at which time. 

The client completely delegates the acceptablity of the document to
a server. Actually, it is not even necessary that the document is a signed
document, 

There is the possibility that no validation of a signature occurs
at all, for example if you validate a dvc 30 years ago. The server has at
least two possibilities, verifying signatures, or looking up an archive
of all dvcs issued. This possibility transforms a chain of trust elements
(in time) into a web. A chain can easily break, a web is much more difficult
to break. 
 
> The validation should not be necessarily made against a single root key.
No one says that. The client may have no idea about roots, trust points or whatever,
it is the server that has that knowledge. A client can also
add certs to the signed document which may be taken as hints by the server.  

> When multiple roots are considered, Certificate Policy (CP) constraints and
> naming constraints are fairly important. They should be able to be defined
> by the requester. When revocation status is looked for, there are cases when
> either CRLs or OCSP responses are adequate or only OCSP responses are
> acceptable. The requester should be able to express his wishes.

The point is to have the requestor as a dumb entity, it is the server who
knows what do do in the context of the application expressed
by a policy identifier. The whole trust management occurs at the server side. 

> 
> The document mentions the possibility to verify all signatures attached to
> the document. This level of complexity would mandate a rather complex
> definition of all the parameters to do this. This appear to be a much longer
> term goal.
The protocol only defined a transaction protocol and a certificate format.
The way how the server is implemented is not specified, only the result, the
dvc should contain a complete list of all actions that had been performed.

> Finally there would be two options: either the server testifies that the
> Digitally Signed Document is well signed and simply provides a signed yes/no
> answer, or does more by providing in addition the proof that led to that
> decision.

Both options are provided. A simple yes/no answer may be given for some
application contexts, but in general it is the idea that a dvc contains
not only a decision, but all elements that have been contributed, in
particular if they cannot easily be reproduced. 

> Conclusion
 
> The first two protocols supporting both "Certification of possession of
> data" and "Certification of claim possession of identity" should not be
> defined. A format describing of the document to be time-stamped should be
> defined instead of providing the second service currently called
> "Certification of claim possession of identity".
Possession of data is a useful service. 

I don't accept the 'INSTEAD of providing the'. You can have both since
these are different things. 

> The third protocol supporting "Validation of a Digitally signed document"
> should be restricted to the verification of a single signature. In order to
> simplify the protocol, the parameters to be presented should be restricted
> to the identification of the "Validation policy" to be used (using an OID to
> refer to that policy) and of the signed message. Note that the Validation
> Policy and a certificate policy are two concepts that should not be
> confused. However more information than the information that was presented
> will usually be needed to be returned, in order to get long term validity of
> the signature, in particular a Time Stamp, a certification path and
> certificate status for every element from that certification path. It is
> proposed to wait until the definition of the RPP service ("Remote Path
> Processing") is stabilized before addressing this level of complexity.
All what you ask for is provided. The requestPolicy defines a validation policy.
The DVC itself contains a time stamp, either provided by itself or by
an external service. The certification path, the certification status, and
all other kinds of OCSP repsonses, crls, dvcs are returned.  

> The last protocol supporting "Validation of a public key certificate" should
> be addressed under the current discussion related to "Remote Path
> Processing" (RPP), so that the WG ends up with a single protocol.
PKIX today says that the result of a cert validation is a verifiable
cert chain, the fact that the exact algorithm for path determination, and
the formats of lookups etc is not defined has not stopped X.509 or 2459.
  
> 
> With the arguments raised above, I am *not* supportive to make this
> specification an experimental RFC.
So be it. 

> Denis
Peter

Date: Thu, 12 Oct 2000 10:30:30 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: Russ Housley <[email-masked]>, pkix <[email-masked]>
Subject: Re: AttributeCertificates: Why is the holder DN preferred?

Tom,

I think you're misquoting the draft. basdCertificateID is the SHOULD for holder
when PKCs are used for authentiation. When entityName is used, the text tells
you how it should compare to the subject and/or subjectAltName from the PKC. It
does not say that the PKC must use any particular form of subject naming.

There is no reference to PI since right now that's a -00 draft with who know
what future (bright, I'm sure:-) and the AC profile is in IETF wide last call. 

Stephen.

[email-masked] wrote:
> 
>      Russ:
> 
>      On one subject which is connected to what Polar brought up, I am
> inclined to think that he is right.  In the AC509Prof draft, section 4.2.2
> states that for PKC-based authentication the entityName MUST be the same as
> the PKC subject field unless that field is empty.  Why should it be
> mandatory to prefer the subject DN to either permanent ID's or e-mail
> addresses, both of which identify individuals in a globally unique way?
> Name collisions are more likely in the DN space than in either of the other
> two, except for PI's with a default assignment authority, and PI's of that
> sort should be forbidden as entityName's.  This does not imply that most of
> the options within GeneralName are appropriate as entityName's, as I don't
> think they are.
> 
>           Tom Gindin
> 
> Russ Housley <[email-masked]> on 10/11/2000 01:50:42 PM
> 
> cc:   Al Arsenault <[email-masked]>, Stephen Farrell
>       <[email-masked]>, Patrik F�ltstr�m <[email-masked]>,
>       [email-masked], [email-masked], Thumrongsak Kosiyatrakul
>       <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan
>       Older <[email-masked]>
> Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
>       andProxies
> 
> Polar:
> 
> > > Okay, I think I finally figured out what Polar is getting at here, but
> > > I'm not sure what the fix is.  Let me try to illustrate with an
> example.
> > >
> > > (We'll be picking on Stephen a little bit in this; nothing personal
> > > intended; apologies for any offense.  :-)
> > >
> > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > > Technologies, OU=Public CAs, CN=The CA".
> > > That CA has a self signed certificate with subject and issuer both
> equal
> > > to the DN above.
> > >
> > > Now, there is an end-user certificate issued under that CA.  The issuer
> > > field of that certificate will be the DN above; the subject field is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > > CN=Stephen".
> > >
> > > The serial number field will be something like "4434".
> > >
> > > Now, an attribute authority has issued our friend Stephen an AC
> > > consistent with the proposed profile.  The "Holder" field in that AC
> can
> > > be one of three things, according to the proposed profile:
> > >
> > >       - it can be the issuer and serial number of the base PKC; that is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> > >
> > >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> > >
> > >       - it can be an ObjectDigest - for which the I-D does not require
> > > support.
> >
> >I think the ObjectDigest is truly the only way to go. However, it still
> >has problems. The object that is talked about must be able to be recalled
> >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
> >delivered with the Holder's Public Key Certificate.
> >
> >I don't believe that requiring the delivery of the Holders certificate is
> >unreasonable. Can something like this be mandated in this profile? I don't
> >see how. I only see that in specific protocols. Or am I wrong?
> 
> PKCs bind a public key to an identity.
> 
> ACs bind attributes to an identity.
> 
> Authentication, which includes validating the PKC certification path and
> having the remote party perform some operation that involves the private
> key associated with the identity.  Without authentication of the identity,
> who cares what attributes are associated with it?
> 
> Russ

-- 
____________________________________________________________
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, 12 Oct 2000 10:53:36 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: The future of DVCS...
Cc: [email-masked]

> 
> Carlisle,
> 
> I think your characterization of DVCS vs. OCSP and SCVP is very 
> accurate and I would be very comfortable with moving it to the 
> experimental track. I would like to hear an affirmation from Peter 
> Sylvester on this.

This had been discussed among the author's and we all seem
to be in violent agreement.  

From: Michael Zolotarev <[email-masked]>
To: [email-masked]
Subject: Delegated Path Validation draft.
Date: Thu, 12 Oct 2000 18:53:58 +1000

A couple of comments.

Should we require the id-pkix-ocsp-valid-req extension to be marked as
critical?

If neither DVPOptions::initialPolicySet nor DVPOptions::trustPoints is
included in the request, the draft says "SHALL omit both optional fields".
This is not clear. Should we include an empty sequence into extension? or
probably a zero-lenght OCTET STRING value?

What should the server do if the both initialPolicySet and trustPoints are
missing? I think the draft should say something about it.

Michael

Date: Thu, 12 Oct 2000 09:25:33 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Carlisle Adams <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: The future of DVCS...

Carlisle,

Thank you for posting this E-mail. As explained hereafter, while I agree
with many of your arguments, I do not share your conclusion.

> Hi,
> 
> Over the past year or more, the question has arisen in various contexts as
> to the status and role of the DVCS draft, especially with respect to TSP,
> OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated in
> the future.
> 
> DVCS precedes and, at some level, encompasses all of these other
> protocols.  However, these protocols -- many of them targeted for the
> standards track -- have been defined for the twin purposes of simplicity
> and rapid implementation.  They are small and clearly defined; each one
> tries to solve essentially one problem.  DVCS, on the other hand, is
> intended to be general, embracing the sometimes abstract notion of the
> validation and certification of arbitrary data.  The actual content of the
> data (the payload) in a sense defines the function of the server (i.e., if
> the data is a hash of something, then the server is providing a time stamp
> function; if the data is a certificate, then the server is providing an
> OCSP or SCVP/DPV function; if the data is a contract or legal document,
> then the server is providing what (at least in North America) might be
> called a notarization function; etc.).  It's not quite as loose as that,
> but that's the basic idea.
> 
> In discussing this protocol with the other authors and with various
> members of the community, I sense "rough consensus" on two things.
> Firstly, it makes sense to allow the more clearly-defined subsets of the
> DVCS functionality to be handled by these other protocols (TSP, OCSP,
> etc.) since they are relatively well-understood and implementations are
> already either completed or underway.  

I agree that more clearly-defined subsets of the DVCS functionality should
be handled by these other protocols (TSP, OCSP, etc.) .. but this also means
that this subset is not the right direction for the long run and thus should
be deprecated. For that reason, this subset should *not* be placed in an
experimental RFC.  

> Secondly, most real-world
> environments are not yet ready to incorporate notarization functions for
> other data formats.  This higher-layer purpose of DVCS is perhaps too
> early as a concept to engage serious review and debate within the wider
> PKIX group right now.

I also agree. However, this is not an argument for saving this material in
an experimental RFC either.

> Consequently, the authors of DVCS are recommending to the chairs that this
> specification be preserved as an Experimental RFC.  It has received some
> discussion (both public and private) over the years, but probably not
> sufficient to warrant progression along the standards track.  

I certainly agree that this specification has not received sufficient
discussion to warrant progression along the standards track.

> Furthermore,
> we are aware of only a single implementation at this time, so any
> interoperability testing is out of the question, at least at the moment.
> But enough work has gone into this protocol that letting it expire as an
> Internet Draft and disappear completely seems inappropriate, especially if
> (as we suspect) this higher-layer functionality will begin to be required
> in PKI environments in the one- to three-year time frame.  

The specification can certainly be saved without being transformed as an
experimental RFC.

> We would like
> to see the specification frozen and preserved for now; it can always be
> re-visited later (and even re-targeted for the standards track) if the
> need arises.
> 
> In light of this recommendation, further revisions to this document seem
> unnecessary; the authors are satisfied with the text in this -07 version
> going to "Experimental" status.

Hereafter are some more technical comments which related to version 06 (I
have not read the recently posted version 07)

The document covers four different services:

1. Certification of possession of data,
2. Certification of claim possession of identity,
3. Validation of a Digitally signed document,
4. Validation of a public key certificate.

Note that, in the following comments, this services are NOT addressed in the
same order as they are listed above.

The second service (Certification of claim possession of identity) can
simply be obtained using directly a Time Stamping server using the TSP
protocol, by defining the structure of the whole message that must be hashed
before it is presented to the TSA. So there is no need to define a new
protocol, but instead to define a data format, which will basically be
formed by the concatenation of some information that relates to the entity
claiming the possession of the data (like first name, family name, home
address, date of birth, place of birth, and any information able to identify
unambiguously the entity claiming the possession of the data) and the data
for which the possession is claimed. Note that there is no need to use any
ASN.1 construct to do this. While it is recognized that this definition
would be useful, it may be questioned whether this work should be done in
the PKIX WG or another group.

The first service (Certification of possession of data) is defined as being
similar to the previous one, except that the full message (e.g. Megabytes)
is transferred instead of a hash. This is not a desirable feature since the
performance of such a service would be quite low and because the server
would be able to know the content of the message, which is not desirable for
several reasons: privacy reasons or when the content is related to IPR.

The last (fourth) service (Validation of a public key certificate) is
closely related to remote path processing, a topic that is being addressed
by two other specifications. There is still the need to have a single
protocol to cover that functionality since the PKIX WG cannot afford
multiple protocols for the same purpose.

The third service (Validation of a Digitally Signed Document) is more
ambitious than the previous service, since every detail of the format of the
signature itself will have to be known by the server. This goes behind the
mathematical correctness of all digital signatures, since it is necessary to
unambiguously know both which certificate has been used to sign the document
and at which time. 

The validation should not be necessarily made against a single root key.
When multiple roots are considered, Certificate Policy (CP) constraints and
naming constraints are fairly important. They should be able to be defined
by the requester. When revocation status is looked for, there are cases when
either CRLs or OCSP responses are adequate or only OCSP responses are
acceptable. The requester should be able to express his wishes.

The document mentions the possibility to verify all signatures attached to
the document. This level of complexity would mandate a rather complex
definition of all the parameters to do this. This appear to be a much longer
term goal.

Finally there would be two options: either the server testifies that the
Digitally Signed Document is well signed and simply provides a signed yes/no
answer, or does more by providing in addition the proof that led to that
decision.

Conclusion

The first two protocols supporting both "Certification of possession of
data" and "Certification of claim possession of identity" should not be
defined. A format describing of the document to be time-stamped should be
defined instead of providing the second service currently called
"Certification of claim possession of identity".

The third protocol supporting "Validation of a Digitally signed document"
should be restricted to the verification of a single signature. In order to
simplify the protocol, the parameters to be presented should be restricted
to the identification of the "Validation policy" to be used (using an OID to
refer to that policy) and of the signed message. Note that the Validation
Policy and a certificate policy are two concepts that should not be
confused. However more information than the information that was presented
will usually be needed to be returned, in order to get long term validity of
the signature, in particular a Time Stamp, a certification path and
certificate status for every element from that certification path. It is
proposed to wait until the definition of the RPP service ("Remote Path
Processing") is stabilized before addressing this level of complexity.

The last protocol supporting "Validation of a public key certificate" should
be addressed under the current discussion related to "Remote Path
Processing" (RPP), so that the WG ends up with a single protocol.

With the arguments raised above, I am *not* supportive to make this
specification an experimental RFC.

Denis

> Steve, Tim:  any comments or alternate suggestions?
> 
> Carlisle.
> 
>      ----------
>      From:   [email-masked][SMTP:[email-masked]]
>      Reply To:       [email-masked]
>      Sent:   Friday, October 06, 2000 6:31 AM
>      Cc:     [email-masked]
>      Subject:        I-D ACTION:draft-ietf-pkix-dcs-07.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           : 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-07.txt
>              Pages           : 48
>              Date            : 05-Oct-00
> 
>      This document describes a general Data Validation and Certification
>      Server (DVCS) 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 assert the validity of signed documents, public key
>      certificates, and the possession or existence of data.

From: Michael Zolotarev <[email-masked]>
To: [email-masked]
Subject: FW: Delegated Path Discovery draft
Date: Thu, 12 Oct 2000 18:17:15 +1000

A scenario:

Client has 2 certificates (C1 and C2). C1 has a single path, C2 has 2
possible paths.

Step 1. Request. Contains C1 and C2. RetryReference void.
	Response. DPDOCSPResponse contains 2 PathResponses. Each has
retryReference =1.
	OCSPResponse::responseStatus (0).

Step 2. Request. The same 2 certificates. RetryReference=1.
	Response. We know that there is no more path for C1. So that the
OCSPResponse::responseStatus should be noMoreData(7). 
	However, there is another path for C2. 
	So that OCSPResponse::responseStatus should be 0.

Because the OCSPResponse::responseStatus is global, applying to all elements
of the DPDOCSPResponse (i.e. to each of the PathResponse), I don't see how
we can distinguish the status in a situation like one above.

Regards
Michael

Date: Wed, 11 Oct 2000 22:46:52 -0400
To: Carlisle Adams <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: The future of DVCS...
Cc: [email-masked]

Carlisle,

I think your characterization of DVCS vs. OCSP and SCVP is very 
accurate and I would be very comfortable with moving it to the 
experimental track. I would like to hear an affirmation from Peter 
Sylvester on this.

Steve

From: Michael Myers <[email-masked]>
To: Carlisle Adams <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: The future of DVCS...
Date: Wed, 11 Oct 2000 14:47:32 -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_001_01C033CC.DC056560
Content-Type: text/plain;
	charset="iso-8859-1"

Chairs:
 
 I offer a second to Carlisle's proposal that the DVCS work effort should be
maintained as proposed.
 
Mike

-----Original Message-----
From: Carlisle Adams [mailto:[email-masked]]
Sent: Wednesday, October 11, 2000 12:40 PM
To: [email-masked]'; [email-masked]'
Cc: [email-masked]
Subject: The future of DVCS...

Hi, 

Over the past year or more, the question has arisen in various contexts as
to the status and role of the DVCS draft, especially with respect to TSP,
OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated in
the future.

DVCS precedes and, at some level, encompasses all of these other protocols.
However, these protocols -- many of them targeted for the standards track --
have been defined for the twin purposes of simplicity and rapid
implementation.  They are small and clearly defined; each one tries to solve
essentially one problem.  DVCS, on the other hand, is intended to be
general, embracing the sometimes abstract notion of the validation and
certification of arbitrary data.  The actual content of the data (the
payload) in a sense defines the function of the server (i.e., if the data is
a hash of something, then the server is providing a time stamp function; if
the data is a certificate, then the server is providing an OCSP or SCVP/DPV
function; if the data is a contract or legal document, then the server is
providing what (at least in North America) might be called a notarization
function; etc.).  It's not quite as loose as that, but that's the basic
idea.

In discussing this protocol with the other authors and with various members
of the community, I sense "rough consensus" on two things.  Firstly, it
makes sense to allow the more clearly-defined subsets of the DVCS
functionality to be handled by these other protocols (TSP, OCSP, etc.) since
they are relatively well-understood and implementations are already either
completed or underway.  Secondly, most real-world environments are not yet
ready to incorporate notarization functions for other data formats.  This
higher-layer purpose of DVCS is perhaps too early as a concept to engage
serious review and debate within the wider PKIX group right now.

Consequently, the authors of DVCS are recommending to the chairs that this
specification be preserved as an Experimental RFC.  It has received some
discussion (both public and private) over the years, but probably not
sufficient to warrant progression along the standards track.  Furthermore,
we are aware of only a single implementation at this time, so any
interoperability testing is out of the question, at least at the moment.
But enough work has gone into this protocol that letting it expire as an
Internet Draft and disappear completely seems inappropriate, especially if
(as we suspect) this higher-layer functionality will begin to be required in
PKI environments in the one- to three-year time frame.  We would like to see
the specification frozen and preserved for now; it can always be re-visited
later (and even re-targeted for the standards track) if the need arises.

In light of this recommendation, further revisions to this document seem
unnecessary; the authors are satisfied with the text in this -07 version
going to "Experimental" status.

Steve, Tim:  any comments or alternate suggestions? 

Carlisle. 

	---------- 
From:   [email-masked][SMTP:[email-masked]] 
Reply To:       [email-masked] 
Sent:   Friday, October 06, 2000 6:31 AM 
Cc:     [email-masked] 
Subject:        I-D ACTION:draft-ietf-pkix-dcs-07.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           : 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-07.txt 
        Pages           : 48 
        Date            : 05-Oct-00 
        
This document describes a general Data Validation and Certification 
Server (DVCS) 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 assert the validity of signed documents, public key 
certificates, and the possession or existence of data. 

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

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

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319392121-11102000>Chairs:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319392121-11102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319392121-11102000>&nbsp;I offer a second to Carlisle's proposal that the 
DVCS work effort should be maintained as proposed.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319392121-11102000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=319392121-11102000>Mike</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Carlisle Adams 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, October 11, 
  2000 12:40 PM<BR><B>To:</B> [email-masked]'; [email-masked]'<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> The future of 
DVCS...<BR><BR></DIV></FONT>
  <P><FONT color=#0000ff face="Times New Roman" size=2>Hi,</FONT> </P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>Over the past year or 
  more, the question has arisen in various contexts as to the status and role of 
  the DVCS draft, especially with respect to TSP, OCSP, SCVP, DPV, DPD, and 
  whatever other variations might be incarnated in the future.</FONT></P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>DVCS precedes and, at 
  some level, encompasses all of these other protocols.&nbsp; However, these 
  protocols -- many of them targeted for the standards track -- have been 
  defined for the twin purposes of simplicity and rapid implementation.&nbsp; 
  They are small and clearly defined; each one tries to solve essentially one 
  problem.&nbsp; DVCS, on the other hand, is intended to be general, embracing 
  the sometimes abstract notion of the validation and certification of arbitrary 
  data.&nbsp; The actual content of the data (the payload) in a sense defines 
  the function of the server (i.e., if the data is a hash of something, then the 
  server is providing a time stamp function; if the data is a certificate, then 
  the server is providing an OCSP or SCVP/DPV function; if the data is a 
  contract or legal document, then the server is providing what (at least in 
  North America) might be called a notarization function; etc.).&nbsp; It's not 
  quite as loose as that, but that's the basic idea.</FONT></P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>In discussing this 
  protocol with the other authors and with various members of the community, I 
  sense "rough consensus" on two things.&nbsp; Firstly, it makes sense to allow 
  the more clearly-defined subsets of the DVCS functionality to be handled by 
  these other protocols (TSP, OCSP, etc.) since they are relatively 
  well-understood and implementations are already either completed or 
  underway.&nbsp; Secondly, most real-world environments are not yet ready to 
  incorporate notarization functions for other data formats.&nbsp; This 
  higher-layer purpose of DVCS is perhaps too early as a concept to engage 
  serious review and debate within the wider PKIX group right now.</FONT></P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>Consequently, the authors 
  of DVCS are recommending to the chairs that this specification be preserved as 
  an Experimental RFC.&nbsp; It has received some discussion (both public and 
  private) over the years, but probably not sufficient to warrant progression 
  along the standards track.&nbsp; Furthermore, we are aware of only a single 
  implementation at this time, so any interoperability testing is out of the 
  question, at least at the moment.&nbsp; But enough work has gone into this 
  protocol that letting it expire as an Internet Draft and disappear completely 
  seems inappropriate, especially if (as we suspect) this higher-layer 
  functionality will begin to be required in PKI environments in the one- to 
  three-year time frame.&nbsp; We would like to see the specification frozen and 
  preserved for now; it can always be re-visited later (and even re-targeted for 
  the standards track) if the need arises.</FONT></P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>In light of this 
  recommendation, further revisions to this document seem unnecessary; the 
  authors are satisfied with the text in this -07 version going to 
  "Experimental" status.</FONT></P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>Steve, Tim:&nbsp; any 
  comments or alternate suggestions?</FONT> </P>
  <P><FONT color=#0000ff face="Times New Roman" size=2>Carlisle.</FONT> </P><BR>
  <UL>
    <P><FONT face="MS Sans Serif" size=2>----------</FONT> <BR><B><FONT 
    face="MS Sans Serif" size=2>From:</FONT></B> &nbsp; <FONT 
    face="MS Sans Serif" 
    size=2>[email-masked][SMTP:[email-masked]]</FONT> 
    <BR><B><FONT face="MS Sans Serif" size=2>Reply To:</FONT></B> 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face="MS Sans Serif" 
    size=2>[email-masked]</FONT> <BR><B><FONT face="MS Sans Serif" 
    size=2>Sent:</FONT></B> &nbsp; <FONT face="MS Sans Serif" size=2>Friday, 
    October 06, 2000 6:31 AM</FONT> <BR><B><FONT face="MS Sans Serif" 
    size=2>Cc:</FONT></B> &nbsp;&nbsp;&nbsp; <FONT face="MS Sans Serif" 
    size=2>[email-masked]</FONT> <BR><B><FONT face="MS Sans Serif" 
    size=2>Subject:</FONT></B> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    face="MS Sans Serif" size=2>I-D ACTION:draft-ietf-pkix-dcs-07.txt</FONT> 
</P>
    <P><FONT face=Arial size=2>A New Internet-Draft is available from the 
    on-line Internet-Drafts directories.</FONT> <BR><FONT face=Arial size=2>This 
    draft is a work item of the Public-Key Infrastructure (X.509) Working Group 
    of the IETF.</FONT> </P>
    <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
    Internet X.509 Public Key Infrastructure Data </FONT><BR><FONT face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    Validation and Certification Server Protocols</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : C. Adams, P. 
    Sylvester, M. Zolotarev, </FONT><BR><FONT face=Arial 
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    R. Zuccherato</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    face=Arial size=2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
    draft-ietf-pkix-dcs-07.txt</FONT> 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
    48</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial 
    size=2>Date&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 
    05-Oct-00</FONT> <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR><FONT 
    face=Arial size=2>This document describes a general Data Validation and 
    Certification</FONT> <BR><FONT face=Arial size=2>Server (DVCS) and the 
    protocols to be used when communicating with</FONT> <BR><FONT face=Arial 
    size=2>it.&nbsp; The Data Validation and Certification Server is a Trusted 
    Third</FONT> <BR><FONT face=Arial size=2>Party (TTP) that can be used as one 
    component in building reliable</FONT> <BR><FONT face=Arial 
    size=2>non-repudiation services (see [ISONR]).</FONT> <BR><FONT face=Arial 
    size=2>Useful Data Validation and Certification Server responsibilities in 
    a</FONT> <BR><FONT face=Arial size=2>PKI are to assert the validity of 
    signed documents, public key</FONT> <BR><FONT face=Arial 
    size=2>certificates, and the possession or existence of data.</FONT> 
</P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C033CC.DC056560--

From: [email-masked]
To: Russ Housley <[email-masked]>
cc: Polar Humenn <[email-masked]>, Al Arsenault <[email-masked]>, Stephen Farrell <[email-masked]>, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, [email-masked], [email-masked], Thumrongsak Kosiyatrakul <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan Older <[email-masked]>
Date: Wed, 11 Oct 2000 17:41:09 -0400
Subject: AttributeCertificates: Why is the holder DN preferred?

     Russ:

     On one subject which is connected to what Polar brought up, I am
inclined to think that he is right.  In the AC509Prof draft, section 4.2.2
states that for PKC-based authentication the entityName MUST be the same as
the PKC subject field unless that field is empty.  Why should it be
mandatory to prefer the subject DN to either permanent ID's or e-mail
addresses, both of which identify individuals in a globally unique way?
Name collisions are more likely in the DN space than in either of the other
two, except for PI's with a default assignment authority, and PI's of that
sort should be forbidden as entityName's.  This does not imply that most of
the options within GeneralName are appropriate as entityName's, as I don't
think they are.

          Tom Gindin

Russ Housley <[email-masked]> on 10/11/2000 01:50:42 PM

To:   Polar Humenn <[email-masked]>
cc:   Al Arsenault <[email-masked]>, Stephen Farrell
      <[email-masked]>, Patrik F�ltstr�m <[email-masked]>,
      [email-masked], [email-masked], Thumrongsak Kosiyatrakul
      <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan
      Older <[email-masked]>
Subject:  Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
      andProxies

Polar:

> > Okay, I think I finally figured out what Polar is getting at here, but
> > I'm not sure what the fix is.  Let me try to illustrate with an
example.
> >
> > (We'll be picking on Stephen a little bit in this; nothing personal
> > intended; apologies for any offense.  :-)
> >
> > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > Technologies, OU=Public CAs, CN=The CA".
> > That CA has a self signed certificate with subject and issuer both
equal
> > to the DN above.
> >
> > Now, there is an end-user certificate issued under that CA.  The issuer
> > field of that certificate will be the DN above; the subject field is
> > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > CN=Stephen".
> >
> > The serial number field will be something like "4434".
> >
> > Now, an attribute authority has issued our friend Stephen an AC
> > consistent with the proposed profile.  The "Holder" field in that AC
can
> > be one of three things, according to the proposed profile:
> >
> >       - it can be the issuer and serial number of the base PKC; that is
> > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> >
> >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> >
> >       - it can be an ObjectDigest - for which the I-D does not require
> > support.
>
>I think the ObjectDigest is truly the only way to go. However, it still
>has problems. The object that is talked about must be able to be recalled
>and identified. Otherwise the Attribute Certificate MUST ALWAYS be
>delivered with the Holder's Public Key Certificate.
>
>I don't believe that requiring the delivery of the Holders certificate is
>unreasonable. Can something like this be mandated in this profile? I don't
>see how. I only see that in specific protocols. Or am I wrong?

PKCs bind a public key to an identity.

ACs bind attributes to an identity.

Authentication, which includes validating the PKC certification path and
having the remote party perform some operation that involves the private
key associated with the identity.  Without authentication of the identity,
who cares what attributes are associated with it?

Russ

Date: Wed, 11 Oct 2000 15:48:22 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Russ Housley <[email-masked]>
cc: Al Arsenault <[email-masked]>, Stephen Farrell <[email-masked]>, =?X-UNKNOWN?Q?Patrik__F=E4ltstr=F6m?= <[email-masked]>, [email-masked], [email-masked], Thumrongsak Kosiyatrakul <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan Older <[email-masked]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders,  Targets andProxies

Russ,

On Wed, 11 Oct 2000, Russ Housley wrote:

> Polar:
> 
> > > Okay, I think I finally figured out what Polar is getting at here, but
> > > I'm not sure what the fix is.  Let me try to illustrate with an example.
> > >
> > > (We'll be picking on Stephen a little bit in this; nothing personal
> > > intended; apologies for any offense.  :-)
> > >
> > > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > > Technologies, OU=Public CAs, CN=The CA".
> > > That CA has a self signed certificate with subject and issuer both equal
> > > to the DN above.
> > >
> > > Now, there is an end-user certificate issued under that CA.  The issuer
> > > field of that certificate will be the DN above; the subject field is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > > CN=Stephen".
> > >
> > > The serial number field will be something like "4434".
> > >
> > > Now, an attribute authority has issued our friend Stephen an AC
> > > consistent with the proposed profile.  The "Holder" field in that AC can
> > > be one of three things, according to the proposed profile:
> > >
> > >       - it can be the issuer and serial number of the base PKC; that is
> > > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> > >
> > >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> > >
> > >       - it can be an ObjectDigest - for which the I-D does not require
> > > support.
> >
> >I think the ObjectDigest is truly the only way to go. However, it still
> >has problems. The object that is talked about must be able to be recalled
> >and identified. Otherwise the Attribute Certificate MUST ALWAYS be
> >delivered with the Holder's Public Key Certificate.
> >
> >I don't believe that requiring the delivery of the Holders certificate is
> >unreasonable. Can something like this be mandated in this profile? I don't
> >see how. I only see that in specific protocols. Or am I wrong?
> 
> PKCs bind a public key to an identity.

It is true that PKC's bind a public key to an identity, but that identity
is fully qualified by its subject DN, it's issuer DN, it's issuer's
issuer's DN, and so on all the way up to a root CA. This full identity is
all tied together all the way up to the root by chaining of signatures.

> ACs bind attributes to an identity.

The AC's bind attributes only to the least significant component of an
identity, not the entire identity. The rest of it, i.e. he most
significant part, is THROWN AWAY.

> Authentication, which includes validating the PKC certification path and 
> having the remote party perform some operation that involves the private 
> key associated with the identity.  Without authentication of the identity, 
> who cares what attributes are associated with it?

True, but in some cases you may infact be removed from the authentication.
Take a case where you have a webserver that uses SSL. The
authentication information of a user is processed on the webserver. Now
the web server may want to access some database server on the
authenticated user's behalf. The web server cannot authenticate as the
user. There are several ways to do this. One way is for the name of the
authenticated entity to be to propagated. So, on the database server, the
name who the webserver is acting on behalf is transmitted to the database
server. The database trusts the webserver in this matter. 

The question is what identifying information is good enough? Add an AC in
there or and AA to pull from, you have to emphatically know what that name
is refering to and if they are the same. A simple DN will not work in the
widely scaled interoperable case.

Cheers,
-Polar

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: The future of DVCS...
Date: Wed, 11 Oct 2000 15:40:25 -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_01C033BB.1A17EB50
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

Over the past year or more, the question has arisen in various contexts as
to the status and role of the DVCS draft, especially with respect to TSP,
OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated in
the future.

DVCS precedes and, at some level, encompasses all of these other protocols.
However, these protocols -- many of them targeted for the standards track --
have been defined for the twin purposes of simplicity and rapid
implementation.  They are small and clearly defined; each one tries to solve
essentially one problem.  DVCS, on the other hand, is intended to be
general, embracing the sometimes abstract notion of the validation and
certification of arbitrary data.  The actual content of the data (the
payload) in a sense defines the function of the server (i.e., if the data is
a hash of something, then the server is providing a time stamp function; if
the data is a certificate, then the server is providing an OCSP or SCVP/DPV
function; if the data is a contract or legal document, then the server is
providing what (at least in North America) might be called a notarization
function; etc.).  It's not quite as loose as that, but that's the basic
idea.

In discussing this protocol with the other authors and with various members
of the community, I sense "rough consensus" on two things.  Firstly, it
makes sense to allow the more clearly-defined subsets of the DVCS
functionality to be handled by these other protocols (TSP, OCSP, etc.) since
they are relatively well-understood and implementations are already either
completed or underway.  Secondly, most real-world environments are not yet
ready to incorporate notarization functions for other data formats.  This
higher-layer purpose of DVCS is perhaps too early as a concept to engage
serious review and debate within the wider PKIX group right now.

Consequently, the authors of DVCS are recommending to the chairs that this
specification be preserved as an Experimental RFC.  It has received some
discussion (both public and private) over the years, but probably not
sufficient to warrant progression along the standards track.  Furthermore,
we are aware of only a single implementation at this time, so any
interoperability testing is out of the question, at least at the moment.
But enough work has gone into this protocol that letting it expire as an
Internet Draft and disappear completely seems inappropriate, especially if
(as we suspect) this higher-layer functionality will begin to be required in
PKI environments in the one- to three-year time frame.  We would like to see
the specification frozen and preserved for now; it can always be re-visited
later (and even re-targeted for the standards track) if the need arises.

In light of this recommendation, further revisions to this document seem
unnecessary; the authors are satisfied with the text in this -07 version
going to "Experimental" status.

Steve, Tim:  any comments or alternate suggestions?

Carlisle.

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Friday, October 06, 2000 6:31 AM
> Cc: 	[email-masked]
> Subject: 	I-D ACTION:draft-ietf-pkix-dcs-07.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		: 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-07.txt
> 	Pages		: 48
> 	Date		: 05-Oct-00
> 	
> This document describes a general Data Validation and Certification
> Server (DVCS) 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 assert the validity of signed documents, public key
> certificates, and the possession or existence of data.
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>The future of DVCS...</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Over the =
past year or more, the question has arisen in various contexts as to =
the status and role of the DVCS draft, especially with respect to TSP, =
OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated =
in the future.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">DVCS =
precedes and, at some level, encompasses all of these other =
protocols.&nbsp; However, these protocols -- many of them targeted for =
the standards track -- have been defined for the twin purposes of =
simplicity and rapid implementation.&nbsp; They are small and clearly =
defined; each one tries to solve essentially one problem.&nbsp; DVCS, =
on the other hand, is intended to be general, embracing the sometimes =
abstract notion of the validation and certification of arbitrary =
data.&nbsp; The actual content of the data (the payload) in a sense =
defines the function of the server (i.e., if the data is a hash of =
something, then the server is providing a time stamp function; if the =
data is a certificate, then the server is providing an OCSP or SCVP/DPV =
function; if the data is a contract or legal document, then the server =
is providing what (at least in North America) might be called a =
notarization function; etc.).&nbsp; It's not quite as loose as that, =
but that's the basic idea.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">In =
discussing this protocol with the other authors and with various =
members of the community, I sense &quot;rough consensus&quot; on two =
things.&nbsp; Firstly, it makes sense to allow the more clearly-defined =
subsets of the DVCS functionality to be handled by these other =
protocols (TSP, OCSP, etc.) since they are relatively well-understood =
and implementations are already either completed or underway.&nbsp; =
Secondly, most real-world environments are not yet ready to incorporate =
notarization functions for other data formats.&nbsp; This higher-layer =
purpose of DVCS is perhaps too early as a concept to engage serious =
review and debate within the wider PKIX group right now.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Consequently, the authors of DVCS are recommending to the chairs =
that this specification be preserved as an Experimental RFC.&nbsp; It =
has received some discussion (both public and private) over the years, =
but probably not sufficient to warrant progression along the standards =
track.&nbsp; Furthermore, we are aware of only a single implementation =
at this time, so any interoperability testing is out of the question, =
at least at the moment.&nbsp; But enough work has gone into this =
protocol that letting it expire as an Internet Draft and disappear =
completely seems inappropriate, especially if (as we suspect) this =
higher-layer functionality will begin to be required in PKI =
environments in the one- to three-year time frame.&nbsp; We would like =
to see the specification frozen and preserved for now; it can always be =
re-visited later (and even re-targeted for the standards track) if the =
need arises.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">In light =
of this recommendation, further revisions to this document seem =
unnecessary; the authors are satisfied with the text in this -07 =
version going to &quot;Experimental&quot; status.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Steve, =
Tim:&nbsp; any comments or alternate suggestions?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>
<BR>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked][SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Reply To:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Friday, October 06, 2000 6:31 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">I-D ACTION:draft-ietf-pkix-dcs-07.txt</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A New Internet-Draft is available from =
the on-line Internet-Drafts directories.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This draft is a work item of the =
Public-Key Infrastructure (X.509) Working Group of the IETF.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Title&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Internet X.509 Public Key =
Infrastructure Data </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; Validation and Certification Server =
Protocols</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : C. =
Adams, P. Sylvester, M. Zolotarev, </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; R. Zuccherato</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-ietf-pkix-dcs-07.txt</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Pages&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 48</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 05-Oct-00</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">This document describes a general =
Data Validation and Certification</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Server (DVCS) and the protocols to be =
used when communicating with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it.&nbsp; The Data Validation and =
Certification Server is a Trusted Third</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Party (TTP) that can be used as one =
component in building reliable</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">non-repudiation services (see =
[ISONR]).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Useful Data Validation and =
Certification Server responsibilities in a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">PKI are to assert the validity of =
signed documents, public key</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">certificates, and the possession or =
existence of data.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C033BB.1A17EB50--

Date: Wed, 11 Oct 2000 13:50:42 -0400
To: Polar Humenn <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
Cc: Al Arsenault <[email-masked]>, Stephen Farrell <[email-masked]>, Patrik  F�ltstr�m <[email-masked]>, [email-masked], [email-masked], Thumrongsak Kosiyatrakul <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan Older <[email-masked]>

Polar:

> > Okay, I think I finally figured out what Polar is getting at here, but
> > I'm not sure what the fix is.  Let me try to illustrate with an example.
> >
> > (We'll be picking on Stephen a little bit in this; nothing personal
> > intended; apologies for any offense.  :-)
> >
> > Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> > Technologies, OU=Public CAs, CN=The CA".
> > That CA has a self signed certificate with subject and issuer both equal
> > to the DN above.
> >
> > Now, there is an end-user certificate issued under that CA.  The issuer
> > field of that certificate will be the DN above; the subject field is
> > "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> > CN=Stephen".
> >
> > The serial number field will be something like "4434".
> >
> > Now, an attribute authority has issued our friend Stephen an AC
> > consistent with the proposed profile.  The "Holder" field in that AC can
> > be one of three things, according to the proposed profile:
> >
> >       - it can be the issuer and serial number of the base PKC; that is
> > "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> >
> >       - it can be the entity name, which by the I-D MUST be "C=IE,
> > O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> >
> >       - it can be an ObjectDigest - for which the I-D does not require
> > support.
>
>I think the ObjectDigest is truly the only way to go. However, it still
>has problems. The object that is talked about must be able to be recalled
>and identified. Otherwise the Attribute Certificate MUST ALWAYS be
>delivered with the Holder's Public Key Certificate.
>
>I don't believe that requiring the delivery of the Holders certificate is
>unreasonable. Can something like this be mandated in this profile? I don't
>see how. I only see that in specific protocols. Or am I wrong?

PKCs bind a public key to an identity.

ACs bind attributes to an identity.

Authentication, which includes validating the PKC certification path and 
having the remote party perform some operation that involves the private 
key associated with the identity.  Without authentication of the identity, 
who cares what attributes are associated with it?

Russ

Date: Wed, 11 Oct 2000 13:44:10 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: TSP: Response to the comments raised by Russ Housley
Cc: [email-masked]

<html>
<font size=2>Francois</font>:<br>
<br>
Policy qualifiers can lead to huge interoperability problems.&nbsp; I am
less concerned about URLs that point to CP or CPS documents than other
uses.&nbsp; In RFC 2459, I wanted to prohibit policy qualifiers all
together to avoid the interoperability issues.&nbsp; The limited support
for policy qualifiers is the compromise.<br>
<br>
Russ<br>
<br>
At 10:36 AM 10/10/2000 -0400, [email-masked] wrote:<br>
<br>
<blockquote type=cite cite><font size=2>Russ,</font> <br>
<br>
<font size=2>What don't you like in policy qualifiers?</font> <br>
<br>
<font size=2>I still think it would be useful to have the option to
include a link to the practice statement of the TSA within each time
stamping response. Although I understand that no automated processing is
currently done today with these practice statements, once they are
written in XML, maybe relying parties could then start to do something
with them. However, with no optional pointer to the TSA practice
statement, it will never be possible.<br>
</font><br>
<font size=2>Regards,</font> <br>
<br>
<font size=2>Francois</font> <br>
<br>
<font size=2>&gt;Russ,</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; Thank you for your response.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; The only remaining issues are numbered 3 and 10. See my
comments</font> <br>
<font size=2>&gt; embedded below.</font> <br>
<font size=2>&gt; </font><br>
<font size=2>&gt;&gt; Denis:</font> <br>
<font size=2>&gt;&gt; </font><br>
<font size=2>[snip]</font> <br>
<font size=2>&gt;&gt; </font><br>
<font size=2>&gt;&gt; 3. I am not satisfied.&nbsp; I accept that this is
not the place to define</font> <br>
<font size=2>&gt;&gt; TSP policy or practice statements.&nbsp; However, I
do not think that the RFC</font> <br>
<font size=2>&gt;&gt; 2459 syntax is appropriate for use in the TSP
context.&nbsp; Also, you ignored</font> <br>
<font size=2>&gt;&gt; my concern regarding qualifiers.&nbsp; RFC 2459
contains:</font> <br>
<font size=2>&gt;&gt; </font><br>
<font size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; PolicyInformation ::=
SEQUENCE {</font> <br>
<font size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
policyIdentifier&nbsp;&nbsp; CertPolicyId,</font> <br>
<font size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
policyQualifiers&nbsp;&nbsp; SEQUENCE SIZE (1..MAX) OF</font> <br>
<font size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PolicyQualifierInfo OPTIONAL }</font> <br>
<font size=2>&gt;&gt; </font><br>
<font size=2>&gt;&gt; I would prefer a structure that said
&quot;TSAPolicyId&quot; instead of</font> <br>
<font size=2>&gt;&gt; &quot;CertPolicyId.&quot; Using
&quot;CertPolicyId&quot; in this context will, in my</font> <br>
<font size=2>&gt;&gt; opinion, confuse matters.&nbsp; Also, I would like
to omit policy qualifiers</font> <br>
<font size=2>&gt;&gt; altogether.&nbsp; I do not like them in certificate
policies, and I would</font> <br>
<font size=2>&gt;&gt; like to avoid them in TSA policies.</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; I had corrected the text but I did not understood your
were also</font> <br>
<font size=2>&gt; requesting an ASN.1 change.</font> <br>
<font size=2>&gt; Sorry about that misunderstanding. I agree with your
request and I have</font> <br>
<font size=2>&gt; done the changes, i.e:</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; TSAPolicyId ::= OBJECT IDENTIFIER</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; and in the request:</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; reqPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TSAPolicyId&nbsp;&nbsp;&nbsp; OPTIONAL,</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt; while in the response:</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>&gt;
policy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TSAPolicyId,</font> <br>
<font size=2>&gt;</font> <br>
<font size=2>[snip]</font> </blockquote></html>

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Oct 2000 19:30:44 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Experimental TSA
Cc: [email-masked], [email-masked]

> Rigth now the only interface available is the socket based protocol defined in
> the
> draft-ietf-pkix-time-stamp-09.
> 

With some first tests of sending

   0 30   36: SEQUENCE {
   2 02    1:   INTEGER 1
   5 30   31:   SEQUENCE {
   7 30    7:     SEQUENCE {
   9 06    5:       OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
            :       }
  16 04   20:     OCTET STRING
            :       0D E8 66 25 D3 87 2E 02 45 4F 57 94 BD EC DC F6
            :       4F AA 95 77
            :     }
            :   }

I got back a rejection with a bitstring
encoded as
 
   30 0c 30 0a 02 01 02 03 05 00 00 00 00 05

or: 

   0 30   12: SEQUENCE {
   2 30   10:   SEQUENCE {
   4 02    1:     INTEGER 2
   7 03    5:     BIT STRING 0 unused bits
            :       00 00 00 05
            :     }
            :   }

BTW: I think the example of the Graz implementations is wrong:

direct TCP-based TSA message:
00:00:00:37:00:30:34:02.....
XXXXXXXXXXX

This doesn't seem to be network byte order. 

shouldn't this be 

37:00:00:00:00

Furthermore both implementions close the connection after sending the response.
This is unfriendly and pretty inefficien if you want to send may requests,
I am not sure whether this had been intended by the protocol. 

The length field at the beginning indicate to the client and to
the server how many data are transmitted in an exchange. 

it seems that the same problem occured in the CMP interoperability tests,
and this has already resulted in a draft. 

From: "Rob B Branch" <[email-masked]>
To: Al Arsenault <[email-masked]>, "'Polar Humenn'" <[email-masked]>, Stephen Farrell <[email-masked]>, Patrik Faltstrom <[email-masked]>, [email-masked], [email-masked], Thumrongsak Kosiyatrakul <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan Older <[email-masked]>
Date: Wed, 11 Oct 2000 11:04:02 -0500
Subject: PKI Question

Hello to ALL,

Do the Private Key have to be stored on a separate processor?
Can it be stored on the same processor but in a separate processing space?
Where can I find the rules for PKI?

Thanks in Advance...

RobB...

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Oct 2000 18:06:04 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: Experimental TSA
Cc: [email-masked], [email-masked]

good news.

I have forgotten to cross post the following.

An experimental TSA is available using HTTP and HTTPS,
details how to read it are available under

  http://www.edelweb.fr/tsa.html

The TSA was developed using openssl.  

Peter Sylvester

Date: Wed, 11 Oct 2000 17:41:58 +0200
From: Raffaello <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Experimental TSA

This is a cryptographically signed message in MIME format.

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

Hi,
for those of you interested in testing a TSA experimental implementation based
on the draft-ietf-pkix-time-stamp-09,  our TSA service is available at the
following address 195.223.2.6 ,  port 3318.

Rigth now the only interface available is the socket based protocol defined in
the
draft-ietf-pkix-time-stamp-09.

We would pleased to receive any feed-back from you.

We would like to point out that we have build the token with Snacc 1.3 which
hasn't
BIG INTEGER support so the BIG INTEGER fields of our Token are limited to
32 bit integer  (i.e.  nonce, serialnumber etc..)  and no extensions are
supported.

Thanks
Raffaello/Thomas

--------------msD907512B2EC3FB39F659C2B4
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Content-Transfer-Encoding: base64

--------------msD907512B2EC3FB39F659C2B4--

Date: Wed, 11 Oct 2000 11:24:05 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Stephen Farrell <[email-masked]>
cc: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

On Wed, 11 Oct 2000, Stephen Farrell wrote:

> 
> FWIW I guess I agree with David (and Russ and Carlisle and James and ...)
> 
> Stephen.
> 
> Polar Humenn wrote:
> > 
> > On Wed, 11 Oct 2000, David P. Kemp wrote:
> > 
> > > This discussion has already played out, in a different context, in the
> > > S/MIME working group.
> > >
> > > The concern is not that there is a logic hole; there is not.
> > 
> > I really beg to differ on this one. 
> [snip]

What about adding a non-critical Attribute Extension that completes the DN
path of the Holder? That way, CONSTRAINED environments that emphatically
know where the DNs are defined need not have to deal with it.

However, widely scaled interoperable environments can deal with it
effectively and with assurance.

--
-- Full Directory Name of a Subject
--
DirectoryNamePath ::= SEQUENCE OF (1..MAX) OF DirectoryName 
	-- First is the subject's DirectoryName.
        -- Intermediates are the issuer of the previous DirectoryName
        -- Last is the RootCA of the Holder

--
-- Specific Type Alias for holderIssuerName attribute
--
HolderIssuerName ::= DirectoryNamePath
	-- Name path of the Holder's Issuer CA.

--
-- This attribute completes the Holder's name path up to its RootCA.
--
Attribute Extension:
      name           id-ce-holderIssuerName
      OID            { id-ce ? }
      syntax         HolderIssuerName
      criticality    MUST be FALSE

I think this or something like would solve the problem for Holders when
DN's are applicable.

I think there are still have problems for ProxyInfo and TargetInfo when
using GeneralNames and IssuerSerial.

Regards,
-Polar

> -- 
> ____________________________________________________________
> 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, 11 Oct 2000 15:30:24 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Polar Humenn <[email-masked]>
CC: "David P. Kemp" <[email-masked]>, [email-masked]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

FWIW I guess I agree with David (and Russ and Carlisle and James and ...)

Stephen.

Polar Humenn wrote:
> 
> On Wed, 11 Oct 2000, David P. Kemp wrote:
> 
> > This discussion has already played out, in a different context, in the
> > S/MIME working group.
> >
> > The concern is not that there is a logic hole; there is not.
> 
> I really beg to differ on this one. 
[snip]

-- 
____________________________________________________________
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, 11 Oct 2000 10:07:55 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: "David P. Kemp" <[email-masked]>
cc: [email-masked]
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

On Wed, 11 Oct 2000, David P. Kemp wrote:

> This discussion has already played out, in a different context, in the
> S/MIME working group.
> 
> The concern is not that there is a logic hole; there is not. 

I really beg to differ on this one. We have already figured out that
information was lost if the AC names a holder by only its first DN.
That is a hole in the logic of naming of the holder in general.

> If the relying party does his job and the CAs and AA do theirs, names
> will be coordinated so that they don't collide.  I can't see any
> reasonable record company authorizing "John Smith" to listen to their
> tunes; John will have an account number issued by the record company,
> a PI, something formerly known as a QC unmistakeable identity, or some
> other unique name form agreed to among the parties involved.

You are *suggesting* ways of how you think organizations will operate and
co-operate. The whole purpose of this AA exercise, at least as I see it,
is so that John Smith doesn't have to get his own ID at the record
company, or every company he wishes to do business with. He just uses his
own. 

I'm sure in something like the Military, one might have a common mandated
naming scheme, so this might not be an issue. It's a constrained
environment.

> Mandating a reference to a particular PK certificate is unnecessarily
> heavy-handed; it precludes, for example, rollover (rekeying the
> subscriber's certificate.)  Designing applications that identify users
> by their public keys is one choice, but it cannot be the only one
> permitted by PKIX.

I agree with respect to the key rollover issue. But as I said in my last
message, I think you need to have the objectDigest of the RootCA and not
the holder's certificate. That might not change as much. If it does, you
got a big problem anyway.

However, I think that AA's and users of AC that agree on a common
resolution to naming of RootCAs just might do it. That's not unreasonable
and is currently done with DNS.

> On the other hand, limiting the damage that can occur when parties do
> not do their jobs properly is a legitimate security concern, so PKIX
> should offer ObjectDigest as an option for environments where RPs
> "trust" all 137 roots built into their browsers.

I know, it gets to be ludicrous after a while. :)

> This is the solution adopted by S/MIME - the SigningCertificate
> attribute identifies a PKC as:
> 
>   ESSCertID ::= SEQUENCE {
>      certHash       Hash,
>      issuerSerial   IssuerSerial OPTIONAL }
> 
> but use of that attribute is an option, not a requirement, of RFC 2634.

I think that is what the objectDigest does. However, I think there is
still some problem.

Given that the AC can be used in CONSTRAINED environments of which,
something like a military can agree on a unique naming scheme for DN's,
then the Holder as a single DN should be fine.

However, there can be a DN path critical extension that completes the
Holder's Name. For widely interoperable environments this criticial
extension must be used.

Also, the same problem exists for ProxyInfo and TargetInfo attribute
extensions.

Care to tackle that one?

Cheers,
-Polar

> > 
> > On Tue, 10 Oct 2000, Carlisle Adams wrote:
> > 
> > > Hi Polar,
> > > 
> > > > ----------
> > > > Sent: 	Tuesday, October 10, 2000 3:27 PM
> > > > To: 	Al Arsenault
> > > > Cc: 	Stephen Farrell; Patrik  Faltstrom; [email-masked];
> > > > [email-masked]; Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older
> > > > Subject: 	Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> > > > Targets  andProxies
> > > > 
> > > (...some text deleted...)
> > > 
> > > > The start of the solution is mandating the use of ObjectDigest, where
> > > > a digest can be verified against the Holder's Public Key or Public Key
> > > > Certificate. The question after that is where does one pull the
> > > > Holder's cert or public key from, should it not be readily available,
> > > > i.e. wasn't delivered with the AttributeCertificate. This would
> > > > constitute having the entire DN path to the Holders public key
> > > > certificate anyway, and using the ObjectDigest for verification of the
> > > > identity.
> > > 
> > > > Could we suggest a critical attribute extension that will contain the
> > > > path to the ObjectDigest?
> > >  
> > > Actually, the syntax in X.509 (2000) is that holder is a SEQUENCE of three
> > > optionals (general name, issuer/serial, and object digest).  If the group
> > > decides to do what you're suggesting, no new critical extension would be
> > > necessary; all the profile would have to do is mandate two (or all three) of
> > > the optional fields.
> > 
> > Not good enough. You still need a proper full DN path, (i.e. sequence of
> > DNs) from the root CA of the Holder's certificate. You need it to locate
> > the Holder's certificate to verify it against the ObjectDigest.
> 
> 
> You don't "need" a sequence of DNs carried in a protocol or in an
> attribute certificate to do path development; and it's not obvious why
> it would even help.  If you know the Holder's DN and/or an IssuerSerial
> reference and cannot find the Holder's PKC using that information, how
> would knowing the DNs of CAs above the Issuer aid in finding it?
> 
> Dave
> 
> 
> 

Date: Wed, 11 Oct 2000 09:47:04 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: "Manger, James H" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

On Wed, 11 Oct 2000, Manger, James H wrote:

> A relying party verifying an attribute certificate that only includes the
> holder's name must match a name from an AA to a name from a CA.

Then you MUST name the CA and its CA and its CA, and so on.

> Matching names from two sources is dangerous if the two sources can issued
> the same name to different entities.  It is safe, however, if this cannot
> occur.

However, there is no way for you to control that. The only thing you can
control is that you only accept a set of root CA's (with different keys)
that have different names.

> In the general case trusting an arbitrary combination of CAs and AAs (even
> if they all individually do their job correctly) is insecure when verifying
> an AC that only contains the holder name - as Polar described.

True. So, how does one solve this problem? Not by constraining the
environment.

> However, this is NOT a good reason to mandate extra fields.  It is possible
> to securely verify an AC that only contains the holder name as long as the
> relying party's set of trusted CAs and AAs have some commonality in their
> naming schemes.  It is sufficient that the same name cannot be issued to
> different entities by different CAs and AAs in this trusted collection.

And therefore you limit or break interoperability on a wide scale.

> Use globally unambiguous names (e.g. DNS) or restrict your set of trusted
> CAs and AAs for a given scenario.

I don't have control over names that CA's issue, nor do I have control
over AAs that issue privilege certificates. That's like you being the 51st
state and mandating that the Social Security Agency to conform and use
YOUR person naming scheme for the entire nation and the DMV's of all
states to produce drivers licenses using YOUR person naming scheme so the
person can drive YOUR state.

> It must not be mandated that attribute certificates be bound to public key
> certificates - a major benefit of attribute certificates was separating
> these two domains of control.

Okay I can see that, for things such as Kerberos or unix user ids.
However, with DN's you have the special complex identification problem.
With DN's you are meant to be pointing to a public key. Some evidence is
needed to prove that you are not issuing privileges to a forgery or that
you are not accepting privileges meant for somebody else. Having a
complete path from a root CA might do it. However, that always requires a
lookup to make sure that you have the right certificate and corresponding
signatures that it verifies.

Holder: DN,DNCA,...,DNRootCA

Even if the principal which is the Holder delivers the certificate in
whatever protocol he is using to authenticate himself, the Holder's name
still must be looked up via the DN path in the Attribute Certificate and
be verified. An objectDigest might alleviate that. Still if the Holder
didn't deliver his certificate a certificate lookup is still needed.

So there are two cases in the forms of a protocol, say TLS.

1. The authenticated entity delivers its certificate chain.
   The AC must name the holder using a DN path includes the DN path
   constructed from the certificate chain as a prefix.  The DN path
   in the AC must contain the DN all the way up to the RootCA.

   The certificate from the Holder's RootCA named in the AC must be looked
   up and it must be able to verify the authenticated entities chain as
   well. This covers the case where you trust the same RootCA's the AA
   trusts. So no objectDigest is really needed.

   If you and the AA have no agreement on which RootCA's you trust
   there must be an ObjectDigest! And Strangely enough IT MUST BE THE
   ObjectDigest of the RootCA certificate, not the Holder's!

2. The authenticated entity does not deliver is certificate chain.
   Quite possibly its authentication information is gone. The
   authenticated entity's name has been passed on to another server  as
   being previously authenticated, say at the firewall.  However, you 
   only do this in situations where the certificates that were used
   during authentication can be retrieved somehow.
   
   The AC must name the authentication identity and it's objectDigest
   to make sure that the AC is talking about the proper certificate.
   In this case to be absolutely sure, the authenticated entities
   certificate must be looked up, and the objectDigest verified against
   it.

> what we really want to do here is issue privileges to a public key, not
> just the name of one.
>  
> Absolutely not!  The whole idea is that the source of authority for a given
> privilege knows who (by name) they want to assign it to, but does not care
> what public key that person uses.  The cost is that the names used must be
> unambiguous in a large context that just the AA.

Okay. I can see your point. I'm a big fan of Kerberos and other faster
authentication schemes. However, just using naming in the point of AA must
cause a lookup for verification at least to common trust points. It's not
unreasonable.  Although it still bothers me. Peoples pictures and
signatures on are drivers licenses for a reason.

However, the issue still remains of name "collisions" or "coincidences"
of which cannot be verified.

One approach, of which I think James is getting at, is to mandate that all
DN's in the Entire World and Universe be unique. That would mean a
stringent relationship MUST exist between a subjects DN and an Issuers DN
for public key certificates, i.e. DNS. However, I think, since the
inception of RFC2459 and it's predecessors, this was a detail that was not
addressed, or was addressed to be unwarranted.

Therefore one can only conclude that a NAME of a principal in RFC2459 is
the COMPLETE list of DNs from the subject up to the root CA's DN. It cannot
be shorter. Therefore the Holder must be named by a complete list of DN's
up to its RootCA. 

If we use just DN's and no objectDigests, this must mean that there is
at least a common agreement between all AAs and users of ACs that they
trust the same RootCA's, or the naming scheme of RootCA's. That is if a
DN resolves to a RootCA on the AA side, it resolves to the same RootCA on
the user's side.

I think the basic upshot is that the Holder field must name the entire DN
path up to its rootCA. That is indeed the complete name of the defined
X.509 principal.

Cheers,
-Polar

Date: Wed, 11 Oct 2000 09:17:39 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
To: [email-masked]
Content-MD5: /2zu7h74eDjjpcwYLZFNww==

This discussion has already played out, in a different context, in the
S/MIME working group.

The concern is not that there is a logic hole; there is not.  If the
relying party does his job and the CAs and AA do theirs, names will
be coordinated so that they don't collide.  I can't see any reasonable
record company authorizing "John Smith" to listen to their tunes; John
will have an account number issued by the record company, a PI,
something formerly known as a QC unmistakeable identity, or some other
unique name form agreed to among the parties involved.

Mandating a reference to a particular PK certificate is unnecessarily
heavy-handed; it precludes, for example, rollover (rekeying the
subscriber's certificate.)  Designing applications that identify users
by their public keys is one choice, but it cannot be the only one
permitted by PKIX.

On the other hand, limiting the damage that can occur when parties do
not do their jobs properly is a legitimate security concern, so PKIX
should offer ObjectDigest as an option for environments where RPs
"trust" all 137 roots built into their browsers.

This is the solution adopted by S/MIME - the SigningCertificate
attribute identifies a PKC as:

  ESSCertID ::= SEQUENCE {
     certHash       Hash,
     issuerSerial   IssuerSerial OPTIONAL }

but use of that attribute is an option, not a requirement, of RFC 2634.

> 
> On Tue, 10 Oct 2000, Carlisle Adams wrote:
> 
> > Hi Polar,
> > 
> > > ----------
> > > Sent: 	Tuesday, October 10, 2000 3:27 PM
> > > To: 	Al Arsenault
> > > Cc: 	Stephen Farrell; Patrik  Faltstrom; [email-masked];
> > > [email-masked]; Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older
> > > Subject: 	Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> > > Targets  andProxies
> > > 
> > (...some text deleted...)
> > 
> > > The start of the solution is mandating the use of ObjectDigest, where
> > > a digest can be verified against the Holder's Public Key or Public Key
> > > Certificate. The question after that is where does one pull the
> > > Holder's cert or public key from, should it not be readily available,
> > > i.e. wasn't delivered with the AttributeCertificate. This would
> > > constitute having the entire DN path to the Holders public key
> > > certificate anyway, and using the ObjectDigest for verification of the
> > > identity.
> > 
> > > Could we suggest a critical attribute extension that will contain the
> > > path to the ObjectDigest?
> >  
> > Actually, the syntax in X.509 (2000) is that holder is a SEQUENCE of three
> > optionals (general name, issuer/serial, and object digest).  If the group
> > decides to do what you're suggesting, no new critical extension would be
> > necessary; all the profile would have to do is mandate two (or all three) of
> > the optional fields.
> 
> Not good enough. You still need a proper full DN path, (i.e. sequence of
> DNs) from the root CA of the Holder's certificate. You need it to locate
> the Holder's certificate to verify it against the ObjectDigest.

You don't "need" a sequence of DNs carried in a protocol or in an
attribute certificate to do path development; and it's not obvious why
it would even help.  If you know the Holder's DN and/or an IssuerSerial
reference and cannot find the Holder's PKC using that information, how
would knowing the DNs of CAs above the Issuer aid in finding it?

Dave

From: "Benoit d'Udekem" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: to Unsubscribe
Date: Wed, 11 Oct 2000 15:15:07 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C03396.0CAC8E00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Information on how to unsubscribe is also provided in every single
message posted to the list.

Have a look at the message header. You will find the following line:

List-Unsubscribe: mailto:[email-masked]?body=unsubscribe

Benoit d'Udekem
________________________________________________________________________
ir. Benoit d'Udekem                Email: [email-masked]
Project Manager

GlobalSign SA/NV                   Tel: +32 2 7243636
Haachtsesteenweg 1426              Fax: +32 2 7243637
B-1130 Brussels                    Web: http://www.globalsign.net
Belgium
________________________________________________________________________
Get your FREE Web Server Certificate NOW at 
http://www.globalsign.net/prod/freeserver.cfm?ID=CorpSign
________________________________________________________________________

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

------=_NextPart_000_0005_01C03396.0CAC8E00--

From: "Carmelo Floridia" <[email-masked]>
To: <[email-masked]>
Subject: to Unsuscribe
Date: Wed, 11 Oct 2000 15:05:33 +0200

This is a multi-part message in MIME format.

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

If you ever want to remove yourself from this mailing list,
you can send mail to <[email-masked]> with the following
command in the body of your email message:

    unsubscribe ietf-pkix [email-masked]

------=_NextPart_000_0033_01C03394.B3E6D600
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.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>If you ever want to remove yourself =
from this=20
mailing list,<BR>you can send mail to &lt;<A=20
href=3D"mailto:[email-masked]">[email-masked]</A>&gt; with the=20
following<BR>command in the body of your email=20
message:<BR><BR>&nbsp;&nbsp;&nbsp; unsubscribe ietf-pkix <A=20
href=3D"mailto:[email-masked]">[email-masked]=
ng</A><BR><BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0033_01C03394.B3E6D600--

Sender: [email-masked]
Date: Wed, 11 Oct 2000 14:58:28 +0200
From: Richard Levitte <[email-masked]>
Organization: Celo Communications, Ltd.
To: Frank Balluffi <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: unsubscibe

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

Frank Balluffi wrote:
> 
> Sorry for the spam, but http://www.ietf.org/html.charters/pkix-charter.html
> does not appear to contain directions for unsubscribing (or at least I don't
> see them) nor does it contain directions for where to send this message.

It's a pity that the same info is displayed in two places, and differently.
If you look at the archive page (http://www.imc.org/ietf-pkix/), you'll find
"unsubscribe" mentioned.

However, I do find it a bit surprising that it would be difficult to figure
out that the unsubscribe request should be sent to the same address as the
subscribe command that was obviously sent at some point in time.  And to boot,
when one subscribes one usually gets a welcoming message that explains all
this...

-- 
Richard Levitte			!!! New cell phone number !!!
[email-masked]

/* You might enjoy viewing the complete vCard */
--------------AD2D79ACC7B93080CDF26B92
Content-Type: text/x-vcard; charset=us-ascii;
 name="richard.levitte.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Richard Levitte
Content-Disposition: attachment;
 filename="richard.levitte.vcf"

begin:vcard 
n:Levitte;Richard
tel;cell:+46-733-72 8811
tel;work:+46-8-58 72 8811
x-mozilla-html:FALSE
org:<A HREF="http://www.celocom.com">Celo Communications</A>
version:2.1
email;internet:[email-masked]
title:Software Artist
adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN
note;quoted-printable:<br>=0D=0A<table border=3D0>=0D=0A<tr>=0D=0A  <td bgcolor=3D"#00ffff">c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A      to hide something from one, to keep secret, to conceal.=0D=0A  </td>=0D=0A</tr>=0D=0A</table>=0D=0A<br>=0D=0A<table border=3D3>=0D=0A<tr>=0D=0A <td>=0D=0A  <table>=0D=0A  <tr>=0D=0A   <td valign=3Dtop>o/~</td>=0D=0A   <td><font size=3D-1>Coding, coding, coding</font><br>=0D=0A          Keep'em hackers coding<br>=0D=0A          <font size=3D+1>And When They're Done Coding</font><br>=0D=0A          <font size=3D7>COMPIIIIIIILE!!</font></td>=0D=0A  </tr>=0D=0A  </table>=0D=0A </td>=0D=0A</tr>=0D=0A</table>
fn:Richard Levitte
end:vcard

--------------AD2D79ACC7B93080CDF26B92--

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Oct 2000 14:44:20 +0200 (MET DST)
To: [email-masked]
Subject: RE: unsubscibe

Each message includes this information.

Content-return: allowed
Date: Wed, 11 Oct 2000 05:30:16 -0700
From: Frank Balluffi <[email-masked]>
Subject: RE: unsubscibe
To: "[email-masked]'" <[email-masked]>

Sorry for the spam, but http://www.ietf.org/html.charters/pkix-charter.html
does not appear to contain directions for unsubscribing (or at least I don't
see them) nor does it contain directions for where to send this message.

Frank

From: "Christopher S. Francis" <[email-masked]>
To: "Manger, James H" <[email-masked]>, <[email-masked]>
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies
Date: Wed, 11 Oct 2000 08:51:20 -0400
Importance: Normal

James,

-----Original Message-----
From: Manger, James H [mailto:[email-masked]]
Sent: Tuesday, October 10, 2000 9:32 PM
To: [email-masked]
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
andProxies

.. .snip
In the general case trusting an arbitrary combination of CAs and AAs (even
if they all individually do their job correctly) is insecure when verifying
an AC that only contains the holder name - as Polar described.

However, this is NOT a good reason to mandate extra fields.  It is possible
to securely verify an AC that only contains the holder name as long as the
relying party's set of trusted CAs and AAs have some commonality in their
naming schemes.  It is sufficient that the same name cannot be issued to
different entities by different CAs and AAs in this trusted collection.
....end snip
[Chris Francis - WetStone Technologies] It seems reasonable then to assert
that a relying party's list of trusted SOAs should have unique Distinguished
Names.  This is something that the RP has complete control over and it
avoids the whole problem.  I suspect that many implementations already
impose a similar limitation on the list of trusted roots for PKC validation.
Chris

Content-return: allowed
Date: Wed, 11 Oct 2000 05:30:16 -0700
From: Frank Balluffi <[email-masked]>
Subject: RE: unsubscibe
To: "[email-masked]'" <[email-masked]>

Sorry for the spam, but http://www.ietf.org/html.charters/pkix-charter.html
does not appear to contain directions for unsubscribing (or at least I don't
see them) nor does it contain directions for where to send this message.

Frank

> From: J Johnen [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2000 9:22 PM
> To: Polar Humenn
> Cc: Al Arsenault; Stephen Farrell; Patrik =?UNKNOWN?Q?F=E4ltstr=F6m?=;
> [email-masked]; [email-masked]; Thumrongsak 
> Kosiyatrakul; Shiu-Kai
> Chin; Susan Older
> Subject: unsubscibe
> 
> 
> unsubscribe me from this list, please.
> 
> Polar Humenn wrote:
> 
> > On Tue, 10 Oct 2000, Paul Krumviede wrote:
> >
> > > "The requested URL /~tkosiyat/Paper/High_Assurance_X509.ps was not
> > found on
> > > this server."
> > >
> > > -paul
> > >
> > > --On Tuesday, 10 October, 2000 15:27 -0400 Polar Humenn
> > <[email-masked]>
> > > wrote:
> > >
> > > > http://caliper.syr.edu/~tkosiyat/Paper/High_Assurance_X509.ps
> > >
> > >
> >
> > Opps Sorry, The corrected URL is
> >
> >  http://caliper.syr.edu/~tkosiyat/Papers/High_Assurance_X509.ps
> >
> > Cheers,
> > -Polar
> >

Date: Wed, 11 Oct 2000 10:54:43 +0300
From: Camillo =?iso-8859-1?Q?S=E4rs?= <[email-masked]>
Organization: F-Secure Corporation
To: Bob Jueneman <[email-masked]>, [email-masked]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders,Targets  andProxies

Bob Jueneman wrote:
> But I have to say that this seems like one case where our colleagues in 
> the (moribund?) SPKI group may have a very valid point.  The connection 
> between the attribute cert and the identity cert should not be based on 
> the name, nor on the issuer/serial, but on the KEY contained in the 
> identity cert, or better yet on a message digest of the entire > referenced certificate.

Actually, there is no need to be that strict.  Correct me if I'm wrong, but
the underlying problem here is name space collisions.  I.e. the CA and AA
name spaces may overlap, leading to problems in interpreting names.  The
SPKI group also recognized the need for name certificates, as a tool for
indirection and grouping, but the SPKI name spaces are always locally
defined and rooted in a public key.  No assumption on global names are
present.

One of the proposed solutions here required the trusted CA and AA name
spaces to be "reasonable".  With the rapid increase in available TTP CA
certificates, I feel this assumption is insecure.  If Attribute Certs are
to be generally applicable, we must base their security on some other
property.

My opinion is that using the Object Digest would unnecessarily bind the
Attribute Cert to the actual issued Identity Cert.  If the digest would
only be over the key, the usefulness of the DN would be removed.  If the
cert would be referenced, the Attribute Cert validity period would be
limited by that of the Identity Cert (as in SPKI).

A useful solution to this problem would tie the Attribute Cert to the
issuing entity that issued the Identity Cert in an unambiguous fashion. 
I.e. the Attribute Cert must identify not only the DN, but a relevant
trusted root CA.  Is this requirement too strict?

Regards,
Camillo
-- 
Camillo S�rs <[email-masked]>       http://www.iki.fi/ged/
Researcher, F-Secure Corporation               http://www.F-Secure.com

   F-Secure products: Securing the Mobile, Distributed Enterprise

Date: Tue, 10 Oct 2000 21:30:14 -0400
To: "Bob Jueneman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders,  Targets andProxies
Cc: <[email-masked]>

Bob,

One could choose to mandate an AC binding to the subject's public key 
or the whole cert, rather than to a name, but that causes the 
undesirable effect of mating the AC's validity to the base cert 
validity.  ACs have chosen to not require such a binding, although to 
allow it as an option, preferring instead to allow a more general 
binding, which has attendant security concerns. SPKI chose one of the 
three options ACs offer, which has security benefits, but also 
management problems.

Steve

From: Michael Zolotarev <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: TSP: Response to the comments raised by Russ Housley
Date: Wed, 11 Oct 2000 12:57:14 +1000

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

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

Francois,
I tend to agree with Ross, favoring using just a policy OID. 
 
The reasoning is that a diligent client - since only 'diligent' clients
would be ever interested in reading practice statements - would have to read
the statement before(!) making the very first transaction. So the
information should be available prior to obtaining a timestamp.
 
Anticipating your argument - no, there are better ways of finding references
to the TSA practice statement than executing a 'void' transaction to get the
reference from a timestamp. The SubjectInformationAccess extension in the
TSA cert is a possible one, in addition to other less sophisticated ones.
 
regards
Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, 11 October 2000 0:37
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: TSP: Response to the comments raised by Russ Housley

Russ, 

What don't you like in policy qualifiers? 

I still think it would be useful to have the option to include a link to the
practice statement of the TSA within each time stamping response. Although I
understand that no automated processing is currently done today with these
practice statements, once they are written in XML, maybe relying parties
could then start to do something with them. However, with no optional
pointer to the TSA practice statement, it will never be possible.

Regards, 

Francois 

>Russ, 
> 
> Thank you for your response. 
> 
> The only remaining issues are numbered 3 and 10. See my comments 
> embedded below. 
> 
>> Denis: 
>> 
[snip] 
>> 
>> 3. I am not satisfied.  I accept that this is not the place to define 
>> TSP policy or practice statements.  However, I do not think that the RFC 
>> 2459 syntax is appropriate for use in the TSP context.  Also, you ignored

>> my concern regarding qualifiers.  RFC 2459 contains: 
>> 
>>     PolicyInformation ::= SEQUENCE { 
>>          policyIdentifier   CertPolicyId, 
>>          policyQualifiers   SEQUENCE SIZE (1..MAX) OF 
>>                                  PolicyQualifierInfo OPTIONAL } 
>> 
>> I would prefer a structure that said "TSAPolicyId" instead of 
>> "CertPolicyId." Using "CertPolicyId" in this context will, in my 
>> opinion, confuse matters.  Also, I would like to omit policy qualifiers 
>> altogether.  I do not like them in certificate policies, and I would 
>> like to avoid them in TSA policies. 
> 
> I had corrected the text but I did not understood your were also 
> requesting an ASN.1 change. 
> Sorry about that misunderstanding. I agree with your request and I have 
> done the changes, i.e: 
> 
> TSAPolicyId ::= OBJECT IDENTIFIER 
> 
> and in the request: 
> 
> reqPolicy       TSAPolicyId    OPTIONAL, 
> 
> while in the response: 
> 
> policy          TSAPolicyId, 
> 
[snip] 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: TSP: Response to the comments raised by Russ Housley</TITLE>

<META content="MSHTML 5.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2>Francois,</FONT></SPAN></DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff size=2>I tend 
to agree with Ross, favoring using just a policy OID. </FONT></SPAN></DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff size=2>The 
reasoning is that a diligent client - since only 'diligent' clients would be 
ever interested in reading practice statements - would have to read the 
statement before(!) making the very first transaction. So the information should 
be available prior to obtaining a timestamp.</FONT></SPAN></DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2>Anticipating your argument - no, there are better ways of finding 
references to&nbsp;the TSA practice statement than executing a 'void' 
transaction to get the reference from a timestamp.&nbsp;The 
SubjectInformationAccess extension in the TSA cert is a possible one, in 
addition&nbsp;to other less sophisticated ones.</FONT></SPAN></DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2>regards</FONT></SPAN></DIV>
<DIV><SPAN class=911404802-11102000><FONT face=Arial color=#0000ff 
size=2>Michael</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> [email-masked] 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, 11 October 
  2000 0:37<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> [email-masked]; 
  [email-masked]<BR><B>Subject:</B> RE: TSP: Response to the comments 
  raised by Russ Housley<BR><BR></FONT></DIV>
  <P><FONT size=2>Russ,</FONT> </P>
  <P><FONT size=2>What don't you like in policy qualifiers?</FONT> </P>
  <P><FONT size=2>I still think it would be useful to have the option to include 
  a link to the practice statement of the TSA within each time stamping 
  response. Although I understand that no automated processing is currently done 
  today with these practice statements, once they are written in XML, maybe 
  relying parties could then start to do something with them. However, with no 
  optional pointer to the TSA practice statement, it will never be 
  possible.</FONT></P>
  <P><FONT size=2>Regards,</FONT> </P>
  <P><FONT size=2>Francois</FONT> </P>
  <P><FONT size=2>&gt;Russ,</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>&gt; Thank you for your response.</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt; The only remaining issues are numbered 3 and 10. See my 
  comments</FONT> <BR><FONT size=2>&gt; embedded below.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt;&gt; Denis:</FONT> <BR><FONT 
  size=2>&gt;&gt; </FONT><BR><FONT size=2>[snip]</FONT> <BR><FONT 
  size=2>&gt;&gt; </FONT><BR><FONT size=2>&gt;&gt; 3. I am not satisfied.&nbsp; 
  I accept that this is not the place to define</FONT> <BR><FONT size=2>&gt;&gt; 
  TSP policy or practice statements.&nbsp; However, I do not think that the 
  RFC</FONT> <BR><FONT size=2>&gt;&gt; 2459 syntax is appropriate for use in the 
  TSP context.&nbsp; Also, you ignored</FONT> <BR><FONT size=2>&gt;&gt; my 
  concern regarding qualifiers.&nbsp; RFC 2459 contains:</FONT> <BR><FONT 
  size=2>&gt;&gt; </FONT><BR><FONT size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; 
  PolicyInformation ::= SEQUENCE {</FONT> <BR><FONT 
  size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  policyIdentifier&nbsp;&nbsp; CertPolicyId,</FONT> <BR><FONT 
  size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  policyQualifiers&nbsp;&nbsp; SEQUENCE SIZE (1..MAX) OF</FONT> <BR><FONT 
  size=2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  PolicyQualifierInfo OPTIONAL }</FONT> <BR><FONT size=2>&gt;&gt; 
  </FONT><BR><FONT size=2>&gt;&gt; I would prefer a structure that said 
  "TSAPolicyId" instead of</FONT> <BR><FONT size=2>&gt;&gt; "CertPolicyId." 
  Using "CertPolicyId" in this context will, in my</FONT> <BR><FONT 
  size=2>&gt;&gt; opinion, confuse matters.&nbsp; Also, I would like to omit 
  policy qualifiers</FONT> <BR><FONT size=2>&gt;&gt; altogether.&nbsp; I do not 
  like them in certificate policies, and I would</FONT> <BR><FONT 
  size=2>&gt;&gt; like to avoid them in TSA policies.</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt; I had corrected the text but I did 
  not understood your were also</FONT> <BR><FONT size=2>&gt; requesting an ASN.1 
  change.</FONT> <BR><FONT size=2>&gt; Sorry about that misunderstanding. I 
  agree with your request and I have</FONT> <BR><FONT size=2>&gt; done the 
  changes, i.e:</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT size=2>&gt; 
  TSAPolicyId ::= OBJECT IDENTIFIER</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt; and in the request:</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt; reqPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  TSAPolicyId&nbsp;&nbsp;&nbsp; OPTIONAL,</FONT> <BR><FONT size=2>&gt;</FONT> 
  <BR><FONT size=2>&gt; while in the response:</FONT> <BR><FONT 
  size=2>&gt;</FONT> <BR><FONT size=2>&gt; 
  policy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  TSAPolicyId,</FONT> <BR><FONT size=2>&gt;</FONT> <BR><FONT 
  size=2>[snip]</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0332E.F5662C40--

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: TSP: Response to the comments raised by Russ Housley
Date: Tue, 10 Oct 2000 10:36:36 -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_01C03324.79580628
Content-Type: text/plain;
	charset="iso-8859-1"

Russ,

What don't you like in policy qualifiers?

I still think it would be useful to have the option to include a link to the
practice statement of the TSA within each time stamping response. Although I
understand that no automated processing is currently done today with these
practice statements, once they are written in XML, maybe relying parties
could then start to do something with them. However, with no optional
pointer to the TSA practice statement, it will never be possible.

Regards,

Francois

>Russ,
>
> Thank you for your response.
>
> The only remaining issues are numbered 3 and 10. See my comments
> embedded below.
> 
>> Denis:
>> 
[snip]
>> 
>> 3. I am not satisfied.  I accept that this is not the place to define
>> TSP policy or practice statements.  However, I do not think that the RFC
>> 2459 syntax is appropriate for use in the TSP context.  Also, you ignored
>> my concern regarding qualifiers.  RFC 2459 contains:
>> 
>>     PolicyInformation ::= SEQUENCE {
>>          policyIdentifier   CertPolicyId,
>>          policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>>                                  PolicyQualifierInfo OPTIONAL }
>> 
>> I would prefer a structure that said "TSAPolicyId" instead of
>> "CertPolicyId." Using "CertPolicyId" in this context will, in my
>> opinion, confuse matters.  Also, I would like to omit policy qualifiers
>> altogether.  I do not like them in certificate policies, and I would
>> like to avoid them in TSA policies.
>
> I had corrected the text but I did not understood your were also
> requesting an ASN.1 change.
> Sorry about that misunderstanding. I agree with your request and I have
> done the changes, i.e:
>
> TSAPolicyId ::= OBJECT IDENTIFIER
>
> and in the request:
>
> reqPolicy       TSAPolicyId    OPTIONAL,
>
> while in the response:
>
> policy          TSAPolicyId,
>
[snip]

------_=_NextPart_001_01C03324.79580628
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.2650.12">
<TITLE>RE: TSP: Response to the comments raised by Russ Housley</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>What don't you like in policy qualifiers?</FONT>
</P>

<P><FONT SIZE=3D2>I still think it would be useful to have the option =
to include a link to the practice statement of the TSA within each time =
stamping response. Although I understand that no automated processing =
is currently done today with these practice statements, once they are =
written in XML, maybe relying parties could then start to do something =
with them. However, with no optional pointer to the TSA practice =
statement, it will never be possible.</FONT></P>

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

<P><FONT SIZE=3D2>Francois</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Russ,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Thank you for your response.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The only remaining issues are numbered 3 and =
10. See my comments</FONT>
<BR><FONT SIZE=3D2>&gt; embedded below.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Denis:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>[snip]</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; 3. I am not satisfied.&nbsp; I accept that =
this is not the place to define</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; TSP policy or practice statements.&nbsp; =
However, I do not think that the RFC</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; 2459 syntax is appropriate for use in the =
TSP context.&nbsp; Also, you ignored</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; my concern regarding qualifiers.&nbsp; RFC =
2459 contains:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; PolicyInformation =
::=3D SEQUENCE {</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
policyIdentifier&nbsp;&nbsp; CertPolicyId,</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
policyQualifiers&nbsp;&nbsp; SEQUENCE SIZE (1..MAX) OF</FONT>
<BR><FONT =
SIZE=3D2>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
PolicyQualifierInfo OPTIONAL }</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I would prefer a structure that said =
&quot;TSAPolicyId&quot; instead of</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &quot;CertPolicyId.&quot; Using =
&quot;CertPolicyId&quot; in this context will, in my</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; opinion, confuse matters.&nbsp; Also, I =
would like to omit policy qualifiers</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; altogether.&nbsp; I do not like them in =
certificate policies, and I would</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; like to avoid them in TSA policies.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I had corrected the text but I did not =
understood your were also</FONT>
<BR><FONT SIZE=3D2>&gt; requesting an ASN.1 change.</FONT>
<BR><FONT SIZE=3D2>&gt; Sorry about that misunderstanding. I agree with =
your request and I have</FONT>
<BR><FONT SIZE=3D2>&gt; done the changes, i.e:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; TSAPolicyId ::=3D OBJECT IDENTIFIER</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; and in the request:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; reqPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TSAPolicyId&nbsp;&nbsp;&nbsp; OPTIONAL,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; while in the response:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
policy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
TSAPolicyId,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>[snip]</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C03324.79580628--

From: "Manger, James H" <[email-masked]>
To: [email-masked]
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies
Date: Wed, 11 Oct 2000 12:32:20 +1100

A relying party verifying an attribute certificate that only includes the
holder's name must match a name from an AA to a name from a CA.
 
Matching names from two sources is dangerous if the two sources can issued
the same name to different entities.  It is safe, however, if this cannot
occur.
 
In the general case trusting an arbitrary combination of CAs and AAs (even
if they all individually do their job correctly) is insecure when verifying
an AC that only contains the holder name - as Polar described.
 
However, this is NOT a good reason to mandate extra fields.  It is possible
to securely verify an AC that only contains the holder name as long as the
relying party's set of trusted CAs and AAs have some commonality in their
naming schemes.  It is sufficient that the same name cannot be issued to
different entities by different CAs and AAs in this trusted collection.
 
Use globally unambiguous names (e.g. DNS) or restrict your set of trusted
CAs and AAs for a given scenario.

It must not be mandated that attribute certificates be bound to public key
certificates - a major benefit of attribute certificates was separating
these two domains of control.
 
> what we really want to do here is issue privileges to a public key, not
just the name of one.
 
Absolutely not!  The whole idea is that the source of authority for a given
privilege knows who (by name) they want to assign it to, but does not care
what public key that person uses.  The cost is that the names used must be
unambiguous in a large context that just the AA.

Date: Tue, 10 Oct 2000 18:22:21 -0700
From: J Johnen <[email-masked]>
To: Polar Humenn <[email-masked]>
CC: Al Arsenault <[email-masked]>, Stephen Farrell <[email-masked]>, "Patrik F�ltstr�m" <[email-masked]>, [email-masked], [email-masked], Thumrongsak Kosiyatrakul <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan Older <[email-masked]>
Subject: unsubscibe

unsubscribe me from this list, please.

Polar Humenn wrote:

> On Tue, 10 Oct 2000, Paul Krumviede wrote:
>
> > "The requested URL /~tkosiyat/Paper/High_Assurance_X509.ps was not
> found on
> > this server."
> >
> > -paul
> >
> > --On Tuesday, 10 October, 2000 15:27 -0400 Polar Humenn
> <[email-masked]>
> > wrote:
> >
> > > http://caliper.syr.edu/~tkosiyat/Paper/High_Assurance_X509.ps
> >
> >
>
> Opps Sorry, The corrected URL is
>
>  http://caliper.syr.edu/~tkosiyat/Papers/High_Assurance_X509.ps
>
> Cheers,
> -Polar
>

Date: Tue, 10 Oct 2000 17:12:51 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Carlisle Adams <[email-masked]>
cc: Al Arsenault <[email-masked]>, Stephen Farrell <[email-masked]>, Patrik  Faltstrom <[email-masked]>, [email-masked], [email-masked], Thumrongsak Kosiyatrakul <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan Older <[email-masked]>
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

On Tue, 10 Oct 2000, Carlisle Adams wrote:

> > Sent: 	Tuesday, October 10, 2000 3:27 PM
> > To: 	Al Arsenault
> > Cc: 	Stephen Farrell; Patrik  Faltstrom; [email-masked];
> > [email-masked]; Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older
> > Subject: 	Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> > Targets  andProxies
> > 
> (...some text deleted...)
> 
> > The start of the solution is mandating the use of ObjectDigest, where
> > a digest can be verified against the Holder's Public Key or Public Key
> > Certificate. The question after that is where does one pull the
> > Holder's cert or public key from, should it not be readily available,
> > i.e. wasn't delivered with the AttributeCertificate. This would
> > constitute having the entire DN path to the Holders public key
> > certificate anyway, and using the ObjectDigest for verification of the
> > identity.
> 
> > Could we suggest a critical attribute extension that will contain the
> > path to the ObjectDigest?
>  
> Actually, the syntax in X.509 (2000) is that holder is a SEQUENCE of three
> optionals (general name, issuer/serial, and object digest).  If the group
> decides to do what you're suggesting, no new critical extension would be
> necessary; all the profile would have to do is mandate two (or all three) of
> the optional fields.

Not good enough. You still need a proper full DN path, (i.e. sequence of
DNs) from the root CA of the Holder's certificate. You need it to locate
the Holder's certificate to verify it against the ObjectDigest.

> Having said that, however, I'm still not convinced that there is a
> problem in the specifications.  The relying party has two chains of
> certificates: an AC chain; and a corresponding PKC chain.  BOTH chains
> have to validate properly (i.e., fit within specified name and path
> length constraints, etc., etc., AND terminate at a trusted public
> key).  The trusted public key of the AC Source-of-Authority (which may
> or may not be the same as the root CA, depending upon the model) must
> have been acquired via a secure out-of-band mechanism.  Given that
> both the AC path and the corresponding PKC path are validated by the
> relying party, where is the "logic hole" for the attack you're
> concerned about?

The hole is currently that the AA is allowed to certify that "Henry Ford"
has some privileges without stating the chain of authorities that defined
"Henry Ford"s name (and public key). 

If your system accepts identities from a number of different public key
certificate authorities, Henry Ford can come from two different trusted
CA's. Which Henry Ford really has the privileges? Information has been
thrown away.  In the current scenario, I may have to accept both, because
I wouldn't be able to tell which one the AC was pointing to. If you use
the Issuer Serial form, all you do is just push the problem up one level.

Now, if I had the ObjectDigest I could verify that the privileges belonged
to the Henry Ford to which they were issued. The only thing to do, is be
able to locate the public key certificate in the advent that I don't
already have it. That's why I sort of suggested a DN path critical
extension. Constrained environments wouldn't have to provide it, but
interoperable ones would to make any real sense of it.

As Bob really said, what we really want to do here is issue privileges to
a public key, not just the name of one.

Cheers,
-Polar

From: Carlisle Adams <[email-masked]>
To: Al Arsenault <[email-masked]>, "'Polar Humenn'" <[email-masked]>
Cc: Stephen Farrell <[email-masked]>, Patrik  Faltstrom <[email-masked]>, [email-masked], [email-masked], Thumrongsak Kosiyatrakul <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan Older <[email-masked]>
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies
Date: Tue, 10 Oct 2000 16:26:47 -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_01C032F8.6A0DEE70
Content-Type: text/plain

Hi Polar,

> Sent: 	Tuesday, October 10, 2000 3:27 PM
> To: 	Al Arsenault
> Cc: 	Stephen Farrell; Patrik  Faltstrom; [email-masked];
> [email-masked]; Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older
> Subject: 	Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> Targets  andProxies
> 
(...some text deleted...)

	The start of the solution is mandating the use of ObjectDigest,
where a
	digest can be verified against the Holder's Public Key or Public Key
	Certificate. The question after that is where does one pull the
Holder's
	cert or public key from, should it not be readily available, i.e.
wasn't
	delivered with the AttributeCertificate. This would constitute
having the
	entire DN path to the Holders public key certificate anyway, and
using 
	the ObjectDigest for verification of the identity.

	Could we suggest a critical attribute extension that will contain
the 
	path to the ObjectDigest?
 
Actually, the syntax in X.509 (2000) is that holder is a SEQUENCE of three
optionals (general name, issuer/serial, and object digest).  If the group
decides to do what you're suggesting, no new critical extension would be
necessary; all the profile would have to do is mandate two (or all three) of
the optional fields.

Having said that, however, I'm still not convinced that there is a problem
in the specifications.  The relying party has two chains of certificates:
an AC chain; and a corresponding PKC chain.  BOTH chains have to validate
properly (i.e., fit within specified name and path length constraints, etc.,
etc., AND terminate at a trusted public key).  The trusted public key of the
AC Source-of-Authority (which may or may not be the same as the root CA,
depending upon the model) must have been acquired via a secure out-of-band
mechanism.  Given that both the AC path and the corresponding PKC path are
validated by the relying party, where is the "logic hole" for the attack
you're concerned about?

Carlisle.

------_=_NextPart_001_01C032F8.6A0DEE70
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.67">
<TITLE>RE: Fwd: AttributeCertificates: Path Names to AC Holders, =
Targets  andProxies</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Polar =
Humenn[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Tuesday, October 10, 2000 3:27 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Al =
Arsenault</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Stephen =
Farrell; Patrik&nbsp; Faltstrom; [email-masked]; [email-masked]; =
Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older</FONT></P>

<P><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Re: Fwd: AttributeCertificates: Path Names to AC Holders, =
Targets&nbsp; andProxies</FONT>
</P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The start =
of the solution is mandating the use of ObjectDigest, where a</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">digest =
can be verified against the Holder's Public Key or Public Key</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Certificate. The question after that is where does one pull the =
Holder's</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">cert or =
public key from, should it not be readily available, i.e. wasn't</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">delivered =
with the AttributeCertificate. This would constitute having the</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">entire DN =
path to the Holders public key certificate anyway, and using </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">the =
ObjectDigest for verification of the identity.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Could we =
suggest a critical attribute extension that will contain the </FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">path to =
the ObjectDigest?</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Actually, =
the syntax in X.509 (2000) is that holder is a SEQUENCE of three =
optionals (general name, issuer/serial, and object digest).&nbsp; If =
the group decides to do what you're suggesting, no new critical =
extension would be necessary; all the profile would have to do is =
mandate two (or all three) of the optional fields.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Having =
said that, however, I'm still not convinced that there is a problem in =
the specifications.&nbsp; The relying party has two chains of =
certificates:&nbsp; an AC chain; and a corresponding PKC chain.&nbsp; =
BOTH chains have to validate properly (i.e., fit within specified name =
and path length constraints, etc., etc., AND terminate at a trusted =
public key).&nbsp; The trusted public key of the AC Source-of-Authority =
(which may or may not be the same as the root CA, depending upon the =
model) must have been acquired via a secure out-of-band =
mechanism.&nbsp; Given that both the AC path and the corresponding PKC =
path are validated by the relying party, where is the &quot;logic =
hole&quot; for the attack you're concerned about?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C032F8.6A0DEE70--

Date: Tue, 10 Oct 2000 16:11:09 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Bob Jueneman <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Thumrongsak Kosiyatrakul <[email-masked]>, Susan Older <[email-masked]>, Shiu-Kai Chin <[email-masked]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies

On Tue, 10 Oct 2000, Bob Jueneman wrote:

> There is nothing like wide-eyed child saying "Mommy, mommy, the
> Emperor doesn't have any clothes on!" to make the grown-ups wake up
> and take notice.  (No offense intended, Polar!)

No offense taken. :)

> But let me clear up a couple of possible misunderstandings.  In one
> message, Polar said that George#2 "steals" the attribute cert of
> George#1. I assume that by that he meant something like Al Arsenault's
> scenario, whereby George#2 gets a deliberately confusing certificate
> from a rogue CA, i.e., he did not simply steal George#1's private key.  
> I assume Polar understands, but I want to be sure.

Correct. I assume no public keys are stolen. The PKI is intact.

> Second, it should be obvious that the chain of trust from the
> root-level Attribute CA is every bit as important as the chain of
> trust involved in the identity CA chain.  If you don't trust the root,
> and every subordinate CA in the chain, with respect to some policy
> then you can hardly expect to trust the end-entity.  Unfortunately,
> adding more and more "trusted roots" to the various browsers and other
> relying party software makes the security weaker, not stronger -- a
> fact that the end users and some important vendors don't seem to have
> grasped yet.

Yep. I assume that there is a chain of Public Key Certificates verifying
the issuance of the attribute certificate, just like any PKCA issues
Public Key Certificates.

> But assuming that the Attribute CA's are credible, then the
> possibility of a collision in the issue name and serial number name
> space seems somewhat improbable, but not at all impossible.  In fact,
> an attacker could conceivably request certificates one at a time until
> a serial number collision did occur. Likewise, the DN name space could
> also collide. Maybe less likely in the case of someone named Jueneman
> or Arsenault, but highly likely in the case of a "Smith".

I agree.

> I'll confess that I have almost completely ignored the attribute
> certificate standards progression, because I am not yet sufficiently
> convinced as to the business case for such certificates to spend much
> time on them.
> 
> But I have to say that this seems like one case where our colleagues
> in the (moribund?) SPKI group may have a very valid point.  The
> connection between the attribute cert and the identity cert should not
> be based on the name, nor on the issuer/serial, but on the KEY
> contained in the identity cert, or better yet on a message digest of
> the entire referenced certificate.

Exactly.

> Assuming that is what the Object Digest represents, and based solely
> on my imperfect level of understanding, it seems to me that the DN
> and/or issuer/serial number relationship might be useful hints in
> trying to tack down the identity cert, but that the match MUST be
> based on an object digest of the entire certificate which is
> incorporated by reference.
>
> Isn't that why digital signatures were invented, so we could validate
> more than just the name of a document, but actually validate the
> content?

Exactly. At this point I think the ObjectDigest form of the Holder should
be mandated. Let there be a critical attribute extension that can be used
to locate the Holder's identity certificate. The question is should it's
existance be mandatory.

You need at least a DN path to a CA that you trust. The problem with
interoperability on a wide scale is that the AA probably needs to specify
the DN path all the way up to the Root CA of the Holder for which
privileges are requested.

Any other suggestions?

Cheers,
-Polar

> Bob
> 
> >>> Al Arsenault <[email-masked]> 10/10/00 09:10AM >>>
> Okay, I think I finally figured out what Polar is getting at here, but
> I'm not sure what the fix is.  Let me try to illustrate with an example. 
> 
> (We'll be picking on Stephen a little bit in this; nothing personal
> intended; apologies for any offense.  :-)
> 
> Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> Technologies, OU=Public CAs, CN=The CA". 
> That CA has a self signed certificate with subject and issuer both equal
> to the DN above.
> 
> Now, there is an end-user certificate issued under that CA.  The issuer
> field of that certificate will be the DN above; the subject field is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> CN=Stephen".
> 
> The serial number field will be something like "4434".
> 
> Now, an attribute authority has issued our friend Stephen an AC
> consistent with the proposed profile.  The "Holder" field in that AC can
> be one of three things, according to the proposed profile:
> 
> 	- it can be the issuer and serial number of the base PKC; that is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> 
> 	- it can be the entity name, which by the I-D MUST be "C=IE,
> O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> 
> 	- it can be an ObjectDigest - for which the I-D does not require
> support.
> 
> Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
> claim Stephen's legitimate AC as his own. So, he can set up his own CA
> and issue a self-signed certificate with the same name as the legitimate
> one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
> CA".  The KEY cannot be the same - we'll assume that the attacker
> doesn't know the root CA's private key, which is usually a reasonable
> assumption - but you can't stop the attacker from copying the names.
> Then, Al can use that certificate to issue a user certificate with the
> same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
> CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
> will be "4434", just like in the legitimate certificate.
> 
> Now, the question is, given the value of the "Holder" field in the AC,
> to which PKC does it correspond - Stephen's real one, or Al's forgery?
> Based on the Issuer/serial number option, you can't tell - both
> purported certs have identical issuer and serial number values. Based on
> the entityName option, you also can't tell - even though you've used the
> full DNs, they're identical; it's just the keys (and signature values,
> of course) that are different. Based on a Digest of the PKC or PK, you
> could tell.
> 
> Now - how realistic is this attack in practice? I don't know.  First of
> all, I as the attacker could simply fake an AC issuer's cert first,
> rather than start from the root CA.  Second, so what if I have managed
> to convince somebody that an AC goes with my PKC vice Stephen's - has it
> gained me anything useful?  I'm not sure. Third, this attack starts by
> exploiting the age-old issue with PKCs that you have to get the root
> CA's public key through some secure, out of band means in order to make
> everything work.
> 
> So I'm not sure what the solution to this is, other than reversing
> ourselves and mandating the ObjectDigest choice.  It's clearly not
> "include the entire DN vice just the CN". At this point, I think that
> the easiest thing to do may be to strengthen the warning in the Security
> Considerations section.  That is, explain this issue and that it may be
> a risk in some environments.  I don't think that we want to make any
> other changes at this point.
> 
> (If Stephen and Russ agree on that approach, I can propose a paragraph
> or two for the Security Considerations section. Otherwise, I'm at a loss
> for a solution.)
> 
> 			Al Arsenault
> 			Chief Security Architect
> 			Diversinet Corp.
> 
> 
> 
> 
> Polar Humenn wrote:
> > 
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> > 
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising and
> > > if it is an issue then it also applies to public key certificates (I think
> > > this is more or less what Carlisle was saying is a previous response to the
> > > PKIX list).
> > 
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> > 
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> > 
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> > 
> > In simplistic terms, With PKCs it's like saying:
> > 
> > "This is George Burns."
> > 
> > And with an Attribute Certificate, it's like saying:
> > 
> > "George has Cigars"
> > 
> > If you have a PKC that says
> > 
> > "This is George Bush"
> > 
> > Which George has the cigars?
> > 
> > Cheers,
> > -Polar
> > 
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik F�ltstr�m wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik F�ltstr�m, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[email-masked]>
> > > > >To: [email-masked] 
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your application
> > > > >does not have control over both clients and server, i.e. they both don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA, and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > > >identify a holder, proxy, or target of the Attribute Certificate because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates are
> > > > >signed by 5's public key. Here's one of my employees and his certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a attribute
> > > > >certificate to Henry Ford from General Motors so that he can access the
> > > > >Holden plant through the Internet. It is clearly not enough that I just
> > > > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we can verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a client using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number, then
> > > > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > > > >or not.  (Provided both the privilege service and target both trust the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to include
> > > > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates, which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > --
> > > ____________________________________________________________
> > > 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, 10 Oct 2000 15:48:24 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Al Arsenault <[email-masked]>
cc: Stephen Farrell <[email-masked]>, Patrik  =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, [email-masked], [email-masked], Thumrongsak Kosiyatrakul <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan Older <[email-masked]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

On Tue, 10 Oct 2000, Paul Krumviede wrote:

> "The requested URL /~tkosiyat/Paper/High_Assurance_X509.ps was not
found on
> this server."
>
> -paul
>
> --On Tuesday, 10 October, 2000 15:27 -0400 Polar Humenn
<[email-masked]>
> wrote:
>
> > http://caliper.syr.edu/~tkosiyat/Paper/High_Assurance_X509.ps
>
>

Opps Sorry, The corrected URL is

 http://caliper.syr.edu/~tkosiyat/Papers/High_Assurance_X509.ps

Cheers,
-Polar

Date: Tue, 10 Oct 2000 15:27:52 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Al Arsenault <[email-masked]>
cc: Stephen Farrell <[email-masked]>, Patrik  =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, [email-masked], [email-masked], Thumrongsak Kosiyatrakul <[email-masked]>, Shiu-Kai Chin <[email-masked]>, Susan Older <[email-masked]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

Hi Al,

Thanks for seeing the problem. Comments below:

On Tue, 10 Oct 2000, Al Arsenault wrote:

> Okay, I think I finally figured out what Polar is getting at here, but
> I'm not sure what the fix is.  Let me try to illustrate with an example. 
> 
> (We'll be picking on Stephen a little bit in this; nothing personal
> intended; apologies for any offense.  :-)
> 
> Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> Technologies, OU=Public CAs, CN=The CA". 
> That CA has a self signed certificate with subject and issuer both equal
> to the DN above.
> 
> Now, there is an end-user certificate issued under that CA.  The issuer
> field of that certificate will be the DN above; the subject field is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> CN=Stephen".
> 
> The serial number field will be something like "4434".
> 
> Now, an attribute authority has issued our friend Stephen an AC
> consistent with the proposed profile.  The "Holder" field in that AC can
> be one of three things, according to the proposed profile:
> 
> 	- it can be the issuer and serial number of the base PKC; that is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> 
> 	- it can be the entity name, which by the I-D MUST be "C=IE,
> O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> 
> 	- it can be an ObjectDigest - for which the I-D does not require
> support.

I think the ObjectDigest is truly the only way to go. However, it still
has problems. The object that is talked about must be able to be recalled
and identified. Otherwise the Attribute Certificate MUST ALWAYS be
delivered with the Holder's Public Key Certificate.

I don't believe that requiring the delivery of the Holders certificate is
unreasonable. Can something like this be mandated in this profile? I don't
see how. I only see that in specific protocols. Or am I wrong?

> Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
> claim Stephen's legitimate AC as his own. So, he can set up his own CA
> and issue a self-signed certificate with the same name as the legitimate
> one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
> CA".  The KEY cannot be the same - we'll assume that the attacker
> doesn't know the root CA's private key, which is usually a reasonable
> assumption - but you can't stop the attacker from copying the names.
> Then, Al can use that certificate to issue a user certificate with the
> same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
> CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
> will be "4434", just like in the legitimate certificate.
> 
> Now, the question is, given the value of the "Holder" field in the AC,
> to which PKC does it correspond - Stephen's real one, or Al's forgery?
> Based on the Issuer/serial number option, you can't tell - both
> purported certs have identical issuer and serial number values. Based on
> the entityName option, you also can't tell - even though you've used the
> full DNs, they're identical; it's just the keys (and signature values,
> of course) that are different. Based on a Digest of the PKC or PK, you
> could tell.
> 
> Now - how realistic is this attack in practice? I don't know.  

The "reality" approach is probably not a great way to reason about this
attack. The "reality" of attacks are always exploited in some form sooner
or later. For example, DES is not considered really good any more, as well
as low bit valued public keys. The arguments for them in their time was
the "reality" of the attack. That reason was just the "reality" of
computing power with respect to the time. However, here what we are
talking about is the "reality" of a glaring hole in the logic. It doesn't
take the reality of a lot of computing power to overcome this one.

> First of all, I as the attacker could simply fake an AC issuer's cert
> first, rather than start from the root CA.  Second, so what if I have
> managed to convince somebody that an AC goes with my PKC vice
> Stephen's - has it gained me anything useful?  I'm not sure. 

I try to look at things in a verifiable way. If I have a Henry Ford from
GM and a Henry Ford from Chyrsler and I have an Attribute Certificate
claiming that Henry Ford has some privilegse, I cannot really say to whom
the privileges belong unless I constrain my operating environment such
that I can throw one out, or deem it impossible, i.e. I don't trust
anything from GM.

The constrained environment approach is okay if I'm running a nuclear power
plant. However, it's not good enough I'm running an E-commerce site in
which I want identities defined by thousands of RA/CA's to be issued
privileges to buy stuff or get access to stuff. I just don't have that
control.

We've done some work on the verifiability of trust in the X.509 public
key directory frame work.

See http://caliper.syr.edu/~tkosiyat/Paper/High_Assurance_X509.ps

We would really like to extend this work to attribute certificates as
well, as it facilitates the need for privileges and delegation within the
X.509 framework. However, if we have holes such as this, it will not be
possible.

> Third, this attack starts by exploiting the age-old issue with PKCs
> that you have to get the root CA's public key through some secure, out
> of band means in order to make everything work.

Not quite so. I can provide this attack without knowing or forging any
private keys. I can be a legitimate user with a real public/private
keypair from a CA. All I need is a name "collision" at a lower level.

The mere fact that I can issue privileges to Henry Ford of GM MUST NOT
mean I have also inadvertently issued privileges to Henry Ford of Chrysler
in some other realm.

> So I'm not sure what the solution to this is, other than reversing
> ourselves and mandating the ObjectDigest choice.  It's clearly not
> "include the entire DN vice just the CN". At this point, I think that
> the easiest thing to do may be to strengthen the warning in the Security
> Considerations section.  That is, explain this issue and that it may be
> a risk in some environments.  I don't think that we want to make any
> other changes at this point.

I think only strengthening the wording is not really enough. That's like
telling people they SHOULD NOT use Username/Password schemes in the clear.
The mere fact that standards exist such as Telnet, FTP, etc, means we
can't get rid of them, and it's really tough to stop it from happening.

> (If Stephen and Russ agree on that approach, I can propose a paragraph
> or two for the Security Considerations section. Otherwise, I'm at a
> loss for a solution.)

The start of the solution is mandating the use of ObjectDigest, where a
digest can be verified against the Holder's Public Key or Public Key
Certificate. The question after that is where does one pull the Holder's
cert or public key from, should it not be readily available, i.e. wasn't
delivered with the AttributeCertificate. This would constitute having the
entire DN path to the Holders public key certificate anyway, and using the
ObjectDigest for verification of the identity.

Could we suggest a critical attribute extension that will contain the path
to the ObjectDigest?

Note, the same problem exists for ProxyInfo and TargetInfo attribute
extensions as well.

Cheers,
-Polar

> 			Al Arsenault
> 			Chief Security Architect
> 			Diversinet Corp.
> 
> 
> 
> 
> Polar Humenn wrote:
> > 
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> > 
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising and
> > > if it is an issue then it also applies to public key certificates (I think
> > > this is more or less what Carlisle was saying is a previous response to the
> > > PKIX list).
> > 
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> > 
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> > 
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> > 
> > In simplistic terms, With PKCs it's like saying:
> > 
> > "This is George Burns."
> > 
> > And with an Attribute Certificate, it's like saying:
> > 
> > "George has Cigars"
> > 
> > If you have a PKC that says
> > 
> > "This is George Bush"
> > 
> > Which George has the cigars?
> > 
> > Cheers,
> > -Polar
> > 
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik F�ltstr�m wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik F�ltstr�m, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[email-masked]>
> > > > >To: [email-masked]
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your application
> > > > >does not have control over both clients and server, i.e. they both don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA, and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > > >identify a holder, proxy, or target of the Attribute Certificate because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates are
> > > > >signed by 5's public key. Here's one of my employees and his certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a attribute
> > > > >certificate to Henry Ford from General Motors so that he can access the
> > > > >Holden plant through the Internet. It is clearly not enough that I just
> > > > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we can verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a client using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number, then
> > > > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > > > >or not.  (Provided both the privilege service and target both trust the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to include
> > > > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates, which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > --
> > > ____________________________________________________________
> > > 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, 10 Oct 2000 15:10:13 -0400
To: Al Arsenault <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies
Cc: Polar Humenn <[email-masked]>, Stephen Farrell <[email-masked]>, "Patrik  F�ltstr�m" <[email-masked]>, [email-masked], [email-masked]

Al:

I do not understand how the attacker's certificate path validates.  The 
self-signed certificate must be trusted.  That trust comes from procedures 
outside of either the PKC spec or the AC spec.

Maybe we need to make the language stronger about validating the PKC before 
using the AC.

Russ

At 11:10 AM 10/10/2000 -0400, Al Arsenault wrote:
>Okay, I think I finally figured out what Polar is getting at here, but
>I'm not sure what the fix is.  Let me try to illustrate with an example.
>
>(We'll be picking on Stephen a little bit in this; nothing personal
>intended; apologies for any offense.  :-)
>
>Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
>Technologies, OU=Public CAs, CN=The CA".
>That CA has a self signed certificate with subject and issuer both equal
>to the DN above.
>
>Now, there is an end-user certificate issued under that CA.  The issuer
>field of that certificate will be the DN above; the subject field is
>"C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
>CN=Stephen".
>
>The serial number field will be something like "4434".
>
>Now, an attribute authority has issued our friend Stephen an AC
>consistent with the proposed profile.  The "Holder" field in that AC can
>be one of three things, according to the proposed profile:
>
>         - it can be the issuer and serial number of the base PKC; that is
>"C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
>
>         - it can be the entity name, which by the I-D MUST be "C=IE,
>O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
>
>         - it can be an ObjectDigest - for which the I-D does not require
>support.
>
>Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
>claim Stephen's legitimate AC as his own. So, he can set up his own CA
>and issue a self-signed certificate with the same name as the legitimate
>one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
>CA".  The KEY cannot be the same - we'll assume that the attacker
>doesn't know the root CA's private key, which is usually a reasonable
>assumption - but you can't stop the attacker from copying the names.
>Then, Al can use that certificate to issue a user certificate with the
>same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
>CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
>will be "4434", just like in the legitimate certificate.
>
>Now, the question is, given the value of the "Holder" field in the AC,
>to which PKC does it correspond - Stephen's real one, or Al's forgery?
>Based on the Issuer/serial number option, you can't tell - both
>purported certs have identical issuer and serial number values. Based on
>the entityName option, you also can't tell - even though you've used the
>full DNs, they're identical; it's just the keys (and signature values,
>of course) that are different. Based on a Digest of the PKC or PK, you
>could tell.
>
>Now - how realistic is this attack in practice? I don't know.  First of
>all, I as the attacker could simply fake an AC issuer's cert first,
>rather than start from the root CA.  Second, so what if I have managed
>to convince somebody that an AC goes with my PKC vice Stephen's - has it
>gained me anything useful?  I'm not sure. Third, this attack starts by
>exploiting the age-old issue with PKCs that you have to get the root
>CA's public key through some secure, out of band means in order to make
>everything work.
>
>So I'm not sure what the solution to this is, other than reversing
>ourselves and mandating the ObjectDigest choice.  It's clearly not
>"include the entire DN vice just the CN". At this point, I think that
>the easiest thing to do may be to strengthen the warning in the Security
>Considerations section.  That is, explain this issue and that it may be
>a risk in some environments.  I don't think that we want to make any
>other changes at this point.
>
>(If Stephen and Russ agree on that approach, I can propose a paragraph
>or two for the Security Considerations section. Otherwise, I'm at a loss
>for a solution.)
>
>                         Al Arsenault
>                         Chief Security Architect
>                         Diversinet Corp.
>
>
>
>
>Polar Humenn wrote:
> >
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> >
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising and
> > > if it is an issue then it also applies to public key certificates (I 
> think
> > > this is more or less what Carlisle was saying is a previous response 
> to the
> > > PKIX list).
> >
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> >
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> >
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> >
> > In simplistic terms, With PKCs it's like saying:
> >
> > "This is George Burns."
> >
> > And with an Attribute Certificate, it's like saying:
> >
> > "George has Cigars"
> >
> > If you have a PKC that says
> >
> > "This is George Bush"
> >
> > Which George has the cigars?
> >
> > Cheers,
> > -Polar
> >
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik F�ltstr�m wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik F�ltstr�m, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[email-masked]>
> > > > >To: [email-masked]
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets 
> and Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your application
> > > > >does not have control over both clients and server, i.e. they both 
> don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of 
> naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA, 
> and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > > >identify a holder, proxy, or target of the Attribute Certificate 
> because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty 
> low on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates are
> > > > >signed by 5's public key. Here's one of my employees and his 
> certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For 
> example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a 
> attribute
> > > > >certificate to Henry Ford from General Motors so that he can 
> access the
> > > > >Holden plant through the Internet. It is clearly not enough that I 
> just
> > > > >define the "Holder" as using the Issuer-Serial form of 
> GeneralName, such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we 
> can verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a 
> client using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry 
> Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number, then
> > > > >there wouldn't even be a question of whether the AC applied to Ian 
> Botham
> > > > >or not.  (Provided both the privilege service and target both 
> trust the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to 
> include
> > > > >DN paths. Alternatively, I may suggest attribute extensions 
> (critical or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates, which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > --
> > > ____________________________________________________________
> > > 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, 10 Oct 2000 15:01:06 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: "Christopher S. Francis" <[email-masked]>
CC: Polar Humenn <[email-masked]>, Stephen Farrell  <[email-masked]>, "Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?="  <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

Christopher,

	If the relying party properly checks both the AC and purported PKC all
the way back to their trusted roots, and the RP has gotten the "right"
public key for the trusted root, then yes, this attack will be detected.

	First, I'll point out that the AC issuer's PK Cert may or may not chain
back to the same trusted root as the PK cert's of the holders to which
it issues certs.  (That is, in my example, the AC issuer's cert may
chain back to "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
CA", or to a different root.) The I-D is silent on this issue - properly
so, in my opinion.  

	But, that means that just checking the signature on the AC, and then
checking the AC Issuer's chain is not guaranteed to detect the attack.
If the AC Issuer's PK Cert chains back to a different root, also trusted
by the RP, then just doing that part of the check won't reveal the
attack. You have to check the purported PK Cert, too.

	Which is why I pointed out that it's not clear to me how meaningful
this attack is in practice.  If the RP does the whole job, the attack
should not work. If the RP does a lousy job, and just checks the AC and
accepts the purported PKC without checking, there's a problem in the
system. (It's the RP's fault, but there's still a problem in the
system.)  And if the RP finds Awful Al's PK Cert, tries to validate it
and fails and thus rejects the entire transaction without trying
Stephen's PK Cert, there may be a "denial of service" attack - about
which we may or may not care.

				Al Arsenault

"Christopher S. Francis" wrote:
> 
> Al,
> 
> I'm new here so forgive me if I'm missing something obvious, but in your
> example, doesn't the relying party have an obligation to verify the
> signature on the AC using a key that it is confident belongs to the Source
> Of Authority (or a key that can be traced back to an approved SOA)?  If the
> relying party in your example validates the AC in this way, the forged AC
> would fail the signature check.
> 
> What am I missing?
> 
> Christopher S. Francis
> WetStone Technologies, Inc.
> 935 Main Street, Suite A-1
> Safety Harbor, FL   34695
> (727) 642-8993
> http://www.wetstonetech.com/
> 
> From: Al Arsenault [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2000 11:10 AM
> To: Polar Humenn
> Cc: Stephen Farrell; Patrik F�ltstr�m; [email-masked];
> [email-masked]
> Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
> andProxies
> 
> Okay, I think I finally figured out what Polar is getting at here, but
> I'm not sure what the fix is.  Let me try to illustrate with an example.
> 
> (We'll be picking on Stephen a little bit in this; nothing personal
> intended; apologies for any offense.  :-)
> 
> Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> Technologies, OU=Public CAs, CN=The CA".
> That CA has a self signed certificate with subject and issuer both equal
> to the DN above.
> 
> Now, there is an end-user certificate issued under that CA.  The issuer
> field of that certificate will be the DN above; the subject field is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> CN=Stephen".
> 
> The serial number field will be something like "4434".
> 
> Now, an attribute authority has issued our friend Stephen an AC
> consistent with the proposed profile.  The "Holder" field in that AC can
> be one of three things, according to the proposed profile:
> 
>         - it can be the issuer and serial number of the base PKC; that is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> 
>         - it can be the entity name, which by the I-D MUST be "C=IE,
> O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> 
>         - it can be an ObjectDigest - for which the I-D does not require
> support.
> 
> Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
> claim Stephen's legitimate AC as his own. So, he can set up his own CA
> and issue a self-signed certificate with the same name as the legitimate
> one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
> CA".  The KEY cannot be the same - we'll assume that the attacker
> doesn't know the root CA's private key, which is usually a reasonable
> assumption - but you can't stop the attacker from copying the names.
> Then, Al can use that certificate to issue a user certificate with the
> same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
> CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
> will be "4434", just like in the legitimate certificate.
> 
> Now, the question is, given the value of the "Holder" field in the AC,
> to which PKC does it correspond - Stephen's real one, or Al's forgery?
> Based on the Issuer/serial number option, you can't tell - both
> purported certs have identical issuer and serial number values. Based on
> the entityName option, you also can't tell - even though you've used the
> full DNs, they're identical; it's just the keys (and signature values,
> of course) that are different. Based on a Digest of the PKC or PK, you
> could tell.
> 
> Now - how realistic is this attack in practice? I don't know.  First of
> all, I as the attacker could simply fake an AC issuer's cert first,
> rather than start from the root CA.  Second, so what if I have managed
> to convince somebody that an AC goes with my PKC vice Stephen's - has it
> gained me anything useful?  I'm not sure. Third, this attack starts by
> exploiting the age-old issue with PKCs that you have to get the root
> CA's public key through some secure, out of band means in order to make
> everything work.
> 
> So I'm not sure what the solution to this is, other than reversing
> ourselves and mandating the ObjectDigest choice.  It's clearly not
> "include the entire DN vice just the CN". At this point, I think that
> the easiest thing to do may be to strengthen the warning in the Security
> Considerations section.  That is, explain this issue and that it may be
> a risk in some environments.  I don't think that we want to make any
> other changes at this point.
> 
> (If Stephen and Russ agree on that approach, I can propose a paragraph
> or two for the Security Considerations section. Otherwise, I'm at a loss
> for a solution.)
> 
>                         Al Arsenault
>                         Chief Security Architect
>                         Diversinet Corp.
> 
> Polar Humenn wrote:
> >
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> >
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising
> and
> > > if it is an issue then it also applies to public key certificates (I
> think
> > > this is more or less what Carlisle was saying is a previous response to
> the
> > > PKIX list).
> >
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> >
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> >
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> >
> > In simplistic terms, With PKCs it's like saying:
> >
> > "This is George Burns."
> >
> > And with an Attribute Certificate, it's like saying:
> >
> > "George has Cigars"
> >
> > If you have a PKC that says
> >
> > "This is George Bush"
> >
> > Which George has the cigars?
> >
> > Cheers,
> > -Polar
> >
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik F�ltstr�m wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik F�ltstr�m, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[email-masked]>
> > > > >To: [email-masked]
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and
> Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your
> application
> > > > >does not have control over both clients and server, i.e. they both
> don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of
> naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA,
> and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough
> to
> > > > >identify a holder, proxy, or target of the Attribute Certificate
> because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty low
> on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates
> are
> > > > >signed by 5's public key. Here's one of my employees and his
> certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For
> example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden
> Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a
> attribute
> > > > >certificate to Henry Ford from General Motors so that he can access
> the
> > > > >Holden plant through the Internet. It is clearly not enough that I
> just
> > > > >define the "Holder" as using the Issuer-Serial form of GeneralName,
> such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we can
> verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a client
> using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry
> Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number,
> then
> > > > >there wouldn't even be a question of whether the AC applied to Ian
> Botham
> > > > >or not.  (Provided both the privilege service and target both trust
> the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to
> include
> > > > >DN paths. Alternatively, I may suggest attribute extensions (critical
> or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates,
> which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > --
> > > ____________________________________________________________
> > > 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, 10 Oct 2000 14:28:26 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: TSP: Response to the comments raised by Russ Housley
Cc: IETF-PXIX <[email-masked]>

Denis:

This is fine with me.

Russ

At 01:25 PM 10/10/2000 +0200, Denis Pinkas wrote:
>Russ,
>
> > Denis:
> >
> > I am happy with your response to number 3.  Now, for number 10.  How about
> > something like the following:
> >
> >      For the <list your types here> MIME types, implementations SHOULD
>
>I did not realized first why you were leaving the types empty, :-)
>... until I found the acronym collision between
>application/timestamp-request (TSR) and application/timestamp-response
>(TSR).
>
>Here is a proposal to solve this acronym collision:
>
>For the application/timestamp-query and application/timestamp-reply MIME
>types, implementations SHOULD include the optional "name" and "filename"
>parameters. Including a file name serves helps preserve type information
>when timestamps are saved as files.  When these parameters are included, a
>file name with the appropriate extension SHOULD be selected:
>
>        MIME Type                     File Extension
>
>   application/timestamp-query            .TSQ
>   application/timestamp-reply            .TSR
>
>In addition, the file name SHOULD be limited to eight characters followed by
>a three letter extension. The eight character filename base can be any
>distinct name.
>
>Would that text be OK with you ?
>
>Regards,
>
>Denis
>
> >      include the optional "name" and "filename" parameters.  Including a
> >      file name serves helps preserve type information when timestamps are
> >      saved as files.  When these parameters are included, a file name with
> >      the appropriate extension SHOULD be selected:
> >
> >        MIME Type                     File Extension
> >
> >          <your request type>           .<your request extension>
> >
> >          <your response type>          .<your response extension>
> >
> >          ...
> >
> >      In addition, the file name SHOULD be limited to eight characters
> >      followed by a three letter extension. The eight character filename
> >      base can be any distinct name.
> >
> > Russ

Date: Tue, 10 Oct 2000 12:13:42 -0600
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies

There is nothing like wide-eyed child saying "Mommy, mommy, the Emperor doesn't have any clothes on!" to make the grown-ups wake up and take notice.  (No offense intended, Polar!)

But let me clear up a couple of possible misunderstandings.  In one message, Polar said that George#2 "steals" the attribute cert of George#1. I assume that by that he meant something like Al Arsenault's scenario, whereby George#2 gets a deliberately confusing certificate from a rogue CA, i.e., he did not simply steal George#1's private key.  I assume Polar understands, but I want to be sure.

Second, it should be obvious that the chain of trust from the root-level Attribute CA is every bit as important as the chain of trust involved in the identity CA chain.  If you don't trust the root, and every subordinate CA in the chain, with respect to some policy then you can hardly expect to trust the end-entity.  Unfortunately, adding more and more "trusted roots" to the various browsers and other relying party software makes the security weaker, not stronger -- a fact that the end users and some important vendors don't seem to have grasped yet.

But assuming that the Attribute CA's are credible, then the possibility of a collision in the issue name and serial number name space seems somewhat improbable, but not at all impossible.  In fact, an attacker could conceivably request certificates one at a time until a serial number collision did occur. Likewise, the DN name space could also collide. Maybe less likely in the case of someone named Jueneman or Arsenault, but highly likely in the case of a "Smith".

I'll confess that I have almost completely ignored the attribute certificate standards progression, because I am not yet sufficiently convinced as to the business case for such certificates to spend much time on them.

But I have to say that this seems like one case where our colleagues in the (moribund?) SPKI group may have a very valid point.  The connection between the attribute cert and the identity cert should not be based on the name, nor on the issuer/serial, but on the KEY contained in the identity cert, or better yet on a message digest of the entire referenced certificate.  

Assuming that is what the Object Digest represents, and based solely on my imperfect level of understanding, it seems to me that the DN and/or issuer/serial number relationship might be useful hints in trying to tack down the identity cert, but that the match MUST be based on an object digest of the entire certificate which is incorporated by reference.

Isn't that why digital signatures were invented, so we could validate more than just the name of a document, but actually validate the content?

Bob

>>> Al Arsenault <[email-masked]> 10/10/00 09:10AM >>>
Okay, I think I finally figured out what Polar is getting at here, but
I'm not sure what the fix is.  Let me try to illustrate with an example. 

(We'll be picking on Stephen a little bit in this; nothing personal
intended; apologies for any offense.  :-)

Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
Technologies, OU=Public CAs, CN=The CA". 
That CA has a self signed certificate with subject and issuer both equal
to the DN above.

Now, there is an end-user certificate issued under that CA.  The issuer
field of that certificate will be the DN above; the subject field is
"C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
CN=Stephen".

The serial number field will be something like "4434".

Now, an attribute authority has issued our friend Stephen an AC
consistent with the proposed profile.  The "Holder" field in that AC can
be one of three things, according to the proposed profile:

	- it can be the issuer and serial number of the base PKC; that is
"C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"

	- it can be the entity name, which by the I-D MUST be "C=IE,
O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"

	- it can be an ObjectDigest - for which the I-D does not require
support.

Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
claim Stephen's legitimate AC as his own. So, he can set up his own CA
and issue a self-signed certificate with the same name as the legitimate
one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
CA".  The KEY cannot be the same - we'll assume that the attacker
doesn't know the root CA's private key, which is usually a reasonable
assumption - but you can't stop the attacker from copying the names.
Then, Al can use that certificate to issue a user certificate with the
same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
will be "4434", just like in the legitimate certificate.

Now, the question is, given the value of the "Holder" field in the AC,
to which PKC does it correspond - Stephen's real one, or Al's forgery?
Based on the Issuer/serial number option, you can't tell - both
purported certs have identical issuer and serial number values. Based on
the entityName option, you also can't tell - even though you've used the
full DNs, they're identical; it's just the keys (and signature values,
of course) that are different. Based on a Digest of the PKC or PK, you
could tell.

Now - how realistic is this attack in practice? I don't know.  First of
all, I as the attacker could simply fake an AC issuer's cert first,
rather than start from the root CA.  Second, so what if I have managed
to convince somebody that an AC goes with my PKC vice Stephen's - has it
gained me anything useful?  I'm not sure. Third, this attack starts by
exploiting the age-old issue with PKCs that you have to get the root
CA's public key through some secure, out of band means in order to make
everything work.

So I'm not sure what the solution to this is, other than reversing
ourselves and mandating the ObjectDigest choice.  It's clearly not
"include the entire DN vice just the CN". At this point, I think that
the easiest thing to do may be to strengthen the warning in the Security
Considerations section.  That is, explain this issue and that it may be
a risk in some environments.  I don't think that we want to make any
other changes at this point.

(If Stephen and Russ agree on that approach, I can propose a paragraph
or two for the Security Considerations section. Otherwise, I'm at a loss
for a solution.)

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

Polar Humenn wrote:
> 
> On Sun, 8 Oct 2000, Stephen Farrell wrote:
> 
> >
> > Hi,
> >
> > As I've said to Polar previously, I don't see what issue he's raising and
> > if it is an issue then it also applies to public key certificates (I think
> > this is more or less what Carlisle was saying is a previous response to the
> > PKIX list).
> 
> As I have said before. I do not have a problem with PK certificates
> because they are usually accompanied by *Verifying* certificates. Even if
> you only get one public key certificate for a subject say from a client
> program, you must *have* the issuer's certificate to verify it.
> 
> For a contrived example, say you may could have two different issuer PKCs
> with the same DN. Only one of those certificates will verify the subject's
> certificate. That argument recursively completes the naming path to its
> root.
> 
> With the AttributeCertificate it is different, because you only name the
> "Holder", and not the path from its root, which is indeed its entire name.
> In the attribute certificate there is no "Holder" certificate that can be
> verified. There is no other evidence tying the holder to its issuer
> completing its name. Therefore, there is abolutely no definiative way to
> complete its entire name. Even if you use the Issuer-Serial form, the name
> of the Issuer has the same problem. The only time that works is when the
> issuer of the holder's identity is a root CA. The issuer of the holder's
> identity might be a CA other than a root CA.
> 
> In simplistic terms, With PKCs it's like saying:
> 
> "This is George Burns."
> 
> And with an Attribute Certificate, it's like saying:
> 
> "George has Cigars"
> 
> If you have a PKC that says
> 
> "This is George Bush"
> 
> Which George has the cigars?
> 
> Cheers,
> -Polar
> 
> > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > "fix" is to change the definition of GeneralName (and hence the base
> > X.509-2000 and rfc2459 as well as the AC profile).
> >
> > Maybe its me - can anyone else see the issue?
> >
> > Regards,
> > Stephen.
> >
> > Patrik F�ltstr�m wrote:
> > >
> > > This should be discussed on the PKIX mailing list.
> > >
> > > Please discuss...
> > >
> > >      Patrik F�ltstr�m, Area Director Applications Area, IETF
> > >
> > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > >From: Polar Humenn <[email-masked]>
> > > >To: [email-masked] 
> > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > > >
> > > >
> > > >
> > > >Greetings IETF,
> > > >
> > > >This is Polar Humenn with the Object Management Group (OMG).
> > > >
> > > >I have some questions about total interoperability about the PKIX
> > > >Attribute Certificate when used in environments where your application
> > > >does not have control over both clients and server, i.e. they both don't
> > > >subscribe to the same LDAP server.
> > > >
> > > >I have some problems regarding the use of GeneralName for the Holder,
> > > >Proxies and Targets fields of the AttributeCertificate.
> > > >
> > > >When using DN's for these names, they only specify one level of naming.
> > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > >certain authority. Specifically, they do not name the Holder's CA, and its
> > > >CA, and so on.
> > > >
> > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > >identify a holder, proxy, or target of the Attribute Certificate because
> > > >it has the same problem in identifying the issuer.
> > > >
> > > >Let me illustrate a security hole that this specification has:
> > > >
> > > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > > >the totem pole, because of my organizational structure. My identity
> > > >certificate has a path from a real trusted authority, such as:
> > > >
> > > >1. CN=Baltimore
> > > >2. CN=General Motors
> > > >3. CN=Manufacturing
> > > >4. CN=Engineering, L=Germany
> > > >5. CN=Human Resources
> > > >
> > > >All my employee identities are defined by 5 and their certificates are
> > > >signed by 5's public key. Here's one of my employees and his certificate
> > > >serial number:
> > > >
> > > >6. CN=Henry Ford      Serial#=1234
> > > >
> > > >I obviously listed the chain with 1 as the most significant. For example,
> > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > >certificates.
> > > >
> > > >And now for something completely different, let's switch to Holden Car
> > > >Company, Australia.
> > > >
> > > >The privilege service that Holden subscribes to wants to issue a attribute
> > > >certificate to Henry Ford from General Motors so that he can access the
> > > >Holden plant through the Internet. It is clearly not enough that I just
> > > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > > >as:
> > > >
> > > >CN=Human Resources
> > > >Serial#=1234
> > > >
> > > >I really have to fully define the path of the holder so that we can verify
> > > >that the attribute certificate actually applies to the identity I am
> > > >presented with.
> > > >
> > > >For a contrived example, let's say the GM has authenticated a client using
> > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > >CN=Verisign). The authentication provides me with the following cert
> > > >chain, which the GM plant has verified:
> > > >
> > > >1. CN=Verisign
> > > >2. CN=Holden
> > > >3. CN=Human Resources
> > > >4. CN=Ian Botham, Serial#=1234
> > > >
> > > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > > >
> > > >Does it match? Yes, it sure does.
> > > >Should this happen? Obviously not.
> > > >
> > > >I know it's a bit contrived, but it is a security hole.
> > > >
> > > >Now, if the Holder contained the name path to that serial number, then
> > > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > > >or not.  (Provided both the privilege service and target both trust the
> > > >same named high-level certificates, such as Verisign or Baltimore for
> > > >verification).
> > > >
> > > >The same goes for the naming of the targets and proxies.
> > > >
> > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > >Fords at both GM and Holden.
> > > >
> > > >What can we do about this problem?
> > > >
> > > >I would suggest either changing the definition of GeneralName to include
> > > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > > >non-critical?) that complete the path from the Holder, proxies, or
> > > >targets.
> > > >
> > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > >because that will be followed by some verifying PK certificates, which
> > > >consequently defines the issuers name path.
> > > >
> > > >Any comments?
> > > >
> > > >Cheers and Thanks,
> > > >-Polar
> > > >
> > --
> > ____________________________________________________________
> > 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, 10 Oct 2000 14:03:39 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: "Christopher S. Francis" <[email-masked]>
cc: Al Arsenault <[email-masked]>, Stephen Farrell <[email-masked]>, =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies

Hi Al,

The issue that you point out, is outside the AC. The fact is that you need
a chain of PK certificates to verify the authenticity of the AC is a
Public Key verification issue of a statement. It only implies that the AC
came from an entity that you may or may not trust.

What you imply after that is what we are talking about.

Cheers,
-Polar
 
 On Tue, 10 Oct 2000, Christopher S. Francis wrote:

> Al,
> 
> I'm new here so forgive me if I'm missing something obvious, but in your
> example, doesn't the relying party have an obligation to verify the
> signature on the AC using a key that it is confident belongs to the Source
> Of Authority (or a key that can be traced back to an approved SOA)?  If the
> relying party in your example validates the AC in this way, the forged AC
> would fail the signature check.
> 
> What am I missing?
> 
> Christopher S. Francis
> WetStone Technologies, Inc.
> 935 Main Street, Suite A-1
> Safety Harbor, FL   34695
> (727) 642-8993
> http://www.wetstonetech.com/
> 
> From: Al Arsenault [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2000 11:10 AM
> To: Polar Humenn
> Cc: Stephen Farrell; Patrik F�ltstr�m; [email-masked];
> [email-masked]
> Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
> andProxies
> 
> Okay, I think I finally figured out what Polar is getting at here, but
> I'm not sure what the fix is.  Let me try to illustrate with an example.
> 
> (We'll be picking on Stephen a little bit in this; nothing personal
> intended; apologies for any offense.  :-)
> 
> Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> Technologies, OU=Public CAs, CN=The CA".
> That CA has a self signed certificate with subject and issuer both equal
> to the DN above.
> 
> Now, there is an end-user certificate issued under that CA.  The issuer
> field of that certificate will be the DN above; the subject field is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> CN=Stephen".
> 
> The serial number field will be something like "4434".
> 
> Now, an attribute authority has issued our friend Stephen an AC
> consistent with the proposed profile.  The "Holder" field in that AC can
> be one of three things, according to the proposed profile:
> 
>         - it can be the issuer and serial number of the base PKC; that is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> 
>         - it can be the entity name, which by the I-D MUST be "C=IE,
> O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> 
>         - it can be an ObjectDigest - for which the I-D does not require
> support.
> 
> Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
> claim Stephen's legitimate AC as his own. So, he can set up his own CA
> and issue a self-signed certificate with the same name as the legitimate
> one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
> CA".  The KEY cannot be the same - we'll assume that the attacker
> doesn't know the root CA's private key, which is usually a reasonable
> assumption - but you can't stop the attacker from copying the names.
> Then, Al can use that certificate to issue a user certificate with the
> same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
> CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
> will be "4434", just like in the legitimate certificate.
> 
> Now, the question is, given the value of the "Holder" field in the AC,
> to which PKC does it correspond - Stephen's real one, or Al's forgery?
> Based on the Issuer/serial number option, you can't tell - both
> purported certs have identical issuer and serial number values. Based on
> the entityName option, you also can't tell - even though you've used the
> full DNs, they're identical; it's just the keys (and signature values,
> of course) that are different. Based on a Digest of the PKC or PK, you
> could tell.
> 
> Now - how realistic is this attack in practice? I don't know.  First of
> all, I as the attacker could simply fake an AC issuer's cert first,
> rather than start from the root CA.  Second, so what if I have managed
> to convince somebody that an AC goes with my PKC vice Stephen's - has it
> gained me anything useful?  I'm not sure. Third, this attack starts by
> exploiting the age-old issue with PKCs that you have to get the root
> CA's public key through some secure, out of band means in order to make
> everything work.
> 
> So I'm not sure what the solution to this is, other than reversing
> ourselves and mandating the ObjectDigest choice.  It's clearly not
> "include the entire DN vice just the CN". At this point, I think that
> the easiest thing to do may be to strengthen the warning in the Security
> Considerations section.  That is, explain this issue and that it may be
> a risk in some environments.  I don't think that we want to make any
> other changes at this point.
> 
> (If Stephen and Russ agree on that approach, I can propose a paragraph
> or two for the Security Considerations section. Otherwise, I'm at a loss
> for a solution.)
> 
>                         Al Arsenault
>                         Chief Security Architect
>                         Diversinet Corp.
> 
> 
> 
> 
> Polar Humenn wrote:
> >
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> >
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising
> and
> > > if it is an issue then it also applies to public key certificates (I
> think
> > > this is more or less what Carlisle was saying is a previous response to
> the
> > > PKIX list).
> >
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> >
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> >
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> >
> > In simplistic terms, With PKCs it's like saying:
> >
> > "This is George Burns."
> >
> > And with an Attribute Certificate, it's like saying:
> >
> > "George has Cigars"
> >
> > If you have a PKC that says
> >
> > "This is George Bush"
> >
> > Which George has the cigars?
> >
> > Cheers,
> > -Polar
> >
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik F�ltstr�m wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik F�ltstr�m, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[email-masked]>
> > > > >To: [email-masked]
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and
> Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your
> application
> > > > >does not have control over both clients and server, i.e. they both
> don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of
> naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA,
> and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough
> to
> > > > >identify a holder, proxy, or target of the Attribute Certificate
> because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty low
> on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates
> are
> > > > >signed by 5's public key. Here's one of my employees and his
> certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For
> example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden
> Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a
> attribute
> > > > >certificate to Henry Ford from General Motors so that he can access
> the
> > > > >Holden plant through the Internet. It is clearly not enough that I
> just
> > > > >define the "Holder" as using the Issuer-Serial form of GeneralName,
> such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we can
> verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a client
> using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry
> Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number,
> then
> > > > >there wouldn't even be a question of whether the AC applied to Ian
> Botham
> > > > >or not.  (Provided both the privilege service and target both trust
> the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to
> include
> > > > >DN paths. Alternatively, I may suggest attribute extensions (critical
> or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates,
> which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > --
> > > ____________________________________________________________
> > > 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, 10 Oct 2000 16:31:28 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Al Arsenault <[email-masked]>
CC: Polar Humenn <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

Hi Al,

You've highlighted why this is *not* an AC issue. As you've correctly 
pointed out its a root CA information distribution issue and is addressed 
by rfc2459 and son-of-2459. If I can corrupt a relying party's store of 
root CA information, then I can do *lots* more damage than just try 
steal an existing AC.

If new security considerations belong anywhere then its in son-of-2459,
but that already says:

  "The quality of implementations that process certificates may also
   affect the degree of assurance provided.  The path validation algo-
   rithm described in section 6 relies upon the integrity of the trusted
   CA information, and especially the integrity of the public keys asso-
   ciated with the trusted CAs.  By substituting public keys for which
   an attacker has the private key, an attacker could trick the user
   into accepting false certificates."

I could possibly (just to kill the thread:-) buy including an equivalent 
paragraph in the AC profile, since its no harm in itself, but I don't want 
to start turning the security considerations section of the AC profile 
into a PKI tutorial - if we accepted that logic, then shouldn't the same 
paragraph then be present in all specifications that use PKI? Seems silly 
to me since one of the big reasons for PKIX existing in the first place
is to collect such things in one place.

On balance, I'd expect implementers of the AC profile to be familiar enough 
with PKI to know that root CA information has to be protected and would
prefer not to change the draft. ('Course if there's a consensus to do it,
I'll do it.)

Stephen.

Al Arsenault wrote:
> 
> Okay, I think I finally figured out what Polar is getting at here, but
> I'm not sure what the fix is.  Let me try to illustrate with an example.
> 
> (We'll be picking on Stephen a little bit in this; nothing personal
> intended; apologies for any offense.  :-)
> 
> Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
> Technologies, OU=Public CAs, CN=The CA".
> That CA has a self signed certificate with subject and issuer both equal
> to the DN above.
> 
> Now, there is an end-user certificate issued under that CA.  The issuer
> field of that certificate will be the DN above; the subject field is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
> CN=Stephen".
> 
> The serial number field will be something like "4434".
> 
> Now, an attribute authority has issued our friend Stephen an AC
> consistent with the proposed profile.  The "Holder" field in that AC can
> be one of three things, according to the proposed profile:
> 
>         - it can be the issuer and serial number of the base PKC; that is
> "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"
> 
>         - it can be the entity name, which by the I-D MUST be "C=IE,
> O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"
> 
>         - it can be an ObjectDigest - for which the I-D does not require
> support.
> 
> Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
> claim Stephen's legitimate AC as his own. So, he can set up his own CA
> and issue a self-signed certificate with the same name as the legitimate
> one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
> CA".  The KEY cannot be the same - we'll assume that the attacker
> doesn't know the root CA's private key, which is usually a reasonable
> assumption - but you can't stop the attacker from copying the names.
> Then, Al can use that certificate to issue a user certificate with the
> same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
> CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
> will be "4434", just like in the legitimate certificate.
> 
> Now, the question is, given the value of the "Holder" field in the AC,
> to which PKC does it correspond - Stephen's real one, or Al's forgery?
> Based on the Issuer/serial number option, you can't tell - both
> purported certs have identical issuer and serial number values. Based on
> the entityName option, you also can't tell - even though you've used the
> full DNs, they're identical; it's just the keys (and signature values,
> of course) that are different. Based on a Digest of the PKC or PK, you
> could tell.
> 
> Now - how realistic is this attack in practice? I don't know.  First of
> all, I as the attacker could simply fake an AC issuer's cert first,
> rather than start from the root CA.  Second, so what if I have managed
> to convince somebody that an AC goes with my PKC vice Stephen's - has it
> gained me anything useful?  I'm not sure. Third, this attack starts by
> exploiting the age-old issue with PKCs that you have to get the root
> CA's public key through some secure, out of band means in order to make
> everything work.
> 
> So I'm not sure what the solution to this is, other than reversing
> ourselves and mandating the ObjectDigest choice.  It's clearly not
> "include the entire DN vice just the CN". At this point, I think that
> the easiest thing to do may be to strengthen the warning in the Security
> Considerations section.  That is, explain this issue and that it may be
> a risk in some environments.  I don't think that we want to make any
> other changes at this point.
> 
> (If Stephen and Russ agree on that approach, I can propose a paragraph
> or two for the Security Considerations section. Otherwise, I'm at a loss
> for a solution.)
> 
>                         Al Arsenault
>                         Chief Security Architect
>                         Diversinet Corp.
> 
> Polar Humenn wrote:
> >
> > On Sun, 8 Oct 2000, Stephen Farrell wrote:
> >
> > >
> > > Hi,
> > >
> > > As I've said to Polar previously, I don't see what issue he's raising and
> > > if it is an issue then it also applies to public key certificates (I think
> > > this is more or less what Carlisle was saying is a previous response to the
> > > PKIX list).
> >
> > As I have said before. I do not have a problem with PK certificates
> > because they are usually accompanied by *Verifying* certificates. Even if
> > you only get one public key certificate for a subject say from a client
> > program, you must *have* the issuer's certificate to verify it.
> >
> > For a contrived example, say you may could have two different issuer PKCs
> > with the same DN. Only one of those certificates will verify the subject's
> > certificate. That argument recursively completes the naming path to its
> > root.
> >
> > With the AttributeCertificate it is different, because you only name the
> > "Holder", and not the path from its root, which is indeed its entire name.
> > In the attribute certificate there is no "Holder" certificate that can be
> > verified. There is no other evidence tying the holder to its issuer
> > completing its name. Therefore, there is abolutely no definiative way to
> > complete its entire name. Even if you use the Issuer-Serial form, the name
> > of the Issuer has the same problem. The only time that works is when the
> > issuer of the holder's identity is a root CA. The issuer of the holder's
> > identity might be a CA other than a root CA.
> >
> > In simplistic terms, With PKCs it's like saying:
> >
> > "This is George Burns."
> >
> > And with an Attribute Certificate, it's like saying:
> >
> > "George has Cigars"
> >
> > If you have a PKC that says
> >
> > "This is George Bush"
> >
> > Which George has the cigars?
> >
> > Cheers,
> > -Polar
> >
> > > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > > "fix" is to change the definition of GeneralName (and hence the base
> > > X.509-2000 and rfc2459 as well as the AC profile).
> > >
> > > Maybe its me - can anyone else see the issue?
> > >
> > > Regards,
> > > Stephen.
> > >
> > > Patrik F�ltstr�m wrote:
> > > >
> > > > This should be discussed on the PKIX mailing list.
> > > >
> > > > Please discuss...
> > > >
> > > >      Patrik F�ltstr�m, Area Director Applications Area, IETF
> > > >
> > > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > > >From: Polar Humenn <[email-masked]>
> > > > >To: [email-masked]
> > > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > > > >
> > > > >
> > > > >
> > > > >Greetings IETF,
> > > > >
> > > > >This is Polar Humenn with the Object Management Group (OMG).
> > > > >
> > > > >I have some questions about total interoperability about the PKIX
> > > > >Attribute Certificate when used in environments where your application
> > > > >does not have control over both clients and server, i.e. they both don't
> > > > >subscribe to the same LDAP server.
> > > > >
> > > > >I have some problems regarding the use of GeneralName for the Holder,
> > > > >Proxies and Targets fields of the AttributeCertificate.
> > > > >
> > > > >When using DN's for these names, they only specify one level of naming.
> > > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > > >certain authority. Specifically, they do not name the Holder's CA, and its
> > > > >CA, and so on.
> > > > >
> > > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > > >identify a holder, proxy, or target of the Attribute Certificate because
> > > > >it has the same problem in identifying the issuer.
> > > > >
> > > > >Let me illustrate a security hole that this specification has:
> > > > >
> > > > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > > > >the totem pole, because of my organizational structure. My identity
> > > > >certificate has a path from a real trusted authority, such as:
> > > > >
> > > > >1. CN=Baltimore
> > > > >2. CN=General Motors
> > > > >3. CN=Manufacturing
> > > > >4. CN=Engineering, L=Germany
> > > > >5. CN=Human Resources
> > > > >
> > > > >All my employee identities are defined by 5 and their certificates are
> > > > >signed by 5's public key. Here's one of my employees and his certificate
> > > > >serial number:
> > > > >
> > > > >6. CN=Henry Ford      Serial#=1234
> > > > >
> > > > >I obviously listed the chain with 1 as the most significant. For example,
> > > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > > >certificates.
> > > > >
> > > > >And now for something completely different, let's switch to Holden Car
> > > > >Company, Australia.
> > > > >
> > > > >The privilege service that Holden subscribes to wants to issue a attribute
> > > > >certificate to Henry Ford from General Motors so that he can access the
> > > > >Holden plant through the Internet. It is clearly not enough that I just
> > > > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > > > >as:
> > > > >
> > > > >CN=Human Resources
> > > > >Serial#=1234
> > > > >
> > > > >I really have to fully define the path of the holder so that we can verify
> > > > >that the attribute certificate actually applies to the identity I am
> > > > >presented with.
> > > > >
> > > > >For a contrived example, let's say the GM has authenticated a client using
> > > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > > >CN=Verisign). The authentication provides me with the following cert
> > > > >chain, which the GM plant has verified:
> > > > >
> > > > >1. CN=Verisign
> > > > >2. CN=Holden
> > > > >3. CN=Human Resources
> > > > >4. CN=Ian Botham, Serial#=1234
> > > > >
> > > > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > > > >
> > > > >Does it match? Yes, it sure does.
> > > > >Should this happen? Obviously not.
> > > > >
> > > > >I know it's a bit contrived, but it is a security hole.
> > > > >
> > > > >Now, if the Holder contained the name path to that serial number, then
> > > > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > > > >or not.  (Provided both the privilege service and target both trust the
> > > > >same named high-level certificates, such as Verisign or Baltimore for
> > > > >verification).
> > > > >
> > > > >The same goes for the naming of the targets and proxies.
> > > > >
> > > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > > >Fords at both GM and Holden.
> > > > >
> > > > >What can we do about this problem?
> > > > >
> > > > >I would suggest either changing the definition of GeneralName to include
> > > > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > > > >non-critical?) that complete the path from the Holder, proxies, or
> > > > >targets.
> > > > >
> > > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > > >because that will be followed by some verifying PK certificates, which
> > > > >consequently defines the issuers name path.
> > > > >
> > > > >Any comments?
> > > > >
> > > > >Cheers and Thanks,
> > > > >-Polar
> > > > >
> > > --
> > > ____________________________________________________________
> > > 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
> > >
> >

-- 
____________________________________________________________
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: [email-masked]
Subject: Re: Path Names to AC Holders, Targets and Proxies
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Tue, 10 Oct 2000 11:27:18 -0400

Stephen,

You wrote:
> You've made a bad choice trusting that AA. Its operational practices
> are bad (actually apalling!).

Actually I think that Polar's point is that the imprecision in
the IETF names specification(s) takes the AA's policies and practices
out of the picture.  The existing specification doesn't allow the
AA to reliably specify an *interoperable*, well-defined and unique
name - even if it wants to!!

It seems (to me, at least) that the ISO already owns the fuzzy,
multi-option specifications space, so IETF specifications should
focus on specializing ISO specs to promote interoperability.

-DMC

--
Dave Chizmadia
Computer Sciences Corp.

Stephen Farrell <[email-masked]> on 10/10/2000 10:38:58 AM

Please respond to [email-masked]

To:   Polar Humenn <[email-masked]>
cc:   Russ Housley <[email-masked]>, [email-masked],
      [email-masked], [email-masked]
Subject:  Re: Path Names to AC Holders, Targets and Proxies

Polar,

Do you mean that you're willing to trust CAs to pick/certify non-colliding
values (names, keys,...), but not willing to so-trust *any* AA?

If that's so, don't use ACs.

> Let's say I want to use the attribute certificate for a proof of
purchase.
> The Attribute Certificate says "George" has listening rights to play
music
> from my site. He is a guy from a poor country that has spent real money
> to get this attribute certificate from third party service of which I
> trust, but of which I have no control. Another George steals the
attribute
> certificate and uses it at my site. Because George and George match, i
let
> him listen to the music. The first George didn't buy rights for "any"
> George to listen to his music.

You've made a bad choice trusting that AA. Its operational practices
are bad (actually apalling!).

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

From: "Christopher S. Francis" <[email-masked]>
To: "Al Arsenault" <[email-masked]>, "Polar Humenn" <[email-masked]>
Cc: "Stephen Farrell" <[email-masked]>, =?iso-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies
Date: Tue, 10 Oct 2000 12:52:24 -0400
Importance: Normal

Al,

I'm new here so forgive me if I'm missing something obvious, but in your
example, doesn't the relying party have an obligation to verify the
signature on the AC using a key that it is confident belongs to the Source
Of Authority (or a key that can be traced back to an approved SOA)?  If the
relying party in your example validates the AC in this way, the forged AC
would fail the signature check.

What am I missing?

Christopher S. Francis
WetStone Technologies, Inc.
935 Main Street, Suite A-1
Safety Harbor, FL   34695
(727) 642-8993
http://www.wetstonetech.com/

-----Original Message-----
From: Al Arsenault [mailto:[email-masked]]
Sent: Tuesday, October 10, 2000 11:10 AM
To: Polar Humenn
Cc: Stephen Farrell; Patrik F�ltstr�m; [email-masked];
[email-masked]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
andProxies

Okay, I think I finally figured out what Polar is getting at here, but
I'm not sure what the fix is.  Let me try to illustrate with an example.

(We'll be picking on Stephen a little bit in this; nothing personal
intended; apologies for any offense.  :-)

Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
Technologies, OU=Public CAs, CN=The CA".
That CA has a self signed certificate with subject and issuer both equal
to the DN above.

Now, there is an end-user certificate issued under that CA.  The issuer
field of that certificate will be the DN above; the subject field is
"C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
CN=Stephen".

The serial number field will be something like "4434".

Now, an attribute authority has issued our friend Stephen an AC
consistent with the proposed profile.  The "Holder" field in that AC can
be one of three things, according to the proposed profile:

        - it can be the issuer and serial number of the base PKC; that is
"C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"

        - it can be the entity name, which by the I-D MUST be "C=IE,
O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"

        - it can be an ObjectDigest - for which the I-D does not require
support.

Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
claim Stephen's legitimate AC as his own. So, he can set up his own CA
and issue a self-signed certificate with the same name as the legitimate
one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
CA".  The KEY cannot be the same - we'll assume that the attacker
doesn't know the root CA's private key, which is usually a reasonable
assumption - but you can't stop the attacker from copying the names.
Then, Al can use that certificate to issue a user certificate with the
same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
will be "4434", just like in the legitimate certificate.

Now, the question is, given the value of the "Holder" field in the AC,
to which PKC does it correspond - Stephen's real one, or Al's forgery?
Based on the Issuer/serial number option, you can't tell - both
purported certs have identical issuer and serial number values. Based on
the entityName option, you also can't tell - even though you've used the
full DNs, they're identical; it's just the keys (and signature values,
of course) that are different. Based on a Digest of the PKC or PK, you
could tell.

Now - how realistic is this attack in practice? I don't know.  First of
all, I as the attacker could simply fake an AC issuer's cert first,
rather than start from the root CA.  Second, so what if I have managed
to convince somebody that an AC goes with my PKC vice Stephen's - has it
gained me anything useful?  I'm not sure. Third, this attack starts by
exploiting the age-old issue with PKCs that you have to get the root
CA's public key through some secure, out of band means in order to make
everything work.

So I'm not sure what the solution to this is, other than reversing
ourselves and mandating the ObjectDigest choice.  It's clearly not
"include the entire DN vice just the CN". At this point, I think that
the easiest thing to do may be to strengthen the warning in the Security
Considerations section.  That is, explain this issue and that it may be
a risk in some environments.  I don't think that we want to make any
other changes at this point.

(If Stephen and Russ agree on that approach, I can propose a paragraph
or two for the Security Considerations section. Otherwise, I'm at a loss
for a solution.)

                        Al Arsenault
                        Chief Security Architect
                        Diversinet Corp.

Polar Humenn wrote:
>
> On Sun, 8 Oct 2000, Stephen Farrell wrote:
>
> >
> > Hi,
> >
> > As I've said to Polar previously, I don't see what issue he's raising
and
> > if it is an issue then it also applies to public key certificates (I
think
> > this is more or less what Carlisle was saying is a previous response to
the
> > PKIX list).
>
> As I have said before. I do not have a problem with PK certificates
> because they are usually accompanied by *Verifying* certificates. Even if
> you only get one public key certificate for a subject say from a client
> program, you must *have* the issuer's certificate to verify it.
>
> For a contrived example, say you may could have two different issuer PKCs
> with the same DN. Only one of those certificates will verify the subject's
> certificate. That argument recursively completes the naming path to its
> root.
>
> With the AttributeCertificate it is different, because you only name the
> "Holder", and not the path from its root, which is indeed its entire name.
> In the attribute certificate there is no "Holder" certificate that can be
> verified. There is no other evidence tying the holder to its issuer
> completing its name. Therefore, there is abolutely no definiative way to
> complete its entire name. Even if you use the Issuer-Serial form, the name
> of the Issuer has the same problem. The only time that works is when the
> issuer of the holder's identity is a root CA. The issuer of the holder's
> identity might be a CA other than a root CA.
>
> In simplistic terms, With PKCs it's like saying:
>
> "This is George Burns."
>
> And with an Attribute Certificate, it's like saying:
>
> "George has Cigars"
>
> If you have a PKC that says
>
> "This is George Bush"
>
> Which George has the cigars?
>
> Cheers,
> -Polar
>
> > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > "fix" is to change the definition of GeneralName (and hence the base
> > X.509-2000 and rfc2459 as well as the AC profile).
> >
> > Maybe its me - can anyone else see the issue?
> >
> > Regards,
> > Stephen.
> >
> > Patrik F�ltstr�m wrote:
> > >
> > > This should be discussed on the PKIX mailing list.
> > >
> > > Please discuss...
> > >
> > >      Patrik F�ltstr�m, Area Director Applications Area, IETF
> > >
> > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > >From: Polar Humenn <[email-masked]>
> > > >To: [email-masked]
> > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and
Proxies
> > > >
> > > >
> > > >
> > > >Greetings IETF,
> > > >
> > > >This is Polar Humenn with the Object Management Group (OMG).
> > > >
> > > >I have some questions about total interoperability about the PKIX
> > > >Attribute Certificate when used in environments where your
application
> > > >does not have control over both clients and server, i.e. they both
don't
> > > >subscribe to the same LDAP server.
> > > >
> > > >I have some problems regarding the use of GeneralName for the Holder,
> > > >Proxies and Targets fields of the AttributeCertificate.
> > > >
> > > >When using DN's for these names, they only specify one level of
naming.
> > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > >certain authority. Specifically, they do not name the Holder's CA,
and its
> > > >CA, and so on.
> > > >
> > > >Even using the Issuer-Serial type of GeneralName is not good enough
to
> > > >identify a holder, proxy, or target of the Attribute Certificate
because
> > > >it has the same problem in identifying the issuer.
> > > >
> > > >Let me illustrate a security hole that this specification has:
> > > >
> > > >Let's say I am a CA that defines employee identities. I'm pretty low
on
> > > >the totem pole, because of my organizational structure. My identity
> > > >certificate has a path from a real trusted authority, such as:
> > > >
> > > >1. CN=Baltimore
> > > >2. CN=General Motors
> > > >3. CN=Manufacturing
> > > >4. CN=Engineering, L=Germany
> > > >5. CN=Human Resources
> > > >
> > > >All my employee identities are defined by 5 and their certificates
are
> > > >signed by 5's public key. Here's one of my employees and his
certificate
> > > >serial number:
> > > >
> > > >6. CN=Henry Ford      Serial#=1234
> > > >
> > > >I obviously listed the chain with 1 as the most significant. For
example,
> > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > >certificates.
> > > >
> > > >And now for something completely different, let's switch to Holden
Car
> > > >Company, Australia.
> > > >
> > > >The privilege service that Holden subscribes to wants to issue a
attribute
> > > >certificate to Henry Ford from General Motors so that he can access
the
> > > >Holden plant through the Internet. It is clearly not enough that I
just
> > > >define the "Holder" as using the Issuer-Serial form of GeneralName,
such
> > > >as:
> > > >
> > > >CN=Human Resources
> > > >Serial#=1234
> > > >
> > > >I really have to fully define the path of the holder so that we can
verify
> > > >that the attribute certificate actually applies to the identity I am
> > > >presented with.
> > > >
> > > >For a contrived example, let's say the GM has authenticated a client
using
> > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > >CN=Verisign). The authentication provides me with the following cert
> > > >chain, which the GM plant has verified:
> > > >
> > > >1. CN=Verisign
> > > >2. CN=Holden
> > > >3. CN=Human Resources
> > > >4. CN=Ian Botham, Serial#=1234
> > > >
> > > >Then he delivers to the plant the Attribute Certificate for Henry
Ford.
> > > >
> > > >Does it match? Yes, it sure does.
> > > >Should this happen? Obviously not.
> > > >
> > > >I know it's a bit contrived, but it is a security hole.
> > > >
> > > >Now, if the Holder contained the name path to that serial number,
then
> > > >there wouldn't even be a question of whether the AC applied to Ian
Botham
> > > >or not.  (Provided both the privilege service and target both trust
the
> > > >same named high-level certificates, such as Verisign or Baltimore for
> > > >verification).
> > > >
> > > >The same goes for the naming of the targets and proxies.
> > > >
> > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > >Fords at both GM and Holden.
> > > >
> > > >What can we do about this problem?
> > > >
> > > >I would suggest either changing the definition of GeneralName to
include
> > > >DN paths. Alternatively, I may suggest attribute extensions (critical
or
> > > >non-critical?) that complete the path from the Holder, proxies, or
> > > >targets.
> > > >
> > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > >because that will be followed by some verifying PK certificates,
which
> > > >consequently defines the issuers name path.
> > > >
> > > >Any comments?
> > > >
> > > >Cheers and Thanks,
> > > >-Polar
> > > >
> > --
> > ____________________________________________________________
> > 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 Lipp" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "Christian. Vogel" <[email-masked]>
Subject: AW: Experimental TSA by iaik graz
Date: Tue, 10 Oct 2000 17:57:31 +0200
Importance: Normal

>Some time ago there was an announcement about an experimental time stamping
>service provided by the University of Graz.
>
>Is this service still running?

Currently it is not, we have had some machine-changes, but plan to have it
up again on a more stable machine asap. We will keep you informed

Peter

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  Experimental TSA by iaik graz
Sender: [email-masked]
Reply-To: [email-masked]
Date: Wed, 11 Oct 2000 04:30:05 (NZDT)

Peter Sylvester <[email-masked]> writes:

>Some time ago there was an announcement about an experimental time stamping
>service provided by the University of Graz.
>
>Is this service still running?

Not that I know of, it was one of the ones I tried, the server seems to have
gone away and mail to the person involved bounced.

Peter.

Date: Tue, 10 Oct 2000 11:10:14 -0400
From: Al Arsenault <[email-masked]>
Organization: @Home Network
To: Polar Humenn <[email-masked]>
CC: Stephen Farrell <[email-masked]>, "Patrik  =?iso-8859-1?Q?F=E4ltstr=F6m?=" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

Okay, I think I finally figured out what Polar is getting at here, but
I'm not sure what the fix is.  Let me try to illustrate with an example. 

(We'll be picking on Stephen a little bit in this; nothing personal
intended; apologies for any offense.  :-)

Suppose that there's a legitimate root CA with DN "C=IE, O=Baltimore
Technologies, OU=Public CAs, CN=The CA". 
That CA has a self signed certificate with subject and issuer both equal
to the DN above.

Now, there is an end-user certificate issued under that CA.  The issuer
field of that certificate will be the DN above; the subject field is
"C=IE, O=Baltimore Technologies, OU=Public CAs, OU=Architects,
CN=Stephen".

The serial number field will be something like "4434".

Now, an attribute authority has issued our friend Stephen an AC
consistent with the proposed profile.  The "Holder" field in that AC can
be one of three things, according to the proposed profile:

	- it can be the issuer and serial number of the base PKC; that is
"C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The CA" + "4434"

	- it can be the entity name, which by the I-D MUST be "C=IE,
O=Baltimore Technologies, OU=Public CAs, OU=Architects, CN=Stephen"

	- it can be an ObjectDigest - for which the I-D does not require
support.

Okay, that's the legitimate setup.  Now, Awful Al the Attacker wants to
claim Stephen's legitimate AC as his own. So, he can set up his own CA
and issue a self-signed certificate with the same name as the legitimate
one, that is "C=IE, O=Baltimore Technologies, OU=Public CAs, CN=The
CA".  The KEY cannot be the same - we'll assume that the attacker
doesn't know the root CA's private key, which is usually a reasonable
assumption - but you can't stop the attacker from copying the names.
Then, Al can use that certificate to issue a user certificate with the
same DN as Stephen's, namely "C=IE, O=Baltimore Technologies, OU=Public
CAs, OU=Architects, CN=Stephen".  The serial number of this certificate
will be "4434", just like in the legitimate certificate.

Now, the question is, given the value of the "Holder" field in the AC,
to which PKC does it correspond - Stephen's real one, or Al's forgery?
Based on the Issuer/serial number option, you can't tell - both
purported certs have identical issuer and serial number values. Based on
the entityName option, you also can't tell - even though you've used the
full DNs, they're identical; it's just the keys (and signature values,
of course) that are different. Based on a Digest of the PKC or PK, you
could tell.

Now - how realistic is this attack in practice? I don't know.  First of
all, I as the attacker could simply fake an AC issuer's cert first,
rather than start from the root CA.  Second, so what if I have managed
to convince somebody that an AC goes with my PKC vice Stephen's - has it
gained me anything useful?  I'm not sure. Third, this attack starts by
exploiting the age-old issue with PKCs that you have to get the root
CA's public key through some secure, out of band means in order to make
everything work.

So I'm not sure what the solution to this is, other than reversing
ourselves and mandating the ObjectDigest choice.  It's clearly not
"include the entire DN vice just the CN". At this point, I think that
the easiest thing to do may be to strengthen the warning in the Security
Considerations section.  That is, explain this issue and that it may be
a risk in some environments.  I don't think that we want to make any
other changes at this point.

(If Stephen and Russ agree on that approach, I can propose a paragraph
or two for the Security Considerations section. Otherwise, I'm at a loss
for a solution.)

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

Polar Humenn wrote:
> 
> On Sun, 8 Oct 2000, Stephen Farrell wrote:
> 
> >
> > Hi,
> >
> > As I've said to Polar previously, I don't see what issue he's raising and
> > if it is an issue then it also applies to public key certificates (I think
> > this is more or less what Carlisle was saying is a previous response to the
> > PKIX list).
> 
> As I have said before. I do not have a problem with PK certificates
> because they are usually accompanied by *Verifying* certificates. Even if
> you only get one public key certificate for a subject say from a client
> program, you must *have* the issuer's certificate to verify it.
> 
> For a contrived example, say you may could have two different issuer PKCs
> with the same DN. Only one of those certificates will verify the subject's
> certificate. That argument recursively completes the naming path to its
> root.
> 
> With the AttributeCertificate it is different, because you only name the
> "Holder", and not the path from its root, which is indeed its entire name.
> In the attribute certificate there is no "Holder" certificate that can be
> verified. There is no other evidence tying the holder to its issuer
> completing its name. Therefore, there is abolutely no definiative way to
> complete its entire name. Even if you use the Issuer-Serial form, the name
> of the Issuer has the same problem. The only time that works is when the
> issuer of the holder's identity is a root CA. The issuer of the holder's
> identity might be a CA other than a root CA.
> 
> In simplistic terms, With PKCs it's like saying:
> 
> "This is George Burns."
> 
> And with an Attribute Certificate, it's like saying:
> 
> "George has Cigars"
> 
> If you have a PKC that says
> 
> "This is George Bush"
> 
> Which George has the cigars?
> 
> Cheers,
> -Polar
> 
> > Acrtually, maybe this is clearly shown from Polar's suggestion that the
> > "fix" is to change the definition of GeneralName (and hence the base
> > X.509-2000 and rfc2459 as well as the AC profile).
> >
> > Maybe its me - can anyone else see the issue?
> >
> > Regards,
> > Stephen.
> >
> > Patrik F�ltstr�m wrote:
> > >
> > > This should be discussed on the PKIX mailing list.
> > >
> > > Please discuss...
> > >
> > >      Patrik F�ltstr�m, Area Director Applications Area, IETF
> > >
> > > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > > >From: Polar Humenn <[email-masked]>
> > > >To: [email-masked]
> > > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > > >
> > > >
> > > >
> > > >Greetings IETF,
> > > >
> > > >This is Polar Humenn with the Object Management Group (OMG).
> > > >
> > > >I have some questions about total interoperability about the PKIX
> > > >Attribute Certificate when used in environments where your application
> > > >does not have control over both clients and server, i.e. they both don't
> > > >subscribe to the same LDAP server.
> > > >
> > > >I have some problems regarding the use of GeneralName for the Holder,
> > > >Proxies and Targets fields of the AttributeCertificate.
> > > >
> > > >When using DN's for these names, they only specify one level of naming.
> > > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > > >certain authority. Specifically, they do not name the Holder's CA, and its
> > > >CA, and so on.
> > > >
> > > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > > >identify a holder, proxy, or target of the Attribute Certificate because
> > > >it has the same problem in identifying the issuer.
> > > >
> > > >Let me illustrate a security hole that this specification has:
> > > >
> > > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > > >the totem pole, because of my organizational structure. My identity
> > > >certificate has a path from a real trusted authority, such as:
> > > >
> > > >1. CN=Baltimore
> > > >2. CN=General Motors
> > > >3. CN=Manufacturing
> > > >4. CN=Engineering, L=Germany
> > > >5. CN=Human Resources
> > > >
> > > >All my employee identities are defined by 5 and their certificates are
> > > >signed by 5's public key. Here's one of my employees and his certificate
> > > >serial number:
> > > >
> > > >6. CN=Henry Ford      Serial#=1234
> > > >
> > > >I obviously listed the chain with 1 as the most significant. For example,
> > > >if Henry authenticates via TLS, he delivers a chain of these 6
> > > >certificates.
> > > >
> > > >And now for something completely different, let's switch to Holden Car
> > > >Company, Australia.
> > > >
> > > >The privilege service that Holden subscribes to wants to issue a attribute
> > > >certificate to Henry Ford from General Motors so that he can access the
> > > >Holden plant through the Internet. It is clearly not enough that I just
> > > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > > >as:
> > > >
> > > >CN=Human Resources
> > > >Serial#=1234
> > > >
> > > >I really have to fully define the path of the holder so that we can verify
> > > >that the attribute certificate actually applies to the identity I am
> > > >presented with.
> > > >
> > > >For a contrived example, let's say the GM has authenticated a client using
> > > >SSL, and the plant has Versign's verification certificate (i.e.
> > > >CN=Verisign). The authentication provides me with the following cert
> > > >chain, which the GM plant has verified:
> > > >
> > > >1. CN=Verisign
> > > >2. CN=Holden
> > > >3. CN=Human Resources
> > > >4. CN=Ian Botham, Serial#=1234
> > > >
> > > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > > >
> > > >Does it match? Yes, it sure does.
> > > >Should this happen? Obviously not.
> > > >
> > > >I know it's a bit contrived, but it is a security hole.
> > > >
> > > >Now, if the Holder contained the name path to that serial number, then
> > > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > > >or not.  (Provided both the privilege service and target both trust the
> > > >same named high-level certificates, such as Verisign or Baltimore for
> > > >verification).
> > > >
> > > >The same goes for the naming of the targets and proxies.
> > > >
> > > >The problem exists for regular DN naming as their may be two CN=Henry
> > > >Fords at both GM and Holden.
> > > >
> > > >What can we do about this problem?
> > > >
> > > >I would suggest either changing the definition of GeneralName to include
> > > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > > >non-critical?) that complete the path from the Holder, proxies, or
> > > >targets.
> > > >
> > > >I do not have a problem with the Issuer of the Attribute Certificate,
> > > >because that will be followed by some verifying PK certificates, which
> > > >consequently defines the issuers name path.
> > > >
> > > >Any comments?
> > > >
> > > >Cheers and Thanks,
> > > >-Polar
> > > >
> > --
> > ____________________________________________________________
> > 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, 10 Oct 2000 15:38:58 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Polar Humenn <[email-masked]>
CC: Russ Housley <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Path Names to AC Holders, Targets and Proxies

Polar,

Do you mean that you're willing to trust CAs to pick/certify non-colliding 
values (names, keys,...), but not willing to so-trust *any* AA? 

If that's so, don't use ACs.

> Let's say I want to use the attribute certificate for a proof of purchase.
> The Attribute Certificate says "George" has listening rights to play music
> from my site. He is a guy from a poor country that has spent real money
> to get this attribute certificate from third party service of which I
> trust, but of which I have no control. Another George steals the attribute
> certificate and uses it at my site. Because George and George match, i let
> him listen to the music. The first George didn't buy rights for "any"
> George to listen to his music.

You've made a bad choice trusting that AA. Its operational practices
are bad (actually apalling!). 

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, 10 Oct 2000 15:26:59 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Polar Humenn <[email-masked]>
CC: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

Polar,

Polar Humenn wrote:
> 
> On Sun, 8 Oct 2000, Stephen Farrell wrote:
> 
> >
> > Hi,
> >
> > As I've said to Polar previously, I don't see what issue he's raising and
> > if it is an issue then it also applies to public key certificates (I think
> > this is more or less what Carlisle was saying is a previous response to the
> > PKIX list).
> 
> As I have said before. I do not have a problem with PK certificates
> because they are usually accompanied by *Verifying* certificates. Even if
> you only get one public key certificate for a subject say from a client
> program, you must *have* the issuer's certificate to verify it.

Quoting from the end of 4.2.2:

  "Any protocol conforming to this profile SHOULD specify which AC
   holder option is to be used and how this fits with the supported
   authentication schemes defined in that protocol."

Clearly, possession of an AC is not enough to claim the privileges
contained therein, so authentication is required. If your "vulnerability" 
depends on the relying party not being able to distinguish between 
different AC holders at the authentication stage then I think the 
problem lies outside of the use of ACs and hence doesn't affect this 
profile.

The AC profile only talks about the use of PKCs as an authentication
mechanism (since this is PKIX). The profile says that holder SHOULD use
the baseCertificateID choice. This means your problem amounts to the 
case where a relying party (in PKI terms) trusts two *different* CAs with 
the same name who've issued PKCs with the same serial number where one 
party has intentionally grabbed the other's AC and is claiming its 
privilege. Aside from not being convinced, this leads back to my 
original point that you're talking about a putative problem with that
relying party's PKI, not to do with ACs (e.g. how could it get 
revocation status, how could it figure out who'd signed an email, etc.)

If the RP chooses to trust an AA then effectively it is choosing to
trust that AA's holder field. I'm sure that if and when ACs become
as widespread as PKCs, then concepts like CPS will be elaborated. At
that point your concerns get addressed, not in the profile.

> For a contrived example...

Real examples are more convincing.

> With the AttributeCertificate it is different, because you only name the
> "Holder", and not the path from its root, which is indeed its entire name.
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Every time you write something like that you loose me entirely.

[..."George" omitted...]

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, 10 Oct 2000 10:06:53 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Russ Housley <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Path Names to AC Holders, Targets and Proxies 

On Sun, 8 Oct 2000, Russ Housley wrote:

> Polar:
> 
> >I have some questions about total interoperability about the PKIX
> >Attribute Certificate when used in environments where your application
> >does not have control over both clients and server, i.e. they both don't
> >subscribe to the same LDAP server.
> >
> >I have some problems regarding the use of GeneralName for the Holder,
> >Proxies and Targets fields of the AttributeCertificate.
> >
> >When using DN's for these names, they only specify one level of naming.
> >That is, they do not specify the Identity Chain, (i.e. path) upto a
> >certain authority. Specifically, they do not name the Holder's CA, and its
> >CA, and so on.
> 
> This is intentional.  In these cases, we want to bind the attribute to any 
> certificate issued to that identity.  

I don't think that particular is a good idea. That destroys the entire
notion of binding an identity to a certificate for the purposes of
identifying any thing and blows RFC 2459 out of the water. If that is an
intention, it is a misuse, and there should be steps taken in the standard
to prevent that type of misuse. Yuck!

> If identity collisions are possible in your environment, then the
> attributes should be bound to an issuer/serial number pair instead of
> a General Name.

I'm not talking about "my" environment. I'm looking at the entire world of
interoperability. If I had my environment, what would I even need a
standard for an AttributeCertificate for? 

If I had my environment, I would state that there would be critical
extensions to these Attribute certificates so that the paths to the holder
would be complete. However, what good does that do, in an interoperable
environment where you are handed an attribute certificate from some
service that doesn't complete the name.

I'm looking at the case of where I want to accept third party attribute
services of which I trust, but I which I have no control.  I want them to
adhere to standards.

Let's say I want to use the attribute certificate for a proof of purchase.
The Attribute Certificate says "George" has listening rights to play music
from my site. He is a guy from a poor country that has spent real money
to get this attribute certificate from third party service of which I
trust, but of which I have no control. Another George steals the attribute
certificate and uses it at my site. Because George and George match, i let
him listen to the music. The first George didn't buy rights for "any"
George to listen to his music.

I'm not talking about likelihood. I'm talking about VERIFIABLE Security.

> RFC 2459 requires that X.500 distinguished names be present for issuer
> names.  And, in real world implementations, they should include
> significantly more information than a simple common name.

RFC 2459 doesn't imply any structure similarity between the subject's DN
and the issuer's DN. Therefore nothing of the sort can be assumed. Having
more elements in the DN doesn't mean a thing mathematically. It's just a
blob of data, no matter how big or how small. My use of a simple common
name was only to make the problem understandable. I don't care if you had
128 RDNs in there. It's the same thing.

Cheers,
-Polar

From: Peter Sylvester <[email-masked]>
Date: Tue, 10 Oct 2000 15:57:39 +0200 (MET DST)
To: [email-masked]
Subject: Experimental TSA by iaik graz

Some time ago there was an announcement about an experimental
time stamping service provided by the University of Graz.

Is this service still running? 

Date: Tue, 10 Oct 2000 09:28:46 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Stephen Farrell <[email-masked]>
cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

On Sun, 8 Oct 2000, Stephen Farrell wrote:

> 
> Hi,
> 
> As I've said to Polar previously, I don't see what issue he's raising and
> if it is an issue then it also applies to public key certificates (I think 
> this is more or less what Carlisle was saying is a previous response to the
> PKIX list).

As I have said before. I do not have a problem with PK certificates
because they are usually accompanied by *Verifying* certificates. Even if
you only get one public key certificate for a subject say from a client
program, you must *have* the issuer's certificate to verify it. 

For a contrived example, say you may could have two different issuer PKCs
with the same DN. Only one of those certificates will verify the subject's
certificate. That argument recursively completes the naming path to its
root.

With the AttributeCertificate it is different, because you only name the
"Holder", and not the path from its root, which is indeed its entire name.
In the attribute certificate there is no "Holder" certificate that can be
verified. There is no other evidence tying the holder to its issuer
completing its name. Therefore, there is abolutely no definiative way to
complete its entire name. Even if you use the Issuer-Serial form, the name
of the Issuer has the same problem. The only time that works is when the
issuer of the holder's identity is a root CA. The issuer of the holder's
identity might be a CA other than a root CA.

In simplistic terms, With PKCs it's like saying:

"This is George Burns."

And with an Attribute Certificate, it's like saying:

"George has Cigars"

If you have a PKC that says

"This is George Bush"

Which George has the cigars?

Cheers,
-Polar

> Acrtually, maybe this is clearly shown from Polar's suggestion that the
> "fix" is to change the definition of GeneralName (and hence the base
> X.509-2000 and rfc2459 as well as the AC profile).
> 
> Maybe its me - can anyone else see the issue?
> 
> Regards,
> Stephen.
> 
> Patrik F�ltstr�m wrote:
> > 
> > This should be discussed on the PKIX mailing list.
> > 
> > Please discuss...
> > 
> >      Patrik F�ltstr�m, Area Director Applications Area, IETF
> > 
> > >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> > >From: Polar Humenn <[email-masked]>
> > >To: [email-masked]
> > >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> > >
> > >
> > >
> > >Greetings IETF,
> > >
> > >This is Polar Humenn with the Object Management Group (OMG).
> > >
> > >I have some questions about total interoperability about the PKIX
> > >Attribute Certificate when used in environments where your application
> > >does not have control over both clients and server, i.e. they both don't
> > >subscribe to the same LDAP server.
> > >
> > >I have some problems regarding the use of GeneralName for the Holder,
> > >Proxies and Targets fields of the AttributeCertificate.
> > >
> > >When using DN's for these names, they only specify one level of naming.
> > >That is, they do not specify the Identity Chain, (i.e. path) upto a
> > >certain authority. Specifically, they do not name the Holder's CA, and its
> > >CA, and so on.
> > >
> > >Even using the Issuer-Serial type of GeneralName is not good enough to
> > >identify a holder, proxy, or target of the Attribute Certificate because
> > >it has the same problem in identifying the issuer.
> > >
> > >Let me illustrate a security hole that this specification has:
> > >
> > >Let's say I am a CA that defines employee identities. I'm pretty low on
> > >the totem pole, because of my organizational structure. My identity
> > >certificate has a path from a real trusted authority, such as:
> > >
> > >1. CN=Baltimore
> > >2. CN=General Motors
> > >3. CN=Manufacturing
> > >4. CN=Engineering, L=Germany
> > >5. CN=Human Resources
> > >
> > >All my employee identities are defined by 5 and their certificates are
> > >signed by 5's public key. Here's one of my employees and his certificate
> > >serial number:
> > >
> > >6. CN=Henry Ford      Serial#=1234
> > >
> > >I obviously listed the chain with 1 as the most significant. For example,
> > >if Henry authenticates via TLS, he delivers a chain of these 6
> > >certificates.
> > >
> > >And now for something completely different, let's switch to Holden Car
> > >Company, Australia.
> > >
> > >The privilege service that Holden subscribes to wants to issue a attribute
> > >certificate to Henry Ford from General Motors so that he can access the
> > >Holden plant through the Internet. It is clearly not enough that I just
> > >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> > >as:
> > >
> > >CN=Human Resources
> > >Serial#=1234
> > >
> > >I really have to fully define the path of the holder so that we can verify
> > >that the attribute certificate actually applies to the identity I am
> > >presented with.
> > >
> > >For a contrived example, let's say the GM has authenticated a client using
> > >SSL, and the plant has Versign's verification certificate (i.e.
> > >CN=Verisign). The authentication provides me with the following cert
> > >chain, which the GM plant has verified:
> > >
> > >1. CN=Verisign
> > >2. CN=Holden
> > >3. CN=Human Resources
> > >4. CN=Ian Botham, Serial#=1234
> > >
> > >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> > >
> > >Does it match? Yes, it sure does.
> > >Should this happen? Obviously not.
> > >
> > >I know it's a bit contrived, but it is a security hole.
> > >
> > >Now, if the Holder contained the name path to that serial number, then
> > >there wouldn't even be a question of whether the AC applied to Ian Botham
> > >or not.  (Provided both the privilege service and target both trust the
> > >same named high-level certificates, such as Verisign or Baltimore for
> > >verification).
> > >
> > >The same goes for the naming of the targets and proxies.
> > >
> > >The problem exists for regular DN naming as their may be two CN=Henry
> > >Fords at both GM and Holden.
> > >
> > >What can we do about this problem?
> > >
> > >I would suggest either changing the definition of GeneralName to include
> > >DN paths. Alternatively, I may suggest attribute extensions (critical or
> > >non-critical?) that complete the path from the Holder, proxies, or
> > >targets.
> > >
> > >I do not have a problem with the Issuer of the Attribute Certificate,
> > >because that will be followed by some verifying PK certificates, which
> > >consequently defines the issuers name path.
> > >
> > >Any comments?
> > >
> > >Cheers and Thanks,
> > >-Polar
> > >
> -- 
> ____________________________________________________________
> 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, 10 Oct 2000 13:25:48 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Russ Housley <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: Re: TSP: Response to the comments raised by Russ Housley

Russ,

> Denis:
> 
> I am happy with your response to number 3.  Now, for number 10.  How about
> something like the following:
> 
>      For the <list your types here> MIME types, implementations SHOULD

I did not realized first why you were leaving the types empty, :-)
... until I found the acronym collision between
application/timestamp-request (TSR) and application/timestamp-response
(TSR).

Here is a proposal to solve this acronym collision:

For the application/timestamp-query and application/timestamp-reply MIME
types, implementations SHOULD include the optional "name" and "filename"
parameters. Including a file name serves helps preserve type information
when timestamps are saved as files.  When these parameters are included, a
file name with the appropriate extension SHOULD be selected:

       MIME Type                     File Extension

  application/timestamp-query            .TSQ
  application/timestamp-reply            .TSR

In addition, the file name SHOULD be limited to eight characters followed by
a three letter extension. The eight character filename base can be any
distinct name.

Would that text be OK with you ?

Regards,

Denis

>      include the optional "name" and "filename" parameters.  Including a
>      file name serves helps preserve type information when timestamps are
>      saved as files.  When these parameters are included, a file name with
>      the appropriate extension SHOULD be selected:
> 
>        MIME Type                     File Extension
> 
>          <your request type>           .<your request extension>
> 
>          <your response type>          .<your response extension>
> 
>          ...
> 
>      In addition, the file name SHOULD be limited to eight characters
>      followed by a three letter extension. The eight character filename
>      base can be any distinct name.
> 
> Russ

From: Santoni Adriano <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: Denis Pinkas <[email-masked]>, IETF-PXIX <[email-masked]>, "'Peter Sylvester'" <[email-masked]>
Subject: R: R: TSP: Response to the comments raised by Russ Housley
Date: Tue, 10 Oct 2000 08:57:08 +0200

The response is actually *not* just a CMS message, as Sylvester rightly
pointed out. I just made a trivial mistake in my previous comment. So the
issue of  file extensions is worth discussing (not for long, though). The
issue about MIME type instead is not, because application/timestamp has been
already defined. Perhaps we can think of adding subtypes and arguments to
the MIME content-type (eg to distinguish requests from responses), but
that's probably not so critical an issue. What I strongly believe is that
the draft should now brought on to RFC status asap. Too much time has
passed, and the community needs a stable standard (especially in Europe,
where digital signatures are supposed to be strengthened and prolonged in
time with timestamps); maybe we do not have the most perfect standard of all
time, but perfection is unreachable and unnecessary; let's work with this
one and see what happens.

Adriano

SIA S.p.A.
Milano, IT/EU
https://ca.sia.it

-----Messaggio originale-----
Da: Russ Housley [mailto:[email-masked]]
Inviato: luned� 9 ottobre 2000 23.07
A: Santoni Adriano
Cc: Denis Pinkas; IETF-PXIX
Oggetto: Re: R: TSP: Response to the comments raised by Russ Housley

If the response is just a CMS SignedData message, then do not assign a new 
MIME type.  Use the ones already defined in RFC 2633.

Russ

At 09:16 AM 10/09/2000 +0200, Santoni Adriano wrote:
>Is it really useful to tell apart requests vs. responses? From the TSP
>server viewpoint, an incoming message is supposed to be a request and it
>will be processed based on that obvious assumption. So the single
>content-type "application/timestamp" should suffice, IMO. As to file
>extensions, I think it's pretty irrilevant; however, as the response is a
>CMS SignedData message, I presume ".P7M" would be a proper file extension
>for it. As to the request...I do not know; why not ".TSR" ?
>
>Adriano Santoni
>
>SIA S.p.A.
>Milano, IT
>https://ca.sia.it <https://ca.sia.it>
>
>
>-----Messaggio originale-----
>Da: Russ Housley [mailto:[email-masked]]
>Inviato: venerd� 6 ottobre 2000 20.11
>A: Denis Pinkas
>Cc: IETF-PXIX
>Oggetto: Re: TSP: Response to the comments raised by Russ Housley
>
>
>Denis:
>
>I am happy with your response to number 3.  Now, for number 10.  How about
>something like the following:
>
>
>For the <list your types here> MIME types, implementations SHOULD include
>the optional "name" and "filename" parameters.  Including a file name
serves
>helps preserve type information when timestamps are saved as files.  When
>these parameters are included, a file name with the appropriate extension
>SHOULD be selected:
>
>
>
>   MIME Type                     File Extension
>
>
>
>     <your request type>           .<your request extension>
>
>
>
>     <your response type>          .<your response extension>
>
>
>
>     ...
>
>
>
>In addition, the file name SHOULD be limited to eight characters followed
by
>a three letter extension. The eight character filename base can be any
>distinct name.
>
>
>
>Russ
>
>
>At 04:26 PM 10/06/2000 +0200, Denis Pinkas wrote:
>
>
>Russ,
>
>Thank you for your response.
>
>The only remaining issues are numbered 3 and 10. See my comments embedded
>below.
>
> > Denis:
> >
> > Thank you for addressing my concerns.  I address each of your proposed
> > resolutions below.
> >
> > TECHNICAL
> >
> > 1 and 2. Your proposed resolution resolves my concern.
> >
> > 3. I am not satisfied.  I accept that this is not the place to define
TSP
> > policy or practice statements.  However, I do not think that the RFC
2459
> > syntax is appropriate for use in the TSP context.  Also, you ignored my
> > concern regarding qualifiers.  RFC 2459 contains:
> >
> >     PolicyInformation ::= SEQUENCE {
> >          policyIdentifier   CertPolicyId,
> >          policyQualifiers   SEQUENCE SIZE (1..MAX) OF
> >                                  PolicyQualifierInfo OPTIONAL }
> >
> > I would prefer a structure that said "TSAPolicyId" instead of
> > "CertPolicyId." Using "CertPolicyId" in this context will, in my
opinion,
> > confuse matters.  Also, I would like to omit policy qualifiers
> > altogether.  I do not like them in certificate policies, and I would
like
> > to avoid them in TSA policies.
>
>I had corrected the text but I did not understood your were also requesting
>an ASN.1 change.
>Sorry about that misunderstanding. I agree with your request and I have
done
>the changes, i.e:
>
>  TSAPolicyId ::= OBJECT IDENTIFIER
>
>and in the request:
>
>  reqPolicy       TSAPolicyId    OPTIONAL,
>
>while in the response:
>
>  policy          TSAPolicyId,
>
> > 4 through 9. Your proposed resolution resolves my concern.
> >
> > 10. This comment is related to comment number 9, but it has absolutely
> > nothing to do with flow.  It has to do with the specification of file
> > naming conventions.  I would like to see a section that is parallel to
RFC
> > 2633, Section 3.2.1.  Further, I think that that file naming conventions
> > should be labeled SHOULD, not MUST.
>
>I understand the last sentence of your request, but I'm not sure what you
>are requesting for the remaining of it-- all the text in Section 3.2.1 of
>2633 with respect to MIME and S/MIME is not relevant, I think.  Perhaps you
>would like to see something similar to the paragraph regarding base name
>(i.e., 8 characters, can be any distinct name, ..) although many systems
>today are no more limited to 8 characters. :-) If you want some specific
>addition, would you be able to propose it ?
>
>Regards,
>
>Denis
>
> > 11. Fair enough; CMP should include a state machine too.  I believe that
> > many interoperability issues can be avoided by specifying the state
> > machine.  I am not going to hold things up over this issue.
> >
> > 12 and 13. Your proposed resolution resolves my concern.
> >
> > EDITORIAL
> >
> > 14 and 15. Your proposed resolution resolves my concern.
> >
> > 16. Okay.  As I said, this is an editorial comment, so I can live with
the
> > current text.
> >
> > 17 through 24. Your proposed resolution resolves my concern.
> >
> > Russ

Date: Mon, 09 Oct 2000 17:06:46 -0400
To: Santoni Adriano <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: R: TSP: Response to the comments raised by Russ Housley
Cc: Denis Pinkas <[email-masked]>, IETF-PXIX <[email-masked]>

If the response is just a CMS SignedData message, then do not assign a new 
MIME type.  Use the ones already defined in RFC 2633.

Russ

At 09:16 AM 10/09/2000 +0200, Santoni Adriano wrote:
>Is it really useful to tell apart requests vs. responses? From the TSP
>server viewpoint, an incoming message is supposed to be a request and it
>will be processed based on that obvious assumption. So the single
>content-type "application/timestamp" should suffice, IMO. As to file
>extensions, I think it's pretty irrilevant; however, as the response is a
>CMS SignedData message, I presume ".P7M" would be a proper file extension
>for it. As to the request...I do not know; why not ".TSR" ?
>
>Adriano Santoni
>
>SIA S.p.A.
>Milano, IT
>https://ca.sia.it <https://ca.sia.it>
>
>
>-----Messaggio originale-----
>Da: Russ Housley [mailto:[email-masked]]
>Inviato: venerd� 6 ottobre 2000 20.11
>A: Denis Pinkas
>Cc: IETF-PXIX
>Oggetto: Re: TSP: Response to the comments raised by Russ Housley
>
>
>Denis:
>
>I am happy with your response to number 3.  Now, for number 10.  How about
>something like the following:
>
>
>For the <list your types here> MIME types, implementations SHOULD include
>the optional "name" and "filename" parameters.  Including a file name serves
>helps preserve type information when timestamps are saved as files.  When
>these parameters are included, a file name with the appropriate extension
>SHOULD be selected:
>
>
>
>   MIME Type                     File Extension
>
>
>
>     <your request type>           .<your request extension>
>
>
>
>     <your response type>          .<your response extension>
>
>
>
>     ...
>
>
>
>In addition, the file name SHOULD be limited to eight characters followed by
>a three letter extension. The eight character filename base can be any
>distinct name.
>
>
>
>Russ
>
>
>At 04:26 PM 10/06/2000 +0200, Denis Pinkas wrote:
>
>
>Russ,
>
>Thank you for your response.
>
>The only remaining issues are numbered 3 and 10. See my comments embedded
>below.
>
> > Denis:
> >
> > Thank you for addressing my concerns.  I address each of your proposed
> > resolutions below.
> >
> > TECHNICAL
> >
> > 1 and 2. Your proposed resolution resolves my concern.
> >
> > 3. I am not satisfied.  I accept that this is not the place to define TSP
> > policy or practice statements.  However, I do not think that the RFC 2459
> > syntax is appropriate for use in the TSP context.  Also, you ignored my
> > concern regarding qualifiers.  RFC 2459 contains:
> >
> >     PolicyInformation ::= SEQUENCE {
> >          policyIdentifier   CertPolicyId,
> >          policyQualifiers   SEQUENCE SIZE (1..MAX) OF
> >                                  PolicyQualifierInfo OPTIONAL }
> >
> > I would prefer a structure that said "TSAPolicyId" instead of
> > "CertPolicyId." Using "CertPolicyId" in this context will, in my opinion,
> > confuse matters.  Also, I would like to omit policy qualifiers
> > altogether.  I do not like them in certificate policies, and I would like
> > to avoid them in TSA policies.
>
>I had corrected the text but I did not understood your were also requesting
>an ASN.1 change.
>Sorry about that misunderstanding. I agree with your request and I have done
>the changes, i.e:
>
>  TSAPolicyId ::= OBJECT IDENTIFIER
>
>and in the request:
>
>  reqPolicy       TSAPolicyId    OPTIONAL,
>
>while in the response:
>
>  policy          TSAPolicyId,
>
> > 4 through 9. Your proposed resolution resolves my concern.
> >
> > 10. This comment is related to comment number 9, but it has absolutely
> > nothing to do with flow.  It has to do with the specification of file
> > naming conventions.  I would like to see a section that is parallel to RFC
> > 2633, Section 3.2.1.  Further, I think that that file naming conventions
> > should be labeled SHOULD, not MUST.
>
>I understand the last sentence of your request, but I'm not sure what you
>are requesting for the remaining of it-- all the text in Section 3.2.1 of
>2633 with respect to MIME and S/MIME is not relevant, I think.  Perhaps you
>would like to see something similar to the paragraph regarding base name
>(i.e., 8 characters, can be any distinct name, ..) although many systems
>today are no more limited to 8 characters. :-) If you want some specific
>addition, would you be able to propose it ?
>
>Regards,
>
>Denis
>
> > 11. Fair enough; CMP should include a state machine too.  I believe that
> > many interoperability issues can be avoided by specifying the state
> > machine.  I am not going to hold things up over this issue.
> >
> > 12 and 13. Your proposed resolution resolves my concern.
> >
> > EDITORIAL
> >
> > 14 and 15. Your proposed resolution resolves my concern.
> >
> > 16. Okay.  As I said, this is an editorial comment, so I can live with the
> > current text.
> >
> > 17 through 24. Your proposed resolution resolves my concern.
> >
> > Russ

From: Peter Sylvester <[email-masked]>
Date: Mon, 9 Oct 2000 15:19:33 +0200 (MET DST)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: R: R: TSP: Response to the comments raised by Russ Housley
Cc: [email-masked]

> 
> You are right; I made a mistake. The response is not just a CMS msg, so =
> the
> "P7M" extensions would not do.
> 
> How about "TSR" for the request and "TST" for the response?
> 

TST seems to indicate a 'time stamp token'. Since the response is
not a time stamp token, this would be even more misleading.

From: Santoni Adriano <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: R: R: TSP: Response to the comments raised by Russ Housley
Date: Mon, 9 Oct 2000 15:02:40 +0200 

You are right; I made a mistake. The response is not just a CMS msg, so the
"P7M" extensions would not do.

How about "TSR" for the request and "TST" for the response?

A

-----Messaggio originale-----
Da: Peter Sylvester [mailto:[email-masked]]
Inviato: luned� 9 ottobre 2000 10.47
A: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Oggetto: Re: R: TSP: Response to the comments raised by Russ Housley

> 
> Is it really useful to tell apart requests vs. responses? From the TSP
> server viewpoint, an incoming message is supposed to be a request and it
> will be processed based on that obvious assumption. So the single
> content-type "application/timestamp" should suffice, IMO. As to file
> extensions, I think it's pretty irrilevant; however, as the response is a
> CMS SignedData message, I presume ".P7M" would be a proper file extension
> for it. As to the request...I do not know; why not ".TSR" ?

The response is NOT a CMS signeddata. The time stamp token, which
is embedded in the response is a CMS signeddata. 

Date: Sun, 08 Oct 2000 13:24:22 -0400
To: Polar Humenn <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Path Names to AC Holders, Targets and Proxies 
Cc: [email-masked], [email-masked], [email-masked]

Polar:

>I have some questions about total interoperability about the PKIX
>Attribute Certificate when used in environments where your application
>does not have control over both clients and server, i.e. they both don't
>subscribe to the same LDAP server.
>
>I have some problems regarding the use of GeneralName for the Holder,
>Proxies and Targets fields of the AttributeCertificate.
>
>When using DN's for these names, they only specify one level of naming.
>That is, they do not specify the Identity Chain, (i.e. path) upto a
>certain authority. Specifically, they do not name the Holder's CA, and its
>CA, and so on.

This is intentional.  In these cases, we want to bind the attribute to any 
certificate issued to that identity.  If identity collisions are possible 
in your environment, then the attributes should be bound to an 
issuer/serial number pair instead of a General Name.  RFC 2459 requires 
that X.500 distinguished names be present for issuer names.  And, in real 
world implementations, they should include significantly more information 
than a simple common name.

>Even using the Issuer-Serial type of GeneralName is not good enough to
>identify a holder, proxy, or target of the Attribute Certificate because
>it has the same problem in identifying the issuer.

I disagree.  The names that you ave chosen only include common name.  In 
real life, distinguished names, Internet domain names, and RFC 822 names 
all include much more information.

>[much text deleted]
>
>1. CN=Baltimore
>2. CN=General Motors
>3. CN=Manufacturing
>4. CN=Engineering, L=Germany
>5. CN=Human Resources
>6. CN=Henry Ford      Serial#=1234

A more likely distinguished name for the issuer of certificate number 6 is:
         c=US, o=GM, ou=Mfgr, ou= German Engr, cn=HR
A collision with this name is much less likely.

>[much text deleted]
>
>1. CN=Verisign
>2. CN=Holden
>3. CN=Human Resources
>4. CN=Ian Botham, Serial#=1234

Again, a much more likely name for the issuer of certificate 4 is:
         c=AU, o=Holden, ou=HR

Russ

From: Peter Sylvester <[email-masked]>
Date: Mon, 9 Oct 2000 10:46:37 +0200 (MET DST)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: R: TSP: Response to the comments raised by Russ Housley
Cc: [email-masked]

> 
> Is it really useful to tell apart requests vs. responses? From the TSP
> server viewpoint, an incoming message is supposed to be a request and it
> will be processed based on that obvious assumption. So the single
> content-type "application/timestamp" should suffice, IMO. As to file
> extensions, I think it's pretty irrilevant; however, as the response is a
> CMS SignedData message, I presume ".P7M" would be a proper file extension
> for it. As to the request...I do not know; why not ".TSR" ?

The response is NOT a CMS signeddata. The time stamp token, which
is embedded in the response is a CMS signeddata. 

Date: Mon, 09 Oct 2000 09:30:11 +0200
From: Margus Freudenthal <[email-masked]>
To: PKIX list <[email-masked]>
Subject: Transport protocol for OCSP ver. 2

Hello.

Which TCP-based transport protocol is used for OCSP version 2?  The
draft doesn't contain any information about that.  Will it be the old
one that is specified in older OCSP RFC or will it be like in
draft-ietf-pkix-cmp-transport-protocols-02.txt?

-- 
Margus Freudenthal                            [email-masked]
Cybernetica                                   http://www.cyber.ee/

From: Santoni Adriano <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: IETF-PXIX <[email-masked]>
Subject: R: TSP: Response to the comments raised by Russ Housley
Date: Mon, 9 Oct 2000 09:16:09 +0200 

Is it really useful to tell apart requests vs. responses? From the TSP
server viewpoint, an incoming message is supposed to be a request and it
will be processed based on that obvious assumption. So the single
content-type "application/timestamp" should suffice, IMO. As to file
extensions, I think it's pretty irrilevant; however, as the response is a
CMS SignedData message, I presume ".P7M" would be a proper file extension
for it. As to the request...I do not know; why not ".TSR" ?
 
Adriano Santoni
 
SIA S.p.A.
Milano, IT
https://ca.sia.it <https://ca.sia.it>  

-----Messaggio originale-----
Da: Russ Housley [mailto:[email-masked]]
Inviato: venerd� 6 ottobre 2000 20.11
A: Denis Pinkas
Cc: IETF-PXIX
Oggetto: Re: TSP: Response to the comments raised by Russ Housley

Denis:

I am happy with your response to number 3.  Now, for number 10.  How about
something like the following:

For the <list your types here> MIME types, implementations SHOULD include
the optional "name" and "filename" parameters.  Including a file name serves
helps preserve type information when timestamps are saved as files.  When
these parameters are included, a file name with the appropriate extension
SHOULD be selected:

  MIME Type                     File Extension

    <your request type>           .<your request extension> 

    <your response type>          .<your response extension>

    ... 

In addition, the file name SHOULD be limited to eight characters followed by
a three letter extension. The eight character filename base can be any
distinct name.

Russ

At 04:26 PM 10/06/2000 +0200, Denis Pinkas wrote:

Russ,

Thank you for your response.

The only remaining issues are numbered 3 and 10. See my comments embedded
below.
 
> Denis:
> 
> Thank you for addressing my concerns.  I address each of your proposed
> resolutions below.
> 
> TECHNICAL
> 
> 1 and 2. Your proposed resolution resolves my concern.
> 
> 3. I am not satisfied.  I accept that this is not the place to define TSP
> policy or practice statements.  However, I do not think that the RFC 2459
> syntax is appropriate for use in the TSP context.  Also, you ignored my
> concern regarding qualifiers.  RFC 2459 contains:
> 
>     PolicyInformation ::= SEQUENCE {
>          policyIdentifier   CertPolicyId,
>          policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>                                  PolicyQualifierInfo OPTIONAL }
> 
> I would prefer a structure that said "TSAPolicyId" instead of
> "CertPolicyId." Using "CertPolicyId" in this context will, in my opinion,
> confuse matters.  Also, I would like to omit policy qualifiers
> altogether.  I do not like them in certificate policies, and I would like
> to avoid them in TSA policies.

I had corrected the text but I did not understood your were also requesting
an ASN.1 change.
Sorry about that misunderstanding. I agree with your request and I have done
the changes, i.e:

 TSAPolicyId ::= OBJECT IDENTIFIER

and in the request:

 reqPolicy       TSAPolicyId    OPTIONAL,

while in the response:

 policy          TSAPolicyId,

> 4 through 9. Your proposed resolution resolves my concern.
> 
> 10. This comment is related to comment number 9, but it has absolutely
> nothing to do with flow.  It has to do with the specification of file
> naming conventions.  I would like to see a section that is parallel to RFC
> 2633, Section 3.2.1.  Further, I think that that file naming conventions
> should be labeled SHOULD, not MUST.

I understand the last sentence of your request, but I'm not sure what you
are requesting for the remaining of it-- all the text in Section 3.2.1 of
2633 with respect to MIME and S/MIME is not relevant, I think.  Perhaps you
would like to see something similar to the paragraph regarding base name
(i.e., 8 characters, can be any distinct name, ..) although many systems
today are no more limited to 8 characters. :-) If you want some specific
addition, would you be able to propose it ?

Regards,

Denis
 
> 11. Fair enough; CMP should include a state machine too.  I believe that
> many interoperability issues can be avoided by specifying the state
> machine.  I am not going to hold things up over this issue.
> 
> 12 and 13. Your proposed resolution resolves my concern.
> 
> EDITORIAL
> 
> 14 and 15. Your proposed resolution resolves my concern.
> 
> 16. Okay.  As I said, this is an editorial comment, so I can live with the
> current text.
> 
> 17 through 24. Your proposed resolution resolves my concern.
> 
> Russ

Date: Sun, 08 Oct 2000 22:39:45 +0100
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
CC: [email-masked], Polar Humenn <[email-masked]>
Subject: Re: Fwd: AttributeCertificates: Path Names to AC Holders, Targets  andProxies

Hi,

As I've said to Polar previously, I don't see what issue he's raising and
if it is an issue then it also applies to public key certificates (I think 
this is more or less what Carlisle was saying is a previous response to the
PKIX list).

Acrtually, maybe this is clearly shown from Polar's suggestion that the
"fix" is to change the definition of GeneralName (and hence the base
X.509-2000 and rfc2459 as well as the AC profile).

Maybe its me - can anyone else see the issue?

Regards,
Stephen.

Patrik F�ltstr�m wrote:
> 
> This should be discussed on the PKIX mailing list.
> 
> Please discuss...
> 
>      Patrik F�ltstr�m, Area Director Applications Area, IETF
> 
> >Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
> >From: Polar Humenn <[email-masked]>
> >To: [email-masked]
> >Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
> >
> >
> >
> >Greetings IETF,
> >
> >This is Polar Humenn with the Object Management Group (OMG).
> >
> >I have some questions about total interoperability about the PKIX
> >Attribute Certificate when used in environments where your application
> >does not have control over both clients and server, i.e. they both don't
> >subscribe to the same LDAP server.
> >
> >I have some problems regarding the use of GeneralName for the Holder,
> >Proxies and Targets fields of the AttributeCertificate.
> >
> >When using DN's for these names, they only specify one level of naming.
> >That is, they do not specify the Identity Chain, (i.e. path) upto a
> >certain authority. Specifically, they do not name the Holder's CA, and its
> >CA, and so on.
> >
> >Even using the Issuer-Serial type of GeneralName is not good enough to
> >identify a holder, proxy, or target of the Attribute Certificate because
> >it has the same problem in identifying the issuer.
> >
> >Let me illustrate a security hole that this specification has:
> >
> >Let's say I am a CA that defines employee identities. I'm pretty low on
> >the totem pole, because of my organizational structure. My identity
> >certificate has a path from a real trusted authority, such as:
> >
> >1. CN=Baltimore
> >2. CN=General Motors
> >3. CN=Manufacturing
> >4. CN=Engineering, L=Germany
> >5. CN=Human Resources
> >
> >All my employee identities are defined by 5 and their certificates are
> >signed by 5's public key. Here's one of my employees and his certificate
> >serial number:
> >
> >6. CN=Henry Ford      Serial#=1234
> >
> >I obviously listed the chain with 1 as the most significant. For example,
> >if Henry authenticates via TLS, he delivers a chain of these 6
> >certificates.
> >
> >And now for something completely different, let's switch to Holden Car
> >Company, Australia.
> >
> >The privilege service that Holden subscribes to wants to issue a attribute
> >certificate to Henry Ford from General Motors so that he can access the
> >Holden plant through the Internet. It is clearly not enough that I just
> >define the "Holder" as using the Issuer-Serial form of GeneralName, such
> >as:
> >
> >CN=Human Resources
> >Serial#=1234
> >
> >I really have to fully define the path of the holder so that we can verify
> >that the attribute certificate actually applies to the identity I am
> >presented with.
> >
> >For a contrived example, let's say the GM has authenticated a client using
> >SSL, and the plant has Versign's verification certificate (i.e.
> >CN=Verisign). The authentication provides me with the following cert
> >chain, which the GM plant has verified:
> >
> >1. CN=Verisign
> >2. CN=Holden
> >3. CN=Human Resources
> >4. CN=Ian Botham, Serial#=1234
> >
> >Then he delivers to the plant the Attribute Certificate for Henry Ford.
> >
> >Does it match? Yes, it sure does.
> >Should this happen? Obviously not.
> >
> >I know it's a bit contrived, but it is a security hole.
> >
> >Now, if the Holder contained the name path to that serial number, then
> >there wouldn't even be a question of whether the AC applied to Ian Botham
> >or not.  (Provided both the privilege service and target both trust the
> >same named high-level certificates, such as Verisign or Baltimore for
> >verification).
> >
> >The same goes for the naming of the targets and proxies.
> >
> >The problem exists for regular DN naming as their may be two CN=Henry
> >Fords at both GM and Holden.
> >
> >What can we do about this problem?
> >
> >I would suggest either changing the definition of GeneralName to include
> >DN paths. Alternatively, I may suggest attribute extensions (critical or
> >non-critical?) that complete the path from the Holder, proxies, or
> >targets.
> >
> >I do not have a problem with the Issuer of the Attribute Certificate,
> >because that will be followed by some verifying PK certificates, which
> >consequently defines the issuers name path.
> >
> >Any comments?
> >
> >Cheers and Thanks,
> >-Polar
> >

-- 
____________________________________________________________
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: Sun, 8 Oct 2000 15:42:13 +0200
To: [email-masked]
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Fwd: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
Cc: Polar Humenn <[email-masked]>

This should be discussed on the PKIX mailing list.

Please discuss...

     Patrik F�ltstr�m, Area Director Applications Area, IETF

>Date: Fri, 6 Oct 2000 10:29:55 -0400 (EDT)
>From: Polar Humenn <[email-masked]>
>To: [email-masked]
>Subject: AttributeCertificates: Path Names to AC Holders, Targets and Proxies
>
>
>
>Greetings IETF,
>
>This is Polar Humenn with the Object Management Group (OMG).
>
>I have some questions about total interoperability about the PKIX
>Attribute Certificate when used in environments where your application
>does not have control over both clients and server, i.e. they both don't
>subscribe to the same LDAP server.
>
>I have some problems regarding the use of GeneralName for the Holder,
>Proxies and Targets fields of the AttributeCertificate.
>
>When using DN's for these names, they only specify one level of naming.
>That is, they do not specify the Identity Chain, (i.e. path) upto a
>certain authority. Specifically, they do not name the Holder's CA, and its
>CA, and so on.
>
>Even using the Issuer-Serial type of GeneralName is not good enough to
>identify a holder, proxy, or target of the Attribute Certificate because
>it has the same problem in identifying the issuer.
>
>Let me illustrate a security hole that this specification has:
>
>Let's say I am a CA that defines employee identities. I'm pretty low on
>the totem pole, because of my organizational structure. My identity
>certificate has a path from a real trusted authority, such as:
>
>1. CN=Baltimore
>2. CN=General Motors
>3. CN=Manufacturing
>4. CN=Engineering, L=Germany
>5. CN=Human Resources
>
>All my employee identities are defined by 5 and their certificates are
>signed by 5's public key. Here's one of my employees and his certificate
>serial number:
>
>6. CN=Henry Ford      Serial#=1234
>
>I obviously listed the chain with 1 as the most significant. For example,
>if Henry authenticates via TLS, he delivers a chain of these 6
>certificates.
>
>And now for something completely different, let's switch to Holden Car
>Company, Australia.
>
>The privilege service that Holden subscribes to wants to issue a attribute
>certificate to Henry Ford from General Motors so that he can access the
>Holden plant through the Internet. It is clearly not enough that I just
>define the "Holder" as using the Issuer-Serial form of GeneralName, such
>as:
>
>CN=Human Resources
>Serial#=1234
>
>I really have to fully define the path of the holder so that we can verify
>that the attribute certificate actually applies to the identity I am
>presented with.
>
>For a contrived example, let's say the GM has authenticated a client using
>SSL, and the plant has Versign's verification certificate (i.e.
>CN=Verisign). The authentication provides me with the following cert
>chain, which the GM plant has verified:
>
>1. CN=Verisign
>2. CN=Holden
>3. CN=Human Resources
>4. CN=Ian Botham, Serial#=1234
>
>Then he delivers to the plant the Attribute Certificate for Henry Ford.
>
>Does it match? Yes, it sure does.
>Should this happen? Obviously not.
>
>I know it's a bit contrived, but it is a security hole.
>
>Now, if the Holder contained the name path to that serial number, then
>there wouldn't even be a question of whether the AC applied to Ian Botham
>or not.  (Provided both the privilege service and target both trust the
>same named high-level certificates, such as Verisign or Baltimore for
>verification).
>
>The same goes for the naming of the targets and proxies.
>
>The problem exists for regular DN naming as their may be two CN=Henry
>Fords at both GM and Holden.
>
>What can we do about this problem?
>
>I would suggest either changing the definition of GeneralName to include
>DN paths. Alternatively, I may suggest attribute extensions (critical or
>non-critical?) that complete the path from the Holder, proxies, or
>targets.
>
>I do not have a problem with the Issuer of the Attribute Certificate,
>because that will be followed by some verifying PK certificates, which
>consequently defines the issuers name path.
>
>Any comments?
>
>Cheers and Thanks,
>-Polar
>

Date: Fri, 06 Oct 2000 14:11:18 -0400
To: Denis Pinkas <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: TSP: Response to the comments raised by Russ Housley
Cc: IETF-PXIX <[email-masked]>

<html>
Denis:<br>
<br>
I am happy with your response to number 3.&nbsp; Now, for number
10.&nbsp; How about something like the following:<br>

<dl>
<dd>For the &lt;list your types here&gt; MIME types, implementations
SHOULD include the optional &quot;name&quot; and &quot;filename&quot;
parameters.&nbsp; Including a file name serves helps preserve type
information when timestamps are saved as files.&nbsp; When these
parameters are included, a file name with the appropriate extension
SHOULD be selected:<br>
<br>

<dd>&nbsp; MIME
Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
File Extension<br>
<br>

<dd>&nbsp;&nbsp;&nbsp; &lt;your request
type&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
.&lt;your request extension&gt;
<dd>&nbsp;&nbsp; 
<dd>&nbsp;&nbsp;&nbsp; &lt;your response
type&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .&lt;your
response extension&gt;<br>
<br>

<dd>&nbsp;&nbsp;&nbsp; ...
<dd>&nbsp;&nbsp;&nbsp; 
<dd>In addition, the file name SHOULD be limited to eight characters
followed by a three letter extension. The eight character filename base
can be any distinct name.<br>
<br>

</dl>Russ<br>
<br>
<br>
At 04:26 PM 10/06/2000 +0200, Denis Pinkas wrote:<br>
<blockquote type=cite cite>Russ,<br>
<br>
Thank you for your response.<br>
<br>
The only remaining issues are numbered 3 and 10. See my comments
embedded<br>
below.<br>
&nbsp;<br>
&gt; Denis:<br>
&gt; <br>
&gt; Thank you for addressing my concerns.&nbsp; I address each of your
proposed<br>
&gt; resolutions below.<br>
&gt; <br>
&gt; TECHNICAL<br>
&gt; <br>
&gt; 1 and 2. Your proposed resolution resolves my concern.<br>
&gt; <br>
&gt; 3. I am not satisfied.&nbsp; I accept that this is not the place to
define TSP<br>
&gt; policy or practice statements.&nbsp; However, I do not think that
the RFC 2459<br>
&gt; syntax is appropriate for use in the TSP context.&nbsp; Also, you
ignored my<br>
&gt; concern regarding qualifiers.&nbsp; RFC 2459 contains:<br>
&gt; <br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; PolicyInformation ::= SEQUENCE {<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
policyIdentifier&nbsp;&nbsp; CertPolicyId,<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
policyQualifiers&nbsp;&nbsp; SEQUENCE SIZE (1..MAX) OF<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PolicyQualifierInfo OPTIONAL }<br>
&gt; <br>
&gt; I would prefer a structure that said &quot;TSAPolicyId&quot; instead
of<br>
&gt; &quot;CertPolicyId.&quot; Using &quot;CertPolicyId&quot; in this
context will, in my opinion,<br>
&gt; confuse matters.&nbsp; Also, I would like to omit policy
qualifiers<br>
&gt; altogether.&nbsp; I do not like them in certificate policies, and I
would like<br>
&gt; to avoid them in TSA policies.<br>
<br>
I had corrected the text but I did not understood your were also
requesting<br>
an ASN.1 change.<br>
Sorry about that misunderstanding. I agree with your request and I have
done<br>
the changes, i.e:<br>
<br>
&nbsp;TSAPolicyId ::= OBJECT IDENTIFIER<br>
<br>
and in the request:<br>
<br>
&nbsp;reqPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TSAPolicyId&nbsp;&nbsp;&nbsp; OPTIONAL,<br>
<br>
while in the response:<br>
<br>
&nbsp;policy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TSAPolicyId,<br>
<br>
&gt; 4 through 9. Your proposed resolution resolves my concern.<br>
&gt; <br>
&gt; 10. This comment is related to comment number 9, but it has
absolutely<br>
&gt; nothing to do with flow.&nbsp; It has to do with the specification
of file<br>
&gt; naming conventions.&nbsp; I would like to see a section that is
parallel to RFC<br>
&gt; 2633, Section 3.2.1.&nbsp; Further, I think that that file naming
conventions<br>
&gt; should be labeled SHOULD, not MUST.<br>
<br>
I understand the last sentence of your request, but I'm not sure what
you<br>
are requesting for the remaining of it-- all the text in Section 3.2.1
of<br>
2633 with respect to MIME and S/MIME is not relevant, I think.&nbsp;
Perhaps you<br>
would like to see something similar to the paragraph regarding base
name<br>
(i.e., 8 characters, can be any distinct name, ..) although many
systems<br>
today are no more limited to 8 characters. :-) If you want some
specific<br>
addition, would you be able to propose it ?<br>
<br>
Regards,<br>
<br>
Denis<br>
&nbsp;<br>
&gt; 11. Fair enough; CMP should include a state machine too.&nbsp; I
believe that<br>
&gt; many interoperability issues can be avoided by specifying the
state<br>
&gt; machine.&nbsp; I am not going to hold things up over this
issue.<br>
&gt; <br>
&gt; 12 and 13. Your proposed resolution resolves my concern.<br>
&gt; <br>
&gt; EDITORIAL<br>
&gt; <br>
&gt; 14 and 15. Your proposed resolution resolves my concern.<br>
&gt; <br>
&gt; 16. Okay.&nbsp; As I said, this is an editorial comment, so I can
live with the<br>
&gt; current text.<br>
&gt; <br>
&gt; 17 through 24. Your proposed resolution resolves my concern.<br>
&gt; <br>
&gt; Russ</blockquote></html>

From: "Brian Tervo" <[email-masked]>
To: "D.S. Macauley C9951632" <[email-masked]>, <[email-masked]>
Subject: Re: Public Key Infrastructures
Date: Fri, 6 Oct 2000 14:07:11 -0400

This is a multi-part message in MIME format.

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

I have an attached pdf with some basic concepts.

Brian
----- Original Message -----
From: D.S. Macauley C9951632 <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 06, 2000 11:45 AM
Subject: Public Key Infrastructures

> Dear Sir/Madam,
> I am a student at the University of Huddersfield and I was wondering if it
> would be possible if you had any information on what PKI is and were it
> originated from and any other basic background information. Your help
would
> be most appreciated.
> D.Macauley

------=_NextPart_000_001B_01C02F9E.B8D85F20
Content-Type: application/pdf;
	name="PKI for Exec's.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="PKI for Exec's.pdf"

------=_NextPart_000_001B_01C02F9E.B8D85F20--

From: "D.S. Macauley C9951632" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Public Key Infrastructures
Date: Fri, 6 Oct 2000 16:45:54 +0100

Dear Sir/Madam, 
I am a student at the University of Huddersfield and I was wondering if it
would be possible if you had any information on what PKI is and were it
originated from and any other basic background information. Your help would
be most appreciated.

D.Macauley

Date: Fri, 6 Oct 2000 11:14:32 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: Carlisle Adams <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Path Names to AC Holders, Targets and Proxies 

On Fri, 6 Oct 2000, Carlisle Adams wrote:

> > Sent: 	Friday, October 06, 2000 10:28 AM
> > To: 	[email-masked]
> > Cc: 	[email-masked]; [email-masked]
> > Subject: 	Path Names to AC Holders, Targets and Proxies 
> > 
> > Greetings IETF,
> > 
> > This is Polar Humenn with the Object Management Group (OMG).
> > 
> > I have some questions about total interoperability about the PKIX 
> > Attribute Certificate when used in environments where your application
> > does not have control over both clients and server, i.e. they both don't
> > subscribe to the same LDAP server.
>  
> (...some text deleted...)
> 
> > What can we do about this problem?
> > 
> > I would suggest either changing the definition of GeneralName to include
> > DN paths. Alternatively, I may suggest attribute extensions (critical or
> > non-critical?) that complete the path from the Holder, proxies, or
> > targets.
>  
> GeneralName already does include the full DN (not just the CN, as in your
> example).

I only illustrated that with a "simple" DN, consiting of one RDN.

Am I under the false impression that DN's have structure between the
Subject of a certificate and the Issuer?

I had assumed that it can't from the mere fact that the relationship can
be idempotent, i.e. the subject and issuer can be the same DN. Which would
imply that there would have to be some recursive rule governing the
relationship on the structure. 

So, I think, and please correct me if I am wrong, it is perfectly
reasonable to have the following:

Cert 1:
Subject: "CN=Mickey Mouse, O=Disney, OU=Mousekateers"
Issuer:  "CN=Disney RA, O=A BIG CA Company, OU=DisneyRA"

Cert 2:
Subject: "CN=Disney RA, O=A BIG CA Company, OU=DisneyRA"
Issuer:  "CN=A BIGGER CA, O=Another BIGGER CA Company, L=Lamppona"

So, there is no real correlation between the subject and issuer DN's that
can be counted on within the certificate and from certificate to
certificate.

Is this correct? Please correct me if I am wrong.

If this is correct, then we have a problem with the Attribute Certificate
in the general case.

Cheers,
-Polar

From: Carlisle Adams <[email-masked]>
To: [email-masked], "'Polar Humenn'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Path Names to AC Holders, Targets and Proxies 
Date: Fri, 6 Oct 2000 11:02:57 -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_01C02FA6.82DD6D40
Content-Type: text/plain

Hi Polar,

> Sent: 	Friday, October 06, 2000 10:28 AM
> To: 	[email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	Path Names to AC Holders, Targets and Proxies 
> 
> Greetings IETF,
> 
> This is Polar Humenn with the Object Management Group (OMG).
> 
> I have some questions about total interoperability about the PKIX 
> Attribute Certificate when used in environments where your application
> does not have control over both clients and server, i.e. they both don't
> subscribe to the same LDAP server.
 
(...some text deleted...)

> What can we do about this problem?
> 
> I would suggest either changing the definition of GeneralName to include
> DN paths. Alternatively, I may suggest attribute extensions (critical or
> non-critical?) that complete the path from the Holder, proxies, or
> targets.
 
GeneralName already does include the full DN (not just the CN, as in your
example).

Carlisle.

------_=_NextPart_001_01C02FA6.82DD6D40
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: Path Names to AC Holders, Targets and Proxies </TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Polar,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Polar =
Humenn[SMTP:[email-masked]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Friday, October 06, 2000 10:28 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[email-masked]; [email-masked]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">Path Names to AC Holders, Targets and Proxies </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Greetings IETF,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This is Polar Humenn with the Object =
Management Group (OMG).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have some questions about total =
interoperability about the PKIX </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Attribute Certificate when used in =
environments where your application</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">does not have control over both =
clients and server, i.e. they both don't</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">subscribe to the same LDAP =
server.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">(...some =
text deleted...)</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">What can we do about this =
problem?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would suggest either changing the =
definition of GeneralName to include</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DN paths. Alternatively, I may =
suggest attribute extensions (critical or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">non-critical?) that complete the path =
from the Holder, proxies, or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">targets.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">GeneralName already does include the full DN (not just the CN, =
as in your example).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C02FA6.82DD6D40--

Date: Fri, 6 Oct 2000 10:28:00 -0400 (EDT)
From: Polar Humenn <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Path Names to AC Holders, Targets and Proxies 

Greetings IETF,

This is Polar Humenn with the Object Management Group (OMG).

I have some questions about total interoperability about the PKIX 
Attribute Certificate when used in environments where your application
does not have control over both clients and server, i.e. they both don't
subscribe to the same LDAP server.

I have some problems regarding the use of GeneralName for the Holder,
Proxies and Targets fields of the AttributeCertificate.

When using DN's for these names, they only specify one level of naming.
That is, they do not specify the Identity Chain, (i.e. path) upto a
certain authority. Specifically, they do not name the Holder's CA, and its
CA, and so on.

Even using the Issuer-Serial type of GeneralName is not good enough to
identify a holder, proxy, or target of the Attribute Certificate because
it has the same problem in identifying the issuer.

Let me illustrate a security hole that this specification has:

Let's say I am a CA that defines employee identities. I'm pretty low on
the totem pole, because of my organizational structure. My identity
certificate has a path from a real trusted authority, such as:

1. CN=Baltimore
2. CN=General Motors
3. CN=Manufacturing
4. CN=Engineering, L=Germany
5. CN=Human Resources

All my employee identities are defined by 5 and their certificates are
signed by 5's public key. Here's one of my employees and his certificate
serial number:

6. CN=Henry Ford      Serial#=1234

I obviously listed the chain with 1 as the most significant. For example,
if Henry authenticates via TLS, he delivers a chain of these 6
certificates.

And now for something completely different, let's switch to Holden Car
Company, Australia.

The privilege service that Holden subscribes to wants to issue a attribute
certificate to Henry Ford from General Motors so that he can access the
Holden plant through the Internet. It is clearly not enough that I just
define the "Holder" as using the Issuer-Serial form of GeneralName, such
as:

CN=Human Resources
Serial#=1234

I really have to fully define the path of the holder so that we can verify
that the attribute certificate actually applies to the identity I am
presented with.

For a contrived example, let's say the GM has authenticated a client using
SSL, and the plant has Versign's verification certificate (i.e.
CN=Verisign). The authentication provides me with the following cert
chain, which the GM plant has verified:

1. CN=Verisign
2. CN=Holden
3. CN=Human Resources
4. CN=Ian Botham, Serial#=1234

Then he delivers to the plant the Attribute Certificate for Henry Ford.

Does it match? Yes, it sure does. 
Should this happen? Obviously not.

I know it's a bit contrived, but it is a security hole.

Now, if the Holder contained the name path to that serial number, then
there wouldn't even be a question of whether the AC applied to Ian Botham
or not.  (Provided both the privilege service and target both trust the
same named high-level certificates, such as Verisign or Baltimore for
verification).

The same goes for the naming of the targets and proxies.

The problem exists for regular DN naming as their may be two CN=Henry
Fords at both GM and Holden.

What can we do about this problem?

I would suggest either changing the definition of GeneralName to include
DN paths. Alternatively, I may suggest attribute extensions (critical or
non-critical?) that complete the path from the Holder, proxies, or
targets.

I do not have a problem with the Issuer of the Attribute Certificate,
because that will be followed by some verifying PK certificates, which
consequently defines the issuers name path.

Any comments?

Cheers and Thanks,
-Polar

Date: Fri, 06 Oct 2000 16:26:56 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Russ Housley <[email-masked]>
CC: IETF-PXIX <[email-masked]>
Subject: Re: TSP: Response to the comments raised by Russ Housley

Russ,

Thank you for your response.

The only remaining issues are numbered 3 and 10. See my comments embedded
below.
 
> Denis:
> 
> Thank you for addressing my concerns.  I address each of your proposed
> resolutions below.
> 
> TECHNICAL
> 
> 1 and 2. Your proposed resolution resolves my concern.
> 
> 3. I am not satisfied.  I accept that this is not the place to define TSP
> policy or practice statements.  However, I do not think that the RFC 2459
> syntax is appropriate for use in the TSP context.  Also, you ignored my
> concern regarding qualifiers.  RFC 2459 contains:
> 
>     PolicyInformation ::= SEQUENCE {
>          policyIdentifier   CertPolicyId,
>          policyQualifiers   SEQUENCE SIZE (1..MAX) OF
>                                  PolicyQualifierInfo OPTIONAL }
> 
> I would prefer a structure that said "TSAPolicyId" instead of
> "CertPolicyId." Using "CertPolicyId" in this context will, in my opinion,
> confuse matters.  Also, I would like to omit policy qualifiers
> altogether.  I do not like them in certificate policies, and I would like
> to avoid them in TSA policies.

I had corrected the text but I did not understood your were also requesting
an ASN.1 change.
Sorry about that misunderstanding. I agree with your request and I have done
the changes, i.e:

 TSAPolicyId ::= OBJECT IDENTIFIER

and in the request:

 reqPolicy       TSAPolicyId    OPTIONAL,

while in the response:

 policy          TSAPolicyId,

> 4 through 9. Your proposed resolution resolves my concern.
> 
> 10. This comment is related to comment number 9, but it has absolutely
> nothing to do with flow.  It has to do with the specification of file
> naming conventions.  I would like to see a section that is parallel to RFC
> 2633, Section 3.2.1.  Further, I think that that file naming conventions
> should be labeled SHOULD, not MUST.

I understand the last sentence of your request, but I'm not sure what you
are requesting for the remaining of it-- all the text in Section 3.2.1 of
2633 with respect to MIME and S/MIME is not relevant, I think.  Perhaps you
would like to see something similar to the paragraph regarding base name
(i.e., 8 characters, can be any distinct name, ..) although many systems
today are no more limited to 8 characters. :-) If you want some specific
addition, would you be able to propose it ?

Regards,

Denis
 
> 11. Fair enough; CMP should include a state machine too.  I believe that
> many interoperability issues can be avoided by specifying the state
> machine.  I am not going to hold things up over this issue.
> 
> 12 and 13. Your proposed resolution resolves my concern.
> 
> EDITORIAL
> 
> 14 and 15. Your proposed resolution resolves my concern.
> 
> 16. Okay.  As I said, this is an editorial comment, so I can live with the
> current text.
> 
> 17 through 24. Your proposed resolution resolves my concern.
> 
> Russ

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: An Internet Attribute Certificate Profile for Authorization to Proposed Standard
Reply-to: [email-masked]
Date: Fri, 06 Oct 2000 06:55:48 -0400
Sender: [email-masked]

The IESG has received a request from the Public-Key Infrastructure
(X.509) Working Group to consider An Internet Attribute Certificate
Profile for Authorization <draft-ietf-pkix-ac509prof-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 October 20, 2000.

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dcs-07.txt
Date: Fri, 06 Oct 2000 06:31:17 -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-07.txt
	Pages		: 48
	Date		: 05-Oct-00
	
This document describes a general Data Validation and Certification
Server (DVCS) 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 assert the validity of signed documents, public key
certificates, and the possession or existence of data.

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

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

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

--OtherAccess--

--NextPart--

From: Michael Zolotarev <[email-masked]>
To: Jung Joo-won <[email-masked]>, [email-masked]
Subject: RE: Requirement or API for EE's key management
Date: Fri, 6 Oct 2000 13:28:11 +1000 

Jung,
I'm afraid there is no single API covering all aspects of credentials
management you've listed.

Probably CDSA CSSM API may be the best choice here. Not sure you'll find
anything on certificate validation path creation. There is a number of
freeware and commercial cert management libraries, but I'm not sure they use
common API. I'm pretty sure that they aren't, actually.

The CMP presents an acceptable model about EE keys/certs management.

Michael

-----Original Message-----
From: Jung Joo-won [mailto:[email-masked]]
Sent: Friday, 6 October 2000 4:03
To: [email-masked]
Subject: Requirement or API for EE's key management

Is there any documents or specifications about the requirement or
API of End Entity's key pair management?

I do not talk about CMP but about the common API or security
requirements document about key pair generation, storing to hard disk
or floppy or smart card, key pair export/import, certificate download(?)
and certificate validation path creation.

Are there acceptable models about End Entity (or keyholder)'s
private key and certificate management?

Thanks in advance.

Joo-won Jung

-- 
Jung Joowon				| E-mail: [email-masked]
Dept. of Computer Science		|     /\^	Always being
Korea Advanced Inst. of Sci. and Tech.	|    /   \/\		with Network
Taejon, Republic of Korea, 305-701	|   /	  \ \	Mountain Duck
(Quack)

Date: Fri, 6 Oct 2000 03:02:58 +0900
From: Jung Joo-won <[email-masked]>
To: [email-masked]
Subject: Requirement or API for EE's key management

Is there any documents or specifications about the requirement or
API of End Entity's key pair management?

I do not talk about CMP but about the common API or security
requirements document about key pair generation, storing to hard disk
or floppy or smart card, key pair export/import, certificate download(?)
and certificate validation path creation.

Are there acceptable models about End Entity (or keyholder)'s
private key and certificate management?

Thanks in advance.

Joo-won Jung

-- 
Jung Joowon				| E-mail: [email-masked]
Dept. of Computer Science		|     /\^	Always being
Korea Advanced Inst. of Sci. and Tech.	|    /   \/\		with Network
Taejon, Republic of Korea, 305-701	|   /	  \ \	Mountain Duck (Quack)

Date: Thu, 05 Oct 2000 13:49:20 -0400
To: IETF-PXIX <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: TSP: Response to the comments raised by Russ Housley

Denis:

Thank you for addressing my concerns.  I address each of your proposed 
resolutions below.

TECHNICAL

1 and 2. Your proposed resolution resolves my concern.

3. I am not satisfied.  I accept that this is not the place to define TSP 
policy or practice statements.  However, I do not think that the RFC 2459 
syntax is appropriate for use in the TSP context.  Also, you ignored my 
concern regarding qualifiers.  RFC 2459 contains:

    PolicyInformation ::= SEQUENCE {
         policyIdentifier   CertPolicyId,
         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                 PolicyQualifierInfo OPTIONAL }

I would prefer a structure that said "TSAPolicyId" instead of 
"CertPolicyId." Using "CertPolicyId" in this context will, in my opinion, 
confuse matters.  Also, I would like to omit policy qualifiers 
altogether.  I do not like them in certificate policies, and I would like 
to avoid them in TSA policies.

4 through 9. Your proposed resolution resolves my concern.

10. This comment is related to comment number 9, but it has absolutely 
nothing to do with flow.  It has to do with the specification of file 
naming conventions.  I would like to see a section that is parallel to RFC 
2633, Section 3.2.1.  Further, I think that that file naming conventions 
should be labeled SHOULD, not MUST.

11. Fair enough; CMP should include a state machine too.  I believe that 
many interoperability issues can be avoided by specifying the state 
machine.  I am not going to hold things up over this issue.

12 and 13. Your proposed resolution resolves my concern.

EDITORIAL

14 and 15. Your proposed resolution resolves my concern.

16. Okay.  As I said, this is an editorial comment, so I can live with the 
current text.

17 through 24. Your proposed resolution resolves my concern.

Russ

From: "Raymond Lee" <[email-masked]>
To: <[email-masked]>
Subject: unsubscribe
Date: Thu, 5 Oct 2000 05:06:46 -0700
Importance: Normal

unsubscribe

From: Peter Sylvester <[email-masked]>
Date: Wed, 4 Oct 2000 17:43:55 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments

> Thanks a lot. 
You are welcome. 

Date: Wed, 04 Oct 2000 12:05:40 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-ocsp-path-00.txt

Comments on the document on Path discovery

It is questionable whether this function, used alone, should be considered
an extension to OCSP.

Today the basic task of OCSP is to provide the revocation status of the
certificate. However, path discovery may be useful even if no OSCP service
is ever supported by the CA which has issued the certificate (but only
CRLs).

It would seem more appropriate to allow the same server to support both an
OCSP service and a path discovery service, rather than to consider this
service as an extension to OCSP.

Since an OCSP request is assumed to be used, that request includes the
certificate identifier of the leaf certificate. However, the definition of
the "top" root key and the constraints are is missing. They may be indicated
using one of the following ways:

1) with an OID of the validation policy, or
2) with a set of self-signed certificates, and, if the Certificate Policy
constraints and the naming constrains are not included in it, to specify
them separately. For the revocation information, it should be possible to
indicate whether CRLs or OCSP responses are requested, at least for the leaf
certificate and the CA certificates.

The response is missing an easy way to relate every CRL or OCSP response to
every certificate of the chain.

In the security consideration section, it is mentioned that this service
need not be trusted. This is an interesting remark which may be used as an
additional argument to dissociate that service from an OCSP service, since
by definition all responses from an OCSP server are signed (unless there is
an error) and if the service is untrusted, then no signature is necessary.
So returning all that information, without a signature should be considered.

Remainder: As this has already been raised on the mailing list, the fact
that the server is defined as stateful is not appropriate. The parameter
"retryReference" should be deleted.

The structure of both the request and the response should be modified to
accommodate these requirements.

Denis

Date: Wed, 04 Oct 2000 12:04:15 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-ocsp-valid-00.txt

Comments on the document on Delegated path validation

The validation has to be made against a set of rules which may be more
complex than validation against a single root key associated with
Certificate policy constraints and naming constraints. These constraints are
not necessarily embedded in a self-signed certificate. Multiple root keys
may be used in parallel. In addition, it may be important to use either CRLs
or ARLs only, or OCSP responses. This may even be different whether it is
for a leaf certificate or a CA certificate.

This set of rules may be called "validation policy" and is thus fully
distinct from a Certificate Policy (CP). The protocol should support as an
option the possibility to simply provide a single OID which will be the OID
of the validation policy.

As an alternative, when the rules are "simpler", it could be possible to
support a set of trust points with their constraints. 

For all these trust points, it should be possible to specify whether CRLs or
OCSP responses should be used for leaf certificates and whether ARLs or OCSP
responses should be used for CA certificates.

For every trust point, it should be possible to specify the self-signed
certificate and, if the Certificate Policy constraints and the naming
constrains are not included in it, to specify them separately.

The structure of both the request and the response should be modified to
accommodate these requirements.

Denis

Date: Wed, 04 Oct 2000 17:16:00 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Peter Sylvester <[email-masked]>, IETF-PXIX <[email-masked]>
Subject: Re: draft-ietf-pkix-time-stamp-09 comments

Peter,

It is a good catch. 

Effectively there used to be another field after which was:

keyUpdateWarning       (6)
         -- Otherwise, the Time Stamp Token is not present
     }

This field has been purposely deleted because it was not meaningful in a TSP
context, but only in a CMP context.

However the comma was still there. :-(

Thanks a lot. 

Denis

> > Peter,
> >
> > Sorry. The time for new comments/text improvements/ text
> > clarifications is now closed. We are only processing commments
> > received during the IESG last call period. Of course, if the comment
> > is purely editorial, e.g. a typo, we can still certainly take it.
> >
> > Regards,
> >
> > Denis
> >
> 
> The ASN.1 in the compilable module is not correct, there is
> a comma (,) which shouldn't be there.
> 
>          revocationNotification (5),
>           -- notification that a revocation has occurred

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-cmp-transport-protocols-02.txt
Date: Wed, 04 Oct 2000 06:55:14 -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		: Transport Protocols for CMP
	Author(s)	: A. Kapoor, R. Tschalar
	Filename	: draft-ietf-pkix-cmp-transport-protocols-02.txt
	Pages		: 10
	Date		: 03-Oct-00
	
This document describes how to layer Certificate Management
Protocols [CMP] over various transport protocols.

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

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

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

--OtherAccess--

--NextPart--

From: Peter Sylvester <[email-masked]>
Date: Wed, 4 Oct 2000 11:00:18 +0200 (MET DST)
To: [email-masked]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Cc: [email-masked], [email-masked]

> Actually, I think the comma indicates that
> another line is missing that should follow
> this one.
> 

Right, in version 8 there was indeed a (6):

PKIStatus ::= INTEGER {
         granted                (0),
         -- When the Status contains the value zero a Time Stamp Token
         -- is present.
         grantedWithMods        (1),
         rejection              (2),
         waiting                (3),
         revocationWarning      (4),
         revocationNotification (5),
         keyUpdateWarning       (6)
         -- Otherwise, the Time Stamp Token is not present
     }

Fortunately some people keep older versions of the IETF drafts :-) 

Date: Tue, 03 Oct 2000 22:48:35 -0400
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting 
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments

Actually, I think the comma indicates that
another line is missing that should follow
this one.

Peter Sylvester wrote:
> 
> > Peter,
> >
> > Sorry. The time for new comments/text improvements/ text
> > clarifications is now closed. We are only processing commments
> > received during the IESG last call period. Of course, if the comment
> > is purely editorial, e.g. a typo, we can still certainly take it.
> >
> > Regards,
> >
> > Denis
> >
> 
> The ASN.1 in the compilable module is not correct, there is
> a comma (,) which shouldn't be there.
> 
>          revocationNotification (5),
>           -- notification that a revocation has occurred

-- 
Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------

Date: Tue, 03 Oct 2000 11:08:24 -0400
To: [email-masked]
From: Tim Polk <[email-masked]>
Subject: FYI: AES announcement

FYI,

NIST announced the selection of the Rjindael algorithm as the Advanced 
Encryption Standard (AES) yesterday.  For more information, check out the 
NIST AES website at http://csrc.nist.gov/encryption/aes/.

Thanks,

Tim Polk

From: Peter Sylvester <[email-masked]>
Date: Tue, 3 Oct 2000 14:20:43 +0200 (MET DST)
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-time-stamp-09 comments
Cc: [email-masked]

> Peter,
> 
> Sorry. The time for new comments/text improvements/ text
> clarifications is now closed. We are only processing commments
> received during the IESG last call period. Of course, if the comment
> is purely editorial, e.g. a typo, we can still certainly take it.
> 
> Regards,
> 
> Denis
> 

The ASN.1 in the compilable module is not correct, there is
a comma (,) which shouldn't be there. 

         revocationNotification (5),
          -- notification that a revocation has occurred