Subject: Request for consensus call on AC draft

From: Michael Myers <[email-masked]>
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

---

From: "Covey, Carlin" <[email-masked]>
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:"

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

> -----Original Message-----
> 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,
>