On Thu, Aug 15, 2019 at 12:58:45PM -0400, Michael Richardson wrote:
>
> Benjamin Kaduk wrote:
> >> + directly. This is because BRSKI pledges MUST use the CSR Attributes
>
> > (This may not need to be a 2119 MUST since we cite 7030.)
>
> It turns out, in pracice, that many EST clients do not use the CSR
> Attributes, so I need this line as a hammer.
Fair enough.
> >> > "intended" implies that the EST server has some knowledge of what
> >> the > pledge is expected to be doing in the network, right?
> >>
> >> Yes. The ACP document is quite specific about the (rfc822Name)
> >> attributes to assign. Certainly the attributes could include stuff
> >> like "ve608.core1.tor1.example.net" if the Registrar knew how this
> >> device was to be used, but more likely that would be set up
> >> afterwards.
>
> > Hmm, maybe later when we say "the local infrastructure (EST server)
> > informs the pledge of the proper fields to include in the generated
> > CSR" we could reiterate that the EST server has local configuration
> > information to inform this messaging, though it's probably not
> > necessary.
>
> I've added the ().
>
> + fields to include in the generated CSR (such as rfc822Name).
>
> doc> To alleviate these operational difficulties, the pledge MUST request
> doc> the EST "CSR Attributes" from the EST server and the EST server
> doc> needs to be able to reply with the attributes necessary for use of
> doc> the certificate in its intended protocols/services. This approach
> doc> allows for minimal CA integrations and instead the local
> doc> infrastructure (EST server) informs the pledge of the proper fields
> doc> to include in the generated CSR. This approach is beneficial to
> doc> automated boostrapping in the widest number of environments.
> >>
> >> > This is convenient, but has some security considerations in that it
> >> > implies that the validation policy on the CA is somewhat lax, since
> >> the > EST server is expected to be doing most of the policy controls.
> >> Thus, > a compromised pledge/device could send a CSR with unauthorized
> >> fields > and it is likely to be signed, allowing for some level of
> >> privilege > escalation. When the registrar acts as a proxy to the CA
> >> as well as > its EST role, as described later, this risk is
> >> diminished.
> >>
> >> I don't really understand. EST servers are Registration Authorities,
> >> and they have some kind of priviledged access to the CA, and are
> >> mandated to check the CSR. I expected to find a statement to this
> >> effect in RFC7030, in section 4.2.1, but I don't see any particularly
> >> strong language. This seems like a quality of implementation issue in
> >> the Registrar.
>
> > The high-level intended workflow described here is roughly "(1) pledge
> > asks registrar for config; (2) pledge puts that config in a CSR, signs
> > the CSR, and sends the CSR to registrar; (3) registrar passes CSR to CA
> > using registrar's implicit authority. We don't describe any crypto to
> > check that (2) happens as intended, as opposed to the pledge
> > dishonestly claiming "oh, and I'm a CA" or "I can provide all ACP
> > services, even privileged ones", so that has to be done by policy in
> > the registrar, as you note. I'm wary of suggesting the workflow that
> > relies on the registrar's implicit authority at the CA without also
> > noting the registrar's policy enforcement obligations. Though it's
> > possible this is covered elsewhere and doesn't need to be duplicated
> > here.
>
> I think it goes back to the RA and more specifically, the CA, being boss of
> what going into a certificate. To the point where it generally seems really
> hard to deploy new extensions in the public WebPKI.
>
> It does say:
>
> The registrar MUST also confirm that the resulting CSR is
> formatted as
> indicated before forwarding the request to a CA. If the registrar is
> communicating with the CA using a protocol such as full CMC, which
> provides mechanisms to override the CSR attributes, then these
> mechanisms MAY be used even if the client ignores CSR Attribute
> guidance.
Hmm, I guess I must have missed that or skimmed over it too quickly.
> >> > Section 7
> >>
> >> > If this is non-normative and will need to be fleshed out in a
> >> separate > document, would an Appendix be more appropriate?
> >>
> >> Section 9 and 10 refer back to this section in a normative fashion.
>
> > Er, wouldn't that make this section no longer non-normative? (Not that
> > I could find the references you're talking about, so a clue bat is
> > welcome.)
>
> It's of the form, "if you wish to do X, then you MUST do Y"
> (but, X is not a MUST).
That sp
