; should be in positive language
only. Most of the language is what not to do. I think that this is
important to list, but I suggest it be split up into a section "Do this"
and a section "Do not do this"
--
Michael Richardson. o O ( IPv6 I
wsers, 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.
quot;diff RFC"?
If you mean, rfc6125bis, then it seems like it would risk opening wounds.
But, wholesale, "replace section X with " might be useful.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
n to introduce a document about this issue. I think that
it's something that only the IETF can do. Perhaps that would fit into this
UTA document, or perhaps parts of this section 15 goes into another document.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consultin
p in getting external to the IETF review
of this profile.
When/if we are ready, I think that DANCE should be asked to review.
but, yes, let's discuss more.
I'll try to send some proposed text in the next two weeks.
Even if it doesn't go into this d
e TL;DR summary is: "don't shoot yourself in the foot" :-)
Or, be tolerant of things you don't understand.
I agree that it needs a road show to bring this to many other verticals, but
I think that ultimately, those other entities are looking to us to give them
something
Viktor Dukhovni wrote:
> I don't presently see a need to rush TLS 1.2 to the exit. Where
> practical, this is happening steadily and naturally. The carrot is
> working, we can defer the stick.
+1
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sand
no point in talking
about any kind of opportunistic mode.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
pgpWw0kbnmSZW.pgp
Description: PGP signature
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
tween clients and servers,
that
> it will be very difficult to do better than OE.
I really think it's important that people not think of OE as a step towards
something else.
If plaintext is unacceptable, then it's not OE: it's DANE signaled
SMTP(STARTTLS), or ...
--
Micha
ally confirm that you are content for
> your name to
> appear when this is published as an RFC. (also applies to contributors).
I agree.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Descript
KI, Matter, OPC-UA, EAP-TEAP-BRSKI, ...) to replace any IDevID with
otherName:EUI64 identity with a proper name that would fit into SNI.
4. Find a sensible way to extend RFC6066 to accomodote other forms of SNI.
There isn't an IANA registry for this.
--
Michael Richardson. o O ( IPv6
some push to do something SNI
compatible, which means it has to look like a dNSName.
> So, please: Is it about direct EUI64 support in x509? Or about omit
> EUI64 in device certificates?
This is about what SNI supports vs what X509 supports.
--
Michael Richardson. o O ( IPv6 IøT
bHmU/
I think that ietf-uta-tla13-iot will go with no EKUs in certification
authorities: useless bits for constrained IoT networks.
>> On Nov 18, 2024, at 10:28 AM, Michael Richardson
wrote:
>>
>> Signed PGP part
>>
>> Are Extended K
e to cloud communications.
As I recall, we made a conscious decision not to make any quantum-safe
recommendations.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
ht from the beginning. and that the AD was overreaching)
BTW: A MUST with an otherwise clause, is to me, a SHOULD.
(Also, what's a non-default option. Either it can be negotiated, so it's
on by default, or it won't be negotiated, so it's really off.)
--
Michael
g TLS 1.3 likely outweighs the minor problems of one use-case
> who chooses to ignore that mandate.
That's fine, just please don't ask us to revise a 5yr old protocol, which we
are extending, and which already says, "please do TLS 1.3 if you can" with
"MUST do TLS 1
s13.
Vendors violate MUSTs all the time; customers can use RFCs as big hammers to
insist. It really does happen.
But, MUST do TLS 1.3 implies (to me), do *NOT* (refuse to) do TLS 1.2.
The only way to allow (MAY) TLS 1.2, is for TLS 1.3 to be SHOULD.
--
Michael Richardson. o O ( IPv6 IøT consult
an AD telling us that we need to reflect uta-require-tls1.3
in our
document, but really, we do as good a job as we can.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
__
Michael Sweet wrote:
>> On Apr 10, 2025, at 11:24 AM, Michael Richardson
wrote:
>> ...
>> But, MUST do TLS 1.3 implies (to me), do *NOT* (refuse to) do TLS 1.2.
>> The only way to allow (MAY) TLS 1.2, is for TLS 1.3 to be SHOULD.
> You can say
Peter Gutmann wrote:
> Some sort of qualification like that would be my preference as well. I
don't
> think I've ever encountered TLS 1.3 in SCADA (I mean, there's still a lot
of
> TLS 1.0 out there that people are struggling to move to TLS 1.2), so you
could
> just as easily s
ol development time) that there are deployment
considerations, what are we supposed to write?
Finally, how is:
"You MUST Unless you can't"
not literally what SHOULD is.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc,
go with MUST 1.3+MAY 1.2
I'm all for telling everyone to do TLS 1.3.
I do not think this document is helpful.
I think it might be actually harmful.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldw
seful.
Anyway, it's much easier to make an RFC a performance specification (a trade
term about RFPs) when the document doesn't depend upon some parties just
ignoring the MUSTs.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and
Salz, Rich wrote:
>> 1. How do I cite the CABFORUM WebPKI set of anchors.
>> Does it have a clear name? (Because it's not identical on all
platforms/browsers/libraries).
> I am pretty sure that there isn't one. Instead, each trust store
> operator (e.g., browser vendor) is suppos
to reduce the risk of
> unintended certificate mis-issue").
Yes, so it defends against an attack that is never actually named.
At best, I guess this is a "mis-issue attack"
Thank you for the pointer though.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman
with
devices. With the tradeoff against flexibility.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Uta mailing list -- uta@ietf.o
Alan, are you waiting for the authors to say, "Please publish this document"?
If so, please publish this document.
___
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le...@ietf.org
27 matches
Mail list logo
