Re: [pkix] way forward for 5280

["Polk, William T." <william.polk at nist.gov>]

Title: Re: [pkix] way forward for 5280

Jean-Marc,

I have asked David to include a fix for section 7.3 in his clarifications draft. We are limiting the document to 
technical issues identified during the creation of the implementation report, but it makes sense to address
the ambiguity in 7.3 as well, since this is a feature where the implementation report could not demonstrate 
interoperability.

I did not think it is appropriate to include your second change, since it is unrelated to the implementation 
report.  I also see it as largely editorial, rather than technical - there is no debate about  the text, simply
where it would be best placed.  (As a side note, I think the text highlights a deployment issue rather than an 
Implementation decision, so security considerations may be the right place after all.)

Thanks for keeping this one on our radar.

Tim 


On 11/18/09 8:53 AM, "Jean-Marc Desperrier" <jmdesp at free.fr> wrote:

> Stephen Kent wrote:
> > As noted in the meeting minutes, we need to make a minor revision to RFC
> > 5280, so that it can progress, based on the implementation report
> > generated by David Cooper.
>
> If so, it would be a good time to include some other minor remarks.
>
> First, the one I made in the following message
> http://www.imc.org/ietf-pkix/mail-archive/msg05602.htm about paragraph
> "7.3 Internationalized Domain Names in Distinguished Names".
>
> The change I'm suggesting would make the standard more logical, as well
> as easier to both understand and implement. The current difference in
> IDN handling between 7.2 and 7.3 is just a quirk.
> Also according to the implementation report, nobody implemented the IDN
> rules yet, so the change would have no consequences on implementations.
>
> Second, there's a paragraph inside "8. Security Considerations" that is
> not a Security Consideration, it's a recommendation for the format of
> certificate. And as a consequence of being inside the wrong paragraph,
> it's easily missed by implementers (yes, implementers should read
> Security Considerations carefully. But the fact is they don't):
>     CAs SHOULD NOT include URIs that specify https, ldaps, or similar
>     schemes in extensions.  CAs that include an https URI in one of these
>     extensions MUST ensure that the server's certificate can be validated
>     without using the information that is pointed to by the URI.  Relying
>     parties that choose to validate the server's certificate when
>     obtaining information pointed to by an https URI in the
>     cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess
>     extensions MUST be prepared for the possibility that this will result
>     in unbounded recursion.
>
> I think some other placement should be found (4.2.3. Rules for URIS in
> extensions ?), *and* there should be a specific reference to it in the
> extensions that are most affected, that is cRLDistributionPoints,
> authorityInfoAccess, and subjectInfoAccesses.
> _______________________________________________
> pkix mailing list
> pkix at ietf.org
> https://www.ietf.org/mailman/listinfo/pkix