<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/24/2013 08:27 AM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gVS8Yg8u5SkHyh4PiKC4Ccx4Jn7=oAaA5xc+Lz0EW0ZSQ@mail.gmail.com"
type="cite">
<div dir="ltr">Given that credentials are owned by users, and
there may be more than one "admin" user, I'm not sure that's
ideal.</div>
</blockquote>
The plan was always to have some way to scoped down the signing
cert. It seems like the two potential scopes is either the
"keystone" user or the keystone endpoint. It seems like the User
object is more consistent with the rest of the cert management. We
can specify who the default signing user is either in a config file
change or via some new API. I'm trying to do this within the
previous design approach, though, and I am not certain that any new
API is really desirable. We had discussed using the Credentials API
for this in the past. Agreeds that we shouldn't just say "admin"
although that might be a viable default.<br>
<br>
An alternative is to require a "signing user" field into the PKI
token format. That was an extension I was planning for anyway, but
had not yet specified. It still leaves undefinied how to enforce
that a given user certificate is authorized to sign tokens. <br>
<br>
We need to ship the CA cert alongside the signing cert as well. <br>
<br>
The more I think about it, the more I am concerned with using the
credential API as is. I think that the certificates we are talking
about here need to be very carefully controlled. We don't want
someone uploading their own certificate and redirecting the PKI
sigining to their own machines certificate. I think that the
signing certificates need to be stored in the filesystem, and the
Keystone Posix user (or Apache HTTPD user) should only have read
access to these.<br>
<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAC=h7gVS8Yg8u5SkHyh4PiKC4Ccx4Jn7=oAaA5xc+Lz0EW0ZSQ@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br clear="all">
<div>
<div><br>
</div>
-Dolph</div>
<br>
<br>
<div class="gmail_quote">On Tue, Apr 23, 2013 at 11:04 PM, Adam
Young <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="im">
<div>On 04/23/2013 10:29 PM, Dolph Mathews wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">It's not a core API feature, because as
Jonathan pointed out, the resources don't make sense
in a UUID configuration. If it ends up in v3, it
should be done as an extension and they should raise
a 404 when the token_format is UUID (or in Havana, a
standalone middleware that you install when opting
for the PKI token_factory plugin).</div>
</blockquote>
<br>
</div>
I'd like to leave it as V2 only. For V3, we should make
use of the credential API. The CA cert and the signing
certs should both be owned by the keystone admin user, so
the question is how should the auth_token middleware
figure that out?
<div class="im"><br>
<br>
<blockquote type="cite">
<div class="gmail_extra"><br clear="all">
<div>
<div><br>
</div>
-Dolph</div>
<br>
<br>
<div class="gmail_quote">On Tue, Apr 23, 2013 at
8:13 PM, Adam Young <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ayoung@redhat.com"
target="_blank">ayoung@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div>
<div>On 04/23/2013 06:22 PM, Yee, Guang
wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span
style="color:#1f497d">I think
that’s debatable. But please file
a bug so we can keep track of it.</span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d">Thanks,</span></p>
<p class="MsoNormal"><span
style="color:#1f497d">Guang</span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
<div>
<div
style="border:none;border-top:solid
#b5c4df 1.0pt;padding:3.0pt 0in
0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Brownell, Jonathan C
(Corvallis) <br>
<b>Sent:</b> Tuesday, April
23, 2013 3:10 PM<br>
<b>To:</b> Yee, Guang; Miller,
Mark M (EB SW Cloud - R&D
- Corvallis); Adam Young;
Dolph Mathews<br>
<b>Subject:</b> RE: Keystone
Certificate Distribution</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
style="color:#1f497d">I was also
surprised to see that the
/v2.0/certificates/* content is
available even when the
token_format = UUID.</span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d">Jonathan</span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
<div>
<div
style="border:none;border-top:solid
#b5c4df 1.0pt;padding:3.0pt 0in
0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Yee, Guang <br>
<b>Sent:</b> Tuesday, April
23, 2013 2:24 PM<br>
<b>To:</b> Miller, Mark M (EB
SW Cloud - R&D -
Corvallis); Adam Young; Dolph
Mathews<br>
<b>Cc:</b> Brownell, Jonathan
C (Corvallis)<br>
<b>Subject:</b> RE: Keystone
Certificate Distribution</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
style="color:#1f497d">Adam, Dolph,</span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d">Looks like
the certificate distribution APIs
are not in the V3 API set.</span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d">/certificates/ca</span></p>
<p class="MsoNormal"><span
style="color:#1f497d">/certificates/signing</span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d">You guys
recall why we didn’t include them.
In any case, given that PKI token
is now the default, we should
include them in 3.1. What say you?</span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="color:#1f497d">Guang</span></p>
<p class="MsoNormal"> </p>
</div>
</blockquote>
</div>
</div>
No, it is not a bug. The content of that file
might not be needed, but there is no reason to
hide it.<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>