Re: [Anima] rfc822Name use in Autonomic Control Plane document

[Sean Turner <[e-mail]>]

I am coming at this way late, and I apologize for that.

After reviewing draft-ietf-anima-autonomic-control-plane, I think that putting ACP Domain Information in rfc822Name is a bad idea. After reviewing the mailing list for rfc822Name-related messages, I think I may have graduated to thinking that putting ACP Domain Information in rfc822Name is a very risky deployment strategy, and I may have even graduated to thinking it is harmful to others in the Internet ecosystem.

rfc822Name is meant to convey “an Internet mail address” [RFC5280]. ACP Domain Information is not that so it seems, at least to me, like rfc822Name is not the right place to put ACP Domain Information.

My next thought was that others have defined values for otherName, which is the extension point in X.509 to support name forms not envisioned in 2002, so what is special about anima that they should to “squat" on an existing name form? The rationale, which seems oddly out of place in a normative section, did not really make sense to me, especially in the context of IDevID and LDevID. For example, the “Rfc822 addresses have become standard identifiers of entities in many systems, including the majority of user identification in web or mobile applications, ...” might well be true for humans, but it is not true for devices. Humans can only remember few identifiers (e.g., an email addresses) and type them correctly over and over. The situation here is vey different; a device is identified (and authenticated) by the IDevID and LDevID. The sense I got from the rationale boils down to: we need some certs and we think we can get them if we put our “name" in a commonly supported field.

Regardless of whether public CAs or enterprise CAs issue the certs, what seems to be getting lost here is that running a CA is more than just running a server and signing a bag of bits. If you are going to run a CA that is trusted beyond your organization, a lot of policies and procedures are followed to make it trustworthy. You need to write a CP (Certificate Policy) and CPS (Certification Practice Statement) [RFC3647], get lawyers to review it and probably write section 9 (Other Business and Other legal Matters), and you are going to need to get regular audits from a reputable firm. To limit your liability, you are also likely going to need to have Subscriber and/or Relying Party agreements.

As far as private CAs goes, I am not trying to say what is hard and what is not, but both Microsoft CA and OpenSSL support arbitrary data being placed in a subjectAltName.otherName:
- MS: https://docs.microsoft.com/en-us/windows/win32/api/certenroll/nn-certenroll-ix509extensionalternativenames
- OpenSSL: https://www.openssl.org/docs/man1.0.2/

If you are relying on a public CA, I think this is a very risky deployment strategy because this I-D is saying that it is okay to request a name that that has different semantics than the name that you are asking to be certified. Consider whether:
- a CA could reject the request outright?
- a CA would revoke an already issued certificate after determining that the request did not comply with the CP, CPS and/or Subscriber agreement?
- an RP could later claim damages because the Subscriber did not request the certificate in good faith?

I also think that there is some potential for negative impacts on others in the Internet ecosystem based on this I-D, at least in the light of the above. For example, maybe just maybe somebody manages to get 100K IDevID certificates from a public CA. That public CA decides that those certificates were mis-issued and revokes them as their CP/RP agreement allows (or even requires). An entity that has to download and then slog through the bigger-than-normal CRL (Certificate Revocation List) is adversely affected. Maybe that CA only supports OCSP (Online Certificate Status Protocol), but the OCSP Responder is fed by a CRL, the CA still needs to store and process the bigger-than-normal CRL to pump out the OCSP responses so the CA is also adversely impacted.

I know I am not providing an alternative solution here, but maybe we can do that in another thread.

spt

> On Jun 16, 2020, at 22:44, Benjamin Kaduk <[e-mail]> wrote:
> 
> Hi Brian, Michael,
> 
> On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote:
>> On 16-Jun-20 12:20, Michael Richardson wrote:
>>> 
>>> Hi, I have had a few conversations with Toerless who is trying to deal with
>>> the feedback on the ACP document.
>>> 
>>> An item that has come up is the use, or claimed abuse of the rfc822Name SAN.
>>> 
>>> We already had this debate.
>>> Some time ago.  The WG decided.
> 
> With all due respect, this is not the sole decision of the ANIMA WG to
> make.  If WGs had such authority then why bother with cross-area review?
> 
>>> Three or four years ago, I think.
>> 
>> Yes, this is relitigating an issue that was resolved a long time ago in discussing Ben's DISCUSS:
> 
> I'm not sure I understand why you use the word "resolved" here:
> 
>> https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc
> 
> In this message, I say that "I still feel like this is not the best
> architectural choice" and that I will provide a sketch of an alternative in
> my (then-)forthcoming ballot position; that ballot position retains the
> Discuss-level concern about rfc822Name usage along with the promised
> alternative.
> 
>> The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26
> 
> I appreciate that the attempted justification is clearly written; however,
> I do not find it compelling.  Russ did not, either, and I just heard back
> from Sean Turner a few days ago to confirm that he supports Russ's
> comments.  (There should be a few other editorial-ish comments that came
> out of that review that are still pending.)
> 
>> I believe it is incorrect IETF process to rediscuss this point yet again.
> 
> (I'm not sure if the "yet again" refers to "after the WG decided" or "after
> the (alleged) resolution of my first Discuss point".)
> 
> If you believe the technical answer is clear and that I am in error to
> continue to hold my Discuss point for it, are there not also clear IETF
> processes to follow?  E.g., asking for the "Single Discuss" ballot procedure
> described at https://www.ietf.org/standards/process/iesg-ballots/?  I
> believe I have mentioned this option to Toerless previously; my apologies
> if that is not the case.  While I'm willing to continue discussing the
> topic and pull in additional PKIX experts to weigh in, there is perhaps
> some consideration to matters of expediency.
> 
>>> 
>>> I sure wish that we could use something else.
>>> But, CAs and CA software make that very difficult.
>>> 
>>> Given that the era of publically anchored Enterprise CAs is dead, there are
>>> only two ways an (Enterprise) ACP Registrar is going to occur.
>>> 
>>> 1) by running a private CA.
>>>   Sure anything is possible if you are writing your own code, but
>>>   most will not be doing that. (I've supported otherName in my code for
>>>   other purposes, and it's not that difficult, but it's not trivial either)
>>>   My experience with COTS CA systems it that it's really hard to
>>>   get them to do it.    Please prove me wrong.
> 
> (Sadly, I have zero experience with COTS CA systems; I know too much about
> openssl at this point and would presumably be writing my own, in this
> position.)
> 
>>>   The most popular Enterprise CA software is the Microsoft CA.
>>> 
>>> 2) by using ACME to speak to a hosted CA.  Maybe WebPKI, maybe not.
>>>   Either way, getting otherName supported is even harder, because
>>>   nobody else uses it.
> 
> Is the concern the ACME protocol support or just getting the hosted CA to
> cope with it?  The former seems like something that we could make happen in
> the IETF, and the latter seems to have high overlap with point (1).
> 
>>> If we can't depend upon otherName being filled in, then we have to look for
>>> two things.  That means more code paths (two more) to test, more test
>>> vectors, and what exactly does an end point do when both are present, BUT
>>> THEY DO NOT MATCH?  So three more pages of text there.
>>> Remember, that just rejecting the certificate means that we have to send out
>>> a truck, which is what ACP aims to avoid, so that won't be popular.
>>> And of course, there could also be bugs (maybe even CVEs) in the code that
>>> tries to deal with the tie.
> 
> To be honest, this argument feels like a stronger one to me than the bits
> in the -24.  I'm still not willing to accept into the RFC Series a document
> that violates the rules set down by the specification for the technology
> it's making use of, but the refocus on the "running code" aspect is
> appreciated.
> 
> -Ben