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

From: "Covey, Carlin" <[email-masked]>
Date: Fri, 27 Oct 2000 15:37:21 -0700

Polar, see comments embedded below.

> -----Original Message-----
> From: Polar Humenn [mailto:[email-masked]]
> Sent: Friday, October 27, 2000 2:02 PM
> To: Linn, John
> Cc: 'Dale Gustafson'; [email-masked]
> Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

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

---

From: Polar Humenn <[email-masked]>
Date: Sun, 29 Oct 2000 14:03:25 -0500 (EST)

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

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

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

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

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

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