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 <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
