provide example of CSR attribute request

[toerless]

  The Registar MUST also confirm the resulting CSR is formatted as
   indicated before forwarding the request to a CA.  _If the Registar is
   communicating with the CA using a protocol like full CMC which
   provides mechanisms to override the CSR attributes, then these
   mechanisms MAY be used even if the client ignores CSR Attribute
   guidance_.

Clueless question: How the heck would this work ? I thought that the information in the certificate is also signed with the private key of the pledge so nobody can change its information. This paragraph makes it look as if the certificate returned from the CA is only signed by the CA. (yes, clueless question).

What is a pledge supposed to do with certificates that do not match what it did send out to be signed but was changed by the registrar and/or CA ? accept ? Is this another possible error condition to consider ? Eg: acceptance of cert by pledge under what conditions ?

[pritikin]

funny. i was looking at this as well and had to merge our diffs (I tossed some of mine and used yours).

Yes, the CA is the ultimate authority. It signs the cert and the pledge can shove off if it has a problem. The difficulty is actually that the current PKI methods of forwarding a request have either a really complex "full CMC" approach to "modifying" a request or they punt on the idea entirely.

This is exactly what we avoid with the "prior-signed-voucher" stuff. We go for a simpler approach to that problem. But anyway...

In PKI we can either get the pledge to put the right stuff in the request using CSR attributes which is a workaround or use the very specific protocols to communicate with the CA (where 'full CMC' is one protocol and there are others).

when I think about this problem i feel similar to my position on vouchers: lets ditch the entire problem and just use JWT. :/

[pritikin]

The text of https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-09#section-6.1.1 indicates a bunch of information that 'MUST be encoded in the LDevID in the subjectAltName'. This information is known to the server but is not known to the client during enrollment:

anima.acp+{+{+}}@
Example:
anima.acp+fda379A6f6ee00000200000064000001+area51.research@acp.exampl
e.com

The obvious solution is for the service infrastructure to properly encode the information into the certificate issued. Done and Done. Only it isn't easily done:

The PKI CA infrastructure is notoriously difficult to setup and build and integrate with. The IETF PKIX method for having "the service infrastructure to properly encode the information into the certificate" is the Registrar using the CMC defined https://tools.ietf.org/html/rfc5272#section-6.5 RA Certificate Modification Controls which "exist for RAs to be able to modify the contents of a certification request". If that is available then Done and Done again. Unfortunately many CA's only provide a simple REST interface where a CSR is pushed w/o a standard method for RA modification of controls. So this is still on operational issue for building an Anima environment unless one commits to a custom PKI.

An alternate approach suggested by EST is to have the pledge request from the RA what fields might be needed in the CSR. In that way the client can build and sign the CSR and the RA only needs to forward it to the CA via whatever simple interface is available. From the CA's perspective the client simply knew what to request via either manual configuration or protocol. To support this EST introduced the https://tools.ietf.org/html/rfc7030#section-4.5 CSR Attributes exchange. This would trivially address the issue except that the encoding of CSR Attributes is consistent with PKIX definitions: namely that it is a ASN1 structure. The https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-09#section-6.1.1 structure then needs to be defined for encoding into this structure. Ick. One begins to see why BRSKI has moved to json encodings despite the ongoing pressure to stick with ASN1/PKCS7.

Current text of BRSKI mandates that the pledge support this model but doesn't get into defining specific attributes:
"To alleviate these operational difficulties, the Pledge MUST request
the EST "CSR Attributes" from the EST server and the EST server needs
to be able to reply with the attributes necessary for use of the
certificate in its intended protocols/services. This approach allows
for minimal CA integrations and instead the local infrastructure (EST
server) informs the Pledge of the proper fields to include in the
generated CSR. This approach is beneficial to automated boostrapping
in the widest number of environments."

I can see some ways forward:

option1) https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-09#section-6.1.1 defines a very specific structure for the necessary CSR Attribute response. I don't like this because I'm over the ASN1. I was outvoted wrt to JWT so maybe folks want to go this way?

option2) https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-09#section-6.1.1 defines a generic json structure for generic json attributes; and then uses that to define the necessary attributes. This has the advantage of minimizing pain if new attributes are needed as they can go into the easier to define json structure. It has all the complexity of option1 plus additional json complexity. I'm not in favor.

example: do some ASN1craft, and stick json in it
ASN1blahblah
ASN1blahblah
ASN1blah_some_json: {json stuff}
ASN1blah_closing

option3) The above (2) json definition stuff is defined in BRSKI as a generic method of 'easing the ASN1 pain' but leaves the second half to anima. This could be done via a new CSR Attributes URL that uses json encoding rather than touching the existing message format at all. This is arguably a reasonable position as BRSKI already introduces a bunch of json messages to the enrollment flow and thus it might be a good time for this. As I'm in favor of this approach I'll provide example language. This would go in BRSKI replacing some of the current https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-07#section-3.8.2 language starting at the 2nd paragraph:

To alleviate these operational difficulties, the Pledge MUST request the "CSR Attributes" from the Registrar. This is done with an HTTPS POST using the operation path value of "/csrattrNEW" [EDNOTE: pick new URL or even just signal content type]. The syntax for the application/csrattrsNEW [EDNOTE: add IANA section for this] is:

A json structure as follows:

{
// an optional base64encoded 'legacy' EST defined structure. expected to not be used much
"csrattrs: "base64encoded==",
"ACPinfo": "anima.acp+fda379A6f6ee00000200000064000001+area51.research@acp.exampl
e.com"
}

[EDNOTE: text here about supporting unknown fields and etc. Optional reference to the anima document that would define the above ACPinfo field used in the example.]

[pritikin]

option4) We need to recognize this is effectively delivering a bit of configuration information. I'm looking forward to input from Kent w/ his netconf perspective.

[mcr]

I suggest that ACPinfo structure should be broken down into pieces (which the pledge needs to know anyway, such as the prefix), so let's solve this for the ANIMA subjectAltName, and then push back on the PKI people to fix the RA->CA interface for other attributes.

"ACPinfo" : { "acp-prefix" : "fda379A6f6ee00000200000064000001", 
                    "acp-prefix-length": 96,
                    "acp-plus-part": "area51.research",
                    "acp-domain": "acp.example.com"
}

[mcr]

BRSKI will continue to use ASN1 encoded CSR attributes. The rfc822Name OID can be used to form the appropriate CSR attribute structure.
We are open to content negotiation (using Accept: header or a new URL) to return structured JSON rather than the CSR attribute structure.

[mcr]

An example is needed for the BRSKI document of the resulting CSR attribute request.

[mcr]

leave until AUTH48 to update examples.