Re: [Technical Errata Reported] RFC6844 (4922)

On 03/02/17 15:48, Sean Turner wrote:
> Yeah I mean throwing in the 2119-like "must not” in there seems more
> like a change to me to.

Done.

S.

> 
> spt
> 
>> On Feb 3, 2017, at 09:53, Stephen Farrell
>> <[email protected]> wrote:
>> 
>> 
>> Hi all,
>> 
>> That strikes me, not as an erratum, but rather as a change request.
>> IIRC, that specific issue was debated at the time so the text in
>> the RFC is not an error, no matter whether or not one considers it
>> a good or bad idea.
>> 
>> On that basis I think this ought be rejected as an erratum, and if
>> folks wish to fix this, they ought write an Internet-draft that
>> updates RFC6844 and pursue publication of that through the normal
>> processes. (I'd suggest the lamps WG [1] mailing list might be a
>> good venue for any initial discussion as to the desirability of
>> that kind of thing.)
>> 
>> Cheers, S.
>> 
>> [1] https://tools.ietf.org/wg/lamps/
>> 
>> 
>> On 03/02/17 14:18, RFC Errata System wrote:
>>> The following errata report has been submitted for RFC6844, "DNS
>>> Certification Authority Authorization (CAA) Resource Record".
>>> 
>>> -------------------------------------- You may review the report
>>> below and at: 
>>> http://www.rfc-editor.org/errata_search.php?rfc=6844&eid=4922
>>> 
>>> -------------------------------------- Type: Technical Reported
>>> by: Attila Bruncsák <[email protected]>
>>> 
>>> Section: 4
>>> 
>>> Original Text ------------- The search for a CAA record climbs
>>> the DNS name tree from the specified label up to but not
>>> including the DNS root '.'.
>>> 
>>> Corrected Text -------------- The search for a CAA record must
>>> not climb the DNS name tree from the specified label up.
>>> 
>>> Notes ----- Obviously it does not make any sense to climb up. If
>>> there would be CAA record published for the "com" TLD, than it
>>> would make what relation to the CAA of the "example.com" domain?
>>> From an other viewpoint: all CAs are going to check the "com" TLD
>>> for CAA record if a given organization has no CAA record
>>> published in its own domain? Another, more practical example:
>>> "example.com" needs a certificate for his top domain
>>> (https://example.com/), so it decides to publish the CAA record
>>> to enforce the security. Doing this it may unknowingly affect the
>>> renewal of the certificate for the wellhidden.hr.example.com
>>> where the hr.example.com domain is under different administrative
>>> authority than example.com domain itself.
>>> 
>>> Instructions: ------------- This erratum is currently posted as
>>> "Reported". If necessary, please use "Reply All" to discuss
>>> whether it should be verified or rejected. When a decision is
>>> reached, the verifying party can log in to change the status and
>>> edit the report, if necessary.
>>> 
>>> -------------------------------------- RFC6844
>>> (draft-ietf-pkix-caa-15) -------------------------------------- 
>>> Title               : DNS Certification Authority Authorization
>>> (CAA) Resource Record Publication Date    : January 2013 
>>> Author(s)           : P. Hallam-Baker, R. Stradling Category
>>> : PROPOSED STANDARD Source              : Public-Key
>>> Infrastructure (X.509) Area                : Security Stream
>>> : IETF Verifying Party     : IESG
>>> 
>> 
>> _______________________________________________ pkix mailing list 
>> [email protected] https://www.ietf.org/mailman/listinfo/pkix
> 
>

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix