tandardize this extension that so many
actors want or agree to.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
it as those are specific characters in an
XML streams).
I know that RFC5730 does the same thing, but it was written before PRECIS.
So now I think we should instead build on it.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
epp/authExt-1.0
'http://www.verisign.com/epp/authSession-1.0
but it was more for domain:update operations.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ultiple ways to implement things (and especially doing
validation or not).
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ed,
if we are up to "beefing up" handling of login in EPP we might as well take the
opportunity to enlarge the scope and take into account other mechanisms... like
2FA.
> These
> extensions were never published.
They were at some point (and they where implemented) a
this is not core EPP and hence we should defer to other RFCs
dealing with passwords for recommendations instead of trying to invent new ones.
This has nothing to do with the XML schema type.
And I am still not convinced that whitespaces are a problem here (again,
because the password is ente
RDAP are detailed before in many sentences.
So, in short, I am uneasy to say anything because I lack both context and
substance about what we are talking about.
Some examples of relevant work could also be useful.
--
Patrick Mevzek
___
regext mailin
rames per the schemas.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
, but for extended
features also.
I note in passing that there was always a way to extend authorization
mechanisms in EPP, for the domain:auth element.
I have never seen however any extension proposing there anything different.
--
Patrick Mevzek
__
ut
registry and registrar. I would favor changing the name of the extension and
removing Registry from it.
I lack good suggestions for now, maybe later. Policy Mapping? Metadata? Zone
Metadata?
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
eline
> for password length policies can be found in [reference
> here]”. A minimum length of 1 would ensure that the field can’t be
> blank, and the server can check if whatever is provided lines up with
> expectations for clients.
That sound perfect to me. Thanks Scott fo
ssue gracefully (that is enforcing something higher than 6, and not lower, if
they do define the space of characters allowed too).
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
asked by Pieter also I think) would be now a good time to think
about, and if we go towards some "extensibility" in authentication frameworks,
why not just build on existing RFCs?
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
d element... the message you describe is in the response of
a poll command by a client, and this poll command has none of that data you put
in the element of the server reply.
So while I see the underlying idea, I think you are bending RFC5730 quite a lot
to achieve it.
--
Patrick Mevzek
p
is not the case in these examples.
This latest idea from Martin and you is probably the best one we discussed
about as of yet, and if I could get convinced to add myself on the consensus
for it, I am still uneasy by how it uses RFC5730 structures.
--
Patrick Mevzek
p...@dotandco.com
___
sides would not be able to
gain any knowledge of the password used.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
o they needed a proxy
from TCP/700 and TCP/43 (but the whois problem is kind of solved if you switch
to RDAP)
- the .BE registry "recently" migrated all their systems in the cloud too (AWS)
so there is at least this solution that works.
See
https://www.dnsbelgium.be/en/news/first-euro
the element to
remove authorization information.
And associated schema:
>From my notes, and except if it changed recently, .NO uses this feature.
Related to passwords, I think there is nothing about the EPP one (client login).
But you have things like that:
- some registries mandate it to be changed on first login
- some registries mandate it to be changed at least in some frequence (ex: each
183 days).
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ed to implement the extension, it should be good if they
speak up. It could help reshape the design to make sure it accomodate more
cases.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
EPP
> extensions.
This is indeed more pragmatic. But all this mechanism to define which messages
to accept
will be outside the EPP protocol and this WG.
> I will participate this afternoon remotely. See you soon.
I will try to listen too, or be on Jabber.
--
Patrick Mevzek
p...@d
On Mon, Jul 16, 2018, at 17:41, Patrick Mevzek wrote:
> This is indeed more pragmatic. But all this mechanism to define which
> messages to accept
> will be outside the EPP protocol and this WG.
But please also remember that if we want to tackle this problem in a generic
way (and al
I said, this problem exists since EPP started so it is not new,
and it seems the current status quo fits most of the player (due to the number
of people
having participated here), so we are maybe devoting resources to trying to
design
something perfect... that noone will then u
he poll
messages,
because I think the problem is global and we should tackle it globally (or not
at all
and leave it at the current status quo).
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
"custom". So custom should be
dropped from core document. Same for privacy/proxy these concepts are not in
RFC5733, and should be handled in extensions.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailma
hat can be done to make that going smoothly?
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
s
hard to express in a regex
as the position does not matter.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
algorithm.
While indeed protocol 3 is the only value possible, the secDNS extension
could allow other value for flags even if 257 is the only one making sense, and
the only one used in examples.
Should we care to codify these limits?
Things may be different with CDS/CDSNKEY, I am not sure.
--
Patr
pported by some registries, like contact:id
Should that be handled or left to an extension?
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
can not be updated
if it would then become a glue without any IP or become an external host with
an IP.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
n I guess :-))
Not all registries accept all of these values (again you can argue they are not
following the standard, I am not judging that in one way or another just
letting people know what exists really today), so you might want to track that
in the regist
On Tue, Jul 17, 2018, at 09:33, Patrick Mevzek wrote:
> https://datatracker.ietf.org/doc/html/draft-gould-carney-regext-registry
I have hinted in the past that I believe another structure for the XML piece of
data about zone policies could provide more benefits, such as:
- by not hav
ystemd.time.html
With this example:
Thu,Fri 2012-*-1,5 11:12:13
The above refers to 11:12:13 of the first or fifth day of any month of the year
2012, but only if that day is a Thursday or Friday.
HTH,
--
Patrick Mevzek
p...@dotandco.com
___
re
;Data formats for files"
(which files? what data? why the format needs a specification and a working
group?).
"Registry mapping" and "Registry transition" will probably seem obscure to
anyone
outside of the working group. I am myself not even sure what it
to all of them.
It is kind of choosing in the X.509 world if you do one certicate with X
domains related or not on one side or on the other side doing X separate
certificates each one with one domain.
--
Patrick Mevzek
p...@dotandco.com
___
regex
ion enhancements that are often only discovered when implementations
are done.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
he use case, that have
implementations (at least started if not done already), that are generic (can
apply to more than one registry easily) and that fix/enhance current behavior,
before adding new behaviour.
--
Patrick Mevzek
p...@dotandco.com
have
more standardized handling.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ection such and such of RFC7997.
If your draft goes further in the process, I guess this issue will come again
at various last calls and reviews.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
yet being an RFC should be modified to adhere to the new
convention. I see no sensible reason to say to do it for some but not others.
So my opinion is to change the namespace everywhere and not let any new
extenson become an RFC without this change.
--
Patrick Mevzek
p...@dotandco.com
_
d
to encode all those features.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
hat regard or all are, whether they are already implemented somewhere or
not.
But after having expressed my concerns, I will not push further on this and
just remain in agreement with Martin's first message on the issue.
--
Patrick Mevzek
p...@dotandco.com
___
ed to the amount
of energy devoted to each extension, which extension becomes working group
documents
and which extensions really solve problem of more than one registry and hence
may have the chance to be implemented by a sizeable chunk of current players.
HTH,
--
Patrick Mevzek
_
eminder
> in this EPP draft.
I agree with James, for better or worse, no other EPP documents go into such
territories
as leap-second and this specification is no more "time" oriented than the others
so it makes no specific sense to start here talking about leap seconds.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
hat left out all complicated cases, and hence the
implementation will not be widespread.
The fact that no registry claimed to be willing to implement it or to write an
extension for their own policy is very troublesome for me. But maybe it
happened in private or will be announced in the futur
eed to try to "accomodate" if we want success both in term of
numbers of implementations and avoiding fragmentations (where multiple
extensions exist to do exactly the same thing in fact).
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
t, and I can always
comment later on the documents I would have time to work on.
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
nside also solves the problem above
of the fact that they are defined differently and the value inside of extValue
should convey only client-provided content, while the "top" value can be more
freeform.
Thanks for your consideration.
--
Patrick Mevzek
p...@dotandco.com
_
that are not related)
And maybe provide some advice about downgrade, what about the following chain
of events:
- change of password using loginsec:newPW for a long password
- but then change back to short password using pure newPW without the loginSec
part.
Allowed? Recommended?
--
On Sun, Jan 6, 2019, at 23:02, Patrick Mevzek wrote:
> Hello James and Martin,
Thanks for your attention and comments to my email.
I see that we are in disagreement, so I think it is not useful for me to go
again over all points.
My opinion still remains that at this stage the draft abu
participate in this polling, even
if I clearly have my opinion on which documents are most useful to work on than
others and which should get the WG attention or not.
That is the end of my rant.
--
Patrick Mevzek
p...@dotandco.com
___
r
tware implementation of its client part (namespace
version 0.2 and soon 0.3), and I am willing to continue support this
implementation based on document changes,
and provide review and feedback as needed during course of its implementation.
--
Patrick
roper and full RDAP support in the
future, I will try to give more meat as implementor feedback later, without any
ETA on this.
Hope that helps at least a little,
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
htt
act negatively any operation done
outside
of ICANN circles.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
e amount of work, but second option seems better to me
for multiple reasons.
And again, there is a huge non technical difference.
If we give again the impression to change the EPP just to suite gTLD needs,
we should not lament later on the state of EPP worldwide and why not everyone
follows the sta
on "postalAddr", etc.
And again, if a new contact schema appears, registries that want it use it,
those that want to keep the current contact-1.0 keep it, and all is fine
(besides the complexities for registrars, but obviously they will have
to deal with it in any way, placeholders introduce their own complexities
as they will be hardcoded in every piece of code, so that the value is
not offered for edition for example, etc.)
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
same problem of (non technical but possible
confusing) collision.
And more generally, "tech" is too short to convey enough meaning just by itself.
In general I also fail to see what we gain by using short names.
Why not application, technology and ope
rent greeting/login).
Like SRP and the example of RFC5054 "Using the Secure Remote Password (SRP)
Protocol for TLS Authentication".
Or at least, like I suggested on the policy extension, but that was not meant
with a lot of enthusiasm, to implement S
nsion risks
for now the fact that not a lot of registries will implement it.
Each extension should try to stand-alone as much as possible...
Otherwise in your current setup a registry needs to implement this extension,
the core policy one, and then the extension on the policy one. I have low h
n other cases, it would be good to see other registries/registrars voice
their opinion, or even better implement it or something else or explicitely not
for some reasons, etc.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
om the Unicode Latin script
- at least one uppercase, one lowercase, one digit, and one punctuation
character (in no specific order)
- no repeated sequence of two or more characters
- no given character repeated in sequence
- between 17 and 33 characters long in total
--
Patrick Mevz
they can not use it in their case). This is exactly
why the world of EPP extensions is so fragmented. But I will rest my case here.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
rching on the obvious title.
Thanks in advance,
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
s not dealing with only one gTLD
(because even if it exists I doubt that one could mandate all gTLD registries
to accept this CA and only this CA as it is a matter of trust and transitive
trust, so why should any gTLD registry trust unconditionnaly this new CA?)
--
Patrick
n
> external resource (e.g., url) that defines the password policy
> information?
That would then be only for human consumption, an EPP client won't be doing
anything with it, so providing that URL through EPP does not provide any gain
I b
-dataset/
>
> Information about remote participation:
> https://godaddy.zoom.us/j/958439027
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
--
Patrick Mevzek
p...@dotandco.com
_
least the
related issues:
- registry lock services
- the whole transfer process (since authInfo serves only there), taking into
account
that there may be rules applied to all gTLDs by virtue of their common
contracts,
but then there are all the other registries.
t decide per local
policies?
- a mention/discussion of RFC7613 would seem appropriate
- more generally working today on authentication should be based on SASL and
we should open things better and with more extensibility. This extension is just
piggybacking on the current scheme which creates its own range
tries to take into account all existing
cases in the wild, not a subset of them. I have tried to show that the draft
presented
just forgets about existing cases, which could hinder its wide adoption.
--
Patrick Mevzek
p...@dotandco.com
___
rege
ing, that specific behavior I described existed but ceased
to recently when the registry changed its backend (now any single
operation on a domain in a bundle does the same operation for all other
domains in the bundle - that clearly solves the "batch" problem but then
exposes to
r not.
But I would at least suggest that the draft is clearer on what it defines,
policy or format.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
even the IETF. It may be a better fit for some ICANN groups, in order
to deliver some "consensus policies" document (but remembering also at the same
time that there is a world outside of gTLDs). In my view the whole process
around
tr
d in RFC
2026 [1] with a two-tier maturity ladder. Specifications become
Internet Standards through a set of two maturity levels known as the
"Standards Track". These maturity levels are "Proposed Standard" and
"Internet Standard".
--
Patrick Mevzek
think the contact information comes because of §3.1
So it seems useful to have, but then why not say contact information is useful
for all other bootstrap documents (domain, IPv4, IPv6, etc.) also?
This would mean an 7484-bis, so again quite some work.
What do people havi
me criteria to help in future cases) is of
interest
to anybody and some work is started on it, I would be interested to join this
effort.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
a specific time window.
The biggest drawback is that in this scheme the current registrar may not have
any
explicit guaranteed way to oppose any outgoing transfer (because some changes
outside of
it could be enough to authorize the transfer)... except that is what
the status clientTransferProhi
S from DNSSEC.
- please stick to RFC2606 when choosing names for examples (ie: do not use the
TLD .tld)
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
is fine. But clearly bike shedding at
this point.
Will try to read the draft more deeply later for substantive feedback, if any.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
eneric Registry-Registrar Protocol Requirements"
or
RFC 7485 "Inventory and Analysis of WHOIS Registration Objects"
that were written before any work took place.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
rious
non-ASCII space code points, many of which are difficult to
reproduce across different input methods.
(note also RFC8264 §5.3 for a discussion about spaces)
I am still of the opinion that we should have used/referenced that work more.
--
Patrick Mevzek
p...@dotandco.com
the
issue again, I was just leaning towards Barry's opinion that the constraints are
"strange" (yes they come from the XML schema datatypes, but that does not define
the semantic of the field, which is not just an XML token, but really a
password,
which is all the discussion of PRECIS
o that you have at least a timestamp. IANA registration could at
least include a timestamp (when the extension was registered)
PS2: seeing that all of the above come from the fact that we are basically
trying to reinvent XML namespaces but in JSON... and arriving at the situation
where we get al
am interested to work on this if anyone else is also. I might try to offer
a proposal at some point, not sure.
During discussions of this draft, I pointed to SASL for the extensibility it
provides,
but this was apparently not a good fit for this specific extension.
--
Patrick Mevzek
ust making sure
you handle as little sensitive information as needed, and then secure the rest.
Having clear text passwords at the protocol level is definitively not
a MUST for the protocol to work correctly, the protocol could work with other
ways
to authenticate, eliminating the sensitive part of the in
r
(no matter what the transport; and do remember that EPP ought to be transport
agnostic, and there were attempts in the past to have it over SMTP for example,
in fact at least one registry has it that way nowadays...)
--
Patrick Mevzek
p...@dotandco.com
_
of security) but not with the mean (I think we
must go further than just allowing longer passwords, just this adds only
marginal extra security by itself).
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
to happen
earlier,
but that is the past behind us.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
with various warts the current situation.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ep their own
database in sync.
> However many clients seem to send
> just about always and they would need to adjust.
There are as many broken clients as they are broken servers...
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing l
security.
I remain in another side: other solutions, instead of passwords, should be
found.
Continuing to use passwords when other (better) solutions exist is not an effort
I find useful.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
how many
hitpoints it has.
And the above list is far from being exhaustive...
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Hello Scott,
On Fri, Dec 20, 2019, at 13:04, Hollenbeck, Scott wrote:
> > -Original Message-
> > From: regext On Behalf Of Patrick Mevzek
> > Sent: Friday, December 20, 2019 12:14 PM
> > To: regext@ietf.org
> > Subject: [EXTERNAL] Re: [regext] How to h
etf:params:xml:ns:idn-1.0
See the lack of version numbers in the schema URI provided,
but not for all of them :-).
This can be deemed a direct violation of the protocol,
but registrars still have to deal with it in some way.
--
Patrick Mevzek
p...@dotandco.com
__
.
Unfortunately.
Or fortunately :-)
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
draft as it stands completely address the issue.
[1] TL;DR: a registrar has no way to automatically discover
a registry is using the mechanism outlined in this document,
as not announced in the greeting part.
--
Patrick Mevzek
p...@dotandco.com
___
r
s
attached to the domain, or its expiration, etc.)
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
onses, and no document, even BCP, will make
registries change behavior, if there are no good reasons/generic
framework/clear push
from registrars that are very silent in this WG/etc.
Maybe at some point, as controversial it might be, it would make sense to start
working
on "epp-2.0" or
n bothering sending it?
I will leave it at that for now, and see further discussions if the
draft is adopted by the working group.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
ap-deployfindings)
as I have not being able yet to release anything for my own free one under free
time.
But not sure it would add value to the document. We can discuss that separately.
--
Patrick Mevzek
p...@dotandco.com
___
regext ma
On Thu, Jan 23, 2020, at 01:01, Patrick Mevzek wrote:
> 2) for the login security draft I said from the beginning that instead
> of just relaxing the limits on password length, we may want to use
> more standardized methods such as SASL, and in particular there are mechanisms
> to
On Mon, Mar 16, 2020, at 09:28, Gould, James wrote:
>
> One question that was raised by Patrick Mevzek on the mailing list was
> associated with signaling the implementation of a BCP by the server
> that I believe would also apply to the client. This question applies to
> the
101 - 200 of 248 matches
Mail list logo
