Sorry that this email is three weeks old. I felt that it deserved a proper reply.
Eliot Lear <lear=40cisco....@dmarc.ietf.org> wrote:
> The issue for me is library support. If libraries take the doc too
> seriously, it screws the apps that really need to do the right thing
> for their use cases.
I partly agree.
There are two parties here:
1) the validating end
2) the long-lived certificate end
The long-lived certificate end might have a SAN-less (an "insane certificate"?)
certificate, but it does not typically validate that.
So, the thing that we are worried about is the validating end that is subject
to regular updates. It might be built decades after the certificate end.
Note that it needs a trust anchor to be able to validate the
long-lived-certificate,
or nothing works.
Can we agree that this is therefore *not* a simple call to "libcurl"?
I've been through this on Android and iOS and once you need to introduce the
new trust anchor, you get into the much more harry aspects of the API.
The parts of the API where you actually have to say how to you are validating.
It seems extremely unlikely that it would be validating with CN-ID in that
case. (Many of us in IoTSF ManySecured WG are trying to find a way to easily
validate via current DNS-ID rules)
What I'm saying is that I think that your strawman does not hold water.
(Is that the right idiom?)
> Let's turn the question around, because perhaps I am missing something.
> Bearing in mind that there are literally hundreds of millions of
> devices with long-lived certificates fielded today, what advice would
> you give to those who support applications that have to interact with
> them? What harm comes to any use case for there to be a non-default
> library flag, as Victor mentioned there is with OpenSSL?
The default is that you get the stock verification function.
The non-default case is that you provide your own verification function.
There actually isn't really anything else in between.
> Causing the app developers to write their own X.509 validation code –
It's where they already are.
> To Jim’s point, maybe it would be possible to say that the flag should
> be unavailable for certs issued after a certain date, but that date
> would have to be well into the future, and coordinated at least with
> IEEE. That seems like a lot of work for something that, as Rich
> rightly alludes, is really a vendor decision to intelligently make.
Should some of these non-DNS-ID (and also non-CN-ID) verifications become
common place, I can see that one might want to have a policy OID in a CA
certificate that informed a library how it "ought" to verify. Perhaps that
is already a thing.... probably...
(I remember drinking a lot during pki4ipsec WG, but not much else about it)
Eliot Lear <lear=40cisco....@dmarc.ietf.org> wrote:
> Actually, according to 802.1AR-2009, the subject MUST contain requires
> a DN with serial number, and it may contain a SAN (e.g., don’t count on
> it). That’s the major concern. To me, the rest is really negotiable.
I have built IDevID certificates with SANs, with via public anchors,
but they aren't long-lived.
So the only way we get into trouble is when the application specifies a
private trust anchor, asks for CN-ID/DNS-ID validation, and the certificate
is long-lived.
CABFORUM trust anchors are supposed to be limited to 13 months now
(if issues after September 2020), and I believe that this duration is now
getting baked into browsers, and I assume some libraries.
(someone will correct me if I'm wrong)
So, *today* in order to combine:
a) long-lived IDevID signed by private-CA
b) CN-ID verification
c) private-trust anchor
The application developer already needed to tweak flags.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
