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

[Eliot Lear <[e-mail]>]

Ok, so I just want to add that I have been able to populate otherName with garbage and have it get signed by a public CA.  My point is that at least some public CAs are loose.  If LE is important to this space, and if it’s really important, then this is not a solution.  Anyway, Here was the line that I used for my jabber server (it’s certainly not correct):

subjectAltName = DNS:www.ofcourseimright.com,DNS:upstairs.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:_xmpp-client._tcp.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:_xmpp-server._tcp.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;UTF8:ofcourseimright.com

And here’s what I got:

McNext> openssl x509 -noout -text -in jabber_ofcourseimright_com.crt 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            58:12:20:cd:47:fe:82:af:35:8d:75:50:75:05:a6:cb
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA
        Validity
            Not Before: Jun 18 00:00:00 2020 GMT
            Not After : Jul 18 23:59:59 2020 GMT
        Subject: CN=jabber.ofcourseimright.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9e:c8:c0:61:b6:5c:d1:fc:bf:2d:d2:13:6b:db:
                    97:09:45:e8:22:bf:89:24:7e:09:01:fe:91:37:85:
                    ee:25:77:54:92:68:05:07:d2:70:f5:6f:5c:fc:b4:
                    c6:7f:2d:e6:3e:11:68:4b:55:74:10:39:bc:1c:19:
                    3c:82:76:c1:76:ad:9b:6a:be:c3:be:35:dc:e5:5a:
                    48:95:2c:c9:9f:d7:68:c6:6f:83:b4:8d:c8:8a:0a:
                    b8:73:2e:10:c9:0e:a1:70:cb:a4:29:a0:b3:32:34:
                    72:69:9a:7d:20:35:9c:58:f1:a3:17:3f:fd:6f:22:
                    23:e5:58:24:65:56:38:51:6f:10:46:4b:77:fb:2d:
                    c9:5b:ca:db:8e:74:77:20:8b:b4:04:0a:63:75:03:
                    4c:be:19:9f:1f:9a:63:cd:9b:12:3e:b3:09:10:de:
                    d0:a1:d3:8b:bc:83:66:6a:4e:28:3c:5f:f7:ab:23:
                    a7:b6:da:46:59:21:eb:d7:ef:57:53:d8:72:be:55:
                    07:a5:95:c9:61:97:f7:39:c0:78:82:c0:1e:bd:53:
                    fc:ae:2c:6c:7a:c2:69:a0:c4:80:44:ac:b3:6b:f8:
                    01:fc:8f:ab:7e:8b:b8:24:0e:cd:7b:0e:74:94:77:
                    1c:4d:11:a2:d8:36:53:08:1a:d8:1b:fc:23:86:4c:
                    b3:f1
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:8D:8C:5E:C4:54:AD:8A:E1:77:E9:9B:F9:9B:05:E1:B8:01:8D:61:E1

            X509v3 Subject Key Identifier: 
                65:8C:F2:D4:46:7C:FB:D1:5E:62:BC:8C:70:B6:99:D0:95:4B:EB:98
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.6449.1.2.2.7
                  CPS: https://sectigo.com/CPS
                Policy: 2.23.140.1.2.1

            Authority Information Access: 
                CA Issuers - URI:http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt
                OCSP - URI:http://ocsp.sectigo.com

            X509v3 Subject Alternative Name: 
                DNS:jabber.ofcourseimright.com, DNS:www.jabber.ofcourseimright.com
            1.3.6.1.4.1.11129.2.4.2: 
                ......v...\..}h.....#....W|W..j..a:.i......r.e.......G0E.!...f...R...r.S...w.E%.}.J.i.M..... )................!.0...L.e.fs.Z..w.....7~.b....a...{7.V..&[...K.ATn...r.e.:.....H0F.!....~...V.....5F.h.\C.....e.'57.{.!.. 8.I...8...U.Y........f._.6..bb
    Signature Algorithm: sha256WithRSAEncryption
         1c:0d:7b:38:be:c5:b5:58:8e:0e:d9:7d:c8:90:9d:ea:29:94:
         de:a7:a1:11:db:1e:b7:9c:f8:25:48:da:2d:87:2f:76:0b:f8:
         ba:2d:72:49:87:50:3e:e2:9b:2f:a4:ab:61:24:8c:6c:65:c1:
         91:16:c2:7e:50:27:50:93:a8:36:38:ad:66:c4:e4:66:ae:2f:
         21:40:8f:41:f7:53:51:61:80:59:a8:2a:56:9b:9b:e5:85:a4:
         8b:6e:31:0b:b8:ca:4d:82:af:2c:34:83:25:2b:fc:94:05:28:
         f6:04:f8:96:61:3c:21:9b:11:13:48:1d:c0:77:c0:df:d3:47:
         ff:6e:d3:6a:66:eb:16:40:d7:45:67:a0:25:1d:9f:fa:7f:85:
         20:34:08:70:b2:3b:d5:b4:15:77:9b:d5:c0:4e:08:99:ce:24:
         fb:6e:c3:4d:a9:fc:ff:25:d9:09:d0:cd:e1:8b:69:c1:bb:f0:
         40:0a:ad:1b:36:4f:ba:a0:aa:e9:f1:af:cd:73:5a:2a:0f:8a:
         0d:04:ca:52:85:10:eb:d9:fe:85:6c:a6:ae:a3:de:04:a7:9a:
         e0:8c:5d:40:b6:1f:f6:f2:b1:d9:dc:f2:f4:fd:a8:f5:b4:25:
         80:c0:ec:84:1f:bf:02:e6:3d:0c:ca:41:d5:61:d9:a3:a2:c8:
         a0:f2:46:3c


Eliot
> On 17 Jun 2020, at 04: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
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima